UEFI drivers are different from UEFI applications in that, unless there is an error returned from the driver's entry point, the driver stays resident in memory. The UEFI platform firmware, the boot manager, and UEFI applications may load drivers.
Boot drivers are loaded into memory marked as EfiBootServicesCode, and they
allocate their data structures from memory marked as EfiBootServicesData.
These memory types are converted to available memory after ExitBootServices()
is called.
Runtime drivers are loaded in memory marked as EfiRuntimeServicesCode. They
allocate their data structures from memory marked as EfiRuntimeServicesData.
These types of memory are preserved after ExitBootServices() is called. This
preservation allows runtime driver to provide services to an operating system
while the operating system is running. Runtime drivers must publish an
alternative calling mechanism, because the UEFI handle database does not
persist into OS runtime. The alternative calling mechanism is
application-specific.
The most common examples of UEFI runtime drivers are the Floating Point
Software Assist driver (FPSWA.efi) and the network Universal Network Driver
Interface (UNDI) driver. The EDK II does include an UNDI driver. UEFI Drivers
for Network Interface Controllers (NICs) are discussed in detail in Chapter
25. Other runtime drivers are not common and are not discussed in this guide.
Implementing and validating runtime drivers is much more difficult than implementing and validating boot service drivers. The difficulties occur because UEFI supports the translation of runtime services and runtime drivers from a physical addressing mode to a virtual addressing mode. For example, a pointer might not have the same value in the physical address space as it might in the virtual address space. Getting that translation, or mapping, correct is very difficult because if even a single pointer translation is missed, the OS may crash or hang if the runtime driver is called and a code path that accesses that pointer is used. Debugging runtime services provides by UEFI Drivers at OS runtime is more difficult than debugging UEFI Drivers in the preboot environment. Since some code paths are executed infrequently, careful code review and extensive validation of runtime drivers is strongly recommended. Also, there are no utilities to perform such translations automatically. Each piece of data and memory allocation must be inspected manually to determine if it needs to be adjusted. That in itself can be an error-prone process. Additionally, if another driver writer tries to adjust the code, that writer might not be aware of each piece of data or memory allocation that must adjusted.
There are best practices to help perform these translations. However, great care must be taken to follow the recommended practices and UEFI requirements rigorously. Many of the requirements for runtime drivers are listed in the UEFI Specification. Make sure they are well understood. Of particular importance are the sections on runtime services, and specifically, virtual memory.