linux-kernel - Re: [PATCH] x86/cpu/amd: Correct the microcode table for Zenbleed

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: <133ac0c0-8cbb-4c75-a81f-5e2823e1b9dc@citrix.com>
Date: Wed, 26 Nov 2025 11:33:43 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Borislav Petkov <bp@...en8.de>,
 Mario Limonciello <mario.limonciello@....com>, x86@...nel.org,
 Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: [PATCH] x86/cpu/amd: Correct the microcode table for Zenbleed

On 26/11/2025 11:26 am, Andrew Cooper wrote:
> The good revisions are tied to exact steppings, meaning it's not valid to
> match on model number alone, let alone a range.
>
> This is probably only a latent issue.  From public microcode archives, the
> followin CPUs exist 17-30-00, 17-60-00, 17-70-00 and would be captured by the
> model ranges.  They're likely pre-production steppings, and likely didn't get
> Zenbleed microcode, but it's still incorrect to compare them to a different
> stepping's revision.
>
> Either way, convert the logic to use x86_match_min_microcode_rev(), which is
> the preferred mechanism.
>
> Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
> Signed-off-by: Andrew Cooper <andrew.cooper3@...rix.com>
> ---
> CC: Borislav Petkov <bp@...en8.de>
> CC: Mario Limonciello <mario.limonciello@....com>
> CC: x86@...nel.org
> CC: linux-kernel@...r.kernel.org
> ---
>  arch/x86/kernel/cpu/amd.c | 29 ++++++++---------------------
>  1 file changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 5d46709c58d0..9721d24727e9 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -951,26 +951,13 @@ static void init_amd_zen1(struct cpuinfo_x86 *c)
>  	}
>  }
>  
> -static bool cpu_has_zenbleed_microcode(void)
> -{
> -	u32 good_rev = 0;
> -
> -	switch (boot_cpu_data.x86_model) {
> -	case 0x30 ... 0x3f: good_rev = 0x0830107b; break;
> -	case 0x60 ... 0x67: good_rev = 0x0860010c; break;
> -	case 0x68 ... 0x6f: good_rev = 0x08608107; break;
> -	case 0x70 ... 0x7f: good_rev = 0x08701033; break;
> -	case 0xa0 ... 0xaf: good_rev = 0x08a00009; break;
> -
> -	default:
> -		return false;
> -	}
> -
> -	if (boot_cpu_data.microcode < good_rev)
> -		return false;
> -
> -	return true;
> -}
> +static const struct x86_cpu_id amd_zenbleed_microcode[] = {
> +	ZEN_MODEL_STEP_UCODE(0x17, 0x31, 0x0, 0x0830107b),
> +	ZEN_MODEL_STEP_UCODE(0x17, 0x60, 0x1, 0x0860010c),
> +	ZEN_MODEL_STEP_UCODE(0x17, 0x68, 0x1, 0x08608107),
> +	ZEN_MODEL_STEP_UCODE(0x17, 0x71, 0x0, 0x08701033),
> +	ZEN_MODEL_STEP_UCODE(0x17, 0xa0, 0x0, 0x08a00009),
> +};

Sorry, this needs a {} terminator to be correct.  I'll send out a v2 in
a bit, assuming there are no other comments.

~Andrew