[libre-riscv-dev] Spectre mitigation stratagies

[Luke Kenneth Casson Leighton]

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.

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.

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