Re: Spectre

[<Paul.Koning%dell.com@localhost>]

> On Jan 18, 2018, at 8:49 AM, Joerg Sonnenberger <joerg%bec.de@localhost> 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