Meltdown and Spectre information update

[Matthew Dillon]

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.

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.

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.

The mitigations we are looking at so far are:

(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.

(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.

(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.

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.

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.

--

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.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20180106/57435d05/attachment-0002.htm>