>> 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'm not one, so I don't >> really know). Which idiom (check permissions, then speculate / >> speculate, then check permissions) is more common? > No idea, one would think that failing early in order to avoid > unnecessary resource usage would be useful.
Perhaps, but _not_ failing is a win if it turns out the spec ex is confirmed instead of annulled. And if the silicon would be sitting idle otherwise, the only resource used is power. (And die area, but that's used in a static sense, not a dynamic sense.) > Then again, the problem seems to be that not everything from the > speculative path gets canceled / annulled, not so much that the > speculation took place. I agree. For cache issues...it might be useful to freeze spec ex on a cache miss. Go ahead and service the cache miss, but keep the result in a separate cache line, not part of the normal cache. On annullment, just drop it; on confirmation, push it into the normal cache and unfreeze. If you want to get really fancy, have multiple speculative cache lines, kind of a small cache in front of the regular cache purely for speculative use, and don't freeze speculation unless it fills up. Though the spectre (ha ha) of coherency then raises its ugly head. Does anyone know how the typical time to service a cache miss compares with the typical time to determine whether spec ex is annulled or confirmed? If the former is longer, or at least not much shorter, than the latter, then this wouldn't even impair performance much in the miss case. Of course, this wouldn't do anything about covert channels other than the cache. But it'd stop anything using the cache for a covert channel between spec ex and mainline code cold (meltdown and some variants of spectre). It's only a partial fix, but, for most purposes, that's better than no fix. Of course, some of the covert channels touched on in the spectre paper are not fixable, such as power consumption and EMI generation; fortunately, they are significantly harder to read from software. /~\ 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