Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Wed, 6 Dec 2023 22:21:45 +0100
From:   Borislav Petkov <bp@alien8.de>
To:     Jann Horn <jannh@google.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/microcode: Be more verbose, especially about loading
 errors
Message-ID: <20231206212145.GGZXDl6f/ho5olxNvq@fat_crate.local>
References: <20231206172844.1756871-1-jannh@google.com>
 <20231206195814.GDZXDSVgtCWspEJx8Q@fat_crate.local>
 <CAG48ez3weAU-Uti0QyBSDNRv8xYqCJ5UbgJvssEWAWpvyon0DA@mail.gmail.com>
 <20231206203158.GEZXDaPslvxtOS/gze@fat_crate.local>
 <CAG48ez3FwbqaU+hP6cAZEGWdHDJdEMuDyqW7SiYrDFf+rOt=bA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAG48ez3FwbqaU+hP6cAZEGWdHDJdEMuDyqW7SiYrDFf+rOt=bA@mail.gmail.com>
Precedence: bulk

On Wed, Dec 06, 2023 at 09:51:58PM +0100, Jann Horn wrote:
> Ah, right. I guess that's decent for diagnostics, though I think it
> would be nice to have a more explicit message about not finding a
> microcode update, since otherwise you'd have to read the kernel
> sources to figure out that you have to check for a missing second
> line.

I keep preaching scripting something around:

$ grep microcode /proc/cpuinfo | sort | uniq -c
     16 microcode       : 0x800820d

We also have:

$ grep -r . /sys/devices/system/cpu/vulnerabilities/
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines, IBPB: conditional, STIBP: disabled, RSB filling, PBRSB-eIBRS: Not affected
...

You could make sure that this says "no microcode" in the microcode
missing case or so and then grep that on large fleets, massage results
and dig into dmesg only on those which fail. Hopefully a small number.

> Yeah, fair, I guess that's a fairly visible indicator that something's
> wrong with microcode. (Though it doesn't tell you whether your
> microcode is just outdated or you have no microcode for the CPU
> family.)

So what you could do on AMD (probably similar on Intel too) is to fetch

git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

scan the microcode blobs in amd-ucode/

==========================================================
|  inst_cpu  |   err_msk  |   err_cmp  | eq_cpu |   res  |
==========================================================
| 0x00800f82 | 0x00000000 | 0x00000000 | 0x8082 | 0x0000 |
| 0x00830f10 | 0x00000000 | 0x00000000 | 0x8310 | 0x0000 |
| 0x008a0f00 | 0x00000000 | 0x00000000 | 0x8a00 | 0x0000 |
| 0x00800f12 | 0x00000000 | 0x00000000 | 0x8012 | 0x0000 |
| 0x00000000 | 0x00000000 | 0x00000000 | 0x0000 | 0x0000 |
----------------------------------------------------------
   ID: 0x0800820d, CPU rev ID: 0x00008082
   ID: 0x0830107b, CPU rev ID: 0x00008310
   ID: 0x08a00008, CPU rev ID: 0x00008a00
   ID: 0x0800126e, CPU rev ID: 0x00008012


ID are the latest released patch revisions. You then compare them to the
revision on the respective machine using that CPU rev ID which can be
computed from CPUID(1).EAX (inst_cpu) using the table above. Table is
also in the blob.

In the example above my workstation has microcode revision 0x800820d and
CPUID(1).EAX on it is 0x00800f82.

So all up to date. :-)

See, easy peasy. :-P

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette