x86, microcode: BUG: microcode update that changes x86_capability

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

The new Haswell microcode update[1] removes the "hle" (hardware lock
elision) processor capability.  And it is not cosmetic, either: Intel TSX
opcodes will cause an illegal opcode trap after the microcode update[2].

This means cpu_info()->x86_capability becomes stale after the microcode
update.

We could add logic to compute the new x86_capability after a microcode
update run, and OOPS the kernel if something too important (i.e. anything
the kernel uses) went away.  Otherwise, refresh cpu_info()->x86_capability.

Is that doable?


[1] sig 0x000306f2, pf mask 0x6f, 2014-09-03, rev 0x0029, size 28672
    sig 0x000306c3, pf mask 0x32, 2014-07-03, rev 0x001c, size 21504
    sig 0x00040651, pf mask 0x72, 2014-07-03, rev 0x001c, size 20480
    sig 0x00040661, pf mask 0x32, 2014-07-03, rev 0x0012, size 23552

[2] instantly segfaulting every running process using libpthread-2.19,
    as well as any other users of Intel TSX.
    https://bugs.launchpad.net/intel/+bug/1370352

    And yes, this means we will kill support for microcode updates
    outside of the initramfs/early-initramfs, at least in Debian,
    and likely in Ubuntu.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh