> On Jan 18, 2018, at 9:48 AM, Mouse <mo...@rodents-montreal.org> 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