Re: meltdown

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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