Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 201947 - No firewire support.
No firewire support.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Riek
Brian Brock
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2006-08-09 17:32 EDT by Jacob Beacham
Modified: 2008-09-23 22:29 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-23 22:29:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Jacob Beacham 2006-08-09 17:32:59 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?
Comment 1 Jason Baron 2006-08-22 15:34:46 EDT 
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 18:54:41 EDT 
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 05:44:11 EDT 
Dan Dennedy is working on a security patch to the raw1394 driver, using Linux
Capabilities.
Comment 4 Stefan Richter 2006-09-03 05:50:54 EDT 
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 Product and Program Management 2008-09-23 22:29:25 EDT 
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.
First Last Prev Next    This bug is not in your last search results.