Red Hat Bugzilla – Bug 201947
No firewire support.
Last modified: 2008-09-23 22:29:25 EDT
Description of problem:
No support for firewire devices is included in the current kernel.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Our research group has a specific device that is firewire-only, and requires not
only firewire support, but also the raw1394 module. The device works perfectly
on every distribution we've tried (including Fedora Core 4) except for RHEL 4
(the distribution we *pay* for), even after attempting to recompile the included
kernel with firewire support.
Are there any plans to include this support, or any workarounds offered to add
in this support via modules? Will we have to wait until RHEL 5 for firewire
support to be included?
We don't support firewire in rhel4 due to concerns about its stability. It is
highly unlikely that it will be supported in the lifetime of rhel4. I'm not sure
As far as the IEEE 1394 drivers in upstream Linux are concerned, there are not
only stability issues but also security concerns. Cut and paste from what I
wrote elsewhere about raw1394 and ohci1394, slightly edited:
A note on /dev/raw1394's security implications:
1. You cannot access local memory through raw1394, except for ROMs and CSRs that
are exposed to other nodes any way. (But see 5.)
2. It is extremely hard but to manipulate data on attached SBP-2 devices
(FireWire storage devices) via raw1394.
3. You can disturb operation of the FireWire bus via raw1394, e.g. create a DoS
situation for audio/video applications, for SBP-2 devices, or eth1394 network
4. If another PC is attached to the FireWire bus, it may be possible to read or
overwrite the entire RAM of that remote PC. This depends on the PC's
configuration. Most FireWire controllers support this feature (yes, it's not a
bug, or at least wasn't intended to be one...) but not all OSs enable the feature.
This feature is called physical DMA and is enabled by Linux' ohci1394 driver per
default. It speeds up SBP-2. Linux' sbp2 driver does not work correctly without
physical DMA at the moment. Some slides:
5. If you have two FireWire cards in the same box and connect them, you can get
access to local RAM as in point 4.
Jody McIntyre posted plans to improve raw1394's security a while ago:
Neither Jody nor anybody else got around to implement these ideas yet.
I hope to get sbp2 to work correctly (if slowly) without physical DMA too. This
may take considerable time because I have other priorities. Sbp2's
no-physical-DMA related problems are tracked at
http://bugzilla.kernel.org/show_bug.cgi?id=6393 . Furthermore I am thinking
about implementing filtered physical DMA for SBP-2, but this would have weaker
security than entirely disabled physical DMA.
Physical DMA is disabled by loading ohci1394 with the parameter phys_dma=0. The
rarely used pcilynx driver does not provide physical DMA as far as I know.
Dan Dennedy is working on a security patch to the raw1394 driver, using Linux
As for _stability_ of the 1394 kernel subsystem: A lot has improved since Linux
2.6.9. People who are interested in driver backporting could look at
Product Management has reviewed and declined this request. You may appeal this
decision by reopening this request.