There are different types of UEFI images, but all UEFI images contain a PE/COFF header that defines the format of the executable code. The PE/COFF image header follows the format defined by the Microsoft Portable Executable and Common Object File Format Specification. The code can be for IA32, X64, IPF, or EBC. The header defines the processor type and the image type. Refer to the UEFI Image section of the Overview chapter in the UEFI Specification for definitions of the processor types and the following three image types:
UEFI boot services drivers
UEFI runtime drivers
UEFI images are loaded and relocated into memory with the boot service
There are several supported storage locations for UEFI images, including:
Expansion ROMs on a PCI card
System ROM or system flash
A media device such as a hard disk, floppy, CD-ROM, DVD, FLASH drive
In general, UEFI images are not compiled and linked at a specific address. Instead, they are compiled and linked such that relocation fix-ups are included in the UEFI image. This allows the UEFI image to be placed anywhere in system memory. The Boot Service
LoadImage() does the following:
Allocates memory for the image being loaded
Automatically applies the relocation fix-ups to the image
Creates a new image handle in the handle database, which installs an instance of the
This instance of the
EFI_LOADED_IMAGE_PROTOCOL contains information about the UEFI image that was loaded. Because this information is published in the handle database, it is available to all UEFI components.
After a UEFI image is loaded with
LoadImage(), the image can be started with a call to
StartImage(). The header for a UEFI image contains the address of the entry point called by
StartImage(). The entry point always receives the following two parameters:
The image handle of the UEFI image being started
A pointer to the UEFI system table
The image handle and pointer allow the UEFI image to:
Access all of the UEFI services that are available in the platform.
Retrieve information about where the UEFI image was loaded from and where in memory the image was placed.
The operations performed by the UEFI image in its entry point vary depending on the type of UEFI image. The figure below shows the various UEFI image types and the relationships between the different levels of images.
The table below describes the types of images shown in the preceding figure.
Type of image
A UEFI image of type
A special type of application that normally does not return or exit. Instead, it calls the EFI Boot Service
A UEFI image of type
A driver that produces one or more protocols on one or more new service handles and returns
A driver that does not create any handles and does not add any protocols to the handle database. Instead, this type of driver performs some initialization operations and returns an error code so the driver is unloaded from system memory.
Root bridge driver
A driver that creates one or physical controller handles that contain a Device Path Protocol and a protocol that is a software abstraction for the I/O services provided by a root bus produced by a core chipset. The most common root bridge driver is one that creates handles for the PCI root bridges in the platform that support the Device Path Protocol and the PCI Root Bridge I/O Protocol.
UEFI driver model driver
A driver that follows the UEFI driver model described in the UEFI Driver Model chapter of the UEFI Specification. This type of driver is fundamentally different from service drivers, initializing drivers, and root bridge drivers because a driver that follows the UEFI driver model is not allowed to touch hardware or produce device-related services in the driver entry point. Instead, the driver entry point of a driver that follows the UEFI driver model is allowed only to register a set of services that allow the driver to be started and stopped at a later point in the system initialization process.
A driver following the UEFI driver model. This type of driver produces one or more driver handles or driver image handles by installing one or more instances of the Driver Binding Protocol into the handle database. This type of driver does not create any child handles when the
A driver following the UEFI driver model. This type of driver produces one or more driver handles or driver image handles by installing one or more instances of the Driver Binding Protocol in the handle database. This type of driver creates new child handles when the
A driver that follows the UEFI driver model and shares characteristics with both device drivers and bus drivers. This distinction means that the