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: <CAERbo5z6BzHqQxXdxPxmxE_eDR7GGGbt3A8kB0gQiWFBE-28Ug@mail.gmail.com>
Date: Thu, 23 Oct 2025 05:20:53 +0300
From: Adriana Nicolae <adriana@...sta.com>
To: Rob Herring <robh@...nel.org>
Cc: 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 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.

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.

>
> > This series adds support for the kernel to find these tables by
> > reading properties from the Device Tree /chosen node. The bootloader
> > can specify the physical addresses using "linux,smbios-table" and
> > "linux,smbios3-table".
>
> /chosen node entries go in chosen.yaml schema in dtschema repository.
> But first, I need to see some agreement this is how we want to support
> this.
>
> Rob

Adriana