Message-ID: <20251024180746.GT6688@bill-the-cat>
Date: Fri, 24 Oct 2025 12:07:46 -0600
From: Tom Rini <trini@...sulko.com>
To: Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc: Ard Biesheuvel <ardb@...nel.org>, Adriana Nicolae <adriana@...sta.com>,
	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 Fri, Oct 24, 2025 at 02:07:43PM +0300, Ilias Apalodimas wrote:
> Hi Ard, Adriana
> 
> Thanks for cc'ing me.
> 
> On Fri, 24 Oct 2025 at 12:49, Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > 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.
> 
> +1
> U-Boot does offer an EFI implementation indeed, but we can't magically
> force people to use it.
> The problem with SMBIOS is that afaict is still widely used by various
> debugging tools, so we might as well support it.
> I agree with Ard here. I think the best thing we can do is
> - Make the node standard in the DT spec, so everyone gets a reference
> - Gatekeep any alternative implementations for the kernel until
> someone gets this into the DMTF spec as well
> - Send a patch to U-Boot that adds that mode dynamically if booting is
> !EFI and SMIOS support is enabled

This sounds like a good plan to me, from the U-Boot side of things.

-- 
Tom

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists