[libre-riscv-dev] Spectre mitigation stratagies

[Jacob Lifshay]

On Thu, Jan 10, 2019, 05:08 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

> On Thu, Jan 10, 2019 at 12:47 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > On Thu, Jan 10, 2019, 04:04 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> > wrote:
> >
> > > On Thu, Jan 10, 2019 at 1:17 AM Jacob Lifshay <
> programmerjake at gmail.com>
> > > wrote:
> > >
> > > > While we are designing the GPU, we should keep in mind that one way
> to
> > > > avoid spectre-style vulns is to design every part so that any
> instruction
> > > > following an earlier instruction can't affect the
> latency/issuability of
> > > > any earlier instruction. This will prevent some kinds of instruction
> > > timing
> > > > leaks.
> > >
> > >  ooo, that's gonna be a looot of work to research, and the
> > > micro-architecture is... well, getting to the point where i'm having
> > > to keep an eye on my "fear / achievability" antennae :)
> > >
> > > it may surprise you that, despite having a background in security, i'm
> > > *really annoyed* by the paranoia surrounding spectre.  it absolutely
> > > matters for Virtualisation / Hypervisor Server scenarios, however it
> > > doesn't matter a damn for a personal machine.
> > >
> > I disagree, it matters a lot for cases like web browsers where you are
> > running potentially malicious code (javascript from ads for example) and
> > you don't want it to be able to steal other important info.
>
>  darn-it, it's that bad, is it?
>
>  ok.  well, in one of the other messages you mentioned it's quite
> simple, just make sure that the ALUs are reset back to a known
> (identical) state after use, such that there will never be any changes
> in the time taken.  is that basically it?  because if so, that's quite
> simple.
>
That works for units that completely finish executing one instruction
before starting the next only when the instructions are executed in-order.

For units with pipelined or more complicated execution you need to ensure
that instructions' timing are not affected by later instructions, otherwise
you can leak data. For example:

fn f(a: &[u8], b: usize, private: &[usize]) -> u8 {
    let c = b % 12345; // slow op
    let v = a[c];
    if a.len() & 1 == 0 {
        v ^= a[private[b]];
    }
    v
}

if a[private[b]] started executing before a[c] since it's not delayed by
the remainder and the condition is mispredicted, then you can use a cache
bank conflict on loading from a (or something else) to tell you something
about the value of private[b] even though you're not reading it outside of
speculation, however, if later instructions can't affect the timing of
earlier instructions, then that particular mechanism won't work for leaking
data.

Jacob