On 27.10.2025 23:17, Andrew Cooper wrote:
> When Entrysign has been mitigated in firwmare, it is believed to be safe to
> rely on the CPU patchloader again.  This avoids us needing to maintain the
> digest table for all new microcode indefinitely.
> 
> Relax the digest check when firmware looks to be up to date, and leave behind
> a clear message when not.
> 
> This is best-effort only.  If a malicious microcode has been loaded prior to
> Xen running, then all bets are off.
> 
> Signed-off-by: Andrew Cooper <[email protected]>

Like for patch 4, adjustments for Zen6 are then going to be needed here too,
aiui. May be worth repeating that statement here.

> @@ -603,3 +604,82 @@ static void __init __constructor 
> test_digests_sorted(void)
>      }
>  }
>  #endif /* CONFIG_SELF_TESTS */
> +
> +/*
> + * The Entrysign vulnerability affects all Zen1 thru Zen5 CPUs.  Firmware
> + * fixes were produced from Nov 2024.  Zen3 thru Zen5 can continue to take
> + * OS-loadable microcode updates using a new signature scheme, as long as
> + * firmware has been updated first.
> + */
> +void __init amd_check_entrysign(void)
> +{
> +    unsigned int curr_rev;
> +    uint8_t fixed_rev;
> +
> +    if ( boot_cpu_data.vendor != X86_VENDOR_AMD ||

Given the function name, might this check better live at the call site?

> +         boot_cpu_data.family < 0x17 ||
> +         boot_cpu_data.family > 0x1a )
> +        return;
> +
> +    /*
> +     * Table taken from Linux, which is the only known source of information
> +     * about client revisions.  Note, Linux expresses "last-vulnerable-rev"
> +     * while Xen wants "first-fixed-rev".
> +     */
> +    curr_rev = this_cpu(cpu_sig).rev;
> +    switch ( curr_rev >> 8 )
> +    {
> +    case 0x080012: fixed_rev = 0x78; break;
> +    case 0x080082: fixed_rev = 0x10; break;
> +    case 0x083010: fixed_rev = 0x7d; break;
> +    case 0x086001: fixed_rev = 0x0f; break;
> +    case 0x086081: fixed_rev = 0x09; break;
> +    case 0x087010: fixed_rev = 0x35; break;
> +    case 0x08a000: fixed_rev = 0x0b; break;
> +    case 0x0a0010: fixed_rev = 0x7b; break;
> +    case 0x0a0011: fixed_rev = 0xdb; break;
> +    case 0x0a0012: fixed_rev = 0x44; break;
> +    case 0x0a0082: fixed_rev = 0x0f; break;
> +    case 0x0a1011: fixed_rev = 0x54; break;
> +    case 0x0a1012: fixed_rev = 0x4f; break;
> +    case 0x0a1081: fixed_rev = 0x0a; break;
> +    case 0x0a2010: fixed_rev = 0x30; break;
> +    case 0x0a2012: fixed_rev = 0x13; break;
> +    case 0x0a4041: fixed_rev = 0x0a; break;
> +    case 0x0a5000: fixed_rev = 0x14; break;
> +    case 0x0a6012: fixed_rev = 0x0b; break;
> +    case 0x0a7041: fixed_rev = 0x0a; break;
> +    case 0x0a7052: fixed_rev = 0x09; break;
> +    case 0x0a7080: fixed_rev = 0x0a; break;
> +    case 0x0a70c0: fixed_rev = 0x0a; break;
> +    case 0x0aa001: fixed_rev = 0x17; break;
> +    case 0x0aa002: fixed_rev = 0x19; break;
> +    case 0x0b0021: fixed_rev = 0x47; break;
> +    case 0x0b1010: fixed_rev = 0x47; break;
> +    case 0x0b2040: fixed_rev = 0x32; break;
> +    case 0x0b4040: fixed_rev = 0x32; break;
> +    case 0x0b6000: fixed_rev = 0x32; break;
> +    case 0x0b7000: fixed_rev = 0x32; break;

Acked-by: Jan Beulich <[email protected]>
(after cross checking with up-to-date Linux, i.e. including your recent
correction there)

Jan

Reply via email to