On Thu, 23 Oct 2025 at 16:48, Adriana Nicolae <adriana(a)arista.com> wrote:
>
> On Thu, Oct 23, 2025 at 4:54 PM Ard Biesheuvel <ardb(a)kernel.org> wrote:
> >
> > (cc Ilias)
> >
> > On Thu, 23 Oct 2025 at 15:34, Adriana Nicolae <adriana(a)arista.com> wrote:
> > >
> > > On Thu, Oct 23, 2025 at 11:21 AM Ard Biesheuvel <ardb(a)kernel.org> wrote:
> > > >
> > > > On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae <adriana(a)arista.com> wrote:
> > > > >
> > > > > On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <robh(a)kernel.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.
(cc Ilias)
On Thu, 23 Oct 2025 at 15:34, Adriana Nicolae <adriana(a)arista.com> wrote:
>
> On Thu, Oct 23, 2025 at 11:21 AM Ard Biesheuvel <ardb(a)kernel.org> wrote:
> >
> > On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae <adriana(a)arista.com> wrote:
> > >
> > > On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <robh(a)kernel.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?
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.
On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae <adriana(a)arista.com> wrote:
>
> On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <robh(a)kernel.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?
> 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)
Dear fellow firmware aficionados,
Static ACPI has been adopted by Mercedes and other silicon vendors to:
- meet the safety requirements
- stay away from DT lifecycle issues
- leverage chiplet and CXL bindings
- truly multi-host/hypervisor (or even secure/no-secure should people want it) as bindings are defined in an ad-hoc forum (not by an OS community)
DT community leaders and enthusiasts, I believe discussion on the bigger picture related to DT relevance in the long run may be needed as I believe many embedded solutions will follow Mercedes example.
Constructively yours,
François-Frédéric
PS: static ACPI can be handled by a simple parser, do not execute any ACPI byte code, is findable by EFI tables, code base is even smaller than libfdt.
