More in the series of bizarre UEFI bugs

[1] http://arstechnica.com/gadgets/2008/07/atom-nano-review/6/. Scroll down to the third graph, if you want the tl;dr.

[2] http://code.google.com/p/nativeclient/issues/detail?id=2508. I don't post that because it's a particularly egregious example. Even though I don't think the reply makes sense, it's actually more reasonable than most responses. It just happens to be public, because the exchange happened on a public bug tracker.

It's fairly easy to fix this sort of thing with a patch, à la Raymond Chen [3], but, for legal reasons, we can't just hand out patches to every program that incorrectly determines features from the vendor string. It often takes over a year to convince a vendor to issue a patch for its driver or OS, even when we have a benign patch we're using in lab to work around the issue, so we can do compatibility testing (we test pretty much everything) [4]. That's if we're lucky enough to get a vendor that wants to fix it; we often just get the runaround indefinitely. I can recall one case when no printer driver from a certain manufacturer would install on a machine with one of our CPUs, even though that same vendor was selling multiple models that used our CPU.

[3] http://blogs.msdn.com/b/oldnewthing/archive/2012/11/13/10367...

[4] I haven't done lab debug for a while, but the last bug I can recall hearing about was a case where, if you had two webcams recording and playing back to the screen while watching a Blu-ray DVD and running an obscure benchmark from the 90s that wasn't even used in the 90s, the machine would hang approximately once every three days. I don't know where we find the mandmen who come up with these tests.

The funny thing is, we had a feature in our part that we suspected was buggy, and disabling that feature caused the fail to go away (or at least occur incredibly infrequently), but you can't ship a part unless you're really absolutely sure it's not going to hang on real customers, so someone had to track down to the root cause and capture it simulation. Just because disabling that feature meant the bug didn't show up didn't mean that feature was the cause. It could have been that disabling the feature just changed the conditions so that bug became less likely, and only popped up once a year, or maybe needed five webcams to expose, or who knows what? IIRC, it took someone two months to find the exact issue.

See more evidence of this: http://askubuntu.com/questions/141879/error-1962-no-opertati...

http://askubuntu.com/questions/91484/how-to-boot-ubuntu-from...

I think the new Chromebooks use it. This is how they achieved their “instant-on” feature. I can't wait for others to follow suit.

[1] http://www.coreboot.org/

If you want to detect malware, I dont think looking up the boot entry description will do it. Malware do not say "I am a malware, press me to be infected!". It is however a excellent way to prevent competition between operative systems.

My favourite quote from the talk was:

"Files contain code, [and] code, as we all know, contains bugs. Always. So from this we can conclude that UEFI contains bugs. This shouldn’t surprise anyone, other than the Linux kernel which obviously contains no bugs at all ever." [1].

[0] - www.youtube.com/watch?v=V2aq5M3Q76U (Keep in mind this was in January, when there was still a lot of uncertainty about the UEFI Secure Boot/Linux situation).

[1] - http://www.techrepublic.com/blog/australia/untested-buggy-ue...