The firmware is the first software that runs when you press the power button. For decades, that software was BIOS. Then a replacement arrived called UEFI. Most computers sold today use UEFI, but the older system is still everywhere -- in virtual machines, embedded devices, and the assumptions baked into millions of lines of existing code.
Understanding both systems is not optional. You will encounter both, and the differences between them shape everything from disk layout to operating system security.
The Original BIOS
BIOS stands for Basic Input/Output System. IBM introduced it with the original PC in 1981. Its job was straightforward: test the hardware, find a disk with a boot program on it, load that program into memory, and hand over control.
The original BIOS ran in 16-bit real mode -- the same mode the Intel 8088 processor started in. It could address one megabyte of memory. It used interrupt-based service routines that an operating system could call to read a disk sector or write a character to the screen. The interface was simple, stable, and wildly successful.
For twenty years, BIOS barely changed. Vendors added features -- boot menus, PCI scanning, ACPI tables -- but the core interface remained 16-bit, interrupt-driven, and limited to 1 MB of addressable memory. The disk layout it used, called MBR, capped out at 2 terabytes. By the early 2000s, these limits were becoming painful.
Why BIOS Had to Go
Three problems forced the industry to act.
First, the 2 TB disk limit. MBR partition tables use 32-bit logical block addresses. With 512-byte sectors, that gives you 2^32 times 512 bytes -- exactly 2 TiB. Server vendors were already shipping disks larger than that.
Second, the 1 MB memory ceiling. BIOS code had to run in real mode or use awkward workarounds to access more memory. Writing firmware in 16-bit assembly was slow, error-prone, and hostile to features like network stacks or graphical setup screens.
Third, security. BIOS had no mechanism to verify that the code it loaded from disk was legitimate. Any program written to the first sector of a disk would be executed without question. Rootkits that replaced the boot sector were a real and growing threat.
Enter UEFI
UEFI stands for Unified Extensible Firmware Interface. Intel started the project in the mid-1990s under the name EFI for their Itanium processor, which had no legacy BIOS at all. The specification went through several revisions before being handed to an industry consortium called the UEFI Forum in 2005. Today, UEFI is the standard firmware interface for virtually all x86 and ARM platforms.
UEFI is not a single piece of software. It is a specification -- a contract that describes how firmware should behave, what services it must provide, and how operating systems should interact with it. Different vendors write their own UEFI implementations. What they share is the interface.
The practical differences from BIOS are large. UEFI firmware runs in 32-bit or 64-bit protected mode from the start. It can address gigabytes of memory. It has a built-in boot manager that understands file systems, so it can load a boot program from a specific file path on a specific partition rather than blindly executing whatever sits in the first disk sector. It supports a driver model, a network stack, and a command-line shell -- all before the operating system loads.
GPT: The New Partition Table
UEFI introduced a new disk layout called GPT -- the GUID Partition Table. Where MBR uses 32-bit addresses and supports four primary partitions, GPT uses 64-bit addresses and supports up to 128 partitions by default.
The first sector of a GPT disk contains a "protective MBR" -- a fake MBR entry that marks the entire disk as a single partition of an unknown type. This prevents old MBR-only tools from misinterpreting the disk as empty and overwriting the GPT data. It is a compatibility shim, nothing more.
Each GPT partition entry includes a 128-bit GUID (Globally Unique Identifier) as its type code and another GUID as its unique partition identifier. The operating system uses these GUIDs to identify partitions reliably, without depending on partition order or drive letters.
The EFI System Partition
UEFI-booted systems have a small FAT32 partition called the EFI System Partition, or ESP. This is where the firmware looks for bootloader programs. The ESP typically sits at the beginning of the disk and is between 100 MB and 550 MB in size.
Inside the ESP, bootloaders live at well-known paths. For example, the default fallback path is \EFI\BOOT\BOOTX64.EFI on a 64-bit x86 system. A Linux distribution might install its bootloader at \EFI\ubuntu\shimx64.efi. The UEFI boot manager stores these paths in NVRAM variables and presents them as boot options.
The UEFI Boot Flow
The boot process under UEFI looks different from BIOS. Instead of loading a 512-byte sector and jumping to it, UEFI firmware reads a full executable file from the ESP.
UEFI defines several boot phases internally. The Security (SEC) phase runs first, initializing the CPU cache as temporary RAM. The Pre-EFI Initialization (PEI) phase trains the memory and gets DRAM working. The Driver Execution Environment (DXE) phase loads firmware drivers for storage, network, and graphics. Finally, the Boot Device Selection (BDS) phase reads the boot variables from NVRAM and loads the selected bootloader from the ESP.
The operating system never sees most of this. By the time the bootloader runs, it has access to a rich set of UEFI services -- memory allocation, file I/O, network, console output -- that it can call through a well-defined function table. These services remain available until the OS calls ExitBootServices(), at which point the firmware gets out of the way and the OS takes full control of the hardware.
Secure Boot
Secure Boot is a UEFI feature that addresses the third problem: unsigned code execution. When Secure Boot is enabled, the firmware will only load and execute EFI binaries that are signed with a trusted cryptographic key.
The trust chain works like this. The firmware ships with a database of trusted keys, called the "db." It also has a database of revoked keys, called the "dbx." When the firmware loads an EFI binary from the ESP, it checks the binary's digital signature against these databases. If the signature matches a trusted key and has not been revoked, the binary runs. Otherwise, the firmware refuses to load it.
In practice, most systems ship with Microsoft's keys in the trust database because Microsoft signs the bootloaders for Windows and for the "shim" program that Linux distributions use. The shim is a small signed bootloader that contains the distribution's own key. It loads GRUB, checks GRUB's signature against that key, and GRUB in turn verifies the kernel. The chain extends from firmware to shim to GRUB to kernel.
You can add your own keys to the firmware database if you want to sign your own bootloaders. You can also disable Secure Boot entirely. The specification requires that users be able to turn it off on general-purpose PCs.
CSM: The Compatibility Bridge
Many UEFI systems include a feature called the Compatibility Support Module, or CSM. The CSM is essentially a legacy BIOS emulator built into the UEFI firmware. When enabled, it lets the system boot from MBR disks using the old BIOS method.
The CSM exists because the transition from BIOS to UEFI took over a decade. Operating systems, bootloaders, and recovery tools all needed time to add UEFI support. The CSM gave users and vendors a way to run old software on new hardware.
Modern systems are dropping CSM support. Intel removed it from their reference firmware starting with 11th-generation processors. If you are installing a current operating system on current hardware, you should use native UEFI boot with GPT. The only reason to use CSM today is if you need to run old operating systems that lack UEFI bootloaders.
Why Both Still Exist
BIOS is dead in new hardware. But it is alive and well in virtual machines, older servers, and embedded systems. QEMU and VirtualBox still default to BIOS-style boot in many configurations. Legacy operating systems -- anything before Windows Vista SP1 on the x86-64 side, or older Linux installers -- expect BIOS.
More importantly, the concepts from BIOS did not disappear. UEFI still performs POST. It still has to initialize memory, enumerate buses, and find a boot device. It does these things differently -- in 64-bit mode, with drivers and a filesystem -- but the sequence is recognizable. The BIOS boot process is the skeleton that UEFI built on.
Understanding BIOS teaches you what firmware must accomplish. Understanding UEFI teaches you how modern systems accomplish it. You need both.
Next: Memory Initialization