lkml.org 
[lkml]   [2014]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86, microcode: BUG: microcode update that changes x86_capability
On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote:
> 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

This is HSD136, right? Do you have a link to where that ucode comes
from? Does it have release notes?

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

Given that there is exactly one microcode update like this (at least of
the sort that blows up userspace), I think that we should seriously
consider blacklisting just this particular microcode update once
userspace is running.

--Andy


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