From 88d396719d71e8d5ab5b1e2662dcfae900041a82 Mon Sep 17 00:00:00 2001 From: Michael Brown Date: Fri, 13 Mar 2026 15:40:27 +0000 Subject: [PATCH] [efi] Add a dummy SBOM PE section Since October 2025, the Microsoft UEFI Signing Requirements have included a clause stating that "submissions must contain a valid signed SPDX SBOM in a custom '.sbom' PE section". A list of required fields is provided, and a link is given to "the Microsoft SBOM tool to aid SBOM generation". So far, so promising. The Microsoft SBOM tool has no support for handling a .sbom PE section. There is no published document that specifies what is supposed to appear within this PE section. An educated guess is that it should probably contain the raw JSON data in the same format that the Microsoft SBOM tool produces. The list of required fields does not map to identifiable fields within the JSON. In particular: - "file name / software" This might be the top-level "name" field. It's hard to tell. The SPDX SBOM specification is not particularly informative either: the only definition it appears to give for "name" is "This field identifies the name of an Element as designated by the creator", which is a spectacularly useless definition. - "software version / component generation (shim)" This may refer to the "packages[].versionInfo" field. There is no obvious relevance for the words "component", "generation", or "shim". The proximity of "generation" and "shim" suggests that this might be related in some way to the SBAT security generation, which is absolutely not the same thing as the software version. - "vendor / company name (this must exactly match the verified company name in the submitter's EV certificate on the Microsoft HDC partner center account)" This is clearly written as though it has some significance for the UEFI signing submission process. Unfortunately there is no obvious map to any defined SBOM field. An educated guess is that this might be referring to "packages[].supplier", since experiments show that the Microsoft SBOM tool will fail validation unless this field is present. - "product-name" This might also be the top-level "name" field. There is no indication given as to how this might differ from "file name / software". - "OEM Name" and "OEM ID" These seem to be terms made up on the spur of the moment. The three-letter sequence "OEM" does not appear anywhere within the codebase of the Microsoft SBOM tool. In the absence of any meaningful specification, we choose not to engage in good faith with this requirement. Instead, we construct a best guess at the contents of a .sbom section that has some chance of being accepted by the UEFI signing submission process. We assume that anything that passes "sbom-tool validate" will probably be accepted, with the only actual check being that the supplier name must match the registered EV code signing certificate. To anyone who actually cares about the arguably valuable benefits of having a software bill of materials: please stop creating junk requirements. If you want people to actually make the effort to produce useful SBOM data, then make it clear what data you want. Provide unambiguous specifications. Provide example files. Provide tools that actually do the job they are claimed to do. Don't just throw out another piece of "MUST HAS THING BECAUSE IS MORE SECURITY" garbage and call it a day. Signed-off-by: Michael Brown --- src/config/branding.h | 8 +++ src/core/version.c | 7 +++ src/include/ipxe/sbom.h | 117 ++++++++++++++++++++++++++++++++++++++++ src/scripts/efi.lds | 13 +++++ 4 files changed, 145 insertions(+) create mode 100644 src/include/ipxe/sbom.h diff --git a/src/config/branding.h b/src/config/branding.h index f28e1b5d2..e1a0bf5b1 100644 --- a/src/config/branding.h +++ b/src/config/branding.h @@ -170,6 +170,14 @@ FILE_SECBOOT ( PERMITTED ); */ #define PRODUCT_SETTING_URI "https://ipxe.org/cfg/%s" +/* + * Product vendor name + * + * Vendors creating signed iPXE binaries must set this to the name + * present in their EV code signing certificate. + */ +#define PRODUCT_VENDOR "" + /* * Product security name suffix * diff --git a/src/core/version.c b/src/core/version.c index 75f3160db..f9a30b05f 100644 --- a/src/core/version.c +++ b/src/core/version.c @@ -34,6 +34,7 @@ FILE_SECBOOT ( PERMITTED ); #include #include #include +#include #include #include @@ -123,3 +124,9 @@ const char build_name_prefix[] __attribute__ (( section ( ".prefix.name" ) )) /** SBAT data (without any NUL terminator) */ const char sbat[ sizeof ( SBAT_DATA ) - 1 ] __sbat = SBAT_DATA; + +/** SBOM data */ +#define SBOM_DATA SBOM_MANIFEST ( PRODUCT_SHORT_NAME, PRODUCT_VENDOR, VERSION ) + +/** SBOM data (without any NUL terminator) */ +const char sbom[ sizeof ( SBOM_DATA ) - 1 ] __sbom = SBOM_DATA; diff --git a/src/include/ipxe/sbom.h b/src/include/ipxe/sbom.h new file mode 100644 index 000000000..02d8cda9c --- /dev/null +++ b/src/include/ipxe/sbom.h @@ -0,0 +1,117 @@ +#ifndef _IPXE_SBOM_H +#define _IPXE_SBOM_H + +/** @file + * + * Software Bill Of Materials (SBOM) + * + * Since October 2025, the Microsoft UEFI Signing Requirements have + * included a clause stating that "submissions must contain a valid + * signed SPDX SBOM in a custom '.sbom' PE section". A list of + * required fields is provided, and a link is given to "the Microsoft + * SBOM tool to aid SBOM generation". So far, so promising. + * + * The Microsoft SBOM tool has no support for handling a .sbom PE + * section. There is no published document that specifies what is + * supposed to appear within this PE section. An educated guess is + * that it should probably contain the raw JSON data in the same + * format that the Microsoft SBOM tool produces. + * + * The list of required fields does not map to identifiable fields + * within the JSON. In particular: + * + * - "file name / software" + * + * This might be the top-level "name" field. It's hard to tell. + * The SPDX SBOM specification is not particularly informative + * either: the only definition it appears to give for "name" is + * "This field identifies the name of an Element as designated by + * the creator", which is a spectacularly useless definition. + * + * - "software version / component generation (shim)" + * + * This may refer to the "packages[].versionInfo" field. There is + * no obvious relevance for the words "component", "generation", or + * "shim". The proximity of "generation" and "shim" suggests that + * this might be related in some way to the SBAT security + * generation, which is absolutely not the same thing as the + * software version. + * + * - "vendor / company name (this must exactly match the verified + * company name in the submitter's EV certificate on the Microsoft + * HDC partner center account)" + * + * This is clearly written as though it has some significance for + * the UEFI signing submission process. Unfortunately there is no + * obvious map to any defined SBOM field. An educated guess is that + * this might be referring to "packages[].supplier", since + * experiments show that the Microsoft SBOM tool will fail + * validation unless this field is present. + * + * - "product-name" + * + * This might also be the top-level "name" field. There is no + * indication given as to how this might differ from "file name / + * software". + * + * - "OEM Name" and "OEM ID" + * + * These seem to be terms made up on the spur of the moment. The + * three-letter sequence "OEM" does not appear anywhere within the + * codebase of the Microsoft SBOM tool. + * + * In the absence of any meaningful specification, we choose not to + * engage in good faith with this requirement. Instead, we construct + * a best guess at the contents of a .sbom section that has some + * chance of being accepted by the UEFI signing submission process. + * We assume that anything that passes "sbom-tool validate" will + * probably be accepted, with the only actual check being that the + * supplier name must match the registered EV code signing + * certificate. + * + * To anyone who actually cares about the arguably valuable benefits + * of having a software bill of materials: please stop creating junk + * requirements. If you want people to actually make the effort to + * produce useful SBOM data, then make it clear what data you want. + * Provide unambiguous specifications. Provide example files. + * Provide tools that actually do the job they are claimed to do. + * Don't just throw out another piece of "MUST HAS THING BECAUSE IS + * MORE SECURITY" garbage and call it a day. + * + */ + +FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL ); +FILE_SECBOOT ( PERMITTED ); + +/** An SBOM field */ +#define SBOM_FIELD( key, value ) "\"" key "\":" value + +/** An SBOM string field */ +#define SBOM_STRING( key, value ) SBOM_FIELD ( key, "\"" value "\"" ) + +/** An SBOM package */ +#define SBOM_PACKAGE( spdxid, name, supplier, version ) \ + "{" \ + SBOM_STRING ( "SPDXID", spdxid ) "," \ + SBOM_STRING ( "name", name ) "," \ + SBOM_STRING ( "supplier", supplier ) "," \ + SBOM_STRING ( "versionInfo", version ) \ + "}" + +/** An SBOM manifest */ +#define SBOM_MANIFEST( name, supplier, version ) \ + "{" \ + SBOM_STRING ( "name", name ) "," \ + SBOM_FIELD ( "files", "[]" ) "," \ + SBOM_FIELD ( "relationships", "[]" ) "," \ + SBOM_FIELD ( "packages", "[" \ + SBOM_PACKAGE ( "", name, supplier, version ) \ + "]" ) \ + "}" + +/** Mark variable as being in the ".sbom" section */ +#define __sbom __attribute__ (( section ( ".sbom" ), aligned ( 512 ) )) + +extern const char sbom[] __sbom; + +#endif /* _IPXE_SBOM_H */ diff --git a/src/scripts/efi.lds b/src/scripts/efi.lds index a3b2c29d2..d5b2d7567 100644 --- a/src/scripts/efi.lds +++ b/src/scripts/efi.lds @@ -93,6 +93,19 @@ SECTIONS { _esbat = .; } + /* + * The SBOM section + * + */ + + . = ALIGN ( _page_align ); + .sbom : { + _sbom = .; + KEEP(*(.sbom)) + KEEP(*(.sbom.*)) + _esbom = .; + } + /* * Weak symbols that need zero values if not otherwise defined *