I don’t understand the Intel hate. It’s not like their engineers are dumb or lazy. This exploit is very hard to imagine before now. And it’s there because chip makers were trying to wring out more performance. It’s unfortunate if anythig.
> I should note that we kernel programmers have spent decades trying to reduce system call overheads, so to be sure, we are all pretty pissed off at Intel right now. Intel's press releases have also been HIGHLY DECEPTIVE. In particular, they are starting to talk up 'microcode updates', but those are mitigations for the Spectre bug, not for the Meltdown bug. Spectre is another bug, far more difficult to exploit than Meltdown, which leaks information from other processes or the kernel based on those other processes or kernel doing speculative reads and executions which are partially managed by the originating user process. Spectre does NOT involve a protection domain violation like Meltdown, so the Meltdown mitigation cannot mitigate Spectre.
> These bugs (both Meltdown and Spectre) really have to be fixed in the CPUs themselves. Meltdown is the 1000 pound gorilla. I won't be buying any new Intel chips that require the mitigation. I'm really pissed off at Intel.
[1] http://lists.dragonflybsd.org/pipermail/users/2018-January/3...
It might be argued that the risk of the exploit making it into the wild would have been higher if the BSDs were notified, on account of the sort of accidental premature disclosure that actually happened. This would appear to be self-serving if stated by the embargo insiders, but it may still be valid, especially if my guesses that a) this problem's biggest potential impact is in cloud computing, and b) there is relatively little use of BSDs in cloud computing, are accurate.
From https://www.krackattacks.com
> We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. 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.
Note the date there that de Raadt was commenting on the discouragement of sitting on a fix for a month. What is the likelihood that he would be very discouraged to sit on it for six months? What if it was a three month embargo that changed to a six month embargo - when would the fix be released?
I would assume that those are questions that need to be asked prior to notifying a project.
There was another "incident" with the KRAK embargo, where OpenBSD got permission to silently patch it early and then the researcher who found it regretted giving them permission.
I think people put these two incidents together, combine it with the developers' attitudes towards embargoes and come out with: OpenBSD doesn't honour embargoes!
It's the technological version of insider trading
'We don't respect embargoes' -> 'Company only releases to individuals who respect embargoes' -> repeat
If you are open to arguments, there are many good reasons to take a negative stance towards Intel.
Fun fact: I sent an overview of unknown instructions in compressed text form to a gmail address, and Google rejected it citing potentially malicious content.
Was it ever?
It's really not. It's the sort of thing you wonder after first learning about out-of-order and speculative execution in a computer architecture class, but your professor assures you that implementors have been very careful to ensure any partial execution is properly flushed and rolled back. Then it turns out that, nope, no one's actually been keeping an eye on this after all.
Life-safety work has no business in a public cloud.
Anthopogenic climate change falls into this category.
I have to wonder, first, what sort of obvious stupid self-destructive things am I doing right now but ignoring. And second, how can we build systems that systematically take this into account? Is there some way to short-cut the process and find and fix problems in the early stages? Or better yet, design our systems so that they don't have the problems from the start?
There is one attitude that exacerbates those problems that are real - the tacit assumption that concerns do not count for anything until an exploit has been demonstrated.
And, at the time, your professor was correct, to the extent of what he/she defined as "any partial execution".
But his/her definition of "partial execution" only considered state changes to the programmer visible CPU architecture state (i.e., the user level register set and the flags register). Their definition ignored the cache, because at the time the cache was considered simply a transparent optimization system that did not effect the values of contents of the CPU architectural state.
And in a way, that definition is still valid, even after the knowledge of these exploits. The CPU architectural state (registers/flags), even after executing exploit code, is exactly what it would have been had sequential execution happened. The exploit takes advantage of the fact that you can arrange the right set of code to run just the right way to leave a different state in the _cache_ (i.e., that thing believed to have been merely a transparent optimization).
It turns out now that the belief in the cache being transparent and only providing optimizations was the flaw in the belief system at the time.
You're putting words in other people's mouths here.
The details really matter for making an exploit: so the amount of speculation and what gets speculated, how caches work, how good timing is (and how large the difference between cache and memory is) etc.
Merely knowing that the combination of speculation, caching, and timing have the potential to break through memory protection barriers is a far from enough to actually exploit that weakness.
For comparison: it was widely known that sha1 had weaknesses, yet it took many years for somebody to construct two pdfs that actually demonstrate a hash collision.
With this recent news, I feel like part of the reason that Intel has been doing so well is that they have been _cheating_.
All processors (including AMD/ARM) since the early 90's have been using instruction pipelining. It's a universal performance improvement, not Intel cheating.
If it was such a mythical attack why doesn't it work on anyone else's chips? Intel screwed up hard on this and I have no sympathy. Hopefully the incoming lawsuits will make up for the massive amount of money wasted for the performance losses
I've got a friend in CPU design and he's only got about 50 companies he can work for in the world where he could do the same job he does now
I’ve written RTL that speculatively fetches data from memory in order to avoid bubbles in a pipeline. Not a CPU, but the concept is exactly the same.
If somebody had assigned me to a CPU project without guidance from a security architect and ask me to speculate reads, I’d probably have done the same as Intel.
The chance that the same guy did both CPUs is small. It’s just that it’s not an unreasonable way of doing thing if you’re not familiar with these kind of attack.
And if anyone even considered the results of the reads, they likely saw them as nothing more than free cache pre-fetch instructions that would enhance performance should the speculative path turn out to be the correct path after-all.
And because the push was for yet more performance, free cache pre-fetch operations were likely viewed as a great bonus.
> We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
theo de raadt of openbsd called this out, 10 years ago: https://marc.info/?l=openbsd-misc&m=118296441702631
Now i know it would take a lot for a major company to delay/cancel a release like that, but i think it could be argued that they were dishonest if they knew it would have a performance impact.
If so, I hope the market punishes that decision mercilessly.
[0] Caveat: Skylake and later are extra-vulnerable to Spectre because they have even more aggressive speculative execution, but fortunately, the IBRS microcode update is roughly equally performant as retpoline on Skylake+ only.
However for unknown reasons it’s worse in Intel. They were not able to exploit the vulnerability to dump the kernel memory on AMD and ARM.
So I find the whole “Intel you suck” really out of line. I would not be surprised someone clever will come and figure out a Meltdown style attacks which works on AMD and ARM CPUs.
As Bruce Schneier says: “attacks always get better they never get worse”