Re: Spectre

[<Paul.Koning%dell.com@localhost>]

> On Jan 18, 2018, at 10:31 AM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
>> ...
> 
>> 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. 

That's an option.  But for regular (not indirect) branches like the
example access check, most cases are not Spectre risks.  There is only
an issue if the speculatively loaded code is subjected to data dependent
actions that are visible through side channels.  For a lot of code, that
doesn't apply.

So yes, a spec ex barrier after such checks can affect performance 
somewhat.  But a "spec ex disable" bit that utterly turns off speculative
execution for sandboxed code will have an impact that's massively larger.
Easier to apply, sure -- well, once you have those bits which of course
right now you do not.  But a great deal more costly than spec ex
barriers applied with skill.

	paul