On Thu, Jan 18, 2018 at 7:58 AM, <paul.kon...@dell.com> wrote: > > > > 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. >
One difficulty with caches: You'd have to re-cache what you eject, otherwise there's an observable effect. That's the whole point of this family of attacks: the micro architecture does something that you can observe that you'd normally not be able to observe. It's really really hard to not leak any side-channel data at all. Side channel has become the new buffer overflow. Warner
