linux-kernel - Re: [PATCH v2 0/2] DMI: Scan for DMI table from DTS info

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: <CAMj1kXGYinTKiyYhNYWJvoJeUJScCGnyq=ozLgjKAm7_wzG8QA@mail.gmail.com>
Date: Thu, 23 Oct 2025 10:21:40 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Adriana Nicolae <adriana@...sta.com>
Cc: Rob Herring <robh@...nel.org>, krzk@...nel.org, jdelvare@...e.com, 
	frowand.list@...il.com, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org, vasilykh@...sta.com, arm.ebbr-discuss@....com, 
	boot-architecture@...ts.linaro.org, linux-efi@...r.kernel.org, 
	uefi-discuss@...ts.uefi.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/2] DMI: Scan for DMI table from DTS info

On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae <adriana@...sta.com> wrote:
>
> On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <robh@...nel.org> wrote:
> >
> > On Wed, Oct 22, 2025 at 04:45:25AM -0700, adriana wrote:
> > > Some bootloaders like U-boot, particularly for the ARM architecture,
> > > provide SMBIOS/DMI tables at a specific memory address. However, these
> > > systems often do not boot using a full UEFI environment, which means the
> > > kernel's standard EFI DMI scanner cannot find these tables.
> >
> > I thought u-boot is a pretty complete UEFI implementation now. If
> > there's standard way for UEFI to provide this, then that's what we
> > should be using. I know supporting this has been discussed in context of
> > EBBR spec, but no one involved in that has been CC'ed here.
>
> Regarding the use of UEFI, the non UEFI boot is used on Broadcom iProc which
> boots initially into a Hardware Security Module which validates U-boot and then
> loads it. This specific path does not utilize U-Boot's UEFI
> implementation or the
> standard UEFI boot services to pass tables like SMBIOS.
>

What prevents this HSM validated copy of u-boot from loading the kernel via EFI?

> Because there's no UEFI configuration table available in this boot mode, we need
> an alternative mechanism to pass the SMBIOS table address to the kernel. The
> /chosen node seemed like the most straightforward way for the bootloader to
> communicate this non-discoverable information.
>
> I wasn't aware of the EBBR discussions covering this. I've added the
> boot-architecture and arm.ebbr-discuss lists to the Cc. If there's a preferred
> EBBR-compliant way to handle this for non-UEFI boots, I'm happy to adapt
> the approach.
>

For the record, I don't see a huge problem with accepting SMBIOS
tables in this manner, but it would be better if a description of this
method was contributed to the DMTF spec, which currently states that
the only way to discover SMBIOS tables on non-x86 systems is via the
SMBIOS/SMBIOS3 EFI configuration tables. Doing so should prevent other
folks from inventing their own methods for their own vertically
integrated systems. (Other OSes exist, and from a boot arch PoV, we
try to avoid these Linux-only shortcuts)

However, the DT method should *only* be used when not booting via
UEFI, to avoid future surprises, and to ensure that existing OSes
(including older Linux) can always find the SMBIOS tables when booting
via UEFI.

Also, I would suggest to pull the entire entrypoint into DT, rather
than the address in memory of either/both entrypoint(s). Both just
carry some version fields, and the address of the actual SMBIOS data
in memory, and the only difference between SMBIOS and SMBIOS3 is the
size of the address field (32 vs 64 bits)