> 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. > 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. The _right_ fix is for the side effects (cache, among others) to be annulled along with the overt effects when spec ex is annulled. Spec ex barriers are just a workaround to hide the worst of the effects of the bug in buggy hardware - there's so much buggy hardware out in the field that _some_ kind of mitigation measure is appropriate - but workarounds should not be confused with fixes. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
