This was potentially helpful when the chickenbit was the only mitigation and
microcode had not been released, but that was two years ago.

Zenbleed microcode has been avaialble since December 2023, and the subsequent
Entrysign signature vulnerability means that firmware updates block OS-loading
and more OS-loadable microcode will be produced for Zen2.

i.e. the Zenbleed fix is not going to appear at runtime these days.

No practical change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/amd.c               | 2 +-
 xen/arch/x86/cpu/microcode/amd.c     | 2 --
 xen/arch/x86/include/asm/processor.h | 2 --
 3 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 8f468aaf0921..7953261895ac 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -979,7 +979,7 @@ void __init detect_zen2_null_seg_behaviour(void)
 
 }
 
-void amd_check_zenbleed(void)
+static void amd_check_zenbleed(void)
 {
 	const struct cpu_signature *sig = &this_cpu(cpu_sig);
 	unsigned int good_rev;
diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c
index 4a7573c885e5..e7ae1e802353 100644
--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -380,8 +380,6 @@ static int cf_check apply_microcode(const struct microcode_patch *patch,
            "microcode: CPU%u updated from revision %#x to %#x, date = %04x-%02x-%02x\n",
            cpu, old_rev, rev, patch->year, patch->month, patch->day);
 
-    amd_check_zenbleed();
-
     return 0;
 }
 
diff --git a/xen/arch/x86/include/asm/processor.h b/xen/arch/x86/include/asm/processor.h
index 1342241742ac..2e087c625770 100644
--- a/xen/arch/x86/include/asm/processor.h
+++ b/xen/arch/x86/include/asm/processor.h
@@ -435,8 +435,6 @@ enum ap_boot_method {
 };
 extern enum ap_boot_method ap_boot_method;
 
-void amd_check_zenbleed(void);
-
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_X86_PROCESSOR_H */
-- 
2.39.5

On 26.11.2025 14:22, Andrew Cooper wrote:
> This was potentially helpful when the chickenbit was the only mitigation and
> microcode had not been released, but that was two years ago.
> 
> Zenbleed microcode has been avaialble since December 2023, and the subsequent
> Entrysign signature vulnerability means that firmware updates block OS-loading
> and more OS-loadable microcode will be produced for Zen2.
> 
> i.e. the Zenbleed fix is not going to appear at runtime these days.
> 
> No practical change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
on the basis that people unwilling to update their firmware already accept
being vulnerable. To them this might be a perceived regression, i.e. not
exactly "No practical change", but we kind of accept that possibility.

Jan

On 26/11/2025 2:49 pm, Jan Beulich wrote:
> On 26.11.2025 14:22, Andrew Cooper wrote:
>> This was potentially helpful when the chickenbit was the only mitigation and
>> microcode had not been released, but that was two years ago.
>>
>> Zenbleed microcode has been avaialble since December 2023, and the subsequent
>> Entrysign signature vulnerability means that firmware updates block OS-loading
>> and more OS-loadable microcode will be produced for Zen2.
>>
>> i.e. the Zenbleed fix is not going to appear at runtime these days.
>>
>> No practical change.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

> on the basis that people unwilling to update their firmware already accept
> being vulnerable. To them this might be a perceived regression, i.e. not
> exactly "No practical change", but we kind of accept that possibility.

It's not quite that easy.  There are plenty of Zen2 systems without a
firmware update.

But, a user who cares about their security will have a more up-to-date
microcode than 2 years old, and will get the Zenbleed fix at boot time.

What I'm trying to say is that the "old ucode at boot, new at runtime"
case doesn't sensibly exist any more.

~Andrew