I am completely and utterly baffled by this statement. Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly.

I've dealt with kernel dev for BIOS systems, CSM development for UEFI, etc etc. I'll stick with UEFI, even if it does still have some growing pains.

daeken is absolutely right. BIOS is a fucking nightmare.

Real mode (or the lack of it in Intel VT-x) still wakes me up in a cold sweat at night.

> Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly.

Isn't it the case that once the kernel is fully booted, up and running, it bypasses BIOS entirely and talks directly to the hardware? Have all those bugs you mention been related to the booting process itself (constituting a relatively tiny part of the kernel)?

I do not know to what extent the OS bypasses the BIOS, but it is not completly. If you look in the linux kernel config, you will see an option to control how much RAM is reserved for BIOS. Also, on (many?) Dells, Fn+Shift+15324 followed by Fn+r brings up BIOS thermal controls [1]. I have verified this on an Inspiron 1420, in Windows 7 and Ubuntu 12.10 (kernel 3.5.0-21-generic).

[1]http://ubuntuforums.org/showthread.php?t=1684657

That's because it's a lot harder to fuck up a few kilobytes of assembly than it is to fuck up several MB of bootloaders, device drivers, filesystem drivers, code signature verification, etc, etc, all of which are required for a complete EFI implementation.

What we are seeing here is solid evidence of the fact that software is hard - and a lot of companies just don't have the chops to do a good job. Somehow I doubt the Surface Pro would have bugs anything like this, for example.

I guess Surface Pro will be locked down via Secure Boot and won't ever boot Linux unless jailbroken. Whether that's inherently better is probably another question.

According to Microsoft’s own “Windows Hardware Certification Requirements for Client and Server Systems”,[0] on non-ARM systems it is obligatory to offer the ability to disable Secure Boot:

QUOTATION START

18. Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems.

QUOTATION END

0. http://msdn.microsoft.com/en-US/library/windows/hardware/jj1...

This requirement is only for other vendors to get the certification from Microsoft. Microsoft itself does not need to conform to it, so it is still possible that their products will be locked.

It's sad that everybody wants to lock everything down. It's like no one learned anything from the success of the PC.

The PC was only a success for the market as a whole. The setters of the standards did not profit from it at all and even went (close to) bankruptcy because of it.

Contrast this closed hw architectures like Nintendo and Apple produce. No consumer freedom but incredible profit margins.

Note that modern macs are in fact PC's with just minor modifications so they profit from the PC economies of scale while still locking their customers into their hardware platform.

What if lockdown worked in such a way that you could lock it down to only run your Linux kernels? E.g. load up your own certificate in the TPM and use that for signing when you build.

In that case it would be a security feature -- another line of defense against bootloader malware and/or adversaries in physical possession of your machine.

(I don't know how technically feasible that is; I know Canonical and others are looking at having their own cert so at least their unmodified kernels can run, but I don't know the mechanism for how that interacts with already-released UEFI machines.)

The point is that technologies like this are a double-edged sword, not evil in themselves. A similar argument is made by Linus himself for sticking with GPL v2 instead of moving to GPL v3, which outlaws certain DRM-related uses; he's more interested in providing a functioning mechanism, and leaving the policy-setting to others.

sadly the success of locked down.apple devices stands orthogonal to it.

The PC was a success mostly for Microsoft. With the commoditization of hardware around a single software option, PC makers were squeezed and their margins are exceedingly thin. It's the "thin slice of a larger pie" metaphor. It's just that Microsoft has the whole OS pie, while every hardware maker has a vanishingly thin slice of it.

Quite likely it will be locked down. Even if it's not, however, I don't think Microsoft's EFI implementation will be so crap that drivers can brick the device.

Hmm. Almost right, until they introduced ACPI which in itself is much more of a clusterfuck because most of the vendors actually do it all wrong.

Everyone understood BIOS? Really? I thought one of the issues with BIOS that almost nobody understood how it actually worked any more. Large chunks of it are tens of years old and the people who created them have moved on...