Recommended resources
The freely available resources this lesson will direct you to.
- Mastering UEFI: Your Essential Guide to Hardware-Firmware and Boot-Chain Securitywww.youtube.com
- Intro / Overview | UEFI Dev (in C)www.youtube.com
- 2. Firmware Storage Design Discussion — UEFI Platform Initialization Specification 1.8 Errata A documentationuefi.org
- 2. Overview — UEFI Platform Initialization Specification 1.8 Errata A documentationuefi.org
Hello! In the previous lesson, you followed a typical UEFI boot through SEC, PEI, DXE, BDS, and the OS loader. Now the question is: what code is actually running during those phases, where is it stored, and who decides when to run it? This distinction matters in firmware-security work because a built-in firmware driver, an application launched by the boot manager, and an OS driver are different components with different roles.
Allow about 35–40 minutes, including the selected reading and video.
Firmware volumes: where platform code is organized
A typical platform needs more than one monolithic firmware program. It needs early initialization code, components tailored to particular hardware, drivers that provide boot-time capabilities, and sometimes built-in applications. The Platform Initialization (PI) architecture organizes much of this code in firmware volumes (FVs).
An FV is a logical repository for firmware code and data. It contains a firmware file system (FFS), whose files can hold executable modules or data. A physical flash device may hold multiple FVs; “firmware volume” does not mean a separate flash chip. Nor is an FV the EFI System Partition (ESP) on a storage drive. The ESP is one possible place for a boot manager to find a later UEFI executable; an FV is part of the platform firmware’s own organization.
Within an FV, the useful mental picture is volume, firmware file, file section. A firmware file has a type that helps identify its intended use. Its sections may hold executable code, dependency information, or other data. Some sections contain other sections—for example, to package compressed content—so finding an executable can involve looking inside a file rather than treating the whole file as a flat program.
The PI specification is detailed; read only these short passages to establish that storage model:
Read the UEFI Forum’s description to see precisely what an FV, a firmware file, and a file section are. Focus on the nesting of these structures, not the long lists of storage attributes.
In Section 2.1.2, “Firmware Volumes,” read the FV definition; stop before the attribute list. Then read Section 2.1.3, “Firmware File System,” beginning “A firmware file system (FFS) describes the organization of files,” and the opening of Section 2.1.4, “Firmware Files,” beginning “Firmware files are code and/or data stored in firmware volumes.” Stop before the paragraph about PEI file-related services. Finally, in Section 2.1.5, “Firmware File Sections,” read the section model; stop before the figure. Notice the difference between a section that contains other sections and a leaf section that contains data.
A file type describes what kind of firmware component the file represents; a section type describes something inside that file. For example, a DXE-driver file may contain an executable-image section and a dependency-expression section. That distinction becomes useful when inspecting a firmware image: finding a driver’s executable bytes is not the same as understanding when the driver is eligible to run.
Executable modules across the initialization phases
Recall the dependency between phases: early code must run with limited resources; PEI makes essential resources available; DXE can then establish a broader firmware environment. PI firmware uses different executable components to accomplish that work.
| Phase or stage | Relevant component | Its role |
|---|---|---|
| SEC | Security-core code | Begins execution in the platform’s restricted early environment. |
| PEI | PEI core and PEIMs | The core supplies the PEI environment and dispatches modules that perform early platform initialization, such as work needed to establish memory. |
| DXE | DXE core and DXE drivers | The core establishes the DXE environment; drivers add platform and device capabilities needed before boot. |
| BDS | Firmware boot-manager functionality | Uses the environment established earlier to attempt a boot option. BDS is a stage of boot, not a claim that every implementation has one FFS file called “BDS.” |
| OS loading | UEFI executable, often an OS loader | Is launched in the pre-OS UEFI environment and continues the boot path toward the kernel. |
A PEIM—a Pre-EFI Initialization Module—is specialized for PEI’s resource-constrained environment. PEIMs are sometimes described as early drivers, but they are not interchangeable with DXE drivers. The PEI dispatcher examines whether a PEIM’s stated dependencies are satisfied before invoking it. PEIMs can publish or use PPIs (PEIM-to-PEIM Interfaces) to make early capabilities available to one another.
The corresponding idea in DXE is that a DXE driver can supply firmware capabilities, often through protocols that other firmware components can discover and use. The DXE dispatcher can use a driver’s dependency expression to determine when it is ready to run. Dispatching therefore means more than finding executable bytes in an FV: the appropriate environment and prerequisites must also be present.
Read the specification’s focused explanation of PEIMs and PEI dispatch:
2. Overview — UEFI Platform Initialization Specification 1.8 Errata A documentation
Read these UEFI Forum sections to connect the PEI modules introduced above to the decision to run them.
In Section 2.6, “Pre-EFI Initialization Modules (PEIMs),” read the PEIM description, stopping at the end of the section. Then find Section 2.5, “PEI Dispatcher,” and read the dispatch explanation through its final sentence. Focus on why a module present in a firmware volume might not yet be eligible to execute.
For a compact reference to file types, return to the firmware-storage specification:
Use the UEFI Forum’s file-type descriptions to check how stored modules correspond to SEC, PEI, and DXE. This is a selective lookup, not a request to study every file type.
In Section 2.1.4.1, “Firmware File Types,” read the type explanation, then scan Table 2.7 only for security core, PEI core, PEIM, DXE core, driver, and application. Next, in subsection 2.1.4.1.4, “EFI_FV_FILETYPE_DRIVER,” read from “The file type” through “The file must contain no more than one EFI_SECTION_DXE_DEPEX section.” In subsection 2.1.4.1.1, “EFI_FV_FILETYPE_APPLICATION,” read the application distinction in its opening paragraph. The key comparison is driver dispatched by DXE versus application loaded for execution, but not dispatched by DXE.
The table names file types, not a mandatory list of separate chips or binaries on every machine. What matters here is the relationship between a stored module’s type, the phase able to use it, and the dispatcher or loader that starts it.
Why an application is not a DXE driver
A UEFI application is an executable that runs in the UEFI environment, but it is not automatically dispatched as a DXE driver just because it is executable. A firmware setup utility or UEFI shell can be an application. An OS bootloader is also a UEFI executable launched on a boot path. Applications may be built into firmware volumes or supplied on accessible storage, depending on their purpose and the platform.
A DXE driver, by contrast, is intended to extend the firmware environment—for example, by making a device capability available to other pre-OS code. A Linux driver has a different lifetime and environment: it runs under the OS, not as a DXE driver merely because it supports the same device. When someone says “the storage driver failed,” identifying which environment’s driver they mean is essential.
This short video excerpt makes the application side concrete. You do not need to follow every C declaration; watch for where the example program obtains its firmware-provided interfaces and how it behaves once launched.
Intro / Overview | UEFI Dev (in C)
Watch “Intro / Overview | UEFI Dev (in C)” by Queso Fuego for a small UEFI application example, rather than a full firmware-driver implementation.
Watch the entry point to see the pre-OS application receive a System Table pointer and use firmware-provided facilities. Then watch the running program in a virtual UEFI environment. Focus on the distinction between an application using firmware facilities and a driver providing capabilities within firmware; the compilation details are not needed here.
There are two placement details worth keeping separate. First, not every UEFI executable lives in an FV: an OS loader commonly resides on a storage device and is launched by the firmware boot manager. Second, not every executable found in an FV runs immediately: its file type, phase, and dependencies matter. In the next lessons, you will examine the services an application can use and how the boot manager locates a loader on disk.
Reading a boot failure through its components
Suppose firmware reaches its boot menu but cannot start an OS from a particular drive. Knowing the phases prevents a vague diagnosis such as “UEFI did not work.” Reaching the menu suggests that substantial early initialization has already succeeded. The remaining possibilities include a missing pre-OS capability for accessing that drive, an unavailable boot target, or a problem loading the selected executable. You would need evidence before choosing among them.
Conversely, if a platform fails before permanent memory becomes usable, looking first for a missing ESP file would not match the stage of failure. The relevant code is much earlier: SEC, the PEI core, and PEIMs involved in preparing the platform for DXE. This is why firmware architecture is useful for security and testing work: it tells you which component could plausibly have acted at the observed point in boot.
Key takeaways
Firmware volumes organize platform code and data as firmware files containing sections. The phase determines which components can operate: PEIMs perform constrained early work in PEI; DXE drivers extend the richer firmware environment; and UEFI applications, including many boot-path executables, run using that environment rather than being dispatched as DXE drivers. A component’s presence in storage does not by itself mean it has run.
Next, you will distinguish UEFI Boot Services from Runtime Services—which facilities pre-OS drivers and applications can use, and what remains available after the OS takes control.