Booting into UEFI Mode – The Good, the Bad, and the Ugly
UEFI is a much needed replacement for legacy BIOS setups. As for how it works – that’s going to take a bit longer to explain. There are quite a few advantages that UEFI has over BIOS setups, as well as some potential problems to consider.
To understand UEFI it’s helpful to have a solid grasp on BIOS. We’ll begin with a brief look at how a BIOS functions, and then move into UEFI. If you already know how BIOS works – feel free to jump ahead.
BIOS is just that screen that pops up if you hit the right key at boot that makes your computer look like it’s back in 1992. If that’s what you’re thinking, you aren’t wrong, but there’s more to it. BIOS stands for Basic Input Output System, and it’s responsible for your computer being able to boot. Let’s take a look at how BIOS works.
How Legacy BIOS Works
So when we turn on a computer we hit the power button, four hamsters start running on wheels (the first letters of each of their names spelling out BIOS), and then we sit at an operating system. Hopefully you know I’m not serious! Let’s take a look at a typical boot process for IA-32 architecture and a Windows system.
These systems have a BIOS that is stored in non-volatile (traditionally read only) memory. When a computer powers on, it begins by executing at memory address 0xffff0 – the end of the BIOS. Its first responsibility is the POST – Power On Self Test. This is where the BIOS accesses things like memory, I/O devices (think keyboard, monitor, mouse) and checks that everything works properly. It also performs a memory test to determine the RAM available, sets memory and disk drive parameters, configures any plug and play devices (PCIe, USB) and assigns interrupt requests and direct memory addressing. Last but not least it identifies a boot device, one of potentially several partitions flagged as bootable, looks at the boot sector (MBR) and loads it into memory.
Now the BIOS proceeds to check each device in it’s specified order for a bootable device. If one if found it provides a jump instruction to 0x7C00. The MBR contains our first stage boot loader, disk signature, and partition table. The BIOS transfers control to the start of MBR, which then scans for a Volume Boot Record on the specified partition. Keeping it simple, this loads code that loads a second stage boot loader (like NTLDR) which then finally loads the operating system.
To make it simple, BIOS checks for essential hardware, looks for bootable devices, loads a bootstrapper into memory, which calls on a boot loader to start the operating system. What’s the deal with all these steps? Well our BIOS setup lacked the ability to load any more than that first 512 MB block. So we needed this multi-stage process to get things up and running. Kind of a mess right? Well UEFI solved that.
Some of the limitations we faced with BIOS/MBR setups were a maximum of 4 primary partitions, and a 2.2 TB size limit on partitions. Of course we can have plenty of logical partitions if we choose, but remember primary partitions are the only bootable partitions as far as Windows is concerned. Though Linux is perfectly happy booting from one (so long as it’s not a dynamic disk anyways). The partition size limit didn’t matter as much in the past, but now we can pick up a 5 TB Hard Disk Drive for around $130, and that price is going to keep dropping over time.
We know how BIOS works now and see its shortcomings. Now let’s look at UEFI.
UEFI stands for Unified Extensible Firmware Interface, and it is the replacement for BIOS. Along with UEFI comes GPT partitioning to replace MBR setup. Together they added quite a few features, but before we get into that, let’s look at how a computer works with UEFI.
UEFI does not rely on a boot sector like our old friend BIOS. In most cases the old MBR sector does still exist for backwards compatibility. You may hear talk of “disabling UEFI” to use older discs/OS’s – this is incorrect. UEFI is in fact always enabled (as it is your firmware) and all that’s happening is UEFI is supporting a legacy boot method. So, on to the boot process!
When the UEFI computer is turned on, it uses what’s called a boot manager to look at the current boot configuration. In other words, it checks to see which operating system to boot first. It then loads that operating system and executes the necessary code to get it started up. Much simpler. We skip the extra steps of our multi-stage boot loaders and just boot right from the firmware!
There are quite a few advantages to our new UEFI setups, so let’s take a look. MBR type partitioning limits you to 4 primary partitions. GPT can handle a theoretically infinite amount. Though Windows “limits” you to 128. Logical partitions have pretty much secured their place with the dinosaurs. On top of that we can now have much larger partitions. Instead of being limited to 2.2 TB, we can now have up to 9.4 ZB!
With UEFI you also sometimes get a fancy graphical interface for a firmware menu. Gone are the days of the 1990’s looking computer screen (well…in some of them anyways). Now we might be looking at a stylish point and click user interface. This can be good since it makes life easier for the end user. This is bad because it makes changing things you shouldn’t a little easier. End users might be more inclined to explore their systems BIOS (I feel for you, help desk folks).
UEFI presents a simplified boot process that makes for shorter OS load times. With Windows 8+, if you enable fast boot it loads so quickly you can’t get to your firmware configuration screen the traditional way unless you disable fast boot (Shift + restart will take you there if need be though).
UEFI also stores a copy of the partition table in a secondary location. If your partition table becomes corrupted, you aren’t going to flip your desk over and denounce computers. There are a few other advantages like the demise of 16-bit real mode, but that requires diving in deeper than we need.
UEFI made pretty great changes, but it’s not all sunshine andblue skies. We did not address secure boot in the advantages section. This is because I am a Linux nerd. Secure boot stops any operating system from booting that is not signed by a key which is embedded into the UEFI firmware. This can prevent things such as root kits. That’s fantastic. Malicious boot loaders will now have a much much harder time getting onto systems. However, there’s a problem. OEM manufacturers have the possibility of locking customers out of this system and thereby preventing them from installing another operating system.
There seems to be a misconception that Microsoft is going to prevent other operating systems from being loaded onto the computer, but they can’t really do that. Again, this is up to OEM manufacturers. Microsoft can’t mandate anything except what is happening on a Windows Operating System (assuming they didn’t build the hardware – but they are a software company). That doesn’t stop them from paying said OEM’s to exclusively allow Windows OS’s on their hardware though. However, this could create bad blood between MS and institutions that rely on Linux, like Howard County Library.
Secure boot is a fantastic idea and a potential advantage, so long as it is left in the hands of the customer. My laptop dual bootswith Windows 10 (I’m a gamer – my Linux friends, you understand right? Please don’t banish me!) and Kubuntu using secure boot and it works flawlessly. I’ve tested it out, and I can’t boot via anything that I have not given my blessing while secure boot is on. Pretty cool stuff. My only reason for placing secure boot under disadvantages is because of the potential for abuse.
Another downside is UEFI’s use of the FAT32 standard for EFI partitions. This adds a lot of overhead to a system that doesn’t really need it. We’ve got 32 bit pointer-sectors for partitions that only need to load an operating system. That seems a bit excessive to me.
Lastly, UEFI still doesn’t fix one of the problems of our old BIOS/MBR setups. We still have to re-probe for devices once the operating system loads. It would be nice if there was a way to pass that information from the POST onto the Kernel to skip a step and move straight to device initialization.
Conclusions in the UEFI vs Legacy BIOS Boot Debate
UEFI isn’t quite too complicated. It has its ups and downs, but from my perspective it seems like there is more to love than hate. As long as OEMs don’t take away the user’s control over secure boot, I’m perfectly content with this newer system. UEFI seems like it’s here to stay. Love or hate it, but if you’re a computer person, hopefully you understand how it works now.
For more information check out this post on UEFI and Legacy BIOS from our intern program. It gets into the differences in coding for each system, hardware compatibility, and more.