Skip to content

Latest commit

 

History

History
106 lines (89 loc) · 7.78 KB

uefi.adoc

File metadata and controls

106 lines (89 loc) · 7.78 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 rules 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# Rule

UEFI_010

MUST implement a 64-bit UEFI firmware.

UEFI_020

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

UEFI_030

MUST meet the following memory map rules:

  • The default memory space attribute is EFI_MEMORY_WB.

  • Paged virtual-memory scheme MUST be configured by the firmware with identity mapping and MUST support EFI_MEMORY_ATTRIBUTE_PROTOCOL protocol.

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

Enabling paged virtual memory scheme means, satp.MODE must not be set to Bare and proper page table with identity mapping is setup by the firmware. This is required for platform protection use cases before handing off to the OS.

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. Firmware MUST place all secondary harts in an offline state before completion of the EFI_EVENT_GROUP_READY_TO_BOOT event.

This ensures an OS loader is entered with an OS-compatible state for all harts.The OS loader and/or the OS may resume the secondary harts, if required, as part of their boot and join sequence.

UEFI_060

The implementation MUST 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

The implementation MUST 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.

UEFI_080

A Device Tree MUST only be exposed to the OS iff no actual hardware description is included in the DT.

Such a "dummy" DT could be installed by firmware, as a UEFI configuration table entry of type EFI_DTB_TABLE_GUID, to provide necessary hand-off info to an OS, for example, to provide RAM disk information (e.g. via /chosen/linux,initrd-start).

BRS-I Security Requirements

ID# Rule

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# Rule

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# Rule

URT_010

Systems without a Real-Time Clock (RTC), but with an equivalent alternate source for the current time, MUST meet the following requirements:

  • GetTime() MUST be implemented.

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

See additional guidance.

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, and must operate on the same hardware as the ACPI TAD before UEFI boot services are exited.

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

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

The UEFI variables MUST persist across calls to the ResetSystem() runtime service call.

URT_050

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

UEFI variables are normally saved in a dedicated storage which is not directly accessible by the operating system.

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# Rule

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.