linux-kernel - Re: [PATCH 01/13] x86/microcode/intel: Drop stashed AP patch pointer optimization

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:   Tue, 17 Jan 2017 20:59:14 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Borislav Petkov <bp@...en8.de>
cc:     X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 01/13] x86/microcode/intel: Drop stashed AP patch pointer
 optimization

On Tue, 17 Jan 2017, Borislav Petkov wrote:

> From: Borislav Petkov <bp@...e.de>
> 
> This was meant to save us the scanning of the microcode containter in
> the initrd since the first AP had already done that but it can also hurt
> us:
> 
> Imagine a single hyperthreaded CPU (Intel(R) Atom(TM) CPU N270 for
> example) which updates the microcode on the BSP but since the microcode
> engine is shared between the two threads, the update on CPU1 doesn't
> happen because it has already happened on CPU0 and we don't find a newer
> microcode revision.
> 
> Which doesn't set the intel_ucode_patch pointer and at initrd
> jettisoning time and we don't save the microcode patch for later
> application.
> 
> Now, when we suspend to RAM, the loaded microcode gets cleared so we
> need to reload but there's no patch saved in the cache.
> 
> Removing this optimization fixes this issue and all is fine and dandy.
> 
> Signed-off-by: Borislav Petkov <bp@...e.de>

So this one needs to go into x86/urgent

Reviewed-by: Thomas Gleixner <tglx@...utronix.de>