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]

Message-ID: <CALCETrXz1aGqqUiczykeHhxSSRhEZ=qnj-RsyFhoz565YTKEpw@mail.gmail.com>
Date:	Wed, 24 Sep 2014 10:48:57 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Borislav Petkov <bp@...en8.de>,
	Chuck Ebbert <cebbert.lkml@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: x86, microcode: BUG: microcode update that changes x86_capability

On Wed, Sep 24, 2014 at 10:45 AM, Henrique de Moraes Holschuh
<hmh@....eng.br> wrote:
> On Wed, 24 Sep 2014, Andy Lutomirski wrote:
>> On Wed, Sep 24, 2014 at 7:56 AM, Henrique de Moraes Holschuh
>> <hmh@....eng.br> wrote:
>> > And I'd really prefer it to be "update x86_capability, warn the user and
>> > carry on" for anything that is not going to crash the kernel.  Several
>> > distros will really want this backported to -stable, as the older kernels
>> > cannot do early microcode updates.
>> >
>>
>> I'm trying to see if Intel is willing to document any additional
>> controls for the TSX bits in this ucode.  No word yet, but I might
>> hear something soon.
>
> If they do document it, please make sure to ask what will happen in the
> following situation:
>
>    Assume there is a newer release of Intel microcode for these
>    processors, i.e. newer than the microcodes in the 2014-09-13 release.
>    IOW assume there are at least two public microcode updates in which the
>    Intel TSX feature has been disabled by default, but can be enabled by
>    the BIOS/UEFI.
>
>    1. BIOS/UEFI has recent microcode (which has the Intel TSX on/off
>       switch), but it is not the latest microcode, and installed this
>       update on the processor.
>
>    2. BIOS/UEFI has *enabled* Intel TSX on user request.
>
>    3. Microcode is updated to the latest microcode by the operating
>       system, newer than the one in BIOS/UEFI.
>
>    After step 3, will Intel TSX be enabled, or disabled ?
>
> Or, to be more explicit: will future microcode updates preserve Intel TSX
> enabled/disabled state, or will they always reset it to disabled?
>
> This is really important, for obvious reasons.
>

Indeed.

We can sort of fudge it if whatever control BIOS uses is available to
us, too, and we can reprogram it to "enabled" after a microcode update
disables TSX.

If I had one of the affected chips, I'd try scanning the MSR space to
see if a new MSR appears after applying the update.  But I don't, so I
can't do this.

--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/