Re: Spectre

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

> It seems to me that blocking all observable side effects of
> speculative execution can probably only be done by disabling
> speculative execution outright.

Hmm.  Probably.

> That clearly isn't a good thing.

I agree it would not be a good thing to do globally.  Too many things
care too much about performance.

But I do think it is a good thing to have available.  Sandboxes, for
example, might want to do so when executing sandboxed code.  (Might.
Not, of course, always will; see also below.)

> The Spectre fixes all amount to a speculative barrier, which will do
> the job just as well (though it requires code change).

Yes...but it requires a code change in the wrong place.

That "if (access is ok)" check that needs a spec ex barrier could well
be inside a library that doesn't want to cripple performance for
non-sandboxed applications.  See also the spectre paper's description
of use of code that doesn't think it's making an access check but
happens to contain an instruction sequence that can be used that way.

I'd prefer to have a spec ex disable bit which the sandbox could set
for the duration of the sandboxed code.  (Actually, I'd like to have
"two and a half" such bits.  I'd like a privileged three-way choice and
an unprivileged bit: the privileged choice would be spec ex always on,
spec ex always off, or spec ex controlled by the unprivileged bit.
(I'm not sure there's much use case for the privileged "always on"
choice, but it would be easy to do and could be useful for something
like using normally-sandboxed environments for running
known-non-malicious code.)

/~\ 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