Re: Intel CPUs' Kernel Page Table Isolation (KPTI) fix

I wrote:

> Update:  Intel Corp. advised on Monday to _not_ run the existing
> mitigation patches Broadwell and Haswell platforms, because they are
> causing spontaneous reboots 'and other unpredictable system behavior'.

This _may_ have been prompted, in part, by the inimitable Linus Torvalds
erupting in a widely noticed LKML thread to say that Intel's IBRS
(Indirect Branch Restricted Speculation) remediations for the Spectre
variant 2 vulnerability are incompetent 'garbage patches' that do
'literally insane things, [...] things that do not make sense.'

[commenting to David Woodhouse:

  Have you _looked_ at the patches you are talking about? You should
  have - several of them bear your name.

  The patches do things like add the garbage MSR writes to the kernel
  entry/exit points. That's insane. That says "we're trying to protect
  the kernel". We already have retpoline there, with less overhead.

  So somebody isn't telling the truth here. Somebody is pushing complete
  garbage for unclear reasons. Sorry for having to point that out.

  If this was about flushing the BTB at actual context switches between
  different users, I'd believe you. But that's not at all what the
  patches do.

  As it is, the patches are COMPLETE AND UTTER GARBAGE.

  They do literally insane things. They do things that do not make
  sense. That makes all your arguments questionable and suspicious. The
  patches do things that are not sane.

  WHAT THE F*CK IS GOING ON?

  And that's actually ignoring the much _worse_ issue, namely that the
  whole hardware interface is literally mis-designed by morons.

  It's mis-designed for two major reasons:

  - the "the interface implies Intel will never fix it" reason.

  See the difference between IBRS_ALL and RDCL_NO. One implies Intel
  will fix something. The other does not.

  Do you really think that is acceptable?

  - the "there is no performance indicator".

  The whole point of having cpuid and flags from the
  microarchitecture is that we can use those to make decisions.

  But since we already know that the IBRS overhead is <i>huge</i> on
  existing hardware, all those hardware capability bits are just
  complete and utter garbage. Nobody sane will use them, since the cost
  is too damn high. So you end up having to look at "which CPU stepping
  is this" anyway.

  I think we need something better than this garbage.


http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html

However, as Torvalds's interlocutor David Woodhouse then immediately
pointed out, IBRS does work well enough on Intel Skylake architectures,
and retpoline on all the other affected Intel architectures, so this is
not quite the crisis Torvalds's rant would suggest:

  That's why my initial idea, as implemented in this RFC patchset, was to
  stick with IBRS on Skylake, and use retpoline everywhere else.  I'll
  give you "garbage patches", but they weren't being "just mindlessly
  sent around".  If we're going to drop IBRS support and accept the
  caveats, then let's do it as a conscious decision having seen what it
  would look like, not just drop it quietly because poor Davey is too
  scared that Linus might shout at him again. :)

http://lkml.iu.edu/hypermail/linux/kernel/1801.2/05282.html