A note on /dev/raw1394's security implications: 1. You cannot access local memory through raw1394, except for ROMs and CSRs that are exposed to other nodes any way.
2. It is extremely hard to manipulate data on attached SBP-2 devices (FireWire storage devices). 3. You can disturb operation of the FireWire bus, e.g. creating a DoS situation for audio/video applications, for SBP-2 devices, or eth1394 network interfaces. 4. If another PC is attached to the FireWire bus, it may be possible to read or overwrite the entire RAM of that remote PC. This depends on the PC's configuration. Most FireWire controllers support this feature (yes, it's not a bug, or at least wasn't intended to be one...) but not all OSs enable the feature. This feature is called physical DMA and is enabled by Linux' ohci1394 driver per default. It speeds up SBP-2. Linux' sbp2 driver does not work correctly without physical DMA at the moment. Some slides: http://md.hudora.de/presentations/#firewire-pacsec http://md.hudora.de/presentations/#firewire-21c3 Jody McIntyre's plans to improve raw1394's security: http://thread.gmane.org/gmane.linux.kernel.firewire.devel/6395/focus=6395 Neither Jody nor anybody else got around to implement these ideas yet. I hope to get sbp2 to work correctly (if slowly) without physical DMA too. Furthermore I am thinking about implementing filtered physical DMA for SBP-2. -- use /dev/video1394, not /dev/raw1394 https://launchpad.net/bugs/6290 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
