Recommended resources
The freely available resources this lesson will direct you to.
Hello! Last time, you distinguished firmware modules, DXE drivers, and UEFI applications. A driver or application running before the OS needs ways to allocate memory, discover devices, and start other programs. UEFI Boot Services provide those facilities. But when the OS takes control, most of them must stop being used. Runtime Services are the smaller set of firmware functions that can remain callable.
This lesson takes about 35–40 minutes, including the selected reading and video. By the end, you should be able to explain not just what each category does, but the precise event that separates their lifetimes—a useful distinction when discussing boot failures or firmware security in an interview.
Two sets of services, one pre-OS environment
UEFI defines interfaces that pre-OS code can call without implementing every hardware operation itself. A UEFI application, such as an OS loader, receives a pointer to the UEFI System Table. Through that table it can find the Boot Services and Runtime Services tables.
The names describe availability, not simply which code happens to be running. Boot Services are available in the established UEFI boot environment until a successful call to ExitBootServices(). Runtime Services are available before and after that call. This does not mean either set was available from the instant the processor reset: the early SEC and PEI work you studied precedes the fully established UEFI environment.
Read the specification’s introduction before examining individual functions:
7. Services — Boot Services — UEFI Specification 2.9A documentation
The UEFI Specification gives the defining availability rule and explains why an OS loader uses Boot Services before taking control.
In Chapter 7, “Services — Boot Services,” read the opening discussion from the service distinction. Stop before the list of individual function categories and Section 7.1. Focus on the words successful call: loading an OS executable is not, by itself, the event that ends Boot Services.
Boot Services include memory allocation and memory-map functions, event and timer functions, protocol-handling functions, and functions to load or start UEFI images. Device access is often exposed through protocols discovered in the boot environment. For instance, a loader can use firmware-provided facilities to find and read its files before it has an OS storage driver.
That is why a DXE driver and a UEFI application can both benefit from the environment established during DXE, even though—as you saw last time—they are not the same kind of component. Conversely, a Linux storage driver is not using UEFI Boot Services merely because it accesses the same disk. Once Linux has taken control, it manages devices through its own drivers and interfaces.
The boundary: ExitBootServices()
The OS loader needs time to prepare. It may still rely on firmware facilities while locating files, loading the kernel, and obtaining the platform’s memory map. When ready to assume responsibility for platform resource management, it calls ExitBootServices(). After that call succeeds, Boot Services must no longer be called. A pointer left in memory does not make an ended service valid.
The memory map makes this handover concrete. Before exit, some regions hold firmware Boot Services code and data; others hold Runtime Services code and data. After exit, the OS may use the former regions for general purposes, but it must preserve the regions designated for Runtime Services. Thus, “the OS takes control” does not mean “every byte used by firmware can be overwritten.”
7. Services — Boot Services — UEFI Specification 2.9A documentation
These short tables show the resource-management consequence of ending Boot Services.
In Chapter 7, Section 7.2, “Memory Allocation Services,” find Tables 7.5 and 7.6, “Memory Type Usage before ExitBootServices()” and “Memory Type Usage after ExitBootServices().” Compare only the rows for EfiBootServicesCode, EfiBootServicesData, EfiRuntimeServicesCode, and EfiRuntimeServicesData. Then read the note beneath Table 7.6, which begins “An image that calls ExitBootServices()” and ends by identifying the runtime regions the loader and OS must preserve. Skip the remaining memory types and the AllocatePages() prototype for now.
The important boundary is the successful call, not an imprecise milestone such as “the boot menu closes” or “the kernel file has been read.” Until the loader exits Boot Services, it can still use them. Afterwards, it cannot fall back to firmware’s boot-time image loading, memory allocation, or device protocols if something goes wrong. That distinction helps locate a failure: a problem after exit cannot be solved by simply asking a Boot Service to try the disk again.
What remains callable while the OS runs?
Runtime Services support a narrower kind of interaction with firmware. Examples include reading or setting suitable UEFI variables, obtaining firmware time, requesting a system reset, and certain firmware-update-related operations. The OS typically accesses these through its kernel’s firmware support; an ordinary user program does not acquire unrestricted access to firmware just because Runtime Services exist.
This excerpt explains the design motivation. Watch for the contrast between boot-time device facilities and the limited firmware operations an OS might still request. The speaker makes broader claims about how safely particular implementations can be contained; treat those as commentary, not as a guarantee that runtime firmware is risk-free.
UEFI Secure Boot in U-Boot - Grant Likely, Arm
“UEFI Secure Boot in U-Boot,” presented by Grant Likely on The Linux Foundation channel, briefly explains why standardized pre-boot APIs exist and why a smaller firmware interface remains useful to an OS.
Watch preboot APIs for the device-access motivation. Then watch runtime purpose for examples of OS-requested firmware operations, particularly boot-variable changes. You can skip the surrounding implementation discussion.
Variables reveal an important second distinction. GetVariable() and SetVariable() are Runtime Service functions, but that does not make every UEFI variable accessible after exit. Each variable has attributes controlling access and persistence. A variable marked for boot-service access alone ceases to be visible through GetVariable() after ExitBootServices(). A variable marked for runtime access can remain visible then; runtime access also implies boot-service access. Separately, a non-volatile variable can persist across power cycles. Persistence and runtime accessibility answer different questions.
Read the focused passages below rather than the detailed function prototypes or authentication formats:
8. Services — Runtime Services — UEFI Specification 2.10 documentation
The UEFI Specification distinguishes the availability of the variable-service functions from the accessibility of each individual variable.
In Chapter 8, Section 8.2, “Variable Services,” read the opening explanation, ending just before Table 8.3. In Section 8.2.1, “GetVariable(),” find the paragraph under “Description” beginning “Each vendor may create and manage its own variables”; read through its access rule. Finally, in Section 8.2.3, “SetVariable(),” under “Description,” locate the “Attributes have the following usage rules” list. Read the access bullets, from “Runtime access to a data variable implies boot service access” through the rule for non-volatile runtime writes. Skip the later authentication details.
Consider a boot-order setting as a practical use case: the OS may need to request a different boot choice for a later startup. The appropriate firmware variable and Runtime Service can provide that interface, subject to the variable’s attributes and any applicable authorization rules. You will examine which variables identify boot entries and loaders in the next lesson; for now, the key point is why an OS can still communicate some settings to firmware without retaining the entire pre-OS service environment.
One final qualification matters in technical discussions: “Runtime Service” describes its intended lifetime, not a promise that every operation will succeed on every platform. An implementation may report an operation unsupported at runtime, and an OS may choose not to use a particular service. Likewise, a runtime-accessible variable can still have restrictions on writing it.
Key takeaways
Boot Services support the established pre-OS UEFI environment—memory management, protocol discovery, and image loading among other tasks—and end after a successful ExitBootServices() call. Runtime Services can be called before and after that boundary, allowing limited OS-requested firmware operations. The OS may reclaim Boot Services memory after exit but must preserve memory designated for Runtime Services. For variables, distinguish the lifetime of the service function from the access attributes of the specific variable.
Next, you will use that distinction to follow how a firmware boot manager combines disk partitions, the EFI System Partition, and UEFI variables to select a loader.