unwise IEEE 1394 udev rules from Ubuntu merged into mainline udev

unwise IEEE 1394 udev rules from Ubuntu merged into mainline udev

[Stefan Richter]

A word of warning to udev distributors:

If your distro uses the older "ieee1394" kernel drivers (I think all 
distros except Fedora use the old ones, as opposed to the newer 
alternative "firewire" a.k.a. "Juju" kernel drivers), then take care 
whether you want to use the the current vanilla udev ruleset.

The ieee1394 related rules have been changed by the following commits:

"rules: more changes toward Ubuntu rules merge"
Sun, 21 Dec 2008, in udev 136
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hAe7f55711db043370e1681bb5a97ebdeda5d6d3

This breaks video1394 and dv1394.  Fixed by:

"rules: fix ieee1394 rules"
Tue, 5 May 2009, in udev 142
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h÷7e32aeb2b64bba0db8840f5e679d3f76b3ffc5

But raw1394 was also disabled for non-root users, and it still is in 
current udev:

"rules: do not put raw1394 in "video" group"
Mon, 22 Dec 2008, in udev 136
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h®cf7cf2c7b4c41c14508a808b09a5fa9256a024

This change forces users
   - either to modify udev rules to revert this,
   - or to run video acquisition software and other A/V applications as
     root.

Nice.

Yes, there are security considerations regarding the older ieee1394 
drivers.  But first of all, these security considerations have nothing 
to do with access permission of /dev/raw1394.  Instead, they have to do 
with how the ohci1394 enables physical DMA on OHCI-1394 host 
controllers.  Physical DMA is one of the DMA modes offered by OHCI-1394 
drivers and it is necessary for the sbp2 driver (FireWire storage) to 
function.

By default, the ohci1394 driver switches physical DMA on without 
filters.  Alternatively, it can be switched off by a module parameter 
but then sbp2 won't work anymore.

When physical DMA is switched on, remote nodes can read and write any 
memory to which the OHCI-1394 PCI device has access to.  On systems 
without IOMMU, this is the first 4 GB of physical memory of course. 
Basically, physical DMA lets the OHCI-1394 controller act as a bus 
bridge between PCI and 1394; the 1394 port becomes somewhat of a plug 
into PCI.

In the past, this nifty OHCI-1394 feature has been used in one or two 
media-effective demos of how a FireWire iPod with modified firmware 
(e.g. runing ucLinux) can be used to own an Apple Mac.  Nothing else 
than these demos ever came out of this.  Apple have since fixed their 
OHCI-1394 driver implementation to properly filter physical DMA.

We fixed this too eventually --- but not in ohci1394, only by providing 
the new alternative firewire driver stack which has physical DMA filtering.

Now, people who are concerned about this (arguably mostly theoretical) 
FireWire security issue could have
   - sat down to learn what the issue is about,
   - ported the fix from the new firewire drivers to the old 1394
     drivers,
   - or helped getting the new firewire drivers ready to fully replace
     the old drivers.

But wait, why actually fix the issue if you can instead provide a 
workaround which (a) demonstrates that you don't actually know what you 
are doing, (b) doesn't actually fix the problem, (c) entirely destroys 
the ability to run FireWire enabled software --- desktop/ consumer 
oriented software as well as professional software.

This workaround of making /dev/raw1394 accessible to root improves 
security only in one respect:  The hole that is opened by ohci1394 can 
now no longer be used by a client terminal which runs raw1394 (modulo 
root on this terminal).π  Your Linux box is still vulnerable to any 
other of such terminals, be it another Linux box with privileged or 
unprivileged access to raw1394, or a Windows PC or Mac or iPod or 
whatever with respective hacker toolset.

π) As mentioned in the changelog of the udev commit in question, based 
on a comment which I made at the respective Ubuntu bug tracker item, the 
terminal can also be the same PC if it has at least two FireWire 
controllers which are the plugged together.

PS:
Perhaps I should finally copy the physical DMA filtering from the new 
drivers to the old drivers --- but then I have endless other things to 
do, things with actual practical importance.  Like getting the new 
drivers fully featured.  However, I'm seeing an increase of trivial end 
user support questions coming onto myself and all the Linux 1394 
libraries & applications developers in the near future. --- One way or 
another, we need to get back usable FireWire access defaults.
-- 
Stefan Richter
-===-=-== -=-= -=-http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: unwise IEEE 1394 udev rules from Ubuntu merged into mainline udev

[Kay Sievers]

On Thu, May 21, 2009 at 17:26, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> But wait, why actually fix the issue if you can instead provide a workaround
> which (a) demonstrates that you don't actually know what you are doing, (b)
> doesn't actually fix the problem, (c) entirely destroys the ability to run
> FireWire enabled software --- desktop/ consumer oriented software as well as
> professional software.

It's common practice and nothing wrong in general when people try to
disable/restrict stuff they "don't understand".
If I remember correctly, you have been in the discussion, that finally
lead to this decision. I think, it's _your_ part to lead them to the
proper solution then, instead of finger-pointing distros and tell them
later, they don't know what they do. :)

> PS:
> Perhaps I should finally copy the physical DMA filtering from the new
> drivers to the old drivers

I don't think so.

> but then I have endless other things to do,
> things with actual practical importance.  Like getting the new drivers fully
> featured.  However, I'm seeing an increase of trivial end user support
> questions coming onto myself and all the Linux 1394 libraries & applications
> developers in the near future. --- One way or another, we need to get back
> usable FireWire access defaults.

I guess you should finally deprecate the old drivers, and comment-out
the Kconfig entries in the kernel sources, so people/distros who want
to use the old drivers would need to patch that in, to compile it.
Otherwise nothing will ever change. Many people/distros don't know
much about firewire, and will never switch-over, unless _you_ create
an incentive for them.

Firewire is not very commonly used, and having two completely
different implementations in the same kernel sounds really
inefficient, and it splits the pretty limited resources into two
camps.

Having a "stable" and a "new" stack, like they are called in the
kernel config, and having a warning there, that only one of them
should be used, does not really send a clear message either - and
that's what people need. :)

You are doing a really great job caring about both of the stacks and
keep them running, which is very nice from a subsystem maintainer
standpoint. But I think at a larger scale, i think, it just makes
things worse than going through the one-time pain of finally
switching-over, and fixing the remaining issues.

Thanks,
Kay

Re: unwise IEEE 1394 udev rules from Ubuntu merged into mainline

[Stefan Richter]

Kay Sievers wrote:
> On Thu, May 21, 2009 at 17:26, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> 
>> But wait, why actually fix the issue if you can instead provide a workaround
>> which (a) demonstrates that you don't actually know what you are doing, (b)
>> doesn't actually fix the problem, (c) entirely destroys the ability to run
>> FireWire enabled software --- desktop/ consumer oriented software as well as
>> professional software.
> 
> It's common practice and nothing wrong in general when people try to
> disable/restrict stuff they "don't understand".
> If I remember correctly, you have been in the discussion, that finally
> lead to this decision. I think, it's _your_ part to lead them to the
> proper solution then, instead of finger-pointing distros and tell them
> later, they don't know what they do. :)

Well, I do have accounts in some distro bugtrackers because I sometimes 
look there for potential upstream bugs.  Other than that, I admit a 
serious lack of interest in what distros do.  My comments in this 
particular Ubuntu bug were also not driven by actual interest in what 
the Ubuntu maintainers decide --- especially since Ubuntu has so far 
been the only distribution which chose to block user access to /dev/raw1394.

>> PS:
>> Perhaps I should finally copy the physical DMA filtering from the new
>> drivers to the old drivers
> 
> I don't think so.
> 
>> but then I have endless other things to do,
>> things with actual practical importance.  Like getting the new drivers fully
>> featured.  However, I'm seeing an increase of trivial end user support
>> questions coming onto myself and all the Linux 1394 libraries & applications
>> developers in the near future. --- One way or another, we need to get back
>> usable FireWire access defaults.
> 
> I guess you should finally deprecate the old drivers, and comment-out
> the Kconfig entries in the kernel sources, so people/distros who want
> to use the old drivers would need to patch that in, to compile it.
> Otherwise nothing will ever change. Many people/distros don't know
> much about firewire, and will never switch-over, unless _you_ create
> an incentive for them.

I would love to do that, but we need to accomplish two major things 
before we can finally pull the plug on drivers/ieee1394:

   1. Implement IP over 1394 for the new stack.  Somebody is working on
      it; code has been seen on linux1394-devel now.

   2. Get professional/ semiprofessional audio streaming via FFADO
      going.  Right now there are show-stopping problems but we don't
      even have a proper anamnesis yet.

To solve problem two, there are two fronts which can be attacked 
independently:
   -  Make control and streaming through libraw1394 + firewire-cdev
      (at least as well) work like libraw1394 + raw1394 work now,
   -  implement an ALSA interface which us used for streaming IO
      instead of the generic firewire-cdev interface.

Somebody plans to work at the second front during summer.

Oh, perhaps there is also a 3rd item:

   3. Provide an attractive alternative to those who find dv1394
      still to fit their bill.  (That's a special purpose driver
      with an oddball configuration interface, but it seems to be
      still OK for NTSC at least.)

> Firewire is not very commonly used, and having two completely
> different implementations in the same kernel sounds really
> inefficient, and it splits the pretty limited resources into two
> camps.

Correct.

> Having a "stable" and a "new" stack, like they are called in the
> kernel config, and having a warning there, that only one of them
> should be used, does not really send a clear message either - and
> that's what people need. :)

Well, it's really hard to give a simple message which is understood 
easily and true to everyone's need.

I deliberately did not remove the "experimental" label from the new 
drivers yet --- not because they crash all the time (they don't anymore) 
or because they had lesser device compatibility (as far as I can tell, 
they offer more stable device discovery than the old drivers, except 
that two or three rare and old controllers don't work yet but do 
partially work with the old drivers) --- but because there are some 
features which are not yet available in the new stack, see above.

Some crucial features for professional video acquisition have been added 
in kernel 2.6.30 but userspace (libdc1394) is not yet up to date with 
these .30 additions.

> You are doing a really great job caring about both of the stacks and
> keep them running, which is very nice from a subsystem maintainer
> standpoint. But I think at a larger scale, i think, it just makes
> things worse than going through the one-time pain of finally
> switching-over, and fixing the remaining issues.

Thanks.  And yes, in retrospect I wish I had ramped down my work with 
ieee1394 quicker so that more time had been spent on firewire.
-- 
Stefan Richter
-===-=-== -=-= -=-http://arcgraph.de/sr/

Re: unwise IEEE 1394 udev rules from Ubuntu merged into mainline

[Pieter Palmers]

Kay Sievers wrote:
> On Thu, May 21, 2009 at 17:26, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> 
>> But wait, why actually fix the issue if you can instead provide a workaround
>> which (a) demonstrates that you don't actually know what you are doing, (b)
>> doesn't actually fix the problem, (c) entirely destroys the ability to run
>> FireWire enabled software --- desktop/ consumer oriented software as well as
>> professional software.
> 
> It's common practice and nothing wrong in general when people try to
> disable/restrict stuff they "don't understand".
> If I remember correctly, you have been in the discussion, that finally
> lead to this decision. I think, it's _your_ part to lead them to the
> proper solution then, instead of finger-pointing distros and tell them
> later, they don't know what they do. :)
> 
>> PS:
>> Perhaps I should finally copy the physical DMA filtering from the new
>> drivers to the old drivers
> 
> I don't think so.
> 
>> but then I have endless other things to do,
>> things with actual practical importance.  Like getting the new drivers fully
>> featured.  However, I'm seeing an increase of trivial end user support
>> questions coming onto myself and all the Linux 1394 libraries & applications
>> developers in the near future. --- One way or another, we need to get back
>> usable FireWire access defaults.
> 
> I guess you should finally deprecate the old drivers, and comment-out
> the Kconfig entries in the kernel sources, so people/distros who want
> to use the old drivers would need to patch that in, to compile it.
> Otherwise nothing will ever change. Many people/distros don't know
> much about firewire, and will never switch-over, unless _you_ create
> an incentive for them.
> 
> Firewire is not very commonly used, and having two completely
> different implementations in the same kernel sounds really
> inefficient, and it splits the pretty limited resources into two
> camps.
> 
> Having a "stable" and a "new" stack, like they are called in the
> kernel config, and having a warning there, that only one of them
> should be used, does not really send a clear message either - and
> that's what people need. :)
> 
> You are doing a really great job caring about both of the stacks and
> keep them running, which is very nice from a subsystem maintainer
> standpoint. But I think at a larger scale, i think, it just makes
> things worse than going through the one-time pain of finally
> switching-over, and fixing the remaining issues.

The reports I got up till now are that FFADO doesn't work with the new 
stack, notwithstanding the fact that its a 100% userspace library that 
only accesses the firewire bus through libraw1394. In theory this would 
mean that the underlying kernel stack doesn't matter as libraw1394 
abstracts that. In reality that isn't the case.

I would like it if the current ('old') stack would not be deprecated 
before the new one actually works.

Greets,

Pieter

Re: unwise IEEE 1394 udev rules from Ubuntu merged into mainline

[Bill Fink]

On Thu, 21 May 2009, Stefan Richter wrote:

> Kay Sievers wrote:
> > On Thu, May 21, 2009 at 17:26, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> > 
> >> But wait, why actually fix the issue if you can instead provide a workaround
> >> which (a) demonstrates that you don't actually know what you are doing, (b)
> >> doesn't actually fix the problem, (c) entirely destroys the ability to run
> >> FireWire enabled software --- desktop/ consumer oriented software as well as
> >> professional software.
> > 
> > It's common practice and nothing wrong in general when people try to
> > disable/restrict stuff they "don't understand".
> > If I remember correctly, you have been in the discussion, that finally
> > lead to this decision. I think, it's _your_ part to lead them to the
> > proper solution then, instead of finger-pointing distros and tell them
> > later, they don't know what they do. :)
> 
> Well, I do have accounts in some distro bugtrackers because I sometimes 
> look there for potential upstream bugs.  Other than that, I admit a 
> serious lack of interest in what distros do.  My comments in this 
> particular Ubuntu bug were also not driven by actual interest in what 
> the Ubuntu maintainers decide --- especially since Ubuntu has so far 
> been the only distribution which chose to block user access to /dev/raw1394.
> 
> >> PS:
> >> Perhaps I should finally copy the physical DMA filtering from the new
> >> drivers to the old drivers
> > 
> > I don't think so.
> > 
> >> but then I have endless other things to do,
> >> things with actual practical importance.  Like getting the new drivers fully
> >> featured.  However, I'm seeing an increase of trivial end user support
> >> questions coming onto myself and all the Linux 1394 libraries & applications
> >> developers in the near future. --- One way or another, we need to get back
> >> usable FireWire access defaults.
> > 
> > I guess you should finally deprecate the old drivers, and comment-out
> > the Kconfig entries in the kernel sources, so people/distros who want
> > to use the old drivers would need to patch that in, to compile it.
> > Otherwise nothing will ever change. Many people/distros don't know
> > much about firewire, and will never switch-over, unless _you_ create
> > an incentive for them.
> 
> I would love to do that, but we need to accomplish two major things 
> before we can finally pull the plug on drivers/ieee1394:
> 
>    1. Implement IP over 1394 for the new stack.  Somebody is working on
>       it; code has been seen on linux1394-devel now.
> 
>    2. Get professional/ semiprofessional audio streaming via FFADO
>       going.  Right now there are show-stopping problems but we don't
>       even have a proper anamnesis yet.
> 
> To solve problem two, there are two fronts which can be attacked 
> independently:
>    -  Make control and streaming through libraw1394 + firewire-cdev
>       (at least as well) work like libraw1394 + raw1394 work now,
>    -  implement an ALSA interface which us used for streaming IO
>       instead of the generic firewire-cdev interface.
> 
> Somebody plans to work at the second front during summer.
> 
> Oh, perhaps there is also a 3rd item:
> 
>    3. Provide an attractive alternative to those who find dv1394
>       still to fit their bill.  (That's a special purpose driver
>       with an oddball configuration interface, but it seems to be
>       still OK for NTSC at least.)

Yes, this requires someone to modify the ffmpeg code to provide an
alternative to its dv1394 interface for viewing "live" DV video.

						-Bill