UEFI and bugs

[mjg59]

I gave a presentation on UEFI at LCA 2012 - you can watch it here, with the bonus repeat (and different jokes) here. It's a gentle introduction to UEFI, followed by some discussion of the problems we've faced in dealing with implementation bugs.

The fundamental problem is that UEFI is a lot of code. And I really do mean a lot of code. Ignoring drivers, the x86 Linux kernel is around 30MB of code. A comparable subset of the UEFI tree is around 35MB. UEFI is of a comparable degree of complexity to the Linux kernel. There's no reason to assume that the people who've actually written this code are significantly more or less competent than an average Linux developer, so all else being equal we'd probably expect somewhere around the same number of bugs per line. Of course, not all else is equal.

Even today, basically all hardware is shipping with BIOS by default. The only people to enable UEFI are enthusiasts. Various machines will pop up all kinds of dire warnings if you try to turn it on. UEFI has had very little real world testing. And it really does show. In the few months I've been working on UEFI I've discovered machines where SetVirtualAddressMap() calls code that has already been (per spec) discarded. I've seen cases where it was possible to create variables, but not to delete them. I've seen a machine that would irreparably corrupt its firmware when you tried to set a variable. I've tripped over code that fails to parse invalid boot variables, bricking the hardware. Many vendors independently fail to report the correct framebuffer stride. And those are just the ones that have ended up on hardware which crosses my desk, which means I haven't even tested the majority of consumer-grade hardware with UEFI.

The problems with UEFI have very little to do with its design or the ability of the people implementing it. After a few years of iterative improvements it stands a good chance of being more reliable and useful than BIOS. Increased commonality of code between vendors is a blessing and a curse - in the long term it means that these bugs can be shaken out, but in the short term it means that at least one hardware-destroying bug has ended up carried by multiple vendors. Right now we're still in the short term and it's likely that we'll find yet more UEFI bugs that cause all sorts of problems. The next few years will probably be a bumpy ride.

Comments

[gerald_duck]

I guess I'm asking the same question as everyone else: is there any good reason for UEFI to be bigger than Linux, and is it possible to explain that reason succinctly?

Of course, supplementary questions abound, like: if UEFI is less mature and more cumbersome than Linux, why not just use Linux as a boot loader?

uefi size

[(Anonymous)]

One of the reason is that you're pretty much dealing with the issues as linux except for a scheduler. The code contains and inordinate amount of duplication. If you just watch the drivers code. It's a development toolkit and code readability is more important than performance/size. So think of an os with huge amount of code duplication.

Re: uefi size

[pjc50.livejournal.com]

So in practice we'd be better off with devices that booted straight into ROM Linux and then chainloaded their OS off the disk?

That's basically coreboot.

[benanov.livejournal.com]

Coreboot used to pretty much be that, and I believe a Linux kernel is still one of the payloads.