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.

This series adds support for the kernel to find these tables by
reading properties from the Device Tree /chosen node. The bootloader
can specify the physical addresses using "linux,smbios-table" and
"linux,smbios3-table".

The first patch introduces the device tree binding documentation for this
new ABI, and the second patch implements the driver logic in dmi_scan.c.

Changes in v2:
  - Add missing Device Tree binding documentation (Patch 1/2).
  - Split the original patch into a 2-part series (binding + driver).
  - (No functional changes to the driver code in patch 2/2).

Adriana Nicolae (2):
  dt-bindings: firmware: Add binding for SMBIOS /chosen properties
  drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT

 Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml | 33 +++++
 drivers/firmware/dmi_scan.c                                        | 74 ++++++++++++++
 2 files changed, 107 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml

-- 
2.34.1

From: Adriana Nicolae <adriana@arista.com>

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.

This series adds support for the kernel to find these tables by
reading the associated property from the Device Tree /chosen node. The
bootloader can specify the physical addresses using "linux,smbios3-table".

The first patch introduces the device tree binding documentation for this
new ABI, and the second patch implements the driver logic in dmi_scan.c.

Changes in v3:
  - Removed linux,smbios-table property, only keep the SMBIOSv3 property
    (Patch 1/2).
  - Search DT for linux,smbios3-table only, removed the code searching
    for the previous property (Patch 2/2).

Changes in v2:
  - Add missing Device Tree binding documentation (Patch 1/2).
  - Split the original patch into a 2-part series (binding + driver).
  - (No functional changes to the driver code in patch 2/2).

Adriana Nicolae (2):
  dt-bindings: firmware: Add binding for SMBIOS /chosen properties
  drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT

 .../bindings/firmware/linux,smbios-table.yaml | 26 +++++++++
 drivers/firmware/dmi_scan.c                   | 58 +++++++++++++++++++
 2 files changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml

-- 
2.51.0

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.

This series adds support for the kernel to find these tables by
reading the associated property from the Device Tree /chosen node. The
bootloader can specify the physical addresses using the property
"linux,smbios3-entrypoint".

The first patch introduces the device tree binding documentation for this
new ABI, and the second patch implements the driver logic in dmi_scan.c.

Changes in v4:
  - Renamed linux,smbios3-table.yaml file, removed mention of ARM/ARM64
    (Patch 1/2).
  - Drop the second definition of dmi_scan_from_dt() and fold checking
    for CONFIG_OF (Patch 2/2).
  - Drop unnecessary goto on the success case (Patch 2/2).
  - Replace magic number for entrypoint size with SMBIOS3_ENTRY_POINT_SIZE
    definition (Patch 2/2).

Changes in v3:
  - Removed linux,smbios-table property, only keep the SMBIOSv3 property
    (Patch 1/2).
  - Search DT for linux,smbios3-table only, removed the code searching
    for the previous property (Patch 2/2).

Changes in v2:
  - Add missing Device Tree binding documentation (Patch 1/2).
  - Split the original patch into a 2-part series (binding + driver).
  - (No functional changes to the driver code in patch 2/2).

adriana (2):
  dt-bindings: firmware: Add binding for SMBIOS /chosen properties
  drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT

 .../firmware/linux,smbios3-entrypoint.yaml    | 25 +++++++++
 drivers/firmware/dmi_scan.c                   | 54 +++++++++++++++++++
 2 files changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml

-- 
2.51.0

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.

This series adds support for the kernel to find these tables by
reading the associated property from the Device Tree /chosen node. The
bootloader can specify the physical addresses using the property
"smbios3-entrypoint".

This patch implements the driver logic in dmi_scan.c.

Changes in v5:
  - Removed linux,smbios3-entrypoint.yaml file and the first patch.
  - Renamed property to "smbios3-entrypoint".

Changes in v4:
  - Renamed linux,smbios3-table.yaml file, removed mention of ARM/ARM64
    (Patch 1/2).
  - Drop the second definition of dmi_scan_from_dt() and fold checking
    for CONFIG_OF (Patch 2/2).
  - Drop unnecessary goto on the success case (Patch 2/2).
  - Replace magic number for entrypoint size with SMBIOS3_ENTRY_POINT_SIZE
    definition (Patch 2/2).

Changes in v3:
  - Removed linux,smbios-table property, only keep the SMBIOSv3 property
    (Patch 1/2).
  - Search DT for linux,smbios3-table only, removed the code searching
    for the previous property (Patch 2/2).

Changes in v2:
  - Add missing Device Tree binding documentation (Patch 1/2).
  - Split the original patch into a 2-part series (binding + driver).
  - (No functional changes to the driver code in patch 2/2).

adriana (1):
  drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT

 drivers/firmware/dmi_scan.c | 54 +++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

-- 
2.51.0

On Fri, Oct 31, 2025 at 04:59:16AM -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.
> 
> This series adds support for the kernel to find these tables by
> reading the associated property from the Device Tree /chosen node. The
> bootloader can specify the physical addresses using the property
> "smbios3-entrypoint".
> 
> This patch implements the driver logic in dmi_scan.c.
> 
> Changes in v5:
>   - Removed linux,smbios3-entrypoint.yaml file and the first patch.
>   - Renamed property to "smbios3-entrypoint".

Please stop sending new versions as a reply to the old one.

> 
> Changes in v4:
>   - Renamed linux,smbios3-table.yaml file, removed mention of ARM/ARM64
>     (Patch 1/2).
>   - Drop the second definition of dmi_scan_from_dt() and fold checking
>     for CONFIG_OF (Patch 2/2).
>   - Drop unnecessary goto on the success case (Patch 2/2).
>   - Replace magic number for entrypoint size with SMBIOS3_ENTRY_POINT_SIZE
>     definition (Patch 2/2).
> 
> Changes in v3:
>   - Removed linux,smbios-table property, only keep the SMBIOSv3 property
>     (Patch 1/2).
>   - Search DT for linux,smbios3-table only, removed the code searching
>     for the previous property (Patch 2/2).
> 
> Changes in v2:
>   - Add missing Device Tree binding documentation (Patch 1/2).
>   - Split the original patch into a 2-part series (binding + driver).
>   - (No functional changes to the driver code in patch 2/2).
> 
> adriana (1):
>   drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT
> 
>  drivers/firmware/dmi_scan.c | 54 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 54 insertions(+)
> 
> -- 
> 2.51.0
> 
> 

Some bootloaders provide SMBIOS/DMI tables at a specific memory address,
particularly on non-EFI ARM platforms. The kernel's standard EFI DMI
scanner cannot find these tables.

This patch adds a fallback mechanism to the DMI scanner to read the
physical address of the SMBIOS3 entry point from the device tree.

This scan is performed only if the standard EFI check fails.

Signed-off-by: adriana <adriana@arista.com>
---
 drivers/firmware/dmi_scan.c | 54 +++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 70d39adf50dc..82f1848e79fd 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -10,10 +10,12 @@
 #include <linux/random.h>
 #include <asm/dmi.h>
 #include <linux/unaligned.h>
+#include <linux/of.h>
 
 #ifndef SMBIOS_ENTRY_POINT_SCAN_START
 #define SMBIOS_ENTRY_POINT_SCAN_START 0xF0000
 #endif
+#define SMBIOS3_ENTRY_POINT_SIZE 32
 
 struct kobject *dmi_kobj;
 EXPORT_SYMBOL_GPL(dmi_kobj);
@@ -670,6 +672,51 @@ static int __init dmi_smbios3_present(const u8 *buf)
 	return 1;
 }
 
+/**
+ * dmi_scan_from_dt - Find SMBIOS3 entrypoint address via Device Tree
+ *
+ * Checks if the bootloader has passed the physical address of the
+ * SMBIOS3 entrypoint structure via the "smbios3-entrypoint" property
+ * in the /chosen node.
+ * Returns true if a valid entrypoint is found.
+ */
+static bool __init dmi_scan_from_dt(void)
+{
+	struct device_node *chosen;
+	const __be64 *prop;
+	char buf[SMBIOS3_ENTRY_POINT_SIZE];
+	void __iomem *p;
+	bool dmi_available = false;
+	u64 addr;
+	int len;
+
+	if(!IS_ENABLED(CONFIG_OF))
+		return false;
+
+	chosen = of_find_node_by_path("/chosen");
+	if (!chosen)
+		return false;
+
+	prop = of_get_property(chosen, "smbios3-entrypoint", &len);
+	if (prop && len >= sizeof(u64)) {
+		addr = be64_to_cpup(prop);
+
+		p = dmi_early_remap(addr, SMBIOS3_ENTRY_POINT_SIZE);
+		if (!p)
+			goto out;
+
+		memcpy_fromio(buf, p, sizeof(buf));
+		dmi_early_unmap(p, SMBIOS3_ENTRY_POINT_SIZE);
+
+		if (!dmi_smbios3_present(buf))
+			dmi_available = true;
+	}
+
+out:
+	of_node_put(chosen);
+	return dmi_available;
+}
+
 static void __init dmi_scan_machine(void)
 {
 	char __iomem *p, *q;
@@ -718,6 +765,13 @@ static void __init dmi_scan_machine(void)
 			dmi_available = 1;
 			return;
 		}
+	} else if (dmi_scan_from_dt()) {
+		/*
+		 * If EFI is not present or failed, try getting SMBIOS3
+		 * entrypoint from the Device Tree.
+		 */
+		dmi_available = 1;
+		return;
 	} else if (IS_ENABLED(CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK)) {
 		p = dmi_early_remap(SMBIOS_ENTRY_POINT_SCAN_START, 0x10000);
 		if (p == NULL)
-- 
2.51.0

On Fri, 31 Oct 2025 at 11:10, adriana <adriana@arista.com> 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.
>
> This series adds support for the kernel to find these tables by
> reading the associated property from the Device Tree /chosen node. The
> bootloader can specify the physical addresses using the property
> "linux,smbios3-entrypoint".
>
> The first patch introduces the device tree binding documentation for this
> new ABI, and the second patch implements the driver logic in dmi_scan.c.
>
> Changes in v4:
>   - Renamed linux,smbios3-table.yaml file, removed mention of ARM/ARM64
>     (Patch 1/2).
>   - Drop the second definition of dmi_scan_from_dt() and fold checking
>     for CONFIG_OF (Patch 2/2).
>   - Drop unnecessary goto on the success case (Patch 2/2).
>   - Replace magic number for entrypoint size with SMBIOS3_ENTRY_POINT_SIZE
>     definition (Patch 2/2).
>
> Changes in v3:
>   - Removed linux,smbios-table property, only keep the SMBIOSv3 property
>     (Patch 1/2).
>   - Search DT for linux,smbios3-table only, removed the code searching
>     for the previous property (Patch 2/2).
>
> Changes in v2:
>   - Add missing Device Tree binding documentation (Patch 1/2).
>   - Split the original patch into a 2-part series (binding + driver).
>   - (No functional changes to the driver code in patch 2/2).
>
> adriana (2):
>   dt-bindings: firmware: Add binding for SMBIOS /chosen properties
>   drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT
>

For the series,

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

I can take the second patch, but bindings need to go in separately IIRC.

Rob?


>  .../firmware/linux,smbios3-entrypoint.yaml    | 25 +++++++++
>  drivers/firmware/dmi_scan.c                   | 54 +++++++++++++++++++
>  2 files changed, 79 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
>
> --
> 2.51.0
>

On Fri, 31 Oct 2025 at 12:17, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 31 Oct 2025 at 11:10, adriana <adriana@arista.com> 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.
> >
> > This series adds support for the kernel to find these tables by
> > reading the associated property from the Device Tree /chosen node. The
> > bootloader can specify the physical addresses using the property
> > "linux,smbios3-entrypoint".
> >
> > The first patch introduces the device tree binding documentation for this
> > new ABI, and the second patch implements the driver logic in dmi_scan.c.
> >
> > Changes in v4:
> >   - Renamed linux,smbios3-table.yaml file, removed mention of ARM/ARM64
> >     (Patch 1/2).
> >   - Drop the second definition of dmi_scan_from_dt() and fold checking
> >     for CONFIG_OF (Patch 2/2).
> >   - Drop unnecessary goto on the success case (Patch 2/2).
> >   - Replace magic number for entrypoint size with SMBIOS3_ENTRY_POINT_SIZE
> >     definition (Patch 2/2).
> >
> > Changes in v3:
> >   - Removed linux,smbios-table property, only keep the SMBIOSv3 property
> >     (Patch 1/2).
> >   - Search DT for linux,smbios3-table only, removed the code searching
> >     for the previous property (Patch 2/2).
> >
> > Changes in v2:
> >   - Add missing Device Tree binding documentation (Patch 1/2).
> >   - Split the original patch into a 2-part series (binding + driver).
> >   - (No functional changes to the driver code in patch 2/2).
> >
> > adriana (2):
> >   dt-bindings: firmware: Add binding for SMBIOS /chosen properties
> >   drivers: firmware: dmi_scan: Add support for reading SMBIOS from DT
> >
>
> For the series,
>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
>
> I can take the second patch, but bindings need to go in separately IIRC.
>
> Rob?

Feel free to add
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Cheers
/Ilias
>
>
> >  .../firmware/linux,smbios3-entrypoint.yaml    | 25 +++++++++
> >  drivers/firmware/dmi_scan.c                   | 54 +++++++++++++++++++
> >  2 files changed, 79 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> >
> > --
> > 2.51.0
> >

Signed-off-by: adriana <adriana@arista.com>
---
 .../firmware/linux,smbios3-entrypoint.yaml    | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml

diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
new file mode 100644
index 000000000000..4d1521c685ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 Arista Networks
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/linux,smbios3-entrypoint.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Memory location for SMBIOS entry point 
+
+description: |
+  This property is used in the /chosen node to pass the physical address
+  of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface)
+  tables from firmware to the kernel. This is typically used on non-EFI.
+  
+maintainers:
+  - Adriana Nicolae <adriana@arista.com>
+  - Rob Herring <robh+dt@kernel.org>
+
+properties:
+  linux,smbios3-entrypoint:
+    $ref: /schemas/types.yaml#/definitions/uint64
+    description:
+      The 64-bit physical address of the SMBIOSv3 entry point structure.
+
+additionalProperties: true
-- 
2.51.0

On Fri, Oct 31, 2025 at 5:10 AM adriana <adriana@arista.com> wrote:
>
> Signed-off-by: adriana <adriana@arista.com>
> ---
>  .../firmware/linux,smbios3-entrypoint.yaml    | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
>
> diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> new file mode 100644
> index 000000000000..4d1521c685ff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> @@ -0,0 +1,25 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright 2025 Arista Networks
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/linux,smbios3-entrypoint.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Memory location for SMBIOS entry point
> +
> +description: |
> +  This property is used in the /chosen node to pass the physical address
> +  of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface)
> +  tables from firmware to the kernel. This is typically used on non-EFI.
> +
> +maintainers:
> +  - Adriana Nicolae <adriana@arista.com>
> +  - Rob Herring <robh+dt@kernel.org>
> +
> +properties:
> +  linux,smbios3-entrypoint:
> +    $ref: /schemas/types.yaml#/definitions/uint64
> +    description:
> +      The 64-bit physical address of the SMBIOSv3 entry point structure.

This needs to go in the chosen binding instead:

https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/chosen.yaml

On Fri, Oct 31, 2025 at 6:15 AM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, Oct 31, 2025 at 5:10 AM adriana <adriana@arista.com> wrote:
> >
> > Signed-off-by: adriana <adriana@arista.com>
> > ---
> >  .../firmware/linux,smbios3-entrypoint.yaml    | 25 +++++++++++++++++++
> >  1 file changed, 25 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> > new file mode 100644
> > index 000000000000..4d1521c685ff
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> > @@ -0,0 +1,25 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright 2025 Arista Networks
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/firmware/linux,smbios3-entrypoint.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Memory location for SMBIOS entry point
> > +
> > +description: |
> > +  This property is used in the /chosen node to pass the physical address
> > +  of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface)
> > +  tables from firmware to the kernel. This is typically used on non-EFI.
> > +
> > +maintainers:
> > +  - Adriana Nicolae <adriana@arista.com>
> > +  - Rob Herring <robh+dt@kernel.org>
> > +
> > +properties:
> > +  linux,smbios3-entrypoint:
> > +    $ref: /schemas/types.yaml#/definitions/uint64
> > +    description:
> > +      The 64-bit physical address of the SMBIOSv3 entry point structure.
>
> This needs to go in the chosen binding instead:
>
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/chosen.yaml

Also, drop the 'linux,' prefix as SMBIOS is not a linux invention.

Rob

On Fri, Oct 31, 2025 at 1:43 PM Rob Herring <robh@kernel.org> wrote:
>
> On Fri, Oct 31, 2025 at 6:15 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Fri, Oct 31, 2025 at 5:10 AM adriana <adriana@arista.com> wrote:
> > >
> > > Signed-off-by: adriana <adriana@arista.com>
> > > ---
> > >  .../firmware/linux,smbios3-entrypoint.yaml    | 25 +++++++++++++++++++
> > >  1 file changed, 25 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> > > new file mode 100644
> > > index 000000000000..4d1521c685ff
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/firmware/linux,smbios3-entrypoint.yaml
> > > @@ -0,0 +1,25 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +# Copyright 2025 Arista Networks
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/firmware/linux,smbios3-entrypoint.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Memory location for SMBIOS entry point
> > > +
> > > +description: |
> > > +  This property is used in the /chosen node to pass the physical address
> > > +  of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface)
> > > +  tables from firmware to the kernel. This is typically used on non-EFI.
> > > +
> > > +maintainers:
> > > +  - Adriana Nicolae <adriana@arista.com>
> > > +  - Rob Herring <robh+dt@kernel.org>
> > > +
> > > +properties:
> > > +  linux,smbios3-entrypoint:
> > > +    $ref: /schemas/types.yaml#/definitions/uint64
> > > +    description:
> > > +      The 64-bit physical address of the SMBIOSv3 entry point structure.
> >
> > This needs to go in the chosen binding instead:
> >
> > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/chosen.yaml
>
> Also, drop the 'linux,' prefix as SMBIOS is not a linux invention.
Thanks! I've renamed it to "smbios3-entrypoint" and opened a separate
PR for the binding:
https://github.com/devicetree-org/dt-schema/pull/177
>
> Rob

Some bootloaders provide SMBIOS/DMI tables at a specific memory address,
particularly on non-EFI ARM platforms. The kernel's standard EFI DMI
scanner cannot find these tables.

This patch adds a fallback mechanism to the DMI scanner to read the
physical address of the SMBIOS3 entry point from the device tree.

This scan is performed only if the standard EFI check fails.

Signed-off-by: adriana <adriana@arista.com>
---
 drivers/firmware/dmi_scan.c | 54 +++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 70d39adf50dc..c29ca98f09b5 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -10,10 +10,12 @@
 #include <linux/random.h>
 #include <asm/dmi.h>
 #include <linux/unaligned.h>
+#include <linux/of.h>
 
 #ifndef SMBIOS_ENTRY_POINT_SCAN_START
 #define SMBIOS_ENTRY_POINT_SCAN_START 0xF0000
 #endif
+#define SMBIOS3_ENTRY_POINT_SIZE 32
 
 struct kobject *dmi_kobj;
 EXPORT_SYMBOL_GPL(dmi_kobj);
@@ -670,6 +672,51 @@ static int __init dmi_smbios3_present(const u8 *buf)
 	return 1;
 }
 
+/**
+ * dmi_scan_from_dt - Find SMBIOS3 entrypoint address via Device Tree
+ *
+ * Checks if the bootloader has passed the physical address of the
+ * SMBIOS3 entrypoint structure via the "linux,smbios3-entrypoint"
+ * property in the /chosen node.
+ * Returns true if a valid entrypoint is found.
+ */
+static bool __init dmi_scan_from_dt(void)
+{
+	struct device_node *chosen;
+	const __be64 *prop;
+	char buf[SMBIOS3_ENTRY_POINT_SIZE];
+	void __iomem *p;
+	bool dmi_available = false;
+	u64 addr;
+	int len;
+
+	if(!IS_ENABLED(CONFIG_OF))
+		return false;
+
+	chosen = of_find_node_by_path("/chosen");
+	if (!chosen)
+		return false;
+
+	prop = of_get_property(chosen, "linux,smbios3-entrypoint", &len);
+	if (prop && len >= sizeof(u64)) {
+		addr = be64_to_cpup(prop);
+
+		p = dmi_early_remap(addr, SMBIOS3_ENTRY_POINT_SIZE);
+		if (!p)
+			goto out;
+
+		memcpy_fromio(buf, p, sizeof(buf));
+		dmi_early_unmap(p, SMBIOS3_ENTRY_POINT_SIZE);
+
+		if (!dmi_smbios3_present(buf))
+			dmi_available = true;
+	}
+
+out:
+	of_node_put(chosen);
+	return dmi_available;
+}
+
 static void __init dmi_scan_machine(void)
 {
 	char __iomem *p, *q;
@@ -718,6 +765,13 @@ static void __init dmi_scan_machine(void)
 			dmi_available = 1;
 			return;
 		}
+	} else if (dmi_scan_from_dt()) {
+		/*
+		 * If EFI is not present or failed, try getting SMBIOS3
+		 * entrypoint from the Device Tree.
+		 */
+		dmi_available = 1;
+		return;
 	} else if (IS_ENABLED(CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK)) {
 		p = dmi_early_remap(SMBIOS_ENTRY_POINT_SCAN_START, 0x10000);
 		if (p == NULL)
-- 
2.51.0

From: Adriana Nicolae <adriana@arista.com>

Signed-off-by: Adriana Nicolae <adriana@arista.com>
---
 .../bindings/firmware/linux,smbios-table.yaml | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml

diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml
new file mode 100644
index 000000000000..b78d8ec6025f
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2025 Arista Networks
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/linux,smbios-table.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Memory location for SMBIOS table 
+
+description: |
+  This property is used in the /chosen node to pass the physical address
+  of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface)
+  tables from firmware to the kernel. This is typically used on non-EFI
+  platforms like ARM/ARM64.
+  
+maintainers:
+  - Adriana Nicolae <adriana@arista.com>
+  - Rob Herring <robh+dt@kernel.org>
+
+properties:
+  linux,smbios3-table:
+    $ref: /schemas/types.yaml#/definitions/uint64
+    description:
+      The 64-bit physical address of the SMBIOSv3 entry point structure.
+
+additionalProperties: true
-- 
2.51.0

On Fri, 31 Oct 2025 at 09:41, adriana <adriana@arista.com> wrote:
>
> From: Adriana Nicolae <adriana@arista.com>
>
> Signed-off-by: Adriana Nicolae <adriana@arista.com>
> ---
>  .../bindings/firmware/linux,smbios-table.yaml | 26 +++++++++++++++++++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml
>
> diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml
> new file mode 100644
> index 000000000000..b78d8ec6025f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml
> @@ -0,0 +1,26 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright 2025 Arista Networks
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/linux,smbios-table.yaml#

Should the file name reflect the property? I.e., linux,smbios3-table.yaml

> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Memory location for SMBIOS table
> +
> +description: |
> +  This property is used in the /chosen node to pass the physical address
> +  of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface)
> +  tables from firmware to the kernel. This is typically used on non-EFI
> +  platforms like ARM/ARM64.
> +

'like ARM/ARM64' is both unnecessary and inaccurate, so better to drop it.

> +maintainers:
> +  - Adriana Nicolae <adriana@arista.com>
> +  - Rob Herring <robh+dt@kernel.org>
> +
> +properties:
> +  linux,smbios3-table:
> +    $ref: /schemas/types.yaml#/definitions/uint64
> +    description:
> +      The 64-bit physical address of the SMBIOSv3 entry point structure.
> +
> +additionalProperties: true
> --
> 2.51.0
>

On Fri, 31 Oct 2025 at 09:52, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 31 Oct 2025 at 09:41, adriana <adriana@arista.com> wrote:
> >
> > From: Adriana Nicolae <adriana@arista.com>
> >
> > Signed-off-by: Adriana Nicolae <adriana@arista.com>
> > ---
> >  .../bindings/firmware/linux,smbios-table.yaml | 26 +++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml b/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml
> > new file mode 100644
> > index 000000000000..b78d8ec6025f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/linux,smbios-table.yaml
> > @@ -0,0 +1,26 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright 2025 Arista Networks
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/firmware/linux,smbios-table.yaml#
>
> Should the file name reflect the property? I.e., linux,smbios3-table.yaml
>

And maybe the property should be called linux,smbios3-entrypoint?

Sorry for the bikeshedding but this will be set in stone as soon as we
deploy it so better to get it right the first time.

> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Memory location for SMBIOS table
> > +
> > +description: |
> > +  This property is used in the /chosen node to pass the physical address
> > +  of SMBIOS (System Management BIOS) or DMI (Desktop Management Interface)
> > +  tables from firmware to the kernel. This is typically used on non-EFI
> > +  platforms like ARM/ARM64.
> > +
>
> 'like ARM/ARM64' is both unnecessary and inaccurate, so better to drop it.
>
> > +maintainers:
> > +  - Adriana Nicolae <adriana@arista.com>
> > +  - Rob Herring <robh+dt@kernel.org>
> > +
> > +properties:
> > +  linux,smbios3-table:
> > +    $ref: /schemas/types.yaml#/definitions/uint64
> > +    description:
> > +      The 64-bit physical address of the SMBIOSv3 entry point structure.
> > +
> > +additionalProperties: true
> > --
> > 2.51.0
> >

From: Adriana Nicolae <adriana@arista.com>

Signed-off-by: Adriana Nicolae <adriana@arista.com>
---
 drivers/firmware/dmi_scan.c | 58 +++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 70d39adf50dc..acc0e18b8d0f 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -10,6 +10,9 @@
 #include <linux/random.h>
 #include <asm/dmi.h>
 #include <linux/unaligned.h>
+#if IS_ENABLED(CONFIG_OF)
+#include <linux/of.h>
+#endif
 
 #ifndef SMBIOS_ENTRY_POINT_SCAN_START
 #define SMBIOS_ENTRY_POINT_SCAN_START 0xF0000
@@ -670,6 +673,54 @@ static int __init dmi_smbios3_present(const u8 *buf)
 	return 1;
 }
 
+#if IS_ENABLED(CONFIG_OF)
+/**
+ * dmi_scan_from_dt - Find and parse DMI/SMBIOS tables from the Device Tree
+ *
+ * Checks if the bootloader has passed SMBIOS table addresses via the /chosen
+ * node in the Device Tree. This follows the standard kernel DT bindings and
+ * assumes a fixed 32-byte mapping for the entry point.
+ * Returns true if a valid table is found and successfully parsed.
+ */
+static bool __init dmi_scan_from_dt(void)
+{
+	struct device_node *chosen;
+	const __be64 *prop;
+	char buf[32];
+	void __iomem *p;
+	bool dmi_available = false;
+	u64 addr;
+	int len;
+
+	chosen = of_find_node_by_path("/chosen");
+	if (!chosen)
+		return false;
+
+	prop = of_get_property(chosen, "linux,smbios3-table", &len);
+	if (prop && len >= sizeof(u64)) {
+		addr = be64_to_cpup(prop);
+
+		p = dmi_early_remap(addr, 32);
+		if (p == NULL)
+			goto out;
+
+		memcpy_fromio(buf, p, sizeof(buf));
+		dmi_early_unmap(p, 32);
+
+		if (!dmi_smbios3_present(buf)) {
+			dmi_available = true;
+			goto out;
+		}
+	}
+
+out:
+	of_node_put(chosen);
+	return dmi_available;
+}
+#else
+static bool __init dmi_scan_from_dt(void) { return false; }
+#endif /* IS_ENABLED(CONFIG_OF) */
+
 static void __init dmi_scan_machine(void)
 {
 	char __iomem *p, *q;
@@ -718,6 +769,13 @@ static void __init dmi_scan_machine(void)
 			dmi_available = 1;
 			return;
 		}
+	} else if (IS_ENABLED(CONFIG_OF) && dmi_scan_from_dt()) {
+		/*
+		 * If EFI is not present or failed, try getting SMBIOS
+		 * tables from the Device Tree.
+		 */
+		dmi_available = 1;
+		return;
 	} else if (IS_ENABLED(CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK)) {
 		p = dmi_early_remap(SMBIOS_ENTRY_POINT_SCAN_START, 0x10000);
 		if (p == NULL)
-- 
2.51.0

Hi Adriana,

On Fri, 31 Oct 2025 at 10:41, adriana <adriana@arista.com> wrote:
>
> From: Adriana Nicolae <adriana@arista.com>

We'll need a description of why the change is needed here.

[...]

>
>  #ifndef SMBIOS_ENTRY_POINT_SCAN_START
>  #define SMBIOS_ENTRY_POINT_SCAN_START 0xF0000
> @@ -670,6 +673,54 @@ static int __init dmi_smbios3_present(const u8 *buf)
>         return 1;
>  }
>
> +#if IS_ENABLED(CONFIG_OF)
> +/**
> + * dmi_scan_from_dt - Find and parse DMI/SMBIOS tables from the Device Tree
> + *
> + * Checks if the bootloader has passed SMBIOS table addresses via the /chosen
> + * node in the Device Tree. This follows the standard kernel DT bindings and
> + * assumes a fixed 32-byte mapping for the entry point.
> + * Returns true if a valid table is found and successfully parsed.
> + */
> +static bool __init dmi_scan_from_dt(void)
> +{
> +       struct device_node *chosen;
> +       const __be64 *prop;
> +       char buf[32];
> +       void __iomem *p;
> +       bool dmi_available = false;
> +       u64 addr;
> +       int len;
> +
> +       chosen = of_find_node_by_path("/chosen");
> +       if (!chosen)
> +               return false;
> +
> +       prop = of_get_property(chosen, "linux,smbios3-table", &len);
> +       if (prop && len >= sizeof(u64)) {
> +               addr = be64_to_cpup(prop);
> +
> +               p = dmi_early_remap(addr, 32);

Please put '32' into a define that explains what it is

> +               if (p == NULL)

I think if (!p) is preferred

> +                       goto out;
> +
> +               memcpy_fromio(buf, p, sizeof(buf));
> +               dmi_early_unmap(p, 32);
> +
> +               if (!dmi_smbios3_present(buf)) {
> +                       dmi_available = true;
> +                       goto out;
> +               }
> +       }
> +
> +out:
> +       of_node_put(chosen);
> +       return dmi_available;
> +}
> +#else
> +static bool __init dmi_scan_from_dt(void) { return false; }
> +#endif /* IS_ENABLED(CONFIG_OF) */
> +
>  static void __init dmi_scan_machine(void)
>  {
>         char __iomem *p, *q;
> @@ -718,6 +769,13 @@ static void __init dmi_scan_machine(void)
>                         dmi_available = 1;
>                         return;
>                 }
> +       } else if (IS_ENABLED(CONFIG_OF) && dmi_scan_from_dt()) {

Can you fold the IS_ENABLED() in dmi_scan_from_dt() please?

> +               /*
[...]

Thanks
/Ilias

Hello Adriana,

On Fri, 31 Oct 2025 at 09:41, adriana <adriana@arista.com> wrote:
>
> From: Adriana Nicolae <adriana@arista.com>
>
> Signed-off-by: Adriana Nicolae <adriana@arista.com>
> ---
>  drivers/firmware/dmi_scan.c | 58 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
>
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 70d39adf50dc..acc0e18b8d0f 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -10,6 +10,9 @@
>  #include <linux/random.h>
>  #include <asm/dmi.h>
>  #include <linux/unaligned.h>
> +#if IS_ENABLED(CONFIG_OF)
> +#include <linux/of.h>
> +#endif
>
>  #ifndef SMBIOS_ENTRY_POINT_SCAN_START
>  #define SMBIOS_ENTRY_POINT_SCAN_START 0xF0000
> @@ -670,6 +673,54 @@ static int __init dmi_smbios3_present(const u8 *buf)
>         return 1;
>  }
>
> +#if IS_ENABLED(CONFIG_OF)
> +/**
> + * dmi_scan_from_dt - Find and parse DMI/SMBIOS tables from the Device Tree
> + *
> + * Checks if the bootloader has passed SMBIOS table addresses via the /chosen
> + * node in the Device Tree. This follows the standard kernel DT bindings and
> + * assumes a fixed 32-byte mapping for the entry point.

Not sure what 'the standard kernel DT bindings' are, or what you mean
by 'a fixed 32-byte mapping. You could just drop this sentence, I
think, or otherwise, describe that the DT property gives us the
physical address of the SMBIOS3 entrypoint structure.

> + * Returns true if a valid table is found and successfully parsed.

if a valid entry point is found

> + */
> +static bool __init dmi_scan_from_dt(void)
> +{
> +       struct device_node *chosen;
> +       const __be64 *prop;
> +       char buf[32];
> +       void __iomem *p;
> +       bool dmi_available = false;
> +       u64 addr;
> +       int len;
> +
> +       chosen = of_find_node_by_path("/chosen");
> +       if (!chosen)
> +               return false;
> +
> +       prop = of_get_property(chosen, "linux,smbios3-table", &len);
> +       if (prop && len >= sizeof(u64)) {
> +               addr = be64_to_cpup(prop);
> +
> +               p = dmi_early_remap(addr, 32);
> +               if (p == NULL)
> +                       goto out;
> +
> +               memcpy_fromio(buf, p, sizeof(buf));
> +               dmi_early_unmap(p, 32);
> +
> +               if (!dmi_smbios3_present(buf)) {
> +                       dmi_available = true;
> +                       goto out;
> +               }
> +       }
> +
> +out:
> +       of_node_put(chosen);
> +       return dmi_available;
> +}
> +#else
> +static bool __init dmi_scan_from_dt(void) { return false; }
> +#endif /* IS_ENABLED(CONFIG_OF) */
> +
>  static void __init dmi_scan_machine(void)
>  {
>         char __iomem *p, *q;
> @@ -718,6 +769,13 @@ static void __init dmi_scan_machine(void)
>                         dmi_available = 1;
>                         return;
>                 }
> +       } else if (IS_ENABLED(CONFIG_OF) && dmi_scan_from_dt()) {

Please drop the IS_ENABLED() here, and fold it into dmi_scan_from_dt(), by doing

if (!IS_ENABLED(CONFIG_OF))
    return false;

at the beginning. This removes the need to provide two different
versions of dmi_scan_from_dt().


> +               /*
> +                * If EFI is not present or failed, try getting SMBIOS
> +                * tables from the Device Tree.
> +                */
> +               dmi_available = 1;
> +               return;
>         } else if (IS_ENABLED(CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK)) {
>                 p = dmi_early_remap(SMBIOS_ENTRY_POINT_SCAN_START, 0x10000);
>                 if (p == NULL)
> --
> 2.51.0
>

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.
 
> This series adds support for the kernel to find these tables by
> reading properties from the Device Tree /chosen node. The bootloader
> can specify the physical addresses using "linux,smbios-table" and
> "linux,smbios3-table".

/chosen node entries go in chosen.yaml schema in dtschema repository. 
But first, I need to see some agreement this is how we want to support 
this.

Rob

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.

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.

>
> > This series adds support for the kernel to find these tables by
> > reading properties from the Device Tree /chosen node. The bootloader
> > can specify the physical addresses using "linux,smbios-table" and
> > "linux,smbios3-table".
>
> /chosen node entries go in chosen.yaml schema in dtschema repository.
> But first, I need to see some agreement this is how we want to support
> this.
>
> Rob

Adriana

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?

> 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)

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.
>
> > 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).

Which model (passing the address or the structure directly) would the kernel
maintainers prefer if this DT fallback as an alternative for non UEFI
boot is ok?

Adriana

(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?

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, 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.

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.

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

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@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

This sounds like a good plan to me, from the U-Boot side of things.

-- 
Tom

On Fri, Oct 24, 2025 at 9:07 PM Tom Rini <trini@konsulko.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@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
>
> 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@lists.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