LWN: Comments on "The bootstrap process on EFI systems"

The bootstrap process on EFI systems

etienne — Tue, 24 Feb 2015 11:35:59 +0000

> most EFI implementation are for computers that will delivered with MS Windows pre-installed

I can give you an example of a pre-installed Windows 7 on a branded portable PC which is not working(1) when waking from hibernation.
No update for the BIOS are present after 2 years.

(1) not working: In the Unix/Linux sense, meaning it sometimes fails.
Windows users would call it "working" because on a good day, you can try to close the lid for few seconds so the screen re-enter power saving mode - then re-open the lid - and you may get back your screen.
Windows user have learned to carry lucky things and put them on the top left side of the screen when using their computers. Me, I am not superstitious, that brings bad luck...

The bootstrap process on EFI systems

poruid — Mon, 23 Feb 2015 21:11:08 +0000

It's simpler than that: many if not most EFI implementation are for computers that will delivered with MS Windows pre-installed. For that reason the developers will find their implementation working once it boots the targeted MS Windows versions.

A nasty consequence of this circumstance can be that errors in the MS Window boot code, may cause those EFI developers to adjust their code in order to have MS Windows boot properly.

The bootstrap process on EFI systems

etienne — Wed, 18 Feb 2015 11:16:20 +0000

> ... x86 EFI implementations ...
> How many of these bugs affect Windows, requiring Microsoft to have similar workarounds in place?

Maybe Windows has same problems (for instance waking up from power saving modes on some hardware), but Windows users have a different definition of "working" - they expect to pay to have a fix - so they do not complain too much.

The bootstrap process on EFI systems

mjg59 — Wed, 18 Feb 2015 07:14:16 +0000

Yeah, nothing we've hit has been a strong security issue - there's been a couple of denial of service cases, but nothing that allowed arbitrary code. There *have* been issues in some firmware implementations that permitted arbitrary code to be executed, and some of those could be used to circumvent Secure Boot on some platforms. Software is hard.

The bootstrap process on EFI systems

marcH — Wed, 18 Feb 2015 06:33:22 +0000

> and so poked different functions in different ways and exercised different bugs.

I guess none of these bugs ever had any security impact *cough* since it would invalidate Secure Boot *cough*.

The bootstrap process on EFI systems

mjg59 — Wed, 18 Feb 2015 06:29:09 +0000

We try. There were many operating systems booting on BIOS before Linux came along, and so many of the quirks were already known. That wasn't the case with UEFI. The issues we keep hitting are cases where we implemented functionality without knowing what Windows did, and so poked different functions in different ways and exercised different bugs. The last four years have been an exercise in identifying areas where we still have disparities and dealing with them.

The bootstrap process on EFI systems

marcH — Wed, 18 Feb 2015 05:10:43 +0000

> So there's an immense swamp of intellectual output to navigate and unless you happen to step precisely in the footprints of the other guy, you are practically certain to step into a lot of shit they didn't step into...

Isn't Linux trying to step precisely in the footprints of the other guy to avoid finding new issues? I thought this was the long and firmly established tradition with BIOS.

The bootstrap process on EFI systems

viro — Wed, 18 Feb 2015 04:38:08 +0000

Sigh... Bugs that happened to visible break the setup they had been testing got more or less papered over by vendor duhvelopers; those had been a minuscule subset of bogosity spewed forth by said duhvelopers and the rest remains uncaught. Testing another setup has uncovered (again, minuscule) subset of remaining bogosity, some of those not affecting the original setup at all, some breaking it, but doing so in a subtler way. Without a doubt a metric arseload of bugs remain undiscovered; never underestimate the amount of garbage lusers can excrete, given an editor, keyboard and supply of oxygen...

Neither kernel attempts to maximize the amount of turds to step into; there is a major difference between writing a testsuite trying to visibly trigger as many bugs as possible and writing something that tries hard _not_ to. There is a _lot_ of ways to fuck up an implementation of a standard; for something only nominally sentient (albeit human from the legal point of view, more's the pity) lusers do imitate creativity surprisingly well in that area, Murphy Law being what it is. So there's an immense swamp of intellectual output to navigate and unless you happen to step precisely in the footprints of the other guy, you are practically certain to step into a lot of shit they didn't step into...

The bootstrap process on EFI systems

marcH — Wed, 18 Feb 2015 03:35:42 +0000

> With the influx of x86 EFI implementations into the market in 2012, there was a wide variability in their quality, which meant there were a lot of bugs.

How many of these bugs affect Windows, requiring Microsoft to have similar workarounds in place?

If not many, how come it takes Linux to trigger all the other EFI bugs? Surely, Linux is not the most demanding EFI user out there, pushing EFI limits!?

If many affect Windows as well, how come so many EFI bugs get released at all since booting Windows must certainly be the EFI bar to pass?

Wild guesses and other speculations welcome :-) Like for instance this one: Microsoft initially implemented a long but finite list of EFI workarounds, which all BIOS implementers get "for free" without even noticing while Linux is rediscovering them one by one.

The bootstrap process on EFI systems

smitty_one_each — Sat, 14 Feb 2015 20:38:10 +0000

For the acronym deficient:
http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_...