[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