tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: meltdown



>> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index