Message-ID: <CAERbo5xYExnnF7BosjEsevDsZXs6yRg+PmYTPzZQJqAJno3Gtw@mail.gmail.com>
Date: Fri, 31 Oct 2025 10:51:01 +0200
From: Adriana Nicolae <adriana@...sta.com>
To: Tom Rini <trini@...sulko.com>
Cc: Ilias Apalodimas <ilias.apalodimas@...aro.org>, Ard Biesheuvel <ardb@...nel.org>, 
	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 9:07 PM Tom Rini <trini@...sulko.com> wrote:
>
> 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.
Thank you for guiding on this change. I've just posted the v3 kernel
patch series which is simplified to support SMBIOS3 only.

I have also submitted the corresponding U-Boot patch (to add the
property dynamically for non-EFI boots) to the u-boot@...ts.denx.de
list. It may be held for moderation as I am waiting for my
subscription to be approved, but it should appear on the archive soon.

Regarding the DMTF spec, I am not a member and cannot contribute
directly. I would appreciate the help to get this proposed.
Please let me know if there are any concerns with the v3 kernel patch.


>
> --
> Tom

Powered by blists - more mailing lists