linux-kernel - Re: [PATCH v2 7/7] x86/CPU/AMD: Output the AGESA version to the logs

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]

Message-ID: <20251222191852.47fb515e@endymion>
Date: Mon, 22 Dec 2025 19:18:52 +0100
From: Jean Delvare <jdelvare@...e.de>
To: "Mario Limonciello (AMD)" <superm1@...nel.org>
Cc: Yazen Ghannam <yazen.ghannam@....com>, x86@...nel.org, Thomas Gleixner
 <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
 <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H . Peter
 Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 7/7] x86/CPU/AMD: Output the AGESA version to the
 logs

Hi Mario,

On Tue, 16 Dec 2025 06:33:54 -0600, Mario Limonciello (AMD) wrote:
> On AMD Zen platforms that are running AGESA, there is sometimes
> DMI additional string for the AGESA version that can be helpful when
> debugging an issue.  If this string is found output to kernel logs.

This last sentence sounds clumsy.

> 
> Signed-off-by: Mario Limonciello (AMD) <superm1@...nel.org>
> ---
>  arch/x86/kernel/cpu/amd.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index c19c4ee74dd1f..8f44439d3f993 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  #define pr_fmt(fmt) "x86/amd: " fmt
>  
> +#include <linux/dmi.h>
>  #include <linux/export.h>
>  #include <linux/bitops.h>
>  #include <linux/elf.h>
> @@ -1406,3 +1407,20 @@ static __init int print_s5_reset_status_mmio(void)
>  	return 0;
>  }
>  late_initcall(print_s5_reset_status_mmio);
> +
> +#ifdef CONFIG_DMI
> +static __init int print_agesa_dmi_info(void)
> +{
> +	const struct dmi_device *dev = NULL;
> +
> +	while ((dev = dmi_find_device(DMI_DEV_TYPE_ADDITIONAL, NULL, dev))) {
> +		if (!strncmp(dev->name, "AGESA", 5)) {
> +			pr_info("%s\n", dev->name);
> +			break;
> +		}
> +	}

In theory, type 40 DMI records are supposed to be a temporary
workaround until a new definition makes its way to the SMBIOS
specification. There is supposed to be a field in a standard DMI record
which will hold the same information in the future, at which point
systems will no longer need to provide the additional information entry.

I'm therefore surprised that you look for the AGESA information only in
type 40 and not in the standard DMI type where this piece of
information is supposed to be added in a near future.

So I checked my collection of DMI table dumps to find examples. I found
a number of occurrences of such type 40 entries. And it's a mess, I'm
sorry to say.

Some properly reference the Firmware Information handle (0x000) but
others reference handle 0xFFFF instead (which is invalid). Some
reference offset 0x05 within that record (which corresponds to the
Firmware Version string) while others reference offset 0x00 (which is
invalid). All have a 4-byte data field at the end of the entry, with
value 0x00000000, which is needlessly large.

This really looks like an abuse of DMI type 40. These entries are
supposed to overlay enumerated values in other types. This applies to
numeric fields only, overlaying a string field with another string
field is a technical non-sense.

Not sure what AMD engineers had in mind when implementing this. If they
wanted to mention the AGESA version in the firmware string, they could
have done that in DMI type 0, firmware version string directly.
Alternatively, OEM-specific records can be implemented, where hardware
vendors can store any kind of information they like. OEM strings (type
11) would also have been a valid alternative. Using DMI type 40 was
clearly not the right way to do it.

> +
> +	return 0;
> +}
> +late_initcall(print_agesa_dmi_info);
> +#endif

-- 
Jean Delvare
SUSE L3 Support