<div dir="ltr">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.<div><div><br></div><div>On all Intel CPUs the mmu separation reduces performance by around 3.7% for general computinng.</div><div><br></div><div>On Haswell, kernel-only IBPB mode (MSR 0x48=1) we lose 12%, and IBPB all the time we lose 53%.</div><div><br></div><div>On Skylake, kernel-only IBPB mode (MSR 0x48=1) we lose 5%, and IBPB all the time we lose around 24%.</div><div><br></div><div>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.</div><div><br></div><div>For Haswell mode 2 performance (IBPB on all the time) is so horrendous I don't think anyone is going to use it.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>machdep.meltdown_mitigation (set to 0 or 1)</div><div><br></div><div>machdep.spectre_mitigation (set to 0, 1, or 2 -- requires appropriate microcode)</div><div><br></div><div>-Matt</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 9, 2018 at 9:53 PM, Bret Busby <span dir="ltr"><<a href="mailto:bret.busby@gmail.com" target="_blank">bret.busby@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/01/2018, Gerald Henriksen <<a href="mailto:ghenriks@gmail.com">ghenriks@gmail.com</a>> wrote:<br>
> On Tue, 9 Jan 2018 18:26:54 +0000, you wrote:<br>
><br>
>>but I really don't know if it's just an Intel lie at this point (wouldn't<br>
>> be the first one on this fiasco... maybe they just want to avoid a<br>
>> recall)<br>
><br>
> Like it or not, everything coming out of Intel on this will likely<br>
> have gone through their lawyers with the aim of limiting any legal<br>
> damage, and thus truth loses. It is the way of the world.<br>
><br>
> As for the idea of a recall*, won't happen. As pointed out elsewhere,<br>
> this involves 20+ years of processors. Intel has neither the money<br>
> nor the fab capabilitity to implement a recall of that many<br>
> processors.<br>
><br>
><br>
> * - certain select users may get deals made for new processors, things<br>
> like the supercomputer clusters, where the number of processors is<br>
> relatively small but there is a possible big impact.<br>
><br>
<br>
"As pointed out elsewhere, this involves 20+ years of processors."<br>
<br>
</div></div>Seeking clarification - I understood, from all of the reports, from<br>
multiple sources, that I have seen, that it applies to "all processors<br>
manufactured in the last ten years".<br>
<br>
Please clarify.<br>
<br>
<br>
--<br>
<br>
Bret Busby<br>
Armadale<br>
West Australia<br>
<br>
..............<br>
<br>
"So once you do know what the question actually is,<br>
you'll know what the answer means."<br>
- Deep Thought,<br>
Chapter 28 of Book 1 of<br>
"The Hitchhiker's Guide to the Galaxy:<br>
A Trilogy In Four Parts",<br>
written by Douglas Adams,<br>
published by Pan Books, 1992<br>
<br>
..............................<wbr>......................<br>
</blockquote></div><br></div>