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] [day] [month] [year] [list]

Message-ID: <20180222175129.4nluqvqdowrm6jv3@khazad-dum.debian.net>
Date:   Thu, 22 Feb 2018 14:51:29 -0300
From:   Henrique de Moraes Holschuh <hmh@....eng.br>
To:     "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
Cc:     "Raj, Ashok" <ashok.raj@...el.com>, 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>,
        "Luck, Tony" <tony.luck@...el.com>,
        "Kleen, Andi" <andi.kleen@...el.com>,
        Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [v2 1/3] x86/microcode/intel: Check microcode revision before
 updating sibling threads

On Thu, 22 Feb 2018, Van De Ven, Arjan wrote:
> > > 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*.
> 
> yes we will update the SDM, just that is a much longer process than sending code out.
> 
> > 
> > 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.  
> 
> I'd be surprised if it did not. 

The question would be better phrased as: important to which processors?
Just very old ones?

The late microcode update loader has it 16-byte aligned as a side-effect
of malloc() from what I recall when I tested it with SLUB, SLAB (I am
not sure about what the result was for SLOB), so it is an issue that was
introduced with the early initramfs microcode loader support.

However, the early loader doesn't have that benefit for the BSP.  If the
16-byte alignment were important for most stuff since the Core2, we
should be crashing like crazy when attempting early microcode updates...

Thus, apparently, 4-byte alignment (which we do always get out of the
early initramfs) is good enough on most non-ancient processors when
updating the BSP the way Linux does it, since it does work for most
people.

I don't recall what the situation is for the APs for the early loader,
though.

> >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.
> 
> hmm wonder what those tools do nowadays; Intel publishes the microcode
> in the linux native format since some time (and the .dat format is
> about to go away entirely)

I think most of them don't force the alignment in userspace.  The
exceptions are Debian, Ubuntu, and their derivatives when using
initramfs-tools (not dracut).

I do belive there are a few that generate /boot/ucode.initrd to load as
the first initrd via the bootloader using iucode_tool --write-earlyfw
(instead of using cpio).  That would also have the workaround in place.

-- 
  Henrique Holschuh