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): kernel-2.6.9-34.0.2.EL How reproducible: Always Steps to Reproduce: N/A Additional info: 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 about rhel5...
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 interfaces. 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: http://md.hudora.de/presentations/#firewire-pacsec http://md.hudora.de/presentations/#firewire-21c3 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: http://thread.gmane.org/gmane.linux.kernel.firewire.devel/6395/focus=6395 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 Capabilities.
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 http://me.in-berlin.de/~s5r6/linux1394/updates/.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.