Is there not some sort of OS embargo consortium that could be created to resolve this?
For example, from the conversation on the KRACK embargo:
>Q. What is the rationale on extending the embargo so long? To give vendors a chance to patch? It seems like once people in the know know about a vulnerability, the shorter an embargo time the better.
> A. There’s a couple of different interests at play.
> For instance:
> Researchers want to make a timed media splash.
> Security agencies want to evaluate the problem and make sure they get patched before anyone else.
> Vendors want time to prepare patches, yes, but that alone does not justify such a long delay.
> Reviewing the patch, testing it, and preparing it for commit and publishing erratas took only a couple of hours of my free time.
Apparently Meltdown was discovered back in June, or seven months ago. Only a select few were told about it and have been working on it. It is apparent that some are more equal than others in the "free and open source community," which ironically apparently includes Microsoft, Apple, and the three-letter agencies.
To quote that last paper:
> We show how processor architecture features such as simultaneous multithreading, control speculation and shared caches can inadvertently accelerate such covert channels or enable new covert channels and side channels. We first illustrate the reality and severity of this problem by describing concrete attacks.
So not just were side-channel attacks on CPUs documented; specifically the dangers of speculative execution and caching on intel cpus (there: the Itanium) was documented.
It's inconceivable that this comes as a surprise to Intel. They're playing the public for fools.
Of course some of this is intrinsic: speculative loading, caching, and accurate timers are an intrinsic problem: an JIT running in the same process as the JITted code will not be able to keep secrets from that JITted code while all three are in play. But intel specifically also allowed this across memory protection boundaries, which isn't necessary.
Quote from the meltdown paper:
> We expect that Meltdown and Spectre open a new field of research to investigate in what extent performance optimizations change the microarchitectural state, how this state can be translated into an architectural state, and how such attacks can be prevented.
So we won't see the last of Spectre.
Not to be cynical or downplay the research, but that's the kind of thing you (have to?) put into papers to make getting research funding easier in future. Hardly a new field, just very difficult to do research on.
Why does that matter? Because people seem to imply intel isn't to blame here; that since the attacks were unforeseen, it's essentially just bad luck. But that's not the case: the risky bits of architecture were known. It's like finding a memory corruption vulnerability and then deciding not to fix it since you don't also know of an exploit - that's just being careless.
Furthermore; finding holes like this isn't some divine act; although there is luck and skill involved there's no question that others can do so too. Even if an attack were completely new, you have to ask yourself how hard it was to find. Does a supplier have any responsibility to provide secure things? Then they should be looking for these kinds of holes. Obviously to a novice any hack like this looks almost magical - but there's a risk that by interpreting any novel attack as not-their-fault that the vulnerable supplier never bothers trying to make anything secure.
Intel was being careless. They should definitely have known this was exploitable even without knowing how to exploit it. And it's at least conceivable that they could have found this or an exploit like this if they had tried.
it's no surprise they're not high up on the list of important people to tell
* https://news.ycombinator.com/item?id=16074531
That is hardly enough time, considering that it is likely a holiday period for most of the people concerned, to prepare what needed to be prepared. Google and Intel gave themselves six months, in contrast, and they gave Ubuntu since November 2017.
I still haven't nailed down how much advanced notice Matthew Dillion, author of DragonFly BSD, was given; although his apparent level of preparedness with patches on 2018-01-05 can be attributed to the fact that he actually talked publicly about the problem in April 2017, months before Google Project Zero secretly reported it to processor manufacturers in June 2017 in the first place.
Correct, but it’s significantly better than OpenBSD’s timeline (which learnt about it from the media). Mitigation for Meltdown is possible within of a week, or two. It requires working through the night, but it’s possible.
Mitigation after it’s in the media is a whole different situation.
From https://www.krackattacks.com/#openbsd :
> As a compromise, I allowed them to silently patch the vulnerability.
Receiving permission to patch is the opposite of breaking an embargo.
> As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.