[libre-riscv-dev] Spectre mitigation stratagies

[Hendrik Boom]

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.

> 
>  one "solution" would be to massively over-spec the shadow capability,
> such that absolutely all and any new instructions are absolutely
> guaranteed to never hit a resource limit.
> 
>  another is to say, "ok, so there's a new non-speculative instruction
> being issued: *right now*, it *has* to have absolute top priority, in
> this instruction cycle."  that means immediate cancellation of the
> newest speculated instruction using the resource that the
> non-speculative one needs.
> 
>  ... however, that trick won't work on exceptions, interrupts or
> predication, leaving "over-resourcing" and drastically cutting back on
> the instructions issued per clock.
> 
>  none of which is really acceptable.
> 
>  there has to be a better way, such as identifying (programmatically)
> the resources which are vulnerable, and limiting the issue and
> speculation during their operation.
> 
> l.
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev