> On Jan 18, 2018, at 8:49 AM, Joerg Sonnenberger <jo...@bec.de> wrote: > > On Wed, Jan 17, 2018 at 09:38:27PM -0500, Mouse wrote: >> But, on the other hand, I can easily imagine a CPU designer looking at >> it and saying "What's the big deal if this code can read that location? >> It can get it anytime it wants with a simple load instruction anyway.", >> something I have trouble disagreeing with. > > Consider something like BPF -- code executed in the kernel with an > enforced security model to prevent "undesirable" acceses. It will create > logic like: > > void *p = ...; > if (!is_accesible(p)) > raise_error(); > load(p); > > Now imagine that the expression for p is intentionally pointing into > userland and depends on the speculative execution of something else. > Loading the pointer speculatively results in a visible side effect that > defeats in part the access check. In short, it can effectively invert > access control checks for verified code.
Yes, you've just described Spectre. Since this involves a speculative load that is legal from the hardware definition point of view (the load is done by kernel code), this isn't a hardware bug the way Meltdown is. But it's an issue that requires a fix -- which is a speculative execution barrier between the software access check, and the subsequent code that is legal only if the check is successful. paul