Bug 7794 - sbp2 requires ohci1394 to be loaded in insecure mode
sbp2 requires ohci1394 to be loaded in insecure mode
Product: Drivers
Classification: Unclassified
Component: IEEE1394
i386 Linux
: P2 normal
Assigned To: Stefan Richter
Depends on:
Blocks: 10046
  Show dependency treegraph
Reported: 2007-01-08 15:07 UTC by Stefan Richter
Modified: 2008-02-19 12:12 UTC (History)
0 users

See Also:
Kernel Version: all
Tree: Mainline
Regression: ---


Description Stefan Richter 2007-01-08 15:07:11 UTC
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.

Solution 1:
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
unfiltered DMA.

Solution 2:
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).
Comment 1 Stefan Richter 2007-01-08 15:08:26 UTC
It is not advisable to waste time on bug 6393 before this one.
Comment 2 Stefan Richter 2007-07-05 11:53:38 UTC
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.
Comment 3 Stefan Richter 2008-02-19 12:12:48 UTC
There are currently no resources to fix this in drivers/ieee1394/.
drivers/firewire/ does not feature this problem.

Note You need to log in before you can comment on or make changes to this bug.