What Is Runtime After ExitBootServices?

Explains firmware state after ExitBootServices: Boot Services are gone, while Runtime Services remain.

October 28, 2025 Updated June 19, 2026 3 min read

Key idea

Runtime after ExitBootServices is the state after the boot loader successfully calls ExitBootServices(). From that point, UEFI Boot Services are no longer available, and the OS begins managing the system on its own terms.

This is one of the most important boundaries in the UEFI boot flow.

What changes after ExitBootServices

Before ExitBootServices(), firmware still provides Boot Services, the protocol database, the handle database, and many allocation APIs.

After ExitBootServices() succeeds:

Boot Services: no longer valid
Protocol database: no longer used in the same way
Firmware driver model: no longer the main control layer
OS memory manager: takes ownership
Runtime Services: only the preserved part remains

Any code that still calls Boot Services after this boundary is a serious warning sign.

Memory map after EBS

After EBS, the OS may reclaim Boot Services memory.

Examples include:

EfiBootServicesCode
EfiBootServicesData

These regions are no longer reserved for firmware. In contrast, runtime regions such as EfiRuntimeServicesCode and EfiRuntimeServicesData must be preserved according to their runtime descriptors.

Runtime Services that remain

After EBS, the OS may still call Runtime Services if the platform supports them.

Examples include:

GetVariable()
SetVariable()
GetTime()
SetTime()
ResetSystem()
UpdateCapsule()
SetVirtualAddressMap()

But these services must operate in runtime conditions. They cannot assume Boot Services or a full DXE handle database still exists.

How SetVirtualAddressMap fits in

After EBS, the OS may call SetVirtualAddressMap() to provide virtual mappings for runtime descriptors.

Firmware runtime code then handles the VirtualAddressChange event and converts live pointers with ConvertPointer().

If a pointer still holds a physical address while the OS has switched to virtual runtime mode, a later runtime call may crash.

Common failure pattern

A common bug is allocating private context with normal AllocatePool(), leaving it in EfiBootServicesData. Everything works before EBS. After EBS, the OS reclaims that memory.

When the OS later calls GetVariable() or another Runtime Service, firmware reads the stale context and triggers a page fault.

Debug checkpoints

When a failure appears after the kernel starts, ask:

Did ExitBootServices() succeed?
Was the final memory map correct?
Do runtime descriptors have EFI_MEMORY_RUNTIME?
Did the OS call SetVirtualAddressMap()?
Did the VirtualAddressChange handler run?
Were runtime pointers converted with ConvertPointer()?
Is any Boot Services API called after EBS?

This helps separate boot loader bugs, firmware runtime bugs, and OS mapping bugs.

Source-reading checklist

When reading runtime-after-EBS source, check:

- Are any pointers saved into Boot Services data?
- What memory type is used for runtime allocation?
- Does a runtime service depend on protocol or handle database state?
- Are there global pointers or linked lists that need conversion?
- Can the error path after SetVirtualAddressMap still be logged?
- Do capsule, variable, and reset paths run in runtime context?

Conclusion

After ExitBootServices(), firmware is no longer a full boot environment. The OS owns the system, Boot Services are gone, and only a preserved runtime subset remains. For post-boot bugs, check memory types, runtime descriptors, SetVirtualAddressMap(), ConvertPointer(), and any sign that Boot Services are being used after EBS.

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.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.

Đọc blog Xem notes khác