Cc: H. Peter Anvin <hpa@...>, John Stoffel <john@...>, Linus Torvalds <torvalds@...>, Maxim Levitsky <maximlevitsky@...>, Ingo Molnar <mingo@...>, <linux-kernel@...>, Andrew Morton <akpm@...>, Thomas Gleixner <tglx@...>
...
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.
...
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/
--
