linux-kernel - Re: [PATCH v2 3/7] firmware: dmi: Read additional information when decoding DMI table

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: <20251222175945.59c76f67@endymion>
Date: Mon, 22 Dec 2025 17:59:45 +0100
From: Jean Delvare <jdelvare@...e.de>
To: Yazen Ghannam <yazen.ghannam@....com>
Cc: Mario Limonciello <superm1@...nel.org>, <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 3/7] firmware: dmi: Read additional information when
 decoding DMI table

Hi Yazen, Mario,

On Wed, 17 Dec 2025 16:21:34 -0500, Yazen Ghannam wrote:
> On Wed, Dec 17, 2025 at 03:09:33PM -0600, Mario Limonciello wrote:
> > On 12/17/25 3:03 PM, Yazen Ghannam wrote:  
> > > On Tue, Dec 16, 2025 at 06:33:50AM -0600, Mario Limonciello (AMD) wrote:  
> > > > Type 40 entries (Additional information) are summarized in section
> > > > 7.41 as part of the SMBIOS specification.  Save these entries when
> > > > decoding the DMI tables.
> > > 
> > > Why can't an interested user just use dmidecode?
> > 
> > They could.  The reason for doing it in this series is the same reason for
> > the one that we did the S5 bit.
> > 
> > It shows up in the logs, you can tie regressions to the AGESA version at
> > specifically at the time of the failure if they've done BIOS updates since
> > then.  
> 
> Yes, right. Sorry, I mixed this up with the debugfs patch.
> 
> We need to save it here so the init code can find it.
> 
> But why do we need a debugfs entry for it?

FWIW, I had the exact same feeling when first gazing at this patch
series. I believe that every problem that can be solved in user-space
should be solved in user-space. Now I get the reason (explained above)
for logging the information at boot time, and thus the requirement to
parse type 40 in the kernel, but if there's no strong reason to have a
debugfs interface then I'd just drop it.

Of course, we also want to improve support for type 40 in dmidecode. I
admit I didn't pay too much attention to it so far due to a lack of use
case. But now that there's a use case, I'll be happy to work on it (or
commit a contribution if someone else beats me to it).

-- 
Jean Delvare
SUSE L3 Support