Bug 201947 - No firewire support.
Summary: No firewire support.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Daniel Riek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-09 21:32 UTC by Jacob Beacham
Modified: 2008-09-24 02:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-24 02:29:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jacob Beacham 2006-08-09 21:32:59 UTC
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?

Comment 1 Jason Baron 2006-08-22 19:34:46 UTC
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...

Comment 2 Stefan Richter 2006-09-02 22:54:41 UTC
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.

Comment 3 Stefan Richter 2006-09-03 09:44:11 UTC
Dan Dennedy is working on a security patch to the raw1394 driver, using Linux
Capabilities.

Comment 4 Stefan Richter 2006-09-03 09:50:54 UTC
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/.

Comment 5 RHEL Program Management 2008-09-24 02:29:25 UTC
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request.


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