FireWire is a vulnerability for Linux only because the kernel maintainers want it to be. There's a register in FireWire controllers which controls the address range for which remote memory accesses are valid. It can be set to 0, which locks out that function. The last time I looked, years ago, it was set to allow access to the first 4GB of memory, because the code pre-dated 64 bit systems.
I once proposed setting it to 0. This was rejected because there are kernel debuggers which use it.
Linux has, in fact, supported a configuration option CONFIG_FIREWIRE_OHCI_REMOTE_DMA (default n) since 2.6.26 released 13 July 2008. [0][1] In kernel 3.14, this was changed into a module parameter (default n). [2] I did not further investigate the status of firewire modules before then.
I was unable to locate any relevant mailing list posts referencing "firewire" or "DMA" by the author "John Nagle". [3][4]
It's been over a decade since I looked at this. I wrote a FireWire camera driver for QNX around 2003, and looked at Linux to see how they did it. At that time, the upper limit for external memory requests was a hard-coded constant. The config parameter came later. I think this was discussed on USENET, but I can't find it right now.
FireWire doesn't really have "DMA", anyway. It has some auxiliary functions to let the network controller get and set single memory words, one word per packet request/response. All bulk transfers use a different mechanism, which works more like an Ethernet controller, shipping blocks around into receiver-designated buffers. The "memory access" function is in there as a way to send commands to devices. This thing was designed by people who thought that storing bits into a control register was the proper way to talk to a dumb device. In practice, dumb devices now have some small processor, and the "memory access" function ends up being processed by a switch statement, to do "turn camera on" or some such function. There's no real reason for a PC-scale machine to need the DMA functions enabled, except for kernel debugging. That should be permanently disabled in all production systems.
Thunderbolt, on the other hand, apparently really exposes memory on an external cable as a normal function. That's how it extends the PCI bus to external devices. Not good for security.
The new module parameter "remote_dma" (default = N, enable
unfiltered remote DMA = Y) replaces the former build-time
option CONFIG_FIREWIRE_OHCI_REMOTE_DMA. (This kernel
configuration option was located in the "Kernel hacking"
menu, item "Remote debugging over FireWire with firewire-
ohci".) It is therefore now possible to switch on RDMA at
runtime on all kernels with firewire-ohci loaded or built-in,
for example for remote debugging, without the need for a
custom build option.
I am not an expert in these matters, but could it be that OP is wrong with regarding to firewire? From what I am reading here is that dma is off by default, and can only be activated at runtime.
If the OP is right about the need to disable firewire, I hope someone could explain why so…
I once proposed setting it to 0. This was rejected because there are kernel debuggers which use it.