linux-kernel - Re: x86, microcode: BUG: microcode update that changes x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Sep 2014 12:14:59 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	linux-kernel@...r.kernel.org
CC:	Borislav Petkov <bp@...en8.de>, H Peter Anvin <hpa@...or.com>
Subject: Re: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/