Re: Spectre

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

> On Jan 18, 2018, at 9:48 AM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>> 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.
> 
> Well, I'd say it's the same fundamental hardware bug as meltdown, but
> not compounded by an additional hardware property (which I'm not sure I
> would call a bug) which is made much worse by the actual bug.
> 
> To my mind, the bug here is that annulling spec ex doesn't annul _all_
> its effects.  That, fundamentally, is what's behind both spectre and
> meltdown.  In meltdown it's exacerbated by spec ex's failure to check
> permissions fully - but if the side effects were annulled correctly,
> even that failure wouldn't cause trouble.

That's true.  But the problem is that cache fill is only the most
obvious and easiest to exploit side channel.  There are others, such
as timing due to execution units being busy, that are harder to exploit
but also harder to cure.  It seems to me that blocking all observable
side effects of speculative execution can probably only be done by
disabling speculative execution outright.  That clearly isn't a good
thing.  The Spectre fixes all amount to a speculative barrier, which
will do the job just as well (though it requires code change).  The
Meltdown fix is more obvious: don't omit mode dependent access checks
before launching a speculative load, as most CPU designers already did.

	paul