UEFI and bugs
Jan. 23rd, 2012 09:48 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I 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.
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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
driver
Date: 2012-01-23 04:22 pm (UTC)Code size
Date: 2012-01-23 06:36 pm (UTC)Re: Code size
Date: 2012-01-23 07:00 pm (UTC)It's coming
Date: 2012-01-23 06:41 pm (UTC)Why (U)EFI at all?
Date: 2012-01-23 10:17 pm (UTC)Re: Why (U)EFI at all?
Date: 2012-01-24 05:21 am (UTC)no subject
Date: 2012-01-23 10:52 pm (UTC)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)Re: uefi size
Date: 2012-01-24 11:29 am (UTC)That's basically coreboot.
Date: 2012-01-27 02:55 pm (UTC)Slides
Date: 2012-01-23 11:46 pm (UTC)Re: Slides
Date: 2012-01-24 04:40 am (UTC)no subject
Date: 2012-01-25 11:02 am (UTC)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)I see UEFI as another attempt at "de-commoditizing standards", the old Microsoft tactic. It seems to be needlessly complex for its purpose.
Re: What about OpenBIOS?
Date: 2019-04-04 02:18 am (UTC)BIOS emulation
Date: 2012-02-15 02:06 pm (UTC)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:21 pm (UTC)Grub's efiemu is there to emulate enough EFI on a BIOS system to let some EFI-only operating systems boot.
Re: BIOS emulation
Date: 2012-02-15 02:58 pm (UTC)@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)?
Thanks,
//mirabilos
Re: BIOS emulation
Date: 2012-02-15 03:04 pm (UTC)EFI bricking bug
Date: 2012-09-02 07:10 pm (UTC)an EFI bricking on SAMSUNG 530U3C:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
dave@treblig.org
The Brickbug also exists on Windows
Date: 2012-11-22 08:01 pm (UTC)It seems like vital UEFI code can be destroyed by simply booting the "wrong" bootloader, GPT disk, ...