Clarifying the Spectre mitigations...

[Matthew Dillon]

All Intel processors in the last 10 years except a few Atoms are affected.
So, for all intents and purposes, all Intel processors in the last 10 years.

On all Intel CPUs the mmu separation reduces performance by around 3.7% for
general computinng.

On Haswell, kernel-only IBPB mode (MSR 0x48=1) we lose 12%, and IBPB all
the time we lose 53%.

On Skylake, kernel-only IBPB mode (MSR 0x48=1) we lose 5%, and IBPB all the
time we lose around 24%.

Combine the two together and it's pretty nasty.  Best-case Skylake we lose
8.7% in performance with both mitigations active, kernel-only for IBPB, and
we lose 27.7% performance (approximately) with bot mitigations active, IBPB
on all the time.

For Haswell mode 2 performance (IBPB on all the time) is so horrendous I
don't think anyone is going to use it.

I haven't even put any RetPoline stuff in yet.  That will require a lot of
compiler work, which zrj is doing.  However, RetPoline is not expected to
reduce performance much more.

Note that none of this stuff represents a complete fix for Spectre.  Not
even full-on IBPB mode.  It will take new hardware to get a more complete
fix plus our performance back.  Basically the branch prediction cache will
need to tag the protection domain and either PCID or be cleared on %cr3
reload.  And possibly also tag more address bits which it doesn't right now.

DragonFly now has an initial support for spectre and Intel microcode
updates.  I also renamed the sysctl/tunable for mmu separation.  The two
sysctl's are now:

machdep.meltdown_mitigation  (set to 0 or 1)

machdep.spectre_mitigation  (set to 0, 1, or 2 -- requires appropriate
microcode)

-Matt

On Tue, Jan 9, 2018 at 9:53 PM, Bret Busby <bret.busby at gmail.com> wrote:

> On 10/01/2018, Gerald Henriksen <ghenriks at gmail.com> wrote:
> > On Tue, 9 Jan 2018 18:26:54 +0000, you wrote:
> >
> >>but I really don't know if it's just an Intel lie at this point (wouldn't
> >> be the first one on this fiasco... maybe they just want to avoid a
> >> recall)
> >
> > Like it or not, everything coming out of Intel on this will likely
> > have gone through their lawyers with the aim of limiting any legal
> > damage, and thus truth loses.  It is the way of the world.
> >
> > As for the idea of a recall*, won't happen.  As pointed out elsewhere,
> > this involves 20+ years of processors.  Intel has neither the money
> > nor the fab capabilitity to implement a recall of that many
> > processors.
> >
> >
> > * - certain select users may get deals made for new processors, things
> > like the supercomputer clusters, where the number of processors is
> > relatively small but there is a possible big impact.
> >
>
> "As pointed out elsewhere,  this involves 20+ years of processors."
>
> Seeking clarification - I understood, from all of the reports, from
> multiple sources, that I have seen, that it applies to "all processors
> manufactured in the last ten years".
>
> Please clarify.
>
>
> --
>
> Bret Busby
> Armadale
> West Australia
>
> ..............
>
> "So once you do know what the question actually is,
>  you'll know what the answer means."
> - Deep Thought,
>  Chapter 28 of Book 1 of
>  "The Hitchhiker's Guide to the Galaxy:
>  A Trilogy In Four Parts",
>  written by Douglas Adams,
>  published by Pan Books, 1992
>
> ....................................................
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20180109/ded5d11d/attachment-0003.htm>