>> "Possibly more"? Anything that does speculative execution needs a >> good hard look, and that's damn near everything these days. > I wonder about just "these days". The potential for this kind of > problem goes all the way back to STRETCH or the 6600, doesn't it?
I don't know; I don't know enough about either. > Though of course "fail early" is an obvious principle to security > types, given the cost of aborting work in progress I can easily see > the opposite being true for CPU designers I think it's less the cost of aborting work in progress and more the (performance) cost of not keeping silicon busy all the time. > (I'm not one, so I don't really know). Me neither. But it seems passing obvious to me that these hardware bugs were at least partially driven by customer demand for performance. And, to be sure, there are workloads for which neither meltdown nor spectre is a significant risk, even if the hardware is vulnerable. > Which idiom (check permissions, then speculate / speculate, then > check permissions) is more common? I don't know. But the problem is only partially when permissions get checked. Consider spectre used by sandboxed code to read outside the sandbox within a single process; this is doing nothing that, from the hardware point of view, would violate permissions. I could easily see a CPU designer saying "So what's the problem if the code can read that memory? It can read it anytime it wants with a simple load anyway.". The problem is also failure to roll back _all_ side effects when annulling speculative execution. (To be sure, even if that were done it wouldn't fix quite the whole problem; closing one side-channel doesn't necessarily close other side-channels. But it would help.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
