[libre-riscv-dev] Spectre mitigation stratagies

[Jacob Lifshay]

Eliminating Spectre-style bugs doesn't mean that we have to disable
speculation, it just means that we have to be able to completely roll back
speculation in a amount of time independent of what we were speculating,
and that the mis-speculated instructions can't affect timing of previous or
following instructions.

For simple pipelined alus that finish in the same order as started without
any structural hazards other than only being able to start a constant
number of instructions per clock all we need to do is issue the earliest
ready instructions each clock cycle.

For load/store, stores need to not write until they are non-speculative
(like usual) and loads need to execute in-order or ensure that bank
conflicts don't affect instructions becoming ready the next cycle and the
earlier instructions get priority.
We can still forward data from previous speculative stores (assuming there
isn't an acquire fence in between). We need to be able to completely
roll-back any changes to the caches, so we can wait until loads are
non-speculative to handle cache misses.

We also need to consider cache operations from other cores and ensure that
speculative operations are not visible.

We also need to consider speculation's impact on the instruction cache.

I'm ignoring power, rf, and other similar side-channels as completely
impractical to mitigate since we're not trying to NSA-proof the design.

Jacob

On Fri, Jan 11, 2019, 09:04 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

> On Fri, Jan 11, 2019 at 2:20 PM Hendrik Boom <hendrik at topoi.pooq.com>
> wrote:
> >
> > On Fri, Jan 11, 2019 at 10:49:16AM +0000, Luke Kenneth Casson Leighton
> wrote:
> > > On Fri, Jan 11, 2019 at 5:36 AM Jacob Lifshay <
> programmerjake at gmail.com> wrote:
> > >
> > > t for LD/ST.
> > > > > why would other operations be affected?
> > > > >
> > > > if a speculated instruction is using the last of some resource (alu,
> > > > register read port, etc.) and it prevents a non-speculative
> instruction
> > > > from executing, then the speculative instruction is canceled, you
> can tell
> > > > that they've been run because the non-speculative instruction took
> longer
> > > > to start. that delay could be data-dependent (like a predication
> mask in sv
> > > > or something).
> > >
> > >  but.... that's crazy!  that's going to affect *everything*!
> > > interrupts, exceptions, predication, branches, LD/ST - there's hardly
> > > a single part of the design that's going to be massively impacted,
> > > bringing performance to an absolute stand-still!
> >
> > Exactly.  And that's why we have Meltdown and Spectre on most hardware
> > in the world.  It is crazy.  We have to shut down specuative execution
> > to accompish this.
> >
> > One way around it is to provide the OS a way to let the CPU know
> > whether speculative execution is to be permitted.  Then for systems
> > where this kind of attack is infeasible for other reasons (such as
> > never executing suspect code), speculative execution could be turned
> > on, and for others, turned off.
>
>  yeah that aligns with my thoughts on it.  the problem is, for this
>  particular design, that'll be a pretty drastic impact.  nevermind...
>
>  so, it means having a state which a user-space application may say
> "if i am being executed i need protection from speculative execution".
>
>  on a context-switch, which will be on any system call or interrupt or
> anything else, the processor would need to purge state...
>
>  this needs a lot of thought.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>