One reason I still prefer BIOS MBR booting over UEFI

January 30, 2023

Over on the Fediverse I said something I want to elaborate on:

One of the reasons I still prefer BIOS MBR booting over UEFI is that UEFI firmware is almost always clever and the failure mode of clever is 💥. I dislike surprises and explosions in my boot process.

Old fashioned BIOS MBR booting is very simplistic but it's also very predictable; pretty much the only variable in the process is which disk the BIOS will pick as your boot drive. Once that drive is chosen, you'll know exactly what will get booted and how. The MBR boot block will load the rest of your bootloader (possibly in a multi-step process) and then your bootloader will load and boot your Unix. If you have your bootloader completely installed and configured, this process is extremely reliable.

(Loading and booting your Unix is possibly less so, but that's more amenable to tweaking and also understandable in its own way.)

In theory UEFI firmware is supposed to be predictable too. But even in theory it has more moving parts, with various firmware variables that control and thus change the process (see efibootmgr and UEFI boot entries). If something changes these variables in a way you don't expect, you're getting a surprise, and as a corollary you need to inspect the state of these variables (and find what they refer to) in order to understand what your system will do. In practice, UEFI firmware in the field at least used to do weird and unpredictable things, such as search around on plausible EFI System Partitions, find anything that looked bootable, 'helpfully' set up UEFI boot entries for them, and then boot one of them. This is quite creative and also quite unpredictable. What will this sort of UEFI firmware do if part of the EFI System Partition gets corrupted? Your guess is as good as mine, and I don't like guessing about the boot process.

(There's a wide variety of corruptions and surprises you can have with UEFI. For example, are you sure which disk your UEFI firmware is loading your bootloader from, if you have more than one?)

In theory UEFI could simplify your life by letting you directly boot Unix kernels. In practice you want a bootloader even on UEFI, or at least historically you did and I doubt that the core issues have changed recently since Windows also uses a bootloader (which means that there's no pressure on UEFI firmware vendors to make things like frequent updates to EFI variables work).

It's possible that UEFI firmware and the tools to interact with it will evolve to the point where it's solid, reliable, predictable, and easy to deal with. But I don't think we're there yet, not even on servers. And it's hard to see how UEFI can ever get as straightforward as BIOS MBR booting, because some of the complexity is baked into the design of UEFI (such as UEFI boot entries and using an EFI System Partition with a real filesystem that can get corrupted).

Comments on this page:

I do the same, I always configure firmwares to be BIOSs/legacy style boot unless I'm forced to do otherwise.

I've only had minor issues with UEFI (failed poweroff kernel-UEFI signalling) compared to what I have read with other people.

BIOSs have bugs, UEFI contains a BIOS implementation plus a lot more and therefore must be even more bugs.

A big and important question is "what were the motivations of UEFI?". In my head:

  1. A standardised way of getting more features
  2. Windows demands (including bitlocker)
  3. Support to boot from bigger disks

Standardised: it provides standardised APIs, but very importantly the firmwares are themselves NOT standardised. A user cannot replace them with an alternative, unlike operating systems, bootloaders and other OS-like payloads (PXEs, etc).

More features: I'm yet to see a single feature that wouldn't be better to do in or after the bootloader. Yes it's convenient to have some stuff pre-installed rather than having to (alternative universe imagination time) have a USB stick installed inside the chassis permanently, but the variations between vendors and bugs are so annoying that often people provide their own post-bootloader or in-bootloader alternatives anyway. OR they try to rollout a fleet of computers of all the exact same vendor and model.

Exception being to stuff like bitlocker-UEFI interactions such as detecting settings changes and prompting for a decryption key. I'll argue that it's security by obscurity, but it does actually work (at least against common theft). There will always be an unencrypted start point of a chain of trust, even if just transistors, but making it obscure and difficult to get at makes it harder to.

Support for bigger disks: that could have been added to BIOS standards.

From my little perspective: UEFI shifted power around. Hardware vendors may have benefited (or at least assumed they would because more features = more power), Microsoft would have benefited (they get features they want), end users and sysadmin desires didn't factor into this at all.

Written on 30 January 2023.
« The CPU architectural question of what is a (reserved) NOP
I've had bad luck with transparent hugepages on my Linux machines »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jan 30 22:40:48 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.