[libre-riscv-dev] Spectre mitigation stratagies

[Luke Kenneth Casson Leighton]

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.