[libre-riscv-dev] Spectre mitigation stratagies

[Jacob Lifshay]

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

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Thu, Jan 10, 2019 at 10:02 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > 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.
>
>  starting to understand.
>
>  so let me get this straight: this basically comes down to the
> speculative branch firing off LD/ST operations that get cancelled?
>
not that they get cancelled, but that operations (not only ld/st) have
visible side-effects even though they've been canceled.

>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>