[libre-riscv-dev] Spectre mitigation stratagies

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Jan 11 05:12:22 GMT 2019


---
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?

l.



More information about the libre-riscv-dev mailing list