[personal profile] 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.


Date: 2012-01-23 04:22 pm (UTC)
From: (Anonymous)
As an open source uefi driver developer I just wanted to +1 your "utterly infuriating" remark.

Code size

Date: 2012-01-23 06:36 pm (UTC)
From: [identity profile] kaizer.se
How did they manage to spend that many lines of code? That sounds crazy. Also, why are we talking about UEFI as a specific implementation, not a specification?

Re: Code size

Date: 2012-01-23 07:00 pm (UTC)
From: (Anonymous)
Because most implementations rely on the tianocore/edk code

It's coming

Date: 2012-01-23 06:41 pm (UTC)
From: [identity profile] adamwill.id.fedoraproject.org
For the first time, at FUDCon, I came across a consumer machine that defaults to UEFI - it was a Lenovo laptop, I forget the precise model (not a Thinkpad), but just sticking a Fedora DVD in the drive and booting the system gives you an EFI boot of the installer. Never seen that before.

Why (U)EFI at all?

Date: 2012-01-23 10:17 pm (UTC)
From: (Anonymous)
Is there a good introduction as to why UEFI is necessary? Much as I loathe the BIOS, the concept ("load the first sector and jump to it") is surely all you need, isn't it, and that's not 30MB of code.

Re: Why (U)EFI at all?

Date: 2012-01-24 05:21 am (UTC)
From: (Anonymous)
Might want to look over the uefi specification. There's also a book called "beyond bios developing with the UEFI" which goes on and on and on about modularity, how vendors can distribute just drivers that can be put together and interpreted, and all will work well if they follow the protocols. There's also a case study where you can easily have fast booting systems by not loading drivers that are not necessary

Date: 2012-01-23 10:52 pm (UTC)
gerald_duck: (Default)
From: [personal profile] 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

Date: 2012-01-24 05:17 am (UTC)
From: (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

Date: 2012-01-24 11:29 am (UTC)
From: [identity profile] 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.

Date: 2012-01-27 02:55 pm (UTC)
From: [identity profile] benanov.livejournal.com
Coreboot used to pretty much be that, and I believe a Linux kernel is still one of the payloads.


Date: 2012-01-23 11:46 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawl-kZzjKXx-ozohSivtqmU_B9oyXtNYLpU
I can't really watch video at the moment, could you make the slides available? Thanks!

Date: 2012-01-25 11:02 am (UTC)
tcpip: (Default)
From: [personal profile] tcpip
I do admit some pride in having the opportunity to introduce your presentation to LCA.

Your work has been absolutely first class, inspiring many to educate themselves on this important subject.

Thank you.

What about OpenBIOS?

Date: 2012-02-10 08:18 pm (UTC)
From: (Anonymous)
I wonder if OpenBIOS, a much simpler but still quite flexible system, could have replaced the PC BIOS.
I see UEFI as another attempt at "de-commoditizing standards", the old Microsoft tactic. It seems to be needlessly complex for its purpose.

BIOS emulation

Date: 2012-02-15 02:06 pm (UTC)
From: (Anonymous)

I’ve read your LCA paper, which convinced me to stick to my No to EFI. So I’ve got a question.

Is there a BIOS emulation which I could just run on EFI/UEFI? Something like User Mode SeaBIOS (thinking of UML)? In the Secure Boot case, of course, assuming it were signed, but nevertheless. Something to run Linux 2.0 on, or Minix 3, Haiku, classic BSD, etc… (yes, I use them occasionally) or even MS-DOS/DR DOS?

Also, out of curiosity, what’s the efiemu{32,64}.o in GNU GRUB 2 for?

//mirabilos, who’d log on, but either Launchpad OpenID Provider or this blog are b0rken

Re: BIOS emulation

Date: 2012-02-15 02:58 pm (UTC)
From: (Anonymous)
Hrm, but most isn’t all… think Apple… might be worthwhile to put a flea into the ear of the SeaBIOS people next time I see them at some event.

@efiemu: ah, interesting; do you have a reference? Didn’t even know there were EFI-only OSes other than OSX86 and soon maybe Win8…

By the way, do you know where to get slides for other LCA talks (there are more interesting ones; I’ve seen slides for some but not all of them)?


EFI bricking bug

Date: 2012-09-02 07:10 pm (UTC)
From: (Anonymous)
It looks like some people have been unfortunate enough to hit
an EFI bricking on SAMSUNG 530U3C:



The Brickbug also exists on Windows

Date: 2012-11-22 08:01 pm (UTC)
From: (Anonymous)
This Bug also affects users of Samsung Series 5 Notebooks, which perform a so-called "in-place upgrade", for example from win8 to win8pro. There is a chance for a brick after the successful upgrade and following restart. This is not a "Linux-only" problem.
It seems like vital UEFI code can be destroyed by simply booting the "wrong" bootloader, GPT disk, ...


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags