Re: x86, microcode: BUG: microcode update that changes x86_capability

[Andy Lutomirski]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/