4 ms·

What a mess this has been so far... I appreciate all the effort kernel folks had put in it until now but the whole tier 1 companies cabal thing is just disgusti

by caio1982 9y ago

What a mess this has been so far... I appreciate all the effort kernel folks had put in it until now but the whole tier 1 companies cabal thing is just disgusting and it made the problem worse with the early disclosure (not to say "leak" if you count LKML diffs flying around). If at least all the cabal parties were equally covered and protected by now, but nope nope nope. If I were a kernel developer not working for any cabal party I would be very pissed off.

DoofusOfDeath 9y ago
I recall Herb Sutter saying that companies collaborating on the C++ standards had to do it via an organization like the ISO to avoid the risk of antitrust(?) charges. I wonder if the "cabal" you mentioned actually broke those laws?
- Skunkleton 9y ago
  I know it sucks, but I think the intentions were good here. By managing the disclosure in this way, the majority of users _should_ have been protected before public disclosure. Of course that didn't happen, but that was the intent IMO.
TorKlingberg 9y ago
How would you do it then? Publish as soon as it's discovered, and let everyone scramble for fixes as its being exploited?
- caio1982 9y ago
  0. fucking put the pressure on Intel and other chip makers to have microcode updates ready by NYE, like, you know, 6 months after the first report 1. make sure all tier 1 companies involved are equally patched and on the same page as far as mitigations go before EOY, then involve tier 2 companies (see news on "the impromptu war room") a full month before the embargo deadline 2. not commit or patch anything or fly commented diffs around in the freaking public LKML; git branches to be tested and secondary mailing lists can be private if only for a brief period of time That's definitely not what happened, and probably the dirty details have not surfaced yet. I can't wait for this to be reasonably over so we can start to read post mortem on the whole process.
  - euyyn 9y ago
    You can't really force a different company to have patches and updates by a certain deadline, can you. The only hard leverage is the officially planned disclosure date.
- nbsd4lyfe 9y ago
  Notify groups who have to develop fixes (in this case: OS, compiler developers). Especially when they have a record of not violating embargoes and good faith in fixing issues. When the longer time for fixes is done, post an announcement in private pre-disclosure lists. For a very complicated change, give a few days of private testing and provide patches and details to groups that must apply the patches (oss-sec distro list, etc.) For a simple one with existing backports, notify that <DATE> is publication date for a type of vulnerability to <PROGRAM>. Wait 2-4 weeks to publish a working exploit. Don't notify bodies who don't have their own custom code that must be fixed, but happen to pay you enough money. The latter is actually what happened in this case and it's immensely frustrating.
qiqitori 9y ago
My job is just to backport the fixes into an olde kernel version, but I'm not pissed off :p I don't believe in secrets not leaking. The more parties you tell a secret, the sooner it will leak. And if it had gotten leaked, I'd be in a worse situation than right now.

DoofusOfDeath 9y ago

I recall Herb Sutter saying that companies collaborating on the C++ standards had to do it via an organization like the ISO to avoid the risk of antitrust(?) charges. I wonder if the "cabal" you mentioned actually broke those laws?

Skunkleton 9y ago
I know it sucks, but I think the intentions were good here. By managing the disclosure in this way, the majority of users _should_ have been protected before public disclosure. Of course that didn't happen, but that was the intent IMO.

TorKlingberg 9y ago

How would you do it then? Publish as soon as it's discovered, and let everyone scramble for fixes as its being exploited?

caio1982 9y ago
0. fucking put the pressure on Intel and other chip makers to have microcode updates ready by NYE, like, you know, 6 months after the first report 1. make sure all tier 1 companies involved are equally patched and on the same page as far as mitigations go before EOY, then involve tier 2 companies (see news on "the impromptu war room") a full month before the embargo deadline 2. not commit or patch anything or fly commented diffs around in the freaking public LKML; git branches to be tested and secondary mailing lists can be private if only for a brief period of time That's definitely not what happened, and probably the dirty details have not surfaced yet. I can't wait for this to be reasonably over so we can start to read post mortem on the whole process.
- euyyn 9y ago
  You can't really force a different company to have patches and updates by a certain deadline, can you. The only hard leverage is the officially planned disclosure date.
nbsd4lyfe 9y ago
Notify groups who have to develop fixes (in this case: OS, compiler developers). Especially when they have a record of not violating embargoes and good faith in fixing issues. When the longer time for fixes is done, post an announcement in private pre-disclosure lists. For a very complicated change, give a few days of private testing and provide patches and details to groups that must apply the patches (oss-sec distro list, etc.) For a simple one with existing backports, notify that <DATE> is publication date for a type of vulnerability to <PROGRAM>. Wait 2-4 weeks to publish a working exploit. Don't notify bodies who don't have their own custom code that must be fixed, but happen to pay you enough money. The latter is actually what happened in this case and it's immensely frustrating.

qiqitori 9y ago

My job is just to backport the fixes into an olde kernel version, but I'm not pissed off :p I don't believe in secrets not leaking. The more parties you tell a secret, the sooner it will leak. And if it had gotten leaked, I'd be in a worse situation than right now.