3 ms·
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
by Hello71 11y ago
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]
[0] http://cateee.net/lkddb/web-lkddb/FIREWIRE_OHCI_REMOTE_DMA.html http://cateee.net/lkddb/web-lkddb/FIREWIRE_OHCI_REMOTE_DMA.h...
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=080de8c2c57e3199eee837fe8b6d35a43679f8c1 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8bc588e0e585bc9085df75e84d4d5635f45cf360 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
[3] http://search.gmane.org/?query=firewire&author=John+Nagle http://search.gmane.org/?query=firewire&author=John+Nagle
[3] http://search.gmane.org/?query=dma&author=John+Nagle http://search.gmane.org/?query=dma&author=John+Nagle
- zdw 11y agoAre these protections active before the kernel has booted? Does DMA default to be off until enabled? If firewire (and thunderbolt, expresscard) aren't DMA-free by default, then there's a time window before/during boot in which an attack could happen. Full disk encryption/TPM/Secure Boot could help mitigate this though.
- exceptione 11y agoI am wondering myselves too. 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. from: https://ieee1394.wiki.kernel.org/index.php/Release_Notes#Linux_3.14 https://ieee1394.wiki.kernel.org/index.php/Release_Notes#Lin... 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…
- Animats 11y agoIt'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.