So Intel tried to shut *BSD out of the process again (like they did for the original Spectre/Meltdown) so they didn't feel they had to respect any embargo?
> So Intel tried to shut *BSD out of the process again (like they did for the original Spectre/Meltdown) so they didn't feel they had to respect any embargo?
Yes and no... It's really important that this be viewed from the context of the discussion opened by theo in the video from the previous HN post (provided in this thread by codewriter23).
Here's My TL;DW from the irritatingly poor quality video:
Yes, they are pissed that they are being excluded (rumour is amazon and google have been implementing fixes).
However, they are not necessarily "not-respecting" the embargo according to the proposed methodology Theo outlines in the video: to (speculatively) exclude _any_ potential source of speculative execution vulnerabilities to ensure they are safe without giving weight to any one rumour. And then gradually prune back the precautions as they become publicly disclosed.
Apparently they used a similar strategy previously to provide patches for sshd before they were allowed to publicly disclose the vulnerability... prevent the bug from being reachable without revealing exactly what is broken in the commits by never touching the offending code. In this case the idea is to be non-specific, disable a whole class of things even though it might not be necessary (because in this case they really don't know where the problem is exactly).
Disclaimer: The above is not my opinion, it was my interpretation of the relevant context from the video, i do not know if it matches their actions.
It seems possible the commenter on the oss-security mailing list is not aware of this strategy and is giving more weight to openBSD's patch than it deserves (and perhaps wrongly implying openBSD have disrespected the embargo as a sideffect).
However these patches are way beyond me so I cannot tell.
The braking the embargo part is about the FPU issue that they published a patch for a few days before Theo gave the talk.
The part you're referencing is Theo speculating about the next bug. He suspects fixing it requires flushing a cash line but he doesn't know which one (because he doesn't know where the bug is) so he proposes flushing all of them until the bug is published and then removing the flushes that aren't necessary.
He then mentions the last serious OpenSSH bug. Instead of publishing a fix for the bug (and thus disclosing the bug) they decided to publish a patch that moved a bunch of code around and just happened to also make the buggy code unreachable. Then they told everybody to upgrade and once that happened they could safely disclose the bug and publish a fix for it. No embargo necessary and everybody got the fix at the same time. (I assume that's why he brought it up.)
Ah, thanks for pointing that out. But I wonder if there is actually a demonstrable exploit for that patch? Or, if it's the same preemptive approach? I guess i'm arguing that patches didn't necessarily wait for Theo's talk to reveal why they are doing what they are doing.
Can someone with deep enough knowledge of the patch tell if it implicitly demonstrates the flaw? (and therefor effectively breaks public disclosure) or is it purely speculative - oh god the puns are killing me.
> It seems possible the commenter on the oss-security mailing list is not aware of this strategy and is giving more weight to openBSD's patch than it deserves (and perhaps wrongly implying openBSD have disrespected the embargo as a sideffect).
This sort of thing regularly happens. I remember an incident relatively recently when someone inaccurately "pointed out" that Arch Linux had "broken" an embargo by packaging an upstream release [1].
Eh? An embargo is where you share information with someone on the grounds they don't release it until a certain date. If you come by the information some other way then clearly you're not a party to the embargo.
The language being used makes it sound like somehow openbsd is breaking agreements. Considering this appears to be the result of the false perception that OpenBSD breaks embargos they are a party too, its important to fight this loose usage of words.
In the vast majority of cases it is the prudent way to go about it and not doing it (with intent) is often reckless and a dick move well deserved of criticism.
This/these cases however might be an exception.
I fully agree that one should be careful of propagating such false perceptions about OpenBSD (or any other entity).
I disagree. As long as the embargo is purely related to this or that company profiting over another, as opposed to being potentially a matter of safety (see the UK D Notice system, for example), it's laughable to describe breaking something covered by someone else's optional embargo as a "dick move". On the contrary, it's generally highly amusing, and at the very least informative.
However these circumstances can also be a matter of safety. For instance, an easily exploitable SSH vulnerability can incur serious damage to lots of institutions.
Further, the embargo isn't/shouldn't be about protecting Intel - it's about protecting everyone that uses Intel CPUs (sometimes those goals are aligned, sometimes not). How you go about that is one thing and if you intentionally disrespect that embargo (whether you were in on it or not) means that the assumptions and motivations for the embargo are invalidated and the consequences could be huge.
Now you don't necessarily have to agree with the embargo but if you don't know the consequences (in this case it looks like it was likely to be known) you take it up on yourself that you (with most likely very limited information) can identify the consequences of doing such a disclosure.
It's the same problem of doing a irresponsible disclosure of a major vulnerability. Most do consider that to be a dick move.
I was in the room at the time. Warner had the initial outburst. There is a second speaker, and you can hear the voice change, responsible for the profanity. Warner's delivery was much scarier in person though.
Yes and no... It's really important that this be viewed from the context of the discussion opened by theo in the video from the previous HN post (provided in this thread by codewriter23).
Here's My TL;DW from the irritatingly poor quality video:
Yes, they are pissed that they are being excluded (rumour is amazon and google have been implementing fixes).
However, they are not necessarily "not-respecting" the embargo according to the proposed methodology Theo outlines in the video: to (speculatively) exclude _any_ potential source of speculative execution vulnerabilities to ensure they are safe without giving weight to any one rumour. And then gradually prune back the precautions as they become publicly disclosed.
Apparently they used a similar strategy previously to provide patches for sshd before they were allowed to publicly disclose the vulnerability... prevent the bug from being reachable without revealing exactly what is broken in the commits by never touching the offending code. In this case the idea is to be non-specific, disable a whole class of things even though it might not be necessary (because in this case they really don't know where the problem is exactly).
Disclaimer: The above is not my opinion, it was my interpretation of the relevant context from the video, i do not know if it matches their actions.
It seems possible the commenter on the oss-security mailing list is not aware of this strategy and is giving more weight to openBSD's patch than it deserves (and perhaps wrongly implying openBSD have disrespected the embargo as a sideffect).
However these patches are way beyond me so I cannot tell.