[libre-riscv-dev] Spectre mitigation stratagies

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, Jan 11, 2019 at 11:13 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Fri, Jan 11, 2019, 14:44 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> wrote:
>
> > On Saturday, January 12, 2019, Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > 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.
> > >
> > >
> > Predication is done by having a FU that, similar to a Branch FU, throws a
> > shadow across the units allocated to elements waiting for the predication
> > FU to get the opportunity to read the predication register.
> >
> predication can be done by not issuing masked-out instructions when the
> predication register is known, when it's not known, you can issue the
> instructions and mask writes with the predication register, allowing faster
> progress to be made.

 yes when the predicate is known, no problem, immediate progress can
be made, mask-out, great.  [reading the predicate in the instruction
issue phase however would be problematic, as it means that the
instruction issue phase has to have a read port to the *four* register
file banks... so this is why i propose the predication register read
and analysis be handled by a Function Unit]

 in the case where it's not known, if VL=4 that means that 4 Function
Units need to be reserved for (element-based) use, otherwise it would
be absolute hell on earth to re-resolve the Function Unit dependencies
trying to put them "back in".

 ... except that it might *not* be exactly 4, because predication
masks some of them out.

hence the reason why FUs need to be reserved, hence the reason why
resources will be "blocked".

> > Likewise exceptions, which do not get evaluated for triggering until they
> > are free of write hazards, and are at the head of the instruction "oldest
> > order", they still hold up resources, preventing writes by throwing a write
> > shadow across instructions that could be cancelled, thus blocking access to
> > resources.
> >
> You can treat exceptions just like branches, predicting as not taken, and
> issue the instructions following them. You just have to roll them back in
> constant time on a mis-prediction.

 ok so that i think can be done.  the unwinding (the shadows) are not
a chain, the shadow wires are held individually against each
down-stream instruction, so they may all be cancelled very quickly.

 this however does not solve an additional problem that i believe exists.

 my understanding is that whilst non-constant rolling-back time is a
problem, i believe that there is a *separate* and *additional* problem
(one that constant roll-back time does not solve): the fact that the
exceptions are allocated (and thus blocking) resources *at all*.

 is that the case?

l.