What Is the Runtime Phase?
Explains the UEFI Runtime Phase: the firmware parts that still matter after the OS takes control.
Key idea
The Runtime Phase is the period after firmware has handed most control to the operating system, while some firmware functions can still be called by the OS through UEFI Runtime Services.
In short, boot firmware no longer controls the main flow, but firmware has not disappeared completely.
When the Runtime Phase begins
The Runtime Phase is usually discussed after ExitBootServices() succeeds.
Before that point, the boot loader can still use Boot Services such as AllocatePool(), LocateProtocol(), and LoadImage(). After that point, Boot Services are gone, and the OS owns memory management, drivers, scheduling, and the device stack.
However, Runtime Services such as variable services and time services may still be callable by the OS.
Runtime Services that remain
Common API groups include:
GetTime()
SetTime()
GetVariable()
SetVariable()
GetNextVariableName()
ResetSystem()
UpdateCapsule()
QueryCapsuleCapabilities()
SetVirtualAddressMap()Not every platform uses all of these in the same way. For example, GetVariable() and SetVariable() are central to NVRAM, Secure Boot, boot options, and capsule update flows.
How it differs from the Boot Phase
During the Boot Phase, firmware has Boot Services, the protocol database, the driver model, the handle database, and dispatchers.
During the Runtime Phase, the OS is in control. Firmware only keeps the runtime entry points that the OS preserved through the memory map and runtime attributes.
Therefore, a runtime driver must not depend on Boot Services after ExitBootServices().
Link to memory types
Runtime code and data must live in suitable memory regions:
EfiRuntimeServicesCode
EfiRuntimeServicesDataRelated descriptors must carry EFI_MEMORY_RUNTIME. If runtime context is allocated in EfiBootServicesData by mistake, the OS may reclaim it and the firmware runtime path may crash after boot.
Virtual address transition
Some operating systems call SetVirtualAddressMap() to move Runtime Services into virtual address mode.
When the VirtualAddressChange event is signaled, runtime drivers must use ConvertPointer() for internal pointers that need to survive.
If a pointer is not converted, or a nested pointer is converted incorrectly, the bug may only appear after the OS has booted.
Common debug case
For example, firmware variable service works in the boot loader, but GetVariable() causes a page fault after the OS starts.
Possible causes include runtime private context stored in Boot Services memory, or pointers not converted after SetVirtualAddressMap().
Source-reading checklist
When reviewing a runtime path, check:
- Is the module type DXE_RUNTIME_DRIVER?
- Do runtime code and data use the right memory types?
- Do descriptors carry EFI_MEMORY_RUNTIME?
- Is any Boot Services API used after ExitBootServices()?
- Is a VirtualAddressChange event registered?
- Does ConvertPointer() cover private context, globals, and linked lists?
- Do variable, flash, and SMM paths validate input after OS boot?Conclusion
The Runtime Phase is the small part of firmware that remains after the OS takes control. It is much smaller than the Boot Phase, but it is sensitive because it touches NVRAM, Secure Boot, capsule updates, reset, and firmware policy. Runtime bugs should be debugged by looking at memory type, runtime descriptors, SetVirtualAddressMap(), ConvertPointer(), and the fact that Boot Services are no longer available.
Found this article useful?
Share it with someone learning firmware, BIOS/UEFI, or embedded systems, or support the author.
Nội dung liên quan
Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.
What is ACPI: why firmware shouldn't power off by toggling a GPIO
Why shouldn't firmware toggle a GPIO to power off? ACPI is the contract firmware writes and the OS reads: tables, AML, power states, and debugging broken sleep and wake.
What Is Runtime After ExitBootServices?
Explains firmware state after ExitBootServices: Boot Services are gone, while Runtime Services remain.
SMM Architecture Overview
A practical overview of SMM, SMI handling, SMRAM/MMRAM, save state, lock timing, and firmware debug flow.
Biến note thành bài viết hoàn chỉnh
Notes là nơi ghi nhanh khái niệm.