How Does Linux Boot? Part 2: UEFI Is The New Firmware

It’s amazing that the early 1980s IBM PC design lasted as long as it did. Into the 2000s people relied on its very limited BIOS firmware and MBR partition tables. But now it’s the 2010s and things have finally moved forward.

I gave you an overview of how Linux boots. The first steps involve the firmware, storage media, and boot loader. In modern systems that means UEFI, GPT, and GRUB 2.

You attend a Linux server administration course to learn about the operating system, but troubleshooting sometimes involves what comes before it starts.

A motherboard has firmware, for AMD/Intel processors it will be be BIOS or UEFI. The Extensible Firmware Interface (or EFI) came out of Intel-HP Itanium development in the mid 1990s. Unified EFI (or UEFI) was first standardized in 2005.

Don’t say “This system’s BIOS is UEFI.” That’s like saying “This orange is an apple.” UEFI is a type of firmware, not a type of BIOS.

Unified Extensible Firmware Interface logo The transition from BIOS to UEFI started a number of years ago on servers. The transition accelerated with Microsoft’s announcement that they wouldn’t allow retail sales of Windows 8 computers without UEFI firmware and its support for Secure Boot.

The UEFI firmware initializes the hardware — the processor, the memory, and peripheral controllers including Ethernet, SATA, video, and others. A peripheral controller can have its own firmware used to initialize itself, which sometimes is called an Option ROM. UEFI can examine peripheral firmware for embedded signatures which can appear on the UEFI’s “Allowed” and “Disallowed” list. So, if inappropriate peripherals are added, or if peripheral firmware is subverted (among other cases, see many of the NSA exploits recently described in worldwide media), the motherboard firmware prevents its operation.

This is the first part of how UEFI can enforce a security policy that can’t be bypassed without modifying the firmware, the very first thing that runs when power is applied.

Once the peripherals have been initialized (and approved), UEFI looks for something called the EFI System Partition (or ESP). It’s possible you are still using the old IBM MBR (or Master Boot Record) partition tables, but in these days of multi-terabyte disks we need to use GPT or GUID Partition Tables. These solve many shortcomings of MBR, including the inability of the old partition table format to handle disks over 2 TB in size.

UEFI doesn’t know whether your partition tables are modern or not, so it looks for both: Either an MBR partition of type 0xEF or a GPT partition with GUID (or Globally Unique Identifier) C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

It’s likely that the EFI System Partition will be the first partition of the first disk. It’s the first storage media to be used and so it’s the first thing you, or really the installer, need to install. But UEFI does not suffer from the limitations of BIOS, so this partition could be anywhere on the storage media. The EFI System Partition must contain a FAT32 file system, or FAT12 or FAT16 on removeable media like a DVD or USB stick.

What does UEFI do next? The common answer is “It runs the program \EFI\BOOT\BOOTX64.EFI from that partition.”

Well, no. It might do that, it’s common, but UEFI runs whichever program within the EFI System Partition you told it to.

Let’s look at a real Linux system on UEFI-GPT hardware. I’m on a default installation of Red Hat Enterprise Linux 7. I’ll ask UEFI what it is configured to do, and I’ll trim away some of the unneeded output and highlight what we’re looking for:

# efibootmgr -v
BootCurrent: 0004
Timeout: 5 seconds
BootOrder: 0001,0004,0000,0003,0002
Boot0000* EFI VMware Virtual IDE Hard Drive (IDE 0:0)   ACPI(a0341d0,...
Boot0001* EFI VMware Virtual SATA CDROM Drive (1.0)     ACPI(a0341d0,...
Boot0002* EFI Network   ACPI(a0341d0,0)PCI(12,0)MAC(000c29cf6279,0)
Boot0003* EFI Internal Shell (Unsupported option)       MM(b,bee94000,...
Boot0004* Red Hat Enterprise Linux    HD(spec)File(\EFI\redhat\shim.efi)

Red Hat’s installer has added a program named \efi\redhat\shim.efi (it’s FAT32, case is ignored) and told UEFI to run it first.

What’s going on?

If Secure Boot is enabled in UEFI, the firmware’s security policy will only run software with a valid digital signature from a trusted signing authority.

Here is where some “Microsoft is trying to kill Linux!” conspiracy theories can be debunked. This is a UEFI feature and not a feature created or controlled by Microsoft. In fact, Microsoft insists that UEFI firmware allow the hardware’s owner to disable Secure Boot or the platform won’t get the “Approved for Windows 8 (and later)” stickers. At least that’s true for Intel/AMD hardware — for reasons I haven’t completely figured out they insist that the owner not be able to disable it on ARM platforms.

Canonical became a trusted signing authority, they created and digitally signed a program shim.efi. This “shim” of a program slips in between UEFI and the Linux or other OS boot loader. It’s trusted and allowed by UEFI due to the signature. It then chain-loads the next program.

At least that’s what is supposed to happen so far. Meanwhile some manufacturers have done inappropriate things. For example, Lenovo shipped some systems with firmware hard-coded to only run the Windows Boot Manager or Red Hat Enterprise Linux.

What happens next? Well, it depends on which program shim.efi has been coded to chain-load next, and what that stage does in its turn. This part of the story has gotten long enough — have a happy holiday season, and I’ll get to the next part of the story next week, which will end up being next month, and next year!

PS – Make sure to view our entire Linux/UNIX curriculum including our new 4-day course on Linux Virtualization & 2 new 1-day online courses!

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.