Hacker News new | ask | show | jobs
by tomxor 2934 days ago
> 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.

2 comments

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].

[1] http://seclists.org/oss-sec/2017/q3/420