Why to love it, why to hate it, and what it is to begin with.
Many people, both inside and outside of the Linux community, have heard about UEFI and may understand that it is something similar to its predecessor: BIOS. They may understand it is something low-level and VERY necessary for your computer, however they may not understand what it actually does, and why we need it. Here, I hope to provide research and evidence as to what UEFI is, what it does, how it’s different from BIOS, as well as its pros and cons. However, I would like to start with a word of caution about partition tables.
Partition tables are essentially the firmware on a given internal drive which tells your UEFI or BIOS how big partitions are, and where they are on the disk in question. There are two major partition tables: MBR (which stands for Master Boot Record) and GPT (GUID Partition Table). In this article, we examine both UEFI and BIOS as if they were both using MBR. A few things will differ from the information laid out here if your drive uses GPT instead of MBR. Mainly: partition size support is much better on BIOS when using GPT than it is when using MBR. However, we use MBR here across the board to keep things consistent. So, without further ado:
What is this “UEFI”?
According to UEFI.org, UEFI is and stands for:
. . . “Unified Extensible Firmware Interface.” The UEFI Specification defines a new model for the interface between personal-computer operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications.
In a nutshell, this means that UEFI works as a middle-man between your firmware (cause every piece of hardware has it’s own special firmware) and the bootloader (which, in Linux is USUALLY (not always) GRUB), as well as the operating system itself. It does this by having special pools of data that an operating system or bootloader can read and use to interact with your firmware. It also provides certain functions where the Linux kernel can call a certain function and pass it data and have the UEFI understand it wants to do things with different parts of the hardware such as storing info in the RAM, write data to the internal drive, changing the current CPU or GPU clock speeds, and more.
Why do we need UEFI?
Every CPU model have a slightly different version of the x86, x86_64, or amd64 instruction set. x84_64 and amd64 are the exact same thing. x86 is the 32-bit processor instruction set that Intel used to use while the other is the 64-bit instruction set most CPUs for laptops, desktops, and servers use these days. Most Linux distributions support 64-bit while only a few now support 32-bit, such as Lubuntu. These slightly different versions make it so that you cannot write a bootloader or operating system for all hardware running a certain CPU architecture, at least, not without something to compensate for these differences. So, instead, computer manufacturers make the UEFI in order to allow software developers to more easily interact with hardware, and not just the CPU, but all parts of the computer. The interface UEFI provides to the bootloader and operating system to interact with this hardware should be extremely similar between every UEFI version and UEFI manufactures. What differences there are should be able to be accounted for by software developers in the bootloader and the operating system’s kernel. However, we have not always had UEFI. In fact, it is a rather new development.
Up until the late 2000’s, the major software-firmware interface that existed was the BIOS (Basic Input/Output System). Historically, BIOS usually translated commands from the operating system to the firmware so that things worked correctly. However, around the time of Windows 7, Ubuntu 12.04, and other operating systems, BIOS was becoming outdated as operating systems could now do more of this work themselves. This made it so that after boot, the BIOS would just shut off and do next to nothing. Beyond that, the problem with BIOS is that it has a few other, major, limitations:
- BIOS is written in 16-bit, even though most modern CPUs and Linux distributions are 64-bit
- BIOS only supports, at most, 4 partitions, at each up to 2.2 TB each. While this may work in most cases for most users, sometimes, it can be limiting.
- It is not easily extensible
- it is less secure
UEFI has an answer to each of these. Improving it to be better in many ways than BIOS:
- UEFI is either 32- or 64-bit. This allows it to take more advantage of the host system’s hardware upon boot.
- UEFI supports drives up to 9.4 zettabytes of storage
- Secure Boot, which is a way of verifying the integrity of an operating system’s kernel during boot, helps with preventing a certain type of special computer virus, called a root kit, from entrenching itself in a users system and is only available with UEFI.
- UEFI is much more extensible and can be given things such as overclocking utilities and more
- UEFI is faster to boot than BIOS
- UEFI allows for mouse emulation (so you can use your mouse in the UEFI menu)
- UEFI supports complex background and foreground graphics and animations
Beyond all this, UEFI also provides operating systems with an easier method of communicating with firmware, and almost shuts itself down after a bootloader has begun to take over (Side Note: Both BIOS and UEFI do keep running as long as a computer is on. It’s more like they are idle, and not shut down. UEFI is just designed more to do this than BIOS.).
Why don’t some people use UEFI?
The catch to UEFI is that it does not like changing host operating systems. You sometimes have to disable Secure Boot just to boot from a USB drive so that you can install a new operating system. You also have to have a specially formatted partition on your boot drive with a certain flag on it. Typically, this partition is at most 200 MB and formatted in FAT32, but that is 200 MB less available to the user. Sometimes, it can also be harder to update the UEFI. This can lead to decreased performance, bugs, and security issues as time rolls on.
Most Linux distributions do indeed support UEFI. If they have the Ubiquity, Calamares, or Anaconda installers, then they will handle UEFI automatically using any of the automatic settings. So, out of the box, Ubuntu, Fedora, Pop!_OS, Linux Mint, Debian, and many other popular Linux distributions support UEFI, or have instructions on how to handle it. However, more niche distributions such as MX Linux, Antix, Puppy Linux, Arch or Arch Labs, and Drauger OS, may have support for UEFI but it is patchy and may not work correctly out of the box. And still yet, many Linux distributions do not have support for UEFI at all! These are few and far between, as GRUB is usually pretty good about understanding you have UEFI and want to use it. But they do exist, and I felt they should be mentioned here, for completeness.
In general, if you have UEFI available on your system, the pros may outweigh the cons of using UEFI, unless you want to install a new operating system and have to fight with Secure Boot more than some other users may have to. In which case it depends on how easy it is to disable this security feature. Overall, if you have some sort of legacy software that needs BIOS, then use it. Otherwise, it is suggested to use UEFI for better performance, security, and support overall.
The below links are from the documentation of multiple different Linux distributions and provide more in-depth information on how that distro behaves and interacts with UEFI and how to handle it.