linux-kernel - Re: [v2 1/3] x86/microcode/intel: Check microcode revision before updating sibling threads

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: <20180222154605.er6llhcaxmie3rhr@khazad-dum.debian.net>
Date:   Thu, 22 Feb 2018 12:46:05 -0300
From:   Henrique de Moraes Holschuh <hmh@....eng.br>
To:     "Raj, Ashok" <ashok.raj@...el.com>
Cc:     Borislav Petkov <bp@...e.de>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        Andi Kleen <andi.kleen@...el.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>
Subject: Re: [v2 1/3] x86/microcode/intel: Check microcode revision before
 updating sibling threads

On Thu, 22 Feb 2018, Raj, Ashok wrote:
> On Thu, Feb 22, 2018 at 01:15:06PM +0100, Borislav Petkov wrote:
> > On Thu, Feb 22, 2018 at 03:55:54AM -0800, Raj, Ashok wrote:
> > > The current code wasn't trying to enforce checking the loaded microcode revision on a thread
> > > before attempting to load the microcode. While you comeback from resume, if C0T0 already
> > > is up, and we loaded the early microcode, then when handling C0T1 there is no need to 
> > > do a wrmsrl to reapply microcode since its already loaded as part of C0T0. 
> > 
> > And I'm asking exactly this: is it simply "we don't need to do WRMSR" or
> > "we should not"?
> > 
> > Because avoiding the WRMSR costs more than simply doing it and letting
> > the HT thread ignore the supplied microcode.
> 
> This isn't a simple WRMSR like others. Microcode engine needs to do 
> a bunch of validation.
> 
> > 
> > If it is "we don't need to but there's nothing wrong when we do it" then
> > we don't need this patch. And I'm pretty sure "nothing wrong when we do
> > it" would be the answer. Otherwise we have bigger problems.
> 
> In the past the only guidance was to not load microcode at the same time to the 
> thread siblings of a core. We now have new guidance that the sibling must be 
> spinning and not doing other things that can introduce instability around loading 
> microcode.

Document that properly in the Intel SDM, *please*.

While at it, please verify with the microcode teams that the requirement
for 16-byte alignment of the microcode update as present in the Intel
SDM still stands.  Linux does not enforce it on the early microcode
update loader when using an initramfs (but userspace can work around
that, and iucode_tool --early-fw does so).  If that 16-byte alignment is
important, I could dust off some patches that fix it.

-- 
  Henrique Holschuh