Baltix

Bug #6290
Comment #74

Comment 74 for bug 6290

Revision history for this message

Stefan Richter (stefan-r-ubz) wrote on 2010-05-21:

#74

> There is apparently a lot of missing kernel support here

There is nothing missing in the new stack. And what is missing in the old stack could have been added to it if development manpower would have been available, or better yet, development and deployment of the new stack could have been sped up with developer and tester manpower.

> unsafe hacks around that won't be accepted upstream

Do you mean upstream udev? They also accepted Ubuntu's video1394 and dv1394 rules that had typos in them such that they never matched. (Or they added the typos themselves when they merged Ubuntu's rules, I don't know. Commit 41e7f557.) The fact that they removed the raw1394 rule (commit a8cf7cf) with a mere pointer to this distro bug here but without an own analysis of costs vs. rewards or without checking back with raw1394/ libraw1394 developers also shows that upstream is not in a position to judge what is safe and unsafe. You Ubuntu developers OTOH (a) kept confusing device security with host security and raw1394 flaws with ohci1394/sbp2 flaws, (b) never analyzed the actual risks, (c) never analyzed the costs of the rule removal, (d) never researched potential alternatives. Upstream udev simply trusted your judgment, which was a mistake. (And I didn't push for a revert when I noticed this because I thought that the new firewire drivers would show up in distributions any day now or distributors would at least begin to ask for them, which was a mistaken belief on my side.)

One more word on hacks: Ubuntu's raw1394 rule removal was initially motivated by host security implications but did not in fact solve them, because that's the wrong point to go at. It's ohci1394 and a feature of it on which sbp2 relied.

> You are of course welcome to add one locally if you are in a trusted or single-user environment.

That's 1990's Linux mindset. This is an unacceptable hack too.

You OTOH were of course welcome to discuss your concerns and requirements with upstream kernel/ library/ application developers when you removed the rule in Ubuntu, or at least later when this change went upstream. I'm not even talking about contribution of tests or code.

Hmm, maybe I should have taken initiative two years ago (that's when transparent dual stack capability was implemented in libraw1394 by Dan) and should have pushed for the new stack to be provided by default in Ubuntu. The then half-working new stack might have been preferable to the mostly non-working old stack as configured in Ubuntu.

> There is apparently a lot of missing kernel support here

There is nothing missing in the new stack.  And what is missing in the old stack could have been added to it if development manpower would have been available, or better yet, development and deployment of the new stack could have been sped up with developer and tester manpower.

> unsafe hacks around that won't be accepted upstream

Do you mean upstream udev?  They also accepted Ubuntu's video1394 and dv1394 rules that had typos in them such that they never matched. (Or they added the typos themselves when they merged Ubuntu's rules, I don't know.  Commit 41e7f557.)  The fact that they removed the raw1394 rule (commit a8cf7cf) with a mere pointer to this distro bug here but without an own analysis of costs vs. rewards or without checking back with raw1394/ libraw1394 developers also shows that upstream is not in a position to judge what is safe and unsafe.  You Ubuntu developers OTOH (a) kept confusing device security with host security and raw1394 flaws with ohci1394/sbp2 flaws, (b) never analyzed the actual risks, (c) never analyzed the costs of the rule removal, (d) never researched potential alternatives.  Upstream udev simply trusted your judgment, which was a mistake.  (And I didn't push for a revert when I noticed this because I thought that the new firewire drivers would show up in distributions any day now or distributors would at least begin to ask for them, which was a mistaken belief on my side.)

One more word on hacks:  Ubuntu's raw1394 rule removal was initially motivated by host security implications but did not in fact solve them, because that's the wrong point to go at.  It's ohci1394 and a feature of it on which sbp2 relied.

> You are of course welcome to add one locally if you are in a trusted or single-user environment.

That's 1990's Linux mindset.  This is an unacceptable hack too.

You OTOH were of course welcome to discuss your concerns and requirements with upstream kernel/ library/ application developers when you removed the rule in Ubuntu, or at least later when this change went upstream.  I'm not even talking about contribution of tests or code.

Hmm, maybe I should have taken initiative two years ago (that's when transparent dual stack capability was implemented in libraw1394 by Dan) and should have pushed for the new stack to be provided by default in Ubuntu.  The then half-working new stack might have been preferable to the mostly non-working old stack as configured in Ubuntu.