Bottomley: Owning your Windows 8 UEFI Platform [LWN.net]

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 13:41 UTC (Tue) by drag (guest, #31333)
In reply to: Bottomley: Owning your Windows 8 UEFI Platform by hummassa
Parent article: Bottomley: Owning your Windows 8 UEFI Platform

> No EFI is good. It's a better, more configurable, more flexible BIOS.

No EFI is terrible. It's a bigger, more complicated, and more-everything BIOS.

It's BIOS++. It's a massive increase in complexity with no payoff other then having a facier GUI for configuring your boot devices.

The only thing we need or want as Linux users is something in the computer smart enough to initialize the first few K of a select-able boot device to execute the first stage bootloader. Anything more complicated then that is just gives us more potential for headaches and bugs.

Secure boot is the only meaningful enhancement that I am aware of. I am not convinced that it's done well enough to be useful, but if it can be made to be useful then giving the end user the ability to control the keys negates any possible 'vendor lock-in' that we have to worry about.

to post comments

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 17:15 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

> It's BIOS++. It's a massive increase in complexity with no payoff other then having a facier GUI for configuring your boot devices.

I don't know about that, while it's doing the same task of initializing the hardware, it is doing so using much more normal, modern tooling without some of the restrictions of the 1980's BIOS as OS kernel. It's restricted by the task being accomplished and not the impoverished environment.

I would ask BIOS/uEFI, firmware and bootloader developers which environment they prefer as they are the constituents who are most affected by the design.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 17:20 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

It's probably at least partially Stockholm syndrome, but UEFI is (mostly) easier to work with from the bootloader side than BIOS was. The main problem is that we had 30 years of accumulated experience in which bits of BIOS were expected to work and don't have that level of expertise with UEFI yet, and so we trip over rather more bugs or unexpected behaviour.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 20:38 UTC (Tue) by Wol (subscriber, #4433) [Link]

A lot of operating systems completely ignore the bios once they've loaded. That to me, seems a pretty sensible and simple approach. Works fine.

The only thing that UEFI has in its favour is that it does provide protection against root kits - if done properly. Given the mess that is usually done, what's the betting we start getting rot-kits that exploit the UEFI real soon now ...

Cheers,
Wol

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 20, 2013 12:59 UTC (Wed) by nye (guest, #51576) [Link]

>I would ask BIOS/uEFI, firmware and bootloader developers which environment they prefer as they are the constituents who are most affected by the design.

From my selfish end-user perspective, I very much like that with UEFI my boot time is no longer dominated by the time spent before even reaching the boot loader. To be honest, that's the only quality I've ever cared about in a BIOS.

(Of course, there's still room for improvement!)

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 18:43 UTC (Tue) by khim (subscriber, #9252) [Link] (5 responses)

It's a massive increase in complexity with no payoff other then having a facier GUI for configuring your boot devices.

The other payoff is the ability to use latest and greatest Intel's CPUs. You can say a lot of "shoulda coulda woulda" words, but in the end the situation is very simple: if you want to use modern CPU then you need to use multimegabyte binary-only EFI modules provided by Intel. There are no alternative: either you use them or you don't get to play with shiny new CPUs.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 25, 2013 16:50 UTC (Mon) by nix (subscriber, #2304) [Link] (4 responses)

Uh... EFI-supporting BIOSes can also boot in BIOS mode for backward compatibility, and (obviously) still boot the Management Engine long before they make the decision to do that. (My current desktop is booted in just that way, as is the desktop of most Linux users using recent processors, and most existing Windows users on such machines.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 25, 2013 20:33 UTC (Mon) by etienne (guest, #25256) [Link] (1 responses)

Are all EFI PC able to run the EFI stack, init the memory and processor, and reboot to BIOS if they detect the user wants to boot the BIOS way (for instance to run an El-Torito CDROM), or are they loading the EFI stack and try to simulate a real mode BIOS - and then good luck if you try to run memtester which would overwrite the EFI code.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 25, 2013 21:26 UTC (Mon) by khim (subscriber, #9252) [Link]

Are all EFI PC able to run the EFI stack, init the memory and processor, and reboot to BIOS if they detect the user wants to boot the BIOS way (for instance to run an El-Torito CDROM), or are they loading the EFI stack and try to simulate a real mode BIOS

Usually it's a combination: they start as EFI and then at some point switch to old real mode BIOS+SMM code mix.

And then good luck if you try to run memtester which would overwrite the EFI code.

YMMV: some will survive memtester (if they keep the important bits hidden away in SMM), some may crash — especially when USB is involved (the first example Google found).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 25, 2013 20:42 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

EFI-supporting BIOSes can also boot in BIOS mode for backward compatibility

"EFI-supporting BIOS" is an oxymoron. Most such BIOSes are, in fact, thin BIOS emulation shims on top of the real thing: EFI-based firmware.

and (obviously) still boot the Management Engine long before they make the decision to do that

Yup. They start as EFI and then pretend they are BIOS. This combines worst sides of EFI and BIOS approaches but makes older OSes happy if you are lucky. It still means that without EFI your hardware will not boot.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 26, 2013 15:38 UTC (Tue) by nix (subscriber, #2304) [Link]

That entirely depends on what you mean by 'without EFI'. From my POV, in BIOS mode, my motherboard's EFI is just an implementation detail used by very early boot, of no interest once software I can control is running: among other things, I don't need an EFI partition, an EFI bootloader, or any of the other EFI PE stuff. It might as well be an old-style BIOS from my perspective. (The sensors don't work, but that's got nothing to do with EFI and everything to do with a sensor vendor and motherboard vendor who refuse to release any information on the sensor chip: each refers you to the other for info and neither will give you any).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 1:12 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (9 responses)

What about the ability to boot off (and address the partitions) of drives larger than 2TB?

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 19:31 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (8 responses)

I seriously hope you’re not using BIOS calls for that. That’s just… arrgh.

Basically, you put a good enough 32-bit bootloader into front which the 16-bit BIOS can then load. Easy.

(Even so, there *is* LBA48 support in BIOSes new enough. Otherwise, just bang the I/O ports. I think GNU GRUB can probably do that.)

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 20:17 UTC (Thu) by raven667 (subscriber, #5198) [Link] (7 responses)

GRUB isn't the BIOS/firmware, its a bootloader. If you made GRUB part of the BIOS/firmware and add the requirements for initializing the hardware then what you would get would look like EFI. Your suggestion is an argument against the BIOS not in favor of it, since it clearly doesn't have the features you want since your first inclination is to load something else. There is no architectural benefit to building your full featured environment on top of the BIOS rather than just replacing it and providing a BIOS compatibility layer, which is what EFI does.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 20:30 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (6 responses)

No because GNU GRUB is just *one* implementation, and I have my own – BSD boot(8/i386) if you care.

And all implementations have a not too small, not too big set of things to work with and full machine control, unlike with EFI (one early but big #FAIL of it being that Apple machines run a 32-bit EFI which then can only boot a 32-bit kernel, not a 64-bit anything; couldn’t happen with BIOS things, as long as the machine is amd64 capable; this led to Apple supporting running 64-bit userspace with a 32-bit kernel, now isn’t *that* schizo?) which offers so many services that you can, but also *have* to use, and disables or actively breaks direct hardware access and other, older methods of doing things (BIOS is compatible down to 1981 – assuming you’ve got a 5¼" floppy somewhere, I do).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 21:52 UTC (Thu) by raven667 (subscriber, #5198) [Link] (5 responses)

Does a modern chipset even have the appropriate interface for plugging in a 5¼ floppy? Is that anything other than dead code? I actually have used a 5¼ floppy drive in the last year, with a USB interface, not direct connected to the motherboard.

If you had to design the firmware for a modern machine would it look anything like the BIOS? Or would it look more like EFI or GRUB with a command interface and a standard way of driving graphics, input, disk and network devies in a modular way.

Why does a high-capability bootloader even need to exist, shouldn't the machine just be able to load your OS kernel directly?

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 22:14 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (1 responses)

I’d probably design something a bit more featured than a BIOS, but definitely not as much as EFI. No command shell either, but definitely something that supports a serial console as first tier input/output like Sun OpenBOOT does.

Or I’d just use OpenBOOT. I mean, OpenFirmware existed, and was used left and right in the industry, before EFI came to be. It’s not without its own problems (such as, initialising only the first four megs of RAM on my SPARCstation) but not as crazily huge either.

Bootloaders are extensible. New filesystems. Network boot, even http. iSCSI. AOE. nbd. New operating systems. Co-processors that turn a computer of one architecture, say an m68k Amiga, into something entirely different, such as a PowerPC machine (those cards do exist and are supported by Linux, so this is not just speculation, although I’ve not seen something similar for PCs in the last decade; I don’t limit my horizon to PCs though).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 23:34 UTC (Thu) by raven667 (subscriber, #5198) [Link]

So its definitely not the functionality of EFI that you are objecting to, since OpenBoot has much the same functionality, a CLI, etc. it's the specification or the implementation of EFI that you object to?

I don't know much about it but I can guess at the reasons why Intel decided to create EFI rather than extend OpenBoot, it may not have been available at the time or the firmware developers may not have wanted to work with Forth. There are probably other, technical, reasons why Apple didn't port it to x86 and ported EFI, which had been Itanium only, instead.

I don't have a strong opinion on the EFI implementation but I think we both agree that it has the infrastructure to solve the problem in a better way than the BIOS. Or maybe we disagree what the problem space is?

shouldn't the machine just be able to load your OS kernel directly?

Posted Mar 1, 2013 1:00 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

How will it know where to find the kernel?

More to the point, how will the bios be able to tell the kernel all the important options it needs to know?

Your bios will be like LILO (which had to be re-installed every time you made a change to the kernel). Or like CP/M (which had to do a "sysregen" every time the hardware changed).

Cheers,
Wol

shouldn't the machine just be able to load your OS kernel directly?

Posted Mar 1, 2013 1:15 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Well this horse might already be out of the stable with UEFI but creating a way to make variables available to the kernel image doesn't seem impossible, maybe stored as EFI variables in a standard way, or as files on the boot filesystem. How did HPUX boot? That's what EFI was designed for. Maybe the tools aren't there now because there wasn't enough participation by Linux vendors or the Linux Foundation when these issues were decided, no one is going to hand you a seat at the table for these kinds of things, you have to insert yourself worth force if you don't want to be run over.

shouldn't the machine just be able to load your OS kernel directly?

Posted Mar 1, 2013 1:35 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

EFI has that information stored in the nvram boot variables.