Tweet
Originally posted by scorpio810
View Post
variant 1 is about bound check bypass -
it's still speculative execution working as it should, only some people have found way to measure indirectly side-effect (pages being fetched into cache).
But it's still a program only accessing data to which it has already access.
there isn't much to be done to *fix* it (beyond completely new CPUs that also flush speculatively fetched cache, in addition of not comiting result to memory register ; or CPUs that don't do speculative execution at all).
but you can fix your code and program: avoid running 3rd party provided code (eg.: Javascript JIT ; kernel EBPF JIT) in the same context as sensitive data (resp.: in the same process as password managing extension ; in the kernel context).
Also some CPUs like the Pentium4 support branch prediction hinting and you could use them to ask the processor to never speculatively execute past a boundary check in case of speculative execution of 3rd party code.
in other word: until some future CPU fixes its speculative execution, or using a CPU that doesn't execute speculatively (older Intel Atoms, lots of RISC CPU like older ARMs) it's going to say "Spectre_v1:Vulnerable" forever
variant 2 is about the indirect branch predictor getting confused and using the wrong table (e.g.: one that was filled by an attacker running a special program) when running an entirely unrelated and different program (e.g.: a Hyper Visor) due to the way the predictor is implemented (in Google's demo code : both the attacker's program and the targeted program have the same "hash" for the jump instruction) leading the CPU to jump and start speculatively predicting at a completely wrong target.
that's the one which is fixed by firmware updates and retpolines.
That's the one which should change status depending on the compiler that was used (only retpoline manually specified in ASM code, or GCC compiler able to also automatically do them in C code) and/or firmware.
Also it's entirely dependent on how each CPU implements its own peculiar indirect branch prediction.
Intel CPUs are known to be vulnerable, and Google has published demo code.
AMD should be vulnerable, but the way I read the official documentations is that it's not clear if you can actually use that to make an usable real-world exploit
(the Google demo code obviously won't work being taylored after the predictor of a completely different CPU).
A few modern ARM are reported to be vulnerable (I haven't read anything about this actually being exploitable).
I've read that PowerPC G3 and G4 cannot be actually exploited in practice (they are vulnerable, but their speculative execution doesn't go far enough to lead anything exploitable).
Comment