How CSM Boots Legacy MBR OS on Modern UEFI Hardware

The Compatibility Support Module (CSM) is an optional firmware subcomponent within modern Unified Extensible Firmware Interface (UEFI) systems that allows legacy operating systems designed for older BIOS architectures to execute on modern hardware. This article explains how the CSM functions as an emulation bridge, detailing how it translates modern firmware calls, restores legacy 16-bit interrupt services, and replicates the Master Boot Record (MBR) bootloader execution path.

The Architectural Gap Between UEFI and BIOS

Modern UEFI firmware executes in 32-bit or 64-bit mode, using native EFI drivers, a partition-agnostic file system driver (typically FAT32), and the GUID Partition Table (GPT) standard. Under native UEFI, the firmware does not execute boot sector code; instead, it locates and loads pre-compiled EFI executable binaries (such as .efi loaders) defined by NVRAM variables or fallback paths.

In contrast, legacy operating systems—such as Windows 7 (32-bit), Windows XP, or older Linux distributions—rely on the traditional Basic Input/Output System (BIOS). These systems expect the processor to initialize in 16-bit Real Mode, utilize standard software interrupts (such as INT 10h for video and INT 13h for disk operations), and hand over execution to a 512-byte boot sector located at sector zero (LBA 0) of an MBR-partitioned drive.

How the Compatibility Support Module Works

The CSM resolves these hardware and architectural discrepancies through several structured steps:

1. Initializing Legacy Interrupt Vectors

During the platform initialization phase, if CSM is enabled in the firmware settings, the UEFI environment allocates a specific region of low physical memory (below the 1 MB mark) known as the Interrupt Vector Table (IVT) and the BIOS Data Area (BDA). The CSM populates the IVT with entry points pointing to legacy Interrupt Service Routines (ISRs). This ensures that calls to legacy software interrupts—like INT 13h for low-level disk reads and INT 10h for video display—can be captured and processed as expected by legacy bootloaders.

2. Loading Legacy Option ROMs

Modern hardware components, such as graphics cards and storage controllers, ship with UEFI-native drivers. When CSM is invoked, the firmware bypasses or complements these UEFI drivers by locating and executing legacy Option ROMs (OpROMs) embedded within the hardware or system firmware. These legacy OpROMs configure the hardware devices into operational states compatible with standard BIOS calls, such as initializing VGA text mode (80x25 characters) or setting storage controllers into legacy IDE/AHCI emulation modes.

3. Transitioning to 16-bit Execution

Native UEFI executes in protected or long mode. To boot an MBR-based operating system, the CSM must configure the CPU to match the expected legacy state. It switches the processor execution environment into 16-bit Real Mode (or creates an equivalent execution environment) with memory segments initialized to standard legacy defaults.

4. Executing the MBR Boot Sector

Once the legacy environment and storage interrupts are ready, the CSM initiates the legacy boot process:

  1. Storage Interrogation: The CSM uses legacy disk routines to query connected storage devices for valid boot media.
  2. Reading LBA 0: The firmware reads the first 512-byte sector (the Master Boot Record) from the primary storage device into system memory at the fixed physical address 0x0000:0x7C00.
  3. Signature Verification: The CSM verifies that the final two bytes of the sector contain the legacy boot signature 0x55AA.
  4. Handoff: If valid, the processor jumps execution directly to memory address 0x7C00.

From this point forward, the legacy boot code inside the MBR takes control, reads the partition table, identifies the active partition, loads the operating system's secondary bootloader, and continues loading the OS relying on the interrupt services provided by the CSM.