On Thu, 23 Oct 2025 at 16:48, Adriana Nicolae <[email protected]> wrote: > > On Thu, Oct 23, 2025 at 4:54 PM Ard Biesheuvel <[email protected]> wrote: > > > > (cc Ilias) > > > > On Thu, 23 Oct 2025 at 15:34, Adriana Nicolae <[email protected]> wrote: > > > > > > On Thu, Oct 23, 2025 at 11:21 AM Ard Biesheuvel <[email protected]> wrote: > > > > > > > > On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae <[email protected]> > > > > wrote: > > > > > > > > > > On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <[email protected]> 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. _______________________________________________ boot-architecture mailing list -- [email protected] To unsubscribe send an email to [email protected]
