Skip to content

Latest commit

 

History

History
99 lines (82 loc) · 6.62 KB

uefi.adoc

File metadata and controls

99 lines (82 loc) · 6.62 KB
Raw

BRS-I UEFI Requirements

The Unified Extensible Firmware Interface Specification (UEFI) describes the interface between the OS and the supervisor-mode firmware.

This section defines the BRS-I mandatory and optional UEFI requirements on top of existing cite:[UEFI] specification requirements. Additional non-normative guidance may be found in the firmware implementation guidance section.

Important
 All content in this section is optional and recommended for BRS-B.
ID# Requirement

UEFI_010

Implement a 64-bit UEFI firmware.

UEFI_020

Meet the 3rd Party UEFI Certificate Authority (CA) requirements on UEFI memory mitigations cite:[MSUefiCaRequirements].

UEFI_030

Meet BRS-I specific memory map requirements:

  • The default memory space attribute MUST be EFI_MEMORY_WB.

  • Enable address translation.

  • Only use EfiRuntimeServicesData memory type for describing any SMBIOS data structures.

UEFI_040

An implementation MAY comply with the UEFI Platform Initialization Specification cite:[UEFI-PI].

UEFI_050

All hart manipulation internal to a firmware implementation SHOULD be done before completion of the EFI_EVENT_GROUP_READY_TO_BOOT event, with all secondary harts remaining offline from that point on.

This ensures an OS loader is entered with an OS-compatible state for all harts.

UEFI_060

Declare the EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile.

The EFI_CONFORMANCE_PROFILES_UEFI_SPEC_GUID conformance profile MUST be declared, as the BRS requirements are a superset of UEFI cite:[UEFI] (Section 2.6).

UEFI_070

Declare the EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID conformance profile ({ 0x05453310, 0x0545, 0x0545, { 0x05, 0x45, 0x33, 0x05, 0x45, 0x33, 0x05, 0x45 }}).

Only a system fully compliant to the requirements in this section MAY declare the EFI_CONFORMANCE_PROFILE_BRS_1_0_SPEC_GUID conformance profile.

BRS-I Security Requirements

ID# Requirement

USEC_010

Systems implementing UEFI secure boot are RECOMMENDED to implement the EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL protocols cite:[UEFI-PI].

The Security and Security2 architectural protocols are overridden by some bootloaders (e.g. systemd-boot) to validate EFI binaries that cannot be validated against the UEFI security database.

USEC_020

Systems implementing a TPM MUST implement the TCG EFI Protocol Specification cite:[TcgEfiPlat].

BRS-I I/O-specific Requirements

ID# Requirement

UIO_010

Systems implementing PCIe MUST always initialize all root complex hardware and perform resource assignment for all endpoints and usable hotplug-capable switches in the system, even in a boot scenario from a non-PCIe boot device.

This is a stronger requirement than the PCI Firmware Specification firmware/OS device hand-off state (cite:[PCIFW] Section 3.5). See additional guidance.

UIO_020

Systems implementing EFI_GRAPHICS_OUTPUT_PROTOCOL SHOULD configure the frame buffer to be directly accessible.

That is, EFI_GRAPHICS_PIXEL_FORMAT is not PixelBltOnly and FrameBufferBase is reported as a valid hart memory-mapped I/O address.

BRS-I UEFI Runtime Services

ID# Requirement

URT_010

Systems without a Real-Time Clock (RTC) MUST meet the following requirements:

  • GetTime() MUST be implemented (e.g. in terms of CPU cycle counter).

  • SetTime() MUST return EFI_UNSUPPORTED, and be appropriately described in the EFI_RT_PROPERTIES_TABLE.

URT_020

Systems with a Real-Time Clock on an OS-managed bus (e.g. I2C, subject to arbitration issues due to access to the bus by the OS) MUST meet the following requirements:

  • GetTime() and SetTime() MUST return EFI_UNSUPPORTED, when called after the UEFI boot services have been exited.

  • GetTime() and SetTime() MUST be appropriately described in the EFI_RT_PROPERTIES_TABLE.

Also see AML_070.

URT_030

The UEFI ResetSystem() runtime service MUST be implemented.

The OS MUST call the ResetSystem() runtime service call to reset or shutdown the system, preferring this to SBI, ACPI or other system-specific mechanisms. This allows for systems to perform any required system tasks on the way out (e.g. servicing UpdateCapsule() or persisting non-volatile variables in some systems).

URT_040

Non-volatile UEFI variables MUST persist across calls to the ResetSystem() runtime service call.

URT_050

UEFI runtime services MUST be able to update the variables directly without the aid of an OS.

URT_060

The following requirements MUST be met for systems with UEFI secure boot:

  • MUST support a minimum of 128 KiB of non-volatile storage for UEFI variables.

  • The maximum supported variable size MUST be at least 64 KiB.

  • The db signature database variable (EFI_IMAGE_SECURITY_DATABASE) MUST be created with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, to prevent rollback attacks.

  • The dbx signature database variable (EFI_IMAGE_SECURITY_DATABASE1) MUST be created with EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, to prevent rollback attacks.

BRS-I Firmware Update

ID# Requirement

UFU_010

Systems with in-band firmware updates MUST do so either via UpdateCapsule() UEFI runtime service (cite:[UEFI] Section 8.5.3) or via Delivery of Capsules via file on Mass Storage Device (cite:[UEFI] Section 8.5.5).

In-band means the firmware running on a hart updates itself.

UFU_020

Systems implementing in-band firmware updates via UpdateCapsule() MUST accept updates in the Firmware Management Protocol Data Capsule Structure format as described in Delivering Capsules Containing Updates to Firmware Management Protocol cite:[UEFI] (Section 23.3).

UFU_030

Systems implementing in-band firmware updates via UpdateCapsule() MUST provide an ESRT cite:[UEFI] (Section 23.4) describing every firmware image that is updated in-band.

UFU_040

Systems implementing in-band firmware updates via UpdateCapsule() MAY return EFI_UNSUPPORTED, when called after the UEFI boot services have been exited.

See additional guidance.