<div dir="ltr">The Meltdown protection is now stable in the master branch.  A number of minor bugs were fixed after the initial commit.  I am looking into possibly getting into -stable but I don't know yet.<div><br></div><div>We have continued to look into mitigations for the second (more difficult) attack called Spectre.  Unfortunately, it looks like there is no single mitigation for this attack that works well, and different Intel and AMD cpus need different variations to have any positive effect.  Meaning it winds up being a HUGE messy hack that nobody really wants to have to do.  Also, none of the mitigations recommended so far completely protect against Spectre.  I would argue, in fact, that the mitigations only amount to a small roadbump for attackers and will probably be defeated now that the attack vector is known.</div><div><br></div><div>Nothing short of new hardware (not yet produced) will really make a dent in Spectre.  That could be 6 months to a year away, depending on how big a fire is lit under the CPU vendors.</div><div><br></div><div>The mitigations we are looking at so far are:</div><div><br></div><div>(1) Similar to the MMU switch-er-oo we do on Intel cpus for Meltdown, we can insert another sequence of instructions (called a call cascade) to try to clean out the branch prediction cache to make Spectre attacks on the kernel more difficult.  This is effective on Intel CPUs older than Broadwell, but ineffective (or less effective) on Intel CPUs that are Broadwell or newer.</div><div><br></div><div>(2) Intel is supplying a Microcode patch for newer CPUs, but it's hard to say how many BIOS makers will ever adopt it.  This patch hacks up a few MSRs that kernels are supposed to use at user->kernel boundaries.  The problem here is that the MSR's are a stop-gap at best, not a solution, and are unlikely to be widely deployed on systems.  Plus, apparently, they have a fairly severe performance penalty, and only represent a partial mitigation.  In otherwords, a very poor hack by Intel.  Intel wants people to implement their poor hack, even though it will likely be supplanted later on.</div><div><br></div><div>(3) The most common Spectre attack is against the browser (e.g. a javascript attack against the client browser), which is to say an attack which does not cross a protection domain and thus mitigation #1 and #2 above won't have any effect.  The only solution to this sort of attack is to recompile the browser with a hacked up GCC that implements mitigations for indirect procedure calls (which is the most common victim code for a Spectre attack to target).  Again, these are only partial mitigations.</div><div><br></div><div>The same compile foo would also have to be applied to the kernel to some degree.  Again, not fun and there's also the question of recompiling every single port using the hacked up compiler, not to mention the fact that there are dozens of languages out there that won't have this kind of code generation and will NEVER have a compiler-based mitigation.</div><div><br></div><div>In otherwords, all of our options are bad.  Spectre will not be mitigated in any real sense on any existing CPU.  Until new CPUs start appearing down the line, 6 months or later from now, we are kind of all screwed.  All of these mitigation's will probably be worked around by attackers in fairly short order.</div><div><br></div><div>--</div><div><br></div><div>For DragonFlyBSD, I'm looking into at least trying to do some of the kernel mitigations for Spectre.  But even if we do, nobody should feel relieved about it because their effectiveness (for all operating systems) and penetration will be low.</div><div><br></div><div><div>-Matt</div></div></div>