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

[H. Peter Anvin]

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@xxxxxxxxx> wrote:
>On Thu, 18 Sep 2014 12:14:59 -0700
>Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/