Don't ship 32-bit UEFI firmware on x86

[mjg59]

Shipping a UEFI-bootable Linux distribution is a touch awkward[1], with the main sticking point being the necessity to produce boot media with multiple El-Torito images. An El-Torito image is either an image of a floppy disk or a small hard drive, embedded into the ISO. This allows BIOS systems to look for an El Torito image, hook some interrupts and then boot without the BIOS having to care about the fact that the image is embedded in an ISO-9660 filesystem. UEFI systems will look for an El-Torito image with a special tag - if they find it they'll mount it as a FAT filesystem and look for a bootloader, and if not they'll fall back to BIOS compatibility.

So, if you want a CD that'll boot on both BIOS and UEFI systems, you need two El-Torito images - one for BIOS, one for UEFI. Unfortunately, various BIOSes deal exceptionally badly with CD images that contain more than one El-Torito image. The most common failure case is to print a menu asking you to choose an option without labelling the options, but some will just fail outright. Thankfully, this is pretty much exclusively limited to 32-bit systems.

Things get irritatingly more complicated due to a quirk of UEFI. UEFI is based on executing code in native mode. That means that 32-bit UEFI systems can't execute 64-bit code in firmware, even if the CPU is capable of it. A 64-bit OS can only boot on 32-bit UEFI if it has very ugly compatibility hacks, including having to rewrite structures and register state every time it makes a UEFI call. The only OS I'm aware of that implements this is MacOS X. Having looked into what it'd take to implement it in Linux, I decided that hammering rusty nails through my feet would be a preferable use of time. Thankfully, I went drinking instead.

So distributions have a choice. They can either produce UEFI-bootable CD images for 32-bit x86 and risk failures on actual 32-bit systems, or they can ignore UEFI entirely on 32-bit and succeed in booting on all the hardware that people actually own[2]. Unsurprisingly, they tend to choose the second option.

So, if you're building an x86 hardware platform, don't ship with 32-bit UEFI. If you're stuck with a 32-bit CPU then just ship BIOS. If you have a 64-bit CPU then ship a 64-bit UEFI. If you ship with 32-bit UEFI, no significant existing Linux distribution will support you, and you'll face an uphill battle to convince them to do so.

32-bit UEFI. Just say what on earth were you thinking, please, no, can't you find a solution that doesn't involve me getting tetanus jabs.

(If you're worried about the extra memory consumption of 64-bit OSes, just encourage 32-bit userspace on a 64-bit kernel. Or just boot via BIOS)

[1] See the number that still don't manage it despite having had several years to adapt
[2] Until recently, the only vendor to ship 32-bit UEFI firmware on volume hardware was Apple. This was fine on their 32-bit systems, but on their 64-bit systems with 32-bit UEFI booting a 64-bit version of Windows would result in boot failure. Apple rectified this by stating that 64-bit Windows wasn't supported on platforms with 32-bit UEFI, which is a neat trick if you can manage it. 32-bit Windows (and Linux) was fine because it didn't include a UEFI boot image and so didn't trigger the bug.

Comments

So what's the problem?

[(Anonymous)]

I don't see the problem, IF you're willing to limit yourself to supporting the EFI's bit depth. Just ship 32-bit versions of Linux with a 32-bit EFI boot loader and 64-bit versions with a 64-bit EFI boot loader. Clearly specify that on EFI systems, they're intended for EFIs with the specified bit depth. I've hacked together installers that work fine on my 32-bit Mac Mini, just by adding a suitable EFI boot loader to the installer. Granted, things get uglier if you wanted to support systems with 64-bit CPUs and 32-bit EFIs, but to the best of my knowledge, only a few Apple models ship with such a weird setup. Adding 32-bit EFI support to 32-bit versions of distributions doesn't seem like a big deal to me, although I admit that the number of users who need such a thing is rather small.

Re: So what's the problem?

[mjg59]

Because then your 32-bit versions stop working on a bunch of existing 32-bit systems, so you have to ship yet another install image and really just don't do that.

Re: So what's the problem?

[(Anonymous)]

I think I get it now: A 32-bit CD-R image with EFI support risks failure on buggy BIOSes. So what? Create two Linux distribution CDs, one clearly labelled "EFI" and the other clearly labelled "BIOS." Demanding that hardware vendors not produce EFI-based 32-bit computers because of bugs in some BIOSes is putting the cart before the horse.

Re: So what's the problem?

[mjg59]

Mainstream Linux distributions are incredibly unlikely to go to the trouble of QAing an entire additional install image just to support 32-bit UEFI systems, and right now they're also unlikely to remove support for older systems, so by choosing to ship 32-bit UEFI you're reducing the number of OSes that your platform will run.

Re: So what's the problem?

[(Anonymous)]

If the mainstream vendors won't do it, somebody else will. It's not hard to modify an installation image, or even supplement it with a customized boot manager/loader located elsewhere, to get a 32-bit x86 distribution to install in EFI mode. Thus, if there's any demand at all, there WILL be Fedora, Debian, OpenSUSE, Ubuntu, etc. images for 32-bit EFI platforms, or tools to create them automatically, or boot images that contain EFI boot managers that load the kernel from the standard media. If a vendor is concerned about reducing the OSes that will run on a 32-bit EFI computer, that vendor could provide such tools itself.