It seems like there are two camps, the small group of people who care about UEFI and everyone else who doesn’t really notice or care as long as their computer works. So let’s talk about what UEFI is, how it came to be, what it’s suitable for, and why you ought to (or shouldn’t) care.
What is UEFI?
UEFI means Unified Extensible Firmware Interface, a conventional held by an organization known as the United EFI Forum. Intel came out with EFI (Extensible Firmware Interface) and later made the spec public as UEFI. As a spec, application details change between vendors and manufacturers, but the goal is to present an OS bootloader’s conventional and understandable structure. This makes it much simpler to write an OS as you no longer need to worry about all the untidy company of actually starting the chipset.
Several IBVs (Independent Bios Vendors) offer their implementations of UEFI that OEMs who produce motherboards can license and use in their products. Some examples would be AMI, Phoenix, and InSyde. You’ve likely seen their logo or just the text of their name briefly flash on the screen before your OS of choice correctly boots.
Let’s talk about how UEFI boots. Generally, there are a few different phases. We typically say because there are numerous implementations and numerous of them do things out of spec. There are three general phases: safety and security (SEC), Pre-EFI Initialization (PEI), and Drive Execution environment (DXE). Each is a mini operating system. because Intel is the one who started EFI and later turned it into UEFI, much of the design is developed around how Intel processors boot up. other platforms like ARM might refrain from doing much in the SEC or PEI phase.
The boot process for X86 processors is a bit strange. They start in real mode (though most processors these days are technically unreal), with a 20-bit address space (1MB of addressable memory) for backward compatibility reasons. As the processor continues to boot, it switches to secured mode and then finally to long mode. In a multi-core system, all the processors race to get a semaphore or read EAX, and one is designated the BSP (bootstrap processor). The losers all halt until the BSP starts them through an IPI (inter-processor interrupt). Ordinarily, there is an onboard SPI flash chip with firmware mapped into the end of the physical 32-bit region of memory. The Intel management Engine (ME) or AMD platform safety and security processor (PSP) does most of the SEC phase, such as flushing the cache and starting the processors.
Once the processors are started, PEI has officially begun. On Intel systems, there is no system RAM in most of PEI. This is because memory needs to be trained and links initialized before the processor can use them. The ever ruthless push for much more and much more speed from RAM implies that the RAM needs to be tested, calibrated, and configured on every boot as different RAM sticks have other parameters. numerous systems cache these parameters for quicker boot times, but they typically need to be invalidated and retrained as the RAM sticks age. The PSP handles memory training and packing UEFI on some AMD systems before the main x86 processor is pulled out of reset. For Intel systems, they use a trick called XIP (execute in place) which turns the various caches into short-term RAM. There is only a small stack, a tiny amount of heap space, and no static variables for PEI. numerous Intel server platforms rely on the Board management Controller (BMC) to train memory, as training large amounts of memory takes a very long time.
After initializing RAM and transferring the contents of the short-term cache, we relocation to DXE. The DXE phase offers two kinds of services: boot and runtime. Runtime services are meant to be consumed by an OS, services such as non-volatile variables. Boot services are destroyed once ExitBootServices is called (typically by the OS loader), but they are services like keyboard input and graphical drivers. BDS (boot device selection) runs in DXE and is how the system determines what drive to boot (hard drive, USB, etc.).
This has been a very dense and x86 particular overview. numerous architectures such as ARM eschew UEFI for something much more like coreboot, linuxboot, or LK, where it boots a small Linux kernel that then kexec’s into a much larger kernel. However, numerous ARM platforms can also leverage UEFI. only time will tell which way the industry moves.
How It came to Be
In 2005, UEFI entirely replaced EFI (Extensible Firmware Interface), the conventional Intel had put forth a few years prior. EFI borrowed numerous things from Windows of that period, PECOFF image formats, and UEFI, in turn, borrowed methods from EFI. before EFI, there was good old BIOS (Basic Input Output System). The name originated from CP/M systems of 1975. in that period, the BIOS was a way for the system to boot and offer a somewhat uniform interface for applications by offering BIOS interrupt calls. The phone calls enabled a program to access the input and outputs such as the serial ports, the RTC, and the PCI bus. Phoenix and others reverse-engineered the proprietary interface that IBM produced to manufacture IBM compatible machines, which eventually led to something close to a standard.
Is It better Than BIOS?
Yes and no, depending upon your perspective. numerous OS vendors like UEFI because they typically make their lives simpler as the services provided make it easy to give a homogenous experience booting. The Linux community, typically speaking, is agnostic at best and antagonistic at worst towards UEFI. The BIOS interface is pushing 45 years as of the time of writing and is considered legacy in every sense. another point in UEFI’s corner is that it facilitates choosing different boot gadgets and updating the firmware on your machine. UEFI utilizes GUID Partition Table (GPT) over Master Boot record (MBR) — considerd a plus as MBR is somewhat inflexible. numerous platforms shipped today are based on the open-source EDK2 project from TianoCore, an implementation of UEFI that supports X86, ARM, and RISCV.
The biggest grievance with UEFI is that it is a closed black box with unimaginable access to your computer and stays local after the computer boots. BIOS is attractive because the interface is widely known and typically is non-resident. UEFI can be updated simpler but also has a much much more important need for updates. A UEFI update can brick your system entirely. It will not boot, and because of the fuses being blown on the unit, it is practically physically impossible to fix it, even for the manufacturer. significant amounts of testing go into these updates, but most are hesitant to push numerous updates because of the amount of work required.
Why You ought to or Shouldn’t Care
At the end of the day, you care if you can use your computer for the things that are essential to you. Whether that’s playing a game, writing an email, or making a new computer, it doesn’t matter as long as the computer does what you want. and booting is just one oft-forgotten step in making that happen. If you care about understanding every single piece of code your device runs, you need to buckle in for a long ride. There are business such as Librem going to long lengths to make sure that tricky issues like memory init are running in non-proprietary blobs. You can still modify UEFI, [Hales] being a terrific example of tweaking the BIOS of an old school laptop. Open-source tools for inspecting and understanding what’s going on under the hood are getting better.
Ultimately it is as much as you whether you care about the boot process of your device.