On Thu, 23 Oct 2025 at 16:48, Adriana Nicolae adriana@arista.com wrote:
On Thu, Oct 23, 2025 at 4:54 PM Ard Biesheuvel ardb@kernel.org wrote:
(cc Ilias)
On Thu, 23 Oct 2025 at 15:34, Adriana Nicolae adriana@arista.com wrote:
On Thu, Oct 23, 2025 at 11:21 AM Ard Biesheuvel ardb@kernel.org wrote:
On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae adriana@arista.com wrote:
On Wed, Oct 22, 2025 at 11:19 PM Rob Herring robh@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.
Hi Ard, Adriana
Thanks for cc'ing me.
On Fri, 24 Oct 2025 at 12:49, Ard Biesheuvel ardb@kernel.org wrote:
On Thu, 23 Oct 2025 at 16:48, Adriana Nicolae adriana@arista.com wrote:
On Thu, Oct 23, 2025 at 4:54 PM Ard Biesheuvel ardb@kernel.org wrote:
(cc Ilias)
On Thu, 23 Oct 2025 at 15:34, Adriana Nicolae adriana@arista.com wrote:
On Thu, Oct 23, 2025 at 11:21 AM Ard Biesheuvel ardb@kernel.org wrote:
On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae adriana@arista.com wrote:
On Wed, Oct 22, 2025 at 11:19 PM Rob Herring robh@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.
+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
Cheers /Ilias
boot-architecture@lists.linaro.org
-
Ard Biesheuvel -
Ilias Apalodimas