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 <[email protected]> wrote: > On 10/01/2018, Gerald Henriksen <[email protected]> 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 > > .................................................... >
