[libre-riscv-dev] Spectre mitigation stratagies

[Jacob Lifshay]

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.

>
> Once and only once that register is ready.
>
> That means that a massive set of FUs may be allocated to deal with those
> elements, blocking all resources in exactly the way that causes spectre to
> occur.
>
> Thus yes, predication will affect and be affected.
>
> 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.

>
> Thus exceptions may also affect and be affected.
>
> It is not specifically the speculation it is the shadow capability, the
> blocking and holding of resources. Exceptions, predication, branch, these
> all hold resources that prevent non-speculating instructions from
> proceeding, thus resulting in successful timing attacks.
>
> Dealing with the predication would involve terminating further instruction
> issue until the predicate register has been read, decoded and allocated,
> and the preallocated masked out elements cancelled.
>
> In other words totally destroy the whole point of having an OoO
> architecture in the first place.
>
> Exceptions likewise, you cannot issue new instructions until the exception
> shadow knows if it is going to be successful or cleared.
>
> Again this utterly defeats the purpose of having an OoO architecture.
>
> Massively over-allocating on the number of FUs and ALUs and drastically
> cutting back on the instruction issue (particularly vector and especially
> on predication) MIGHT result in new instructions never blocking due to lack
> of FUs.
>
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>