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

Tetanus

[(Anonymous)]

You don't have to worry about tetanus as long as your rusty nails haven't been soiled, really. Pure rust doesn't contain tetanus bacteria.

[(Anonymous)]

I don't understand why the Linux community bends over backwards to accommodate Apple hardware. It's never compliant with anything and they are generally hostile anything not Apple.

[(Anonymous)]

The linux community is composed primarily of people. Some of those people like the Apple design language (particularly the sculpted edges on their laptops, which create a clever illusion of airy thinness) and those people want to run the hardware they happen to like. It's not really mysterious.

Can't agree with you on this one

[(Anonymous)]

UEFI on IA32 isn't going away. It will show up on more embedded systems as time goes on. There is now the Intel MinnowBoard as a non-Apple reference for IA32 UEFI (no CSM for legacy BIOS), so work can be done to close this gap.

Re: Can't agree with you on this one

[pjones.id.fedoraproject.org]

Yeah — but if we're talking about embedded systems, most Linux distributions will never target them. More to the point, Linux distributions which do target embedded systems will likely have custom installation media for them. So there's little need for an OS that is targeting those systems to e.g. also support 32-bit BIOS machines with the same installation media.

Re: Can't agree with you on this one

[yuhongbao.blogspot.com]

Not to mention I doubt most of the embedded systems even have optical drives at all.

Clover Trail uses 32-bit UEFI

[yuhongbao.blogspot.com]

I think Clover Trail also uses 32-bit UEFI with no CSM in order to boot Win8.

Re: Clover Trail uses 32-bit UEFI

[yuhongbao.blogspot.com]

But of course most of these systems don't ship with optical drives, so...

Re: Clover Trail uses 32-bit UEFI

[(Anonymous)]

But most of them have USB ports, right?

Presumably none of this El Torito / ISO9660 stuff applies to thumb-drives and SD cards (when those are bootable), correct?

But don't you have the same problems with the BIOS sometimes not being willing to boot from a usb key that has been formatted with multiple partitions? Most usbkeys are 'supposed' to be formatted like floppies, with no partition table. Some multiboot tools format them like ZIP drives, with a partition table that is mostly empty. Other multiboot utils let you format your usbkey with HDD-style (non-GPT) partitions, so e.g. parttn#1 can be a 2gb fat32, and parttn#2 can be 6gb ext4 with a bootable 64bit Linux distro. Some BIOSes will "just work" with that config, and at least some distros will see both partitions on the usbkey, but when you put the same usbkey into winXP you only see the first fat32 partition (since XP doesn't grok ext4 by default).

I've heard that multi-partition usbkeys can conflict with some older BIOSes. If I want to build a multiboot portable usbkey-based image for a distro, which gives me the option of sticking the usbkey into these four types of machines:

1. 32-bit i686 cpu with legacy BIOS
2. 32-bit i686 cpu with UEFI BIOS
3. 64-bit x86_64 cpu with legacy BIOS
4. 64-bit x86_64 cpu with UEFI BIOS

Can it be done? Or do you run into similar problems as when you try to boot from CD in machines of type#2 in the list?

For extra credit, what if my distro also supports ARM, and I want to have a multiboot usbkey which also supports these:

5. 32-bit ARM cpu with whatever BIOS
6. 64-bit ARM cpu with whatever BIOS

I could go on, talking about booting different versions or spins of the distro, or other distros, and so on, but you get the point.

On a related note...

[yuhongbao.blogspot.com]

Personally, I think AMD should have considered EFI when developing x86-64.

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.

whose code in in this uefi?

[(Anonymous)]

I'm looking to buy a new laptop for school. I need some version of windows to test my code on, but I don't trust a computer with win8 preinstalled. I don't like the idea of a piece of windows software standing between my os and firmware. BIOS always came from the manufacturer, I think. Who writes the UEFI for these systems, and how can I tell where it came from?

Thanks,

James

Re: whose code in in this uefi?

[(Anonymous)]

I hope this was an appropriate place to post this question.

James.

Re: whose code in in this uefi?

[mjg59]

Your BIOS was typically chipset vendor reference code (so either Intel or AMD), BIOS vendor code (AMI, Phoenix, Insyde, HP and sometimes Toshiba) plus board vendor code. UEFI is the same, except the BIOS vendor code is all based on the Intel reference UEFI implementation.

Re: whose code in in this uefi?

[(Anonymous)]

So, no Microsoft code? That makes me feel a little better. Thank you.

Re: whose code in in this uefi?

[mjg59]

Yeah, I don't know of any Microsoft code in any UEFI implementations. The ACPI tables will typically be built with the Microsoft compiler, but that's true on BIOS as well.

[(Anonymous)]

Really it is technically confused. Many computer user don't know details about it. this is the basic knowledge. I am really grateful to you to give these information. Thanx Dear.Information Technology (http://www.digitallyurs.com/)

[(Anonymous)]

Two words: Bay Trail.

I share your pain. Writing a UEFI32 bootloader to try and fire up a 64-bit Linux kernel right now.

[mjg59]

As of 3.14, grub with the UEFI boot protocol patches should be able to launch a 64-bit kernel on a 32-bit UEFI

[(Anonymous)]

True, but I'm using Gummiboot. Still haven't figured it out, but getting there. Got 32-bit/UEFI32 running in the mean time.

[mjg59]

That's not going to work. There's no way to build a 32-bit UEFI stub on the front of a 64-bit kernel, and gummiboot doesn't know how to use the UEFI entry points. Use grub.

[(Anonymous)]

Confirmed that this works for Debian Jessie (at the time of writing Fedora doesn't compile the kernel with the 64/32 EFI thunk).

However what doesn't work is any driver which requires access the device's ROM, such as the AMD Radeon graphics. The access to that ends when the boot loader ends the EFI boot services stage. By then either the bootloader (or the kernel started in EFI stub mode) needs to have copied out the ROM into RAM.

At the time of writing it's simply impossible to get to that point. Grub's linuxefi command conflates secure boot and a EFI stub boot, so if you are booting on a EFI with no support for secure boot it fails with a checksum error. Both Refind and Gummiboot currently have issues booting Linux in EFI stub mode. The radeon driver people NAKed a patch to take the ROM in a file, which would have at least been a work-around.

The result is no way to run Linux from EFI beyond text mode on 2006-era MacBooks. Note that you may not be able to easily run Linux from BIOS emulation mode either: only Bootcamp v4 lets you install non-Windows BIOS-using operating systems, so if you upgraded MacOS beyond that you'll need to reinstall MacOS.

All in all trying to get Linux working as an alternative to an out-of-support MacOS has been two months of continuing disappointment.

yeah umm

[(Anonymous)]

sparky Linux does