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:55:16 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Chuck Ebbert <cebbert.lkml@...il.com>,
	Andy Lutomirski <luto@...capital.net>
CC:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	linux-kernel@...r.kernel.org, Borislav Petkov <bp@...en8.de>
Subject: Re: x86, microcode: BUG: microcode update that changes x86_capability

We should, but this is also part of why we want the early ucode capability.

On September 18, 2014 12:53:28 PM PDT, Chuck Ebbert <cebbert.lkml@...il.com> wrote:
>On Thu, 18 Sep 2014 12:14:59 -0700
>Andy Lutomirski <luto@...capital.net> wrote:
>
>> 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?
>> 
>
>https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24290&lang=eng
>
>I can't find any release notes.
>
>Haswell-EP is also affected, it appears:
>
>http://techreport.com/news/26911/errata-prompts-intel-to-disable-tsx-in-haswell-early-broadwell-cpus
>
>> > 
>> > [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.
>> 
>
>All future updates for these CPUs will have this problem.

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
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/