[lkml]   [2014]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectx86, microcode: BUG: microcode update that changes x86_capability
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

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.

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

 \ /
  Last update: 2014-09-18 16:21    [W:0.137 / U:4.712 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site