[libre-riscv-dev] Spectre mitigation stratagies

[Jacob Lifshay]

On Thu, Jan 10, 2019, 04:04 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

> On Thu, Jan 10, 2019 at 1:17 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > While we are designing the GPU, we should keep in mind that one way to
> > avoid spectre-style vulns is to design every part so that any instruction
> > following an earlier instruction can't affect the latency/issuability of
> > any earlier instruction. This will prevent some kinds of instruction
> timing
> > leaks.
>
>  ooo, that's gonna be a looot of work to research, and the
> micro-architecture is... well, getting to the point where i'm having
> to keep an eye on my "fear / achievability" antennae :)
>
> it may surprise you that, despite having a background in security, i'm
> *really annoyed* by the paranoia surrounding spectre.  it absolutely
> matters for Virtualisation / Hypervisor Server scenarios, however it
> doesn't matter a damn for a personal machine.
>
I disagree, it matters a lot for cases like web browsers where you are
running potentially malicious code (javascript from ads for example) and
you don't want it to be able to steal other important info. For cases like
industrial controllers or kiosks, where you are never running untrusted
code, I completely agree with you.

>
> i.e.: if you've given someone physical access to a personal machine
> (desktop, tablet, laptop), all bets are off in ways that make spectre
> etc. completely irrelevant.
>
> if we were going to put Hypervisor Mode in it, and if it was intended
> as a server-class chip, i would *absolutely* be concerned, and agree
> 100%.  the first target market for this chip - even for industrial
> embedded - is totally different as far as the threat / risk analysis
> is concerned.
>
> that having been said: if it's _really easy_ to avoid those kinds of
> vulnerabilities, then yes, let's do it.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>