[Cryptography] Spectre again (was Re: RISC-V branch predicting)

[Perry E. Metzger]

On Sat, 10 Feb 2018 15:32:20 -0500 Jerry Leichter <leichter at lrw.com>
wrote:
> > Spectre is a completely different beast. It has nothing to do
> > with using speculative accesses bypassing memory protections....
> > 
> > One of the original proof-of-concept attacks for Spectre was a
> > Javascript applet that could read arbitrary memory in the
> > browser. Both the applet and the Javascript runtime execute in a
> > single process; there are no memory access controls between the
> > two in the first place.  
>
> Yes ... and no.
> 
> The Javascript is *intended* to be in a separate security domain
> from the rest of the browser.  The browser tries to maintain the
> separation in software.  Spectre proves once again - this has
> happened repeatedly, for decades - that pure software enforcement
> of security boundaries is very problematic.
[...]
> The whole notion that you can safely execute hostile code within a
> single hardware security domain is one we need to get away from.
> You want to run someone else's Javascript?  Run it in a separate
> address space and process.
[...]
> If even Unix
> processes are too expensive - which will likely be the response of
> browser makers to the notion that each individual piece of
> Javascript should be segmented off into its own process - then
> perhaps we should look at hardware and software models of very
> cheap hardware isolation.

So I'd like to highlight that. This is *the* key thing to remember. We
live in a world where there's lots of mutually hostile software
running inside a single address space. JavaScript stuff inside of
browsers is the biggest example, though there's also other things out
there (like the kernel BPF jit stuff in modern Linux, and there are
other things too.)

The obvious fix for Spectre here isn't easy, it's to either run that
hostile code only in its own process, or to provide hardware access
isolation even inside a single process. For some things, the former is
currently difficult.


Perry
-- 
Perry E. Metzger		perry at piermont.com