UEFI requirements for Windows editions on SoC platforms
This topic describes UEFI requirements that apply to Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows 10 Mobile. For additional requirements that apply only to Windows 10 Mobile, see UEFI requirements for Windows 10 Mobile.
Summary of requirements
The following table lists all current requirements for UEFI compliance as defined in the UEFI specification (Section 2.6 of the UEFI 2.3.1 specification). In this table, the term Explicit Windows Requirement identifies any protocol or service that is directly called by a Windows component. Although only these services are explicitly used by Windows, other listed services and protocols may be implicitly or explicitly required by a core firmware implementation, EFI device drivers or by development and deployment tool chains.
Microsoft welcomes feedback and comments from implementers on this set of requirements. For any UEFI compliance requirements that are determined to not be required by either the OS or the firmware, it is our intention to work through UEFI.org to have these compliance requirements relaxed for this class of device.
For more details about specific requirements, see the sections after the table.
|Requirement||UEFI specification section||Notes|
|EFI system table||4.3||Explicit Windows requirement|
|EFI boot services||6.0|
|Event, timer and task services||6.1|
|Memory services||6.2||Explicit Windows requirement`|
|Protocol handler services||6.3||Explicit Windows requirement|
|Image services||6.4||Explicit Windows requirement|
|Miscellaneous services||6.5||Explicit Windows requirement|
|EFI runtime services||7.0|
|Time services||7.3||Explicit Windows requirement|
|Variable services||7.2||Explicit Windows requirement|
|Miscellaneous services||7.5||Explicit Windows requirement|
|Required UEFI protocols|
|EFI loaded image protocol||8.1|
|EFI loaded image device path protocol||8.2|
|EFI device path protocol||9.2||Explicit Windows requirement|
|EFI device path utilities protocol||9.5|
|EFI decompress protocol||18.5|
|EBC interpreter protocol||20.11|
|Conditionally required UEFI protocols|
|EFI simple text input protocol||11.3||Explicit Windows requirement|
|EFI simple text input EX protocol||11.2|
|EFI simple text output protocol||11.4|
|EFI graphics output protocol||11.9||Explicit Windows requirement|
|EFI EDID discovered protocol||11.9.1|
|EFI EDID active protocol||11.9.1|
|EFI block IO protocol||12.8||Explicit Windows requirement|
|EFI disk IO protocol||12.7|
|EFI simple file system protocol||12.4|
|EFI Unicode collation protocol||12.10|
|EFI simple network protocol||21.1|
|EFI PXE base code protocol||21.3|
|EFI boot integrity services protocol||21.5|
|EFI serial IO protocol||11.8|
|UEFI Arm binding||2.3.5||Explicit Windows requirement|
|Secure boot||27.0||Explicit Windows requirement|
|Boot manager requirements||3.1, 3.3||Explicit Windows requirement|
EFI system table requirements
The EFI System Table must conform to the standard definition at the revision level implemented. The Configuration Table pointed to by the EFI System Table must include the two GUIDs and their associated pointers described in the following table.
|EFI_ACPI_Table GUID||This GUID must point to the ACPI Root System Description Pointer (RSDP) for the platform.|
|SMBIOS_Table GUID||This GUID must point to the SMBIOS Entry Point Structure.
Windows requires SMBIOS Specification, at the 2.4 or higher revision level. Sections 3.2, "Required Structures and Data", and 4, "Conformance Guidelines", are required. A Windows SMBIOS compatibility test is available.
EFI boot services requirements
The following table lists the EFI boot services requirements for Windows.
|EFI boot service||Requirement|
|Memory services||Windows requires all of the memory services.|
|Protocol handler services||Windows requires the following protocol handler services:
|Image services||Windows requires the following image services:
|Miscellaneous boot services||Windows requires the following miscellaneous boot services:
Note: The Stall() implementation is required to have a deterministic (repeatable) error such that error correction or cancellation can be done reliably.
EFI runtime services requirements
The following table lists the EFI runtime services requirements for Windows.
|EFI runtime service||Requirement|
|Time services||Windows requires the following time services:
Note: Time services will only be called during boot (before ExitBootServices()) for accessing platform time-of-day hardware.
|Variable services||All of the UEFI Variable Services are required for managing multiple boot devices and security variables on the target class of systems.|
|Miscellaneous runtime services||Windows requires the following miscellaneous runtime services:
Note: The ResetSystem() implementation must support both reset and shutdown options.
The following table describes the UEFI protocols that are required by Windows to accomplish specific functions during boot.
|Graphics output protocol||Windows requires the Graphics Output Protocol (GOP). Specific frame buffer requirements are:
For integrated displays, HorizontalResolution and VerticalResoluton must be the native resolution of the panel.
For External displays, HorizontalResolution and VerticalResoluton must be the native resolution of the display, or, if this is not supported, then the highest values supported by both the video adapter and the connected display.
PixelsPerScanLine must be equal to HorizontalResolution.
PixelFormat must be PixelBlueGreenRedReserved8BitPerColor. Note that a physical frame buffer is required; PixelBltOnly is not supported.
When execution is handed off to a UEFI boot application, the firmware boot manager and firmware must not use the frame buffer for any purpose. The frame buffer must continue to be scanned out after boot services have exited.
|Alternate display output||The UEFI firmware must support booting using any display connector supported by the hardware. If an internal panel is connected and visible then the internal panel must be used. All outputs that have physically connected displays must show the boot screen. For connected displays, the UEFI firmware must:
Initialize the output with the native mode of the display, if the native resolution can be determined.
If a native mode is not possible, then it must initialize to the highest compatible mode.
If the display capabilities cannot be determined, then the connected display must be initialized in a mode that is known to be compatible with as many monitors as possible (typically 640x480 or 1024x768, at 60Hz).
|Input at boot time||The EFI Simple Text Input Protocol is required for making boot choices or other menu selections on systems that have built-in keyboards or attached keyboards. For keyboard-less systems, three buttons are recommended in the boot environment:
Volume Up button
Volume Down button
Button presses should be reported through the EFI Simple Text Input Protocol by mapping them to the following keyboard keys, respectively:
Up Arrow key
Down Arrow key
|Local storage boot||Windows requires Block I/O Protocol and Device Path Protocol support for the storage solution that contains the EFI system partition and the Windows OS partition. For booting from flash storage that requires wear-leveling or other flash management, this must be implemented in the firmware (not in a UEFI application).|
Windows has security requirements in the areas of Secure Boot, Measured Boot, Cryptography, and Data Protection. These requirements are detailed in the following table. Additionally, for those areas in which SoC hardware prevents compliance with the existing standard (TPM, RTC, etc), additional requirements are being developed. These are described at the end of the table.
|UEFI secure boot||
|UEFI measured boot||
The following requirements do not imply a need for a TCG TPM implementation; they do however imply a need for equivalent functionality for the affected areas.
The platform support may be provided by a firmware implementation of a TPM executing in the secure execution environment, layering on top of the cryptographic acceleration engine and leveraging the isolated storage. Microsoft may be able to provide reference software for such a TPM implementation for use by the vendor. This is subject to further discussions.
|Other security requirements||
The following additional requirements are required by Windows on SoC platforms.
Firmware boot manager requirements
The firmware boot manager must support the default boot behavior defined in section 3.3 of the specification. Additionally, for support of multi-boot, globally-defined variables and the Boot Manager requirements of section 3.1 of the specification are required.
UEFI Arm binding requirements
The UEFI Arm Binding includes requirements specific to the Arm platform needed in order to be UEFI spec compliant. Windows requires everything in the Arm binding that is applicable to ARMv7. Because Windows does not support anything previous to ARMv7, requirements in the binding that are specific to ARMv6k and below are optional.
The binding specifies for example how the MMU should be configured, and how physical memory should be mapped. The binding also specifies that calls made to UEFI protocols and services should be done in only the Arm ISA, meaning that software running in Thumb2 or Thumb would need to switch back to Arm mode before calling UEFI functions.
UEFI Arm multiprocessor startup requirements
Microsoft has developed a protocol for starting multiple Arm cores on a multi-processor UEFI platform. This protocol is required by Windows on Arm platforms that do not support the Power State Coordination Interface (PSCI). Platforms that do support PSCI must not use this protocol. For more information about this protocol, see the Multiprocessor startup on UEFI Arm-based platforms document on the ACPI Component Architecture (ACPICA) Web site.
Platform setup requirements
The firmware is responsible for putting the system hardware into a well-defined state before handing-off to the OS loader. The following table defines the related platform setup requirements.
|Boot path||The firmware must initialize the platform to the point where Windows is able to access the boot device via UEFI and load the kernel. Any device involved in the hierarchy to read from the boot device must be clocked and powered at a reasonable rate, given performance and power considerations. The base processor core itself should also be clocked and powered at a reasonable rate, so that the system can boot in a timely manner without draining the battery.|
|Core system resources||The Core System Resources that are exposed to the OS through ACPI tables must be powered on and clocked. Core System Resources include Interrupt controllers, Timers and DMA controllers that must be managed by the OS. Additionally, interrupts must be masked by the call to ExitBootServices() until the associated device driver in the OS unmasks and re-enables interrupts on the device. If interrupts are enabled during boot services, it is assumed that the firmware will manage them.|
|Debugging||Windows supports debugging via USB 3 Host (XHCI) , USB 2 Host (EHCI)1, IEEE 1394, serial and USB Function interfaces (as well as PCI ethernet adapters). At least one of these must be powered, clocked and initialized by the firmware before OS handoff. Whichever option is provided, it must have an exposed port for debugging purposes, and the controller must be memory-mapped, or be connected via a dedicated (non-shared) peripheral bus.|
|Other platform setup requirements||Any pin-multiplexing and pad configuration must be completed in the firmware prior to handing control to the OS loader.|
Windows requires the OS partition to reside on a GPT partitioned storage solution. MBR partitioned storage can be used as data storage. As defined in the UEFI specification, a UEFI platform requires a dedicated system partition. Windows requires this dedicated system partition, referred to as the EFI system partition (ESP).
Hardware Security Test Interface (HSTI) requirement
The platform must implement the Hardware Security Test Interface, and the platform is required to share documentation and tools as specified in the Hardware Security Testability Specification.
Submit and view feedback for