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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXEnSKF4VcMdOvUUuM-pOEWB38qPhWvUm13rnkQiZXp6SA@mail.gmail.com>
Date: Fri, 24 Oct 2025 11:49:13 +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, 
	Ilias Apalodimas <ilias.apalodimas@...aro.org>
Subject: Re: [PATCH v2 0/2] DMI: Scan for DMI table from DTS info

On Thu, 23 Oct 2025 at 16:48, Adriana Nicolae <adriana@...sta.com> wrote:
>
> On Thu, Oct 23, 2025 at 4:54 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > (cc Ilias)
> >
> > On Thu, 23 Oct 2025 at 15:34, Adriana Nicolae <adriana@...sta.com> wrote:
> > >
> > > On Thu, Oct 23, 2025 at 11:21 AM Ard Biesheuvel <ardb@...nel.org> wrote:
> > > >
> > > > 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?
> > > The vendor's U-Boot configuration for this specific secure boot path
> > > (involving the
> > > HSM) explicitly disables the CMD_BOOTEFI option due to security
> > > mitigations, only
> > > a subset of U-boot commands are whitelisted. We could patch the U-boot
> > > to include
> > > that but it is preferable to follow the vendor's recommandations and
> > > just patch U-boot
> > > to fill that memory location with SMBIOS address or directly with the
> > > entry point.
> >
> > And what security mitigations are deemed needed for the EFI code? You
> > are aware that avoiding EFI boot means that the booting kernel keeps
> > all memory protections disabled for longer than it would otherwise. Is
> > this allowlisting based on simply minimizing the code footprint?
> >
> From the information I have, it might be just minimizing the footprint
> but the vendor's U-Boot configuration for this specific path
> explicitly disables the CMD_BOOTEFI option. While the vendor cites
> security mitigations for this configuration, the specific details
> could be a set of mitigation removing different boot methods and some
> memory access commands.
>
> The core issue is that this non-EFI boot path is the vendor-validated
> configuration. Enabling EFI would deviate from this setup, require
> significant revalidation, and could impact vendor support. Modifying
> U-Boot to populate the DT is a contained change without modifying the
> U-boot vendor configuration.
>

I'm not sure I follow why changing U-Boot's code would not require
revalidation if simply changing its build configuration without
modifying the source code would require that.

> Beyond our specific vendor constraints, this DT method might be used
> by any other non-UEFI arm system needing to expose SMBIOS tables to
> the kernel.
>

Fair point. So let's do this properly: get buy-in from the U-Boot
folks and contribute your u-boot changes as well. And ideally, we'd
get this into the DMTF spec but if you are not set up for that (I
think you might need to be a member to be able to contribute), we can
find some ARM folks who are.