The UEFI Specification v2.11 is well over two thousand pages, and even the short list of “required elements” in §2.6 assumes a general-purpose computer: consoles, a configuration UI, standard buses, and runtime services that keep working after the operating system takes over from BIOS. UEFI was originally designed for such machines, not really for embedded systems or small single-board computers (SBCs) whose silicon init firmware is U-Boot, and whose eMMC cannot be touched from runtime services. A few years back (2022), the UEFI Forum published a way for firmware to declare compliance to only a fraction of what was traditionally considered "required". The intention was to lower the bar for "UEFI compliance" and so be able to leverage UEFI in domains other than general-purpose computers.
The white paper UEFI Conformance Profiles: Allowing “Reduced Model” Implementations, by Richard Wilkins (Phoenix) and Samer El-Haj-Mahmoud (Arm). describes the EFI Conformance Profiles Table, added to §4.6 of UEFI Spec v2.10. After several years in the wild, I thought now would be a good time to summarize what it is, and how it works.
Key Highlights
- A Conformance Profile is a named subset of features. Firmware publishes one or more GUIDs. Each GUID means “I implement this agreed set of UEFI required elements”
- The GUIDs live outside the UEFI spec. The UEFI Spec itself defines only one profile, full conformance. Other industry specs, (e.g. EBBR) define reduced conformance profiles.
- No table means full conformance. That rule exists so firmware written before UEFI Spec v2.10 does not suddenly look non-compliant
- EBBR is the popular example in the wild today. It is how embedded ARM and RISC-V firmware, very often U-Boot, advertises a boot ABI that generic operating systems can target without pretending the board is a general-purpose computer.
- Versions stack on top of one another. EBBR 2.4 asks firmware to publish every EBBR profile GUID it actually meets, so older software that has never heard of 2.4 can still recognize 2.1.
The Conformance Profiles Table
The Conformance Profiles Table is an ordinary UEFI configuration table. You find it the same way you find ACPI or a device tree: walk EFI_SYSTEM_TABLE.ConfigurationTable looking for the GUID.
#define EFI_CONFORMANCE_PROFILES_TABLE_GUID \
{ 0x36122546, 0xf7e7, 0x4c8f, \
{ 0xbd, 0x9b, 0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b }}
typedef struct {
UINT16 Version; // must be 1
UINT16 NumberOfProfiles;
EFI_GUID ConformanceProfiles[];
} EFI_CONFORMANCE_PROFILES_TABLE;One GUID in that array is defined by UEFI itself, and it means “we support §2.6, all of it, at the revision in the system table”:
#define EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID \
{ 0x523c91af, 0xa195, 0x4382, \
{ 0x81, 0x8d, 0x29, 0x5f, 0xe4, 0x00, 0x64, 0x65 }}Everything else is someone else’s profile. The rules, which have been stable since the white paper, and are now normative are:
- Table absent. Treat the firmware as conformant to the UEFI version in the system table. UEFI 2.11 says this is equivalent to publishing the full-spec GUID. For backwards compatibility.
- Table present, full-spec GUID present. Same conclusion: this is a full implementation of the required elements.
- Table present, some other GUID present. The firmware is built to that UEFI revision, but it implements only the subset written down by whoever owns that GUID. Do not assume section 2.6.
A table may contain more than one profile. It is how a platform says “I meet EBBR 2.1 and 2.2 and 2.3,” which is a different statement from “I meet 2.4 only.” Software that was written when 2.1 was the only GUID in the world can keep looking for 2.1 and succeed.
If an OS needs a fully conformant UEFI firmware, it checks the table. If there is a GUID that is not EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID, the OS knows it's on a reduced platform, and has the opportunity to fail gracefully. EDK2 carries the definitions in MdePkg/Include/Guid/ConformanceProfiles.h.
The EBBR profiles, as of v2.4.0
The most popular (only?) example of Conformance Profiles today is ARM's EBBR specification. Here's the history of EBBR's usage of Conformance Profiles:
| Profile | GUID | What that revision added |
|---|---|---|
| EBBR 2.1.x (7 Dec 2022) | cce33c35-74ac-4087-bce7-8b29b02eeb27 | The first profile GUID. ESRT when capsule update is implemented. RISCV_EFI_BOOT_PROTOCOL on RISC-V. DTB content requirements. References UEFI 2.10. |
| EBBR 2.2.x (5 Jun 2024) | 9073eed4-e50d-11ee-b8b0-8b68da62fc80 | Capsule-on-disk variables when in-band update exists. EFI_TCG2_PROTOCOL if a TPM is present. A file format for storing EFI variables. Monotonic counter made optional. ConnectController() must exist. |
| EBBR 2.3.x (20 Dec 2024) | 7721fc77-a724-11ef-8eaa-f7c9b194ba75 | UEFI Boot Manager is required. In-band update uses authenticated capsules in Firmware Management Protocol format. Spin-table boot deprecated on AArch64. References UEFI 2.11. |
| EBBR 2.4.x (11 Mar 2026) | f2bb0422-da8e-11f0-a67b-1be220854098 | Publish every EBBR profile you claim. EFI_GRAPHICS_OUTPUT_PROTOCOL is recommended when a graphical console exists. Conditional requirements for FF-A, PFDI, and SCMI, and a higher RISC-V SBI bar. |
The 2.1 define, which is the one you will still see most often in the wild, is:
#define EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID \
{ 0xcce33c35, 0x74ac, 0x4087, \
{ 0xbc, 0xe7, 0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27 }}Relative to a full reading of UEFI §2.6, EBBR declines, among other things:
- EFI_DECOMPRESS_PROTOCOL. Native EFI decompression is rarely used on these platforms.
- The HII configuration protocols (EFI_HII_CONFIG_ACCESS_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL), and the requirement that LoadImage() install an HII package list for a PE/COFF image that happens to carry one. EBBR still requires EFI_HII_STRING_PROTOCOL and EFI_HII_DATABASE_PROTOCOL, because the shell and the compliance tests use them. A good reminder that “reduced” does not mean “empty.”
- ConnectController() support for the driver-override protocols. Those matter when firmware loads drivers as EFI binaries off a bus. They matter much less when the driver was linked into U-Boot.
- EFI_DISK_IO_PROTOCOL, PXE, the general-purpose UEFI network stack, and the byte-stream, PCI, USB, NVMe pass-through, and SCSI pass-through protocol families.
- Option ROM loading. An EBBR platform with a PCIe device is expected to have that driver’s firmware built in, not discovered from a card ROM.
- A graphical console. If the hardware has one, exposing it is optional, and as of EBBR 2.4 exposing it through the Graphics Output Protocol is recommended rather than required. EDID protocols are not required.
- Runtime services. Many run-time services are either not required at all, or optional
Here's the up-to-date definition of what's required/not required by EBBR:
https://github.com/ARM-software/ebbr/blob/main/source/chapter2-uefi.rst
Both a full EDK2 PC/server BIOS and an EBBR U-Boot BIOS can claim, truthfully, to support the UEFI interface. They cannot both claim to be the same UEFI feature set. The conformance profile is what distinguishes them, in a form the OS can read before it has loaded a driver.
Further Reading
- Richard Wilkins and Samer El-Haj-Mahmoud, UEFI Conformance Profiles: Allowing “Reduced Model” Implementations, UEFI Forum, July 2022.
- UEFI Specification 2.11, section 4.6.4, EFI Conformance Profile Table, and section 2.6, required elements. The table was introduced in UEFI 2.10 (August 2022).
- Embedded Base Boot Requirements Specification, v2.4.0 (11 March 2026). Released PDFs are on the EBBR releases page. Chapter 2 is the UEFI subset; the profile GUIDs are in section 2.4.1.
- MdePkg/Include/Guid/ConformanceProfiles.h in EDK2.
The outcome of the 2022 white paper is that small platforms may now declare a subset of UEFI required features, with a GUID, in a table every EFI application already knows how to find. On ARM embedded systems these GUIDs are defined in the EBBR, and the OS can look for a set of profile GUIDs the board is able to support.
Post a Comment
Be sure to select an account profile (e.g. Google, OpenID, etc.) before typing your comment!