To address Spectre, I assume these patches involve turning off speculative execution in some way. These various benchmarks that seem to show very little performance degradation after the patch should perhaps lead to the question "why was the processor ever doing that in the first place if cutting it out barely affects performance?".
edit: And if its not turning off speculative execution, how is it addressing Spectre? Because I thought that was the only way.
To be fair, the Source of the benchmarks is Intel itself, aka
the one place you should not take the numbers from due to conflict of interest, no matter if they actually are accurate or not.
It doesn't help that during this whole thing, Intel behaved very much like the Iraqi propaganda minister. If they had been a bit more honest from the start, maybe I'd be keener to take their numbers at face value.
My understanding was that the Spectre microcode patches give software a way to block speculative execution (via an MSR register) and to make the lfence instruction also block speculative execution. So, software support will also be needed to make use of these features in defending against Spectre.
What's being measured here must be mainly the impact of the Meltdown fixes.
All they're measuring is the output of their "fixes". Intel has said at least twice that they consider their scope to be how to provide ways to mitigate spectre attacks.
These microcode patches don't turn off speculative execution, they only give a way for the operating system to temporarily and/or partially turn it off and/or flush the branch prediction state (precise explanations are hard to come by).
This is why benchmarks which use more heavily the operating system are affected the most, while benchmarks which stay in user mode doing computations are affected the least.
The meltdown mitigation is to move the OS to a different namespace, and flush the TLB between changes.
Spectre comes in two varieties, the generic branch avoidance "boundary check bypass", and the BTB poisoning one.
The solution to boundary check bypass is to just surrender and document branches as unsuitable for providing security boundaries. Going forward, "branch on out of bounds" is going to be replaced by using unconditional math to clamp access to the array boundary. In any case, this is of very marginal utility to an attacker, because it's only useful if there is some privileged information within an address space where the attacker gets to write code. Really only useful in JIT situations, and those will be quickly fixed in software.
The other half of spectre, the BTB poisoning, is much more scary, as it allows you to inject arbitrary code to an arbitrary process (or kernel!) running on the same CPU. (The limitation is that you only get to run until the branch reaches retirement, and you can only communicate with the rest of the world through cache timing.) This one will be hotfixed by retpolines in software, then fixed by ucode changes that provide options to flush the BTB, and in the long term fixed in hardware by tagging BTB entries better.
Meltdown mitigations do not flush the TLB when changing from kernel to/from user when the PCID feature is in place. That's basically everywhere from Haswell on (for Linux and Windows), and in some places as early as Nehalem (>= 4.9 kernels on Linux, not Windows).
My browser process can read plenty of sensitive information and with js and now streaming wasm JIT increasing the attack vector, I’m not so sure I trust the “quickly fixed in software” :)
Yeah, BTB tagging is probably a lot better than flushing performance wise.
The quick fix is pointer poisoning and sanitizing pointers before access.
For example, if the code of a JS array does p%arraylength before using p, it makes the spectre 1 vulnerability impossible to exploit. Browsers with JIT engines are also very quickly patched software, and afaict all the major browsers have fast-tracked changes to prevent spectre 1. At this point, spectre 1 is no longer a major threat.
In any case, many people are misinformed that disabling speculation is a viable fix. It really isn't -- completely disabling speculation means that every branch has a cost of ~20 cycles and serializes execution around it. Current normal x86 code executes a branch every 5-10 instructions (generally, more when using dynamic languages, less when using static compiled-to-metal languages). Executing branches so often doesn't ruin performance because branch predictor hit rates are >95%, as most of those branches are basically guards, type checks and the like which are almost never taken. Disabling speculation would make modern high-end CPUs spend the vast majority of their time just waiting for the branches to resolve.
There is no, and can be no hardware fix to this. The only solution is just to accept that you cannot use a branch alone to protect secret data.
edit: And if its not turning off speculative execution, how is it addressing Spectre? Because I thought that was the only way.