linux-kernel - RE: [Patch v3 Part2 3/9] x86/microcode/intel: Fix collect_cpu

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, 31 Jan 2023 22:43:23 +0000
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     "Raj, Ashok" <ashok.raj@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Schofield, Alison" <alison.schofield@...el.com>,
        "Chatre, Reinette" <reinette.chatre@...el.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Stefan Talpalaru" <stefantalpalaru@...oo.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Jonathan Corbet <corbet@....net>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Peter Zilstra <peterz@...radead.org>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "Ostrovsky, Boris" <boris.ostrovsky@...cle.com>,
        Martin Pohlack <mpohlack@...zon.de>
Subject: RE: [Patch v3 Part2 3/9] x86/microcode/intel: Fix collect_cpu_info()
 to reflect current microcode

> T0 arrives, and fails the update. That is this piece:
>
>         /* write microcode via MSR 0x79 */
>         wrmsrl(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
>
>         rev = intel_get_microcode_revision();
> 
>         if (rev != mc->hdr.rev) {
>                 pr_err("CPU%d update to revision 0x%x failed\n",
>                        cpu, mc->hdr.rev);
>                 return UCODE_ERROR;
>         }
>
> We return here without updating cpu_sig.rev, as we should.
>
> T1 arrives, updates successfully and updates its cpu_sig.rev.

In an ideal world yes. But what if T1 arrives here and tries to do the
update while T0, which has returned out of the microcode update
code and could be doing anything, happen to be doing WRMSR(some MSR
that the ucode update is tinkering with).

Now T0 explodes (not literally, I hope!) but does something crazy because
it was in the middle of some microcode flow that got updated between two
operations.

-Tony