remote DMA via FireWire (was Re: [git pull] x86 arch updates forv2.6.25)

[Stefan Richter]

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/