Due to bug 6393 and lack of portabable DMA mapping, sbp2 is currently only
working if ohci1394 was loaded with the parameter phys_dma=1, which is the
default. This parameter enables the so-called physical response unit of an
OHCI-1394 host adapter which lets remote nodes read and write the lower 4GB of
the host bus address range --- without assistance of the interrupt handler. This
feature is nice for SBP-2 performance and also has applications in remote
debugging and forensics, however it is also a security risc.
Add dynamic phys_dma filtering to ohci1394 + sbp2. This should be fast to
implement, more secure than unfiltered physical DMA (only SBP-2 targets will be
allowed to talk to the physical response unit), and as well performing as
Internally to sbp2, implement a mapping of virtual addresses or DMA-mapped
addresses to FireWire bus addresses and run all transfers via the normal
asynchronous response unit. This is harder to implement, most secure (since no
node at all needs to be allowed to talk to the physical response unit), and
badly performing (since each FireWire packet will generate an interrupt and will
probaly involve a memcopy).
It is not advisable to waste time on bug 6393 before this one.
New plan: See how it goes with the new firewire stack. If it doesn't turn out
all bad, switch this bug to WILL_NOT_FIX.
The new stack implements dynamic physical DMA filtering. Kristian mentioned he would be interested to also implement Solution 2 for the new stack in the long term.
There are currently no resources to fix this in drivers/ieee1394/.
drivers/firewire/ does not feature this problem.