Message-ID: <CAERbo5zgS8XoGcFB3wejqDpx14-SBr5oWn7pu3=PE0djRiKZqg@mail.gmail.com>
Date: Thu, 23 Oct 2025 17:47:53 +0300
From: Adriana Nicolae <adriana@...sta.com>
To: Ard Biesheuvel <ardb@...nel.org>
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, 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.

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.

> Introducing a non-standard mechanism means that others will now have
> to maintain it and coexist with it, rather than simply using the
> existing code which already fully supports what you are trying to
> accomplish (both on the bootloader and the kernel side)
>
> IOW, in my opinion, simply enabling CMD_BOOTEFI for your bootloader is
> a much better choice here. I'm not a u-boot expert but as I understand
> it, loading/authenticating the image and booting it in EFI mode are
> two separate things, and so the secure boot path would change very
> little.
>
> > > > 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)
> > I understand the points raised about UEFI taking precedence and the
> > preference for standardization (DMTF). If this DT method is accepted
> > as a fallback only for non-UEFI boots like this one, the kernel implementation
> > will respect that precedence.
> >
> > Regarding the alternative to place the full SMBIOS entry point structure into
> > a DT property (as a byte array) instead of just its memory address. Both
> > approaches seem feasible from the U-Boot side. I opted initially for passing
> > the address to reuse the existing kernel functions (dmi_smbios3_present and
> > dmi_present) which already handle mapping and validation of the entry point
> > read from memory (as done for the EFI case).
> >
>
> Actually, it appears that dmidecode expects the entrypoint data in
> /sys/firmware/dmi/tables/smbios_entry_point, and so you will need to
> populate that file in any case, and so pulling it into the DT node is
> not as useful. But having both SMBIOS and SMBIOS3 is pointless, so
> please only bother with the latter.

Powered by blists - more mailing lists