Messages in this thread | | | Date | Fri, 08 Feb 2008 20:38:04 +0100 | From | Stefan Richter <> | Subject | remote DMA via FireWire (was Re: [git pull] x86 arch updates for v2.6.25) |
| |
Bernhard Kaindl wrote: > Regarding security: > > On the software side: The new fw-ohci driver seems to allow physical DMA only > to devices which pretend to be FireWire disks (it is the specified way to > transfer the data) ...
To be precise, firewire-sbp2 tells firewire-ohci to open up the physical response unit (which implements the remote DMA feature) for the target node from when it tries the SBP-2 login until when it completes the SBP-2 logout or the target is plugged out. Let's call it filtered physical DMA.
A mode which doesn't require the physical response unit could be implemented in firewire-sbp2, but this would come with a considerable overhead regarding code, runtime CPU usage due to huge interrupt handling load, and additional runtime memory footprint.
The older sbp2 driver relies on unfiltered physical DMA, hence is less secure. There can be a mode selected at compile time to run without physical DMA, but that's buggy and implemented in a way which is not portable.
The only reason why we don't have an SBP-2 initiator which works without remote DMA is that nobody is bothered enough to either debug that mode in the old driver or implement it in the new driver. Besides, we could rather trivially add filtered physical DMA to the old sbp2/ieee1394/ohci1394 stack but nobody took the time to do this yet either.
> With FireWire enabled by the BIOS, a hacker could (in theory) load his > own operating system into the system RAM and boot it ...
x86 BIOSes don't initialize OHCI-1394 controllers up to the point that its physical response unit were working remote nodes were granted access to it.
Apple's OpenFirmware implements SBP-2 initiator but I don't know if it uses the physical response unit. But this point is moot --- you can boot from SBP-2 targets. -- Stefan Richter -=====-==--- --=- -=--- http://arcgraph.de/sr/
| |