3 Load and Execute Additional Firmware Modules: The system BIOS executes additional
All changes in this version
Title
Load and Execute Additional Firmware Modules: The system BIOS executes additional
Control
pieces of firmware that either extend the capabilities of the system BIOS or initialize other hardware components necessary for booting the system. These additional modules may be stored within the same flash memory as the system BIOS or they may be stored in the hardware devices they initialize (e.g., video card, local area network card). 4. Select Boot Device: After system hardware has been configured, the system BIOS searches for a boot device (e.g., hard drive, optical drive, USB drive) and executes the boot loader stored on that device. 5. Load Operating System : While the system BIOS is still in control of the computer, the boot loader begins to load and initialize the operating system kernel. Once the kernel is functional, primary control of the computer system transfers from the system BIOS to the operating system.
In addition, the system BIOS loads system management interrupt (SMI) handlers (also known as System Management Mode (SMM) code) and initializes Advanced Configuration and Power Interface (ACPI) tables and code. These provide important system management functions for the running computer system, such as power and thermal management.
This section describes the boot process in conventional BIOS-based systems and the boot process in UEFI-based systems. While conventional BIOS is used in many desktop and laptop computers deployed today, the industry has begun transitioning to UEFI BIOS.
2.2.1 Conventional BIOS Boot Process
Figure 1 shows a typical boot process for x86-compatible systems running a conventional BIOS. The conventional BIOS often executes in 16-bit real mode, although some more recent implementations execute in protected mode. Some conventional BIOS-based firmware has a small block of BIOS firmware— known as the BIOS boot block— that is logically separate from the rest of the BIOS. On these computer systems, the boot block is the first firmware executed during the boot process. The boot block is responsible for checking the integrity of the remaining BIOS code, and may provide mechanisms for recovery if the main system BIOS firmware is corrupted. On most trusted computing architectures, the BIOS boot block serves as the computer system’s CRTM because this firmware is implicitly trusted to bootstrap the process of building a measurement chain for subsequent attestation of other firmware and software that is executed on the machine [TCG05].
The boot block executes the part of the conventional BIOS that initializes most hardware components— the Power-on-Self-Test (POST) code. During POST, key low-level hardware on the computer system is initialized, including the chipset, CPU, and memory. The system BIOS initializes the video card, which may load and execute its own BIOS to initialize graphics processors and memory. Figure 1: Conventional BIOS Boot Process 1
Next, the system BIOS searches for other peripherals and microcontrollers, and executes any Option ROMs on these components necessary to initialize them. Option ROMs execute very early in the boot process and can add a variety of features to the boot process. For example, the Option ROM on a network adapter could load the Preboot Execution Environment (PXE), which allows a computer to boot over the network.
Next, the system BIOS scans the computer system for storage devices that have been identified as boot devices. In a typical case, the BIOS attempts to boot from the first boot device it finds that has a valid master boot record (MBR). The MBR points to a boot loader stored on the hard drive, which in turn starts the process of loading the operating system.
During the boot process the system BIOS loads SMI handlers and initializes ACPI tables and code. SMI handlers run in a special high-privilege mode on the CPU known as System Management Mode, a 32-bit mode that is capable of bypassing many of the hardware security mechanisms of protected mode, such as memory segmentation and page protections.
1 This figure is based on information and a diagram found at [Duarte08]. 2.2.2 UEFI Boot Process
At a high level, the UEFI boot process, shown in Figure 2, follows a similar flow to the conventional BIOS boot process. One difference is that UEFI code runs in 32- or 64-bit protected mode on the CPU, not in 16-bit real mode as is often the case with conventional BIOS. Most UEFI-based platforms start with a small core block of code that has the primary responsibility of authenticating subsequent code executed on the computer system. This is very similar to the role of the boot block in conventional BIOS. This part of the boot process is known as the Security (SEC) phase, and it serves as the core root of trust in the computer system.
Figure 2: UEFI BIOS Boot Process
The next phase of the UEFI boot process is the Pre-EFI Initialization (PEI) Phase. The PEI phase is intended to initialize key system components, such as the processor, chipset and motherboard. In some cases, the code in the Security Phase and the PEI Phase comprise the core root of trust in a UEFI system.
The purpose of the PEI Phase is to prepare the system for the Driver Execution Environment (DXE) phase. The DXE phase is where most system initialization is performed. The firmware executed in this phase is responsible for searching for and executing drivers that provide device support during the boot process, or provide additional features. During this phase the UEFI BIOS may execute conventional option ROMs, which have a similar purpose.
The PEI and DXE phases of the UEFI boot process lay the foundation to load an operating system. The final tasks necessary to load an operating system are performed in the Boot Device Selection (BDS) phase. This phase initializes console devices for simple input/output operations on the system. These console devices include local text or graphical interfaces, as well as remote interfaces, such as Telnet or remote displays over HTTP. The BDS phase also loads any additional drivers necessary to manage console or boot devices. Finally, the firmware loads the boot loader from the first MBR or GUID Partition Table (GPT) formatted boot device, and loads the operating system.
During the boot process the UEFI BIOS loads SMI handlers and initializes ACPI tables and code.
The Run Time phase of the UEFI boot process begins when the operating system is ready to take control from the UEFI BIOS. UEFI runtime services are available to the operating system during this phase.
2.3 Updating the System BIOS
A system and its supporting management software and firmware may provide several authorized mechanisms for legitimately updating the system BIOS. These include: 1. User-Initiated Updates: System and motherboard manufacturers typically supply end users with utilities capable of updating the system BIOS. Historically, end users booted from external media to perform these updates, but today most manufacturers provide utilities that can update the system BIOS from the user’s normal operating system. Depending on the security mechanisms implemented on the system, these utilities might directly update the system BIOS or they may schedule an update for the next system reboot. 2. Managed Updates: A given computer system may have hardware and software-based agents that allow a system administrator to remotely update the system BIOS without direct involvement from the user. 3. Rollback: System BIOS implementations that authenticate updates before applying them may also check version numbers during the update process. In these cases, the system BIOS may have a special update process for rolling back the installed firmware to an earlier version. For instance, the rollback process might require the physical presence of the user. This mechanism guards against attackers flashing old firmware with known vulnerabilities.