Microsoft to Utilize UEFI to Make Boots Faster with Windows 8

[Tharic-Nar]

With all the hustle surrounding Microsoft's BUILD conference over with, the Windows 8 development team has gotten back to work on its blog, informing us of all that's going to be coming to the company's upcoming OS. In a post made earlier this week, boot times are explored - a topic that both hardware and software vendors love to talk about often.

You can read the rest of our post and discuss here.

 

[marfig]

The problem with the UEFI Secure Boot protocol is the digital certificate from a recognized CA, which frankly cannot work for operating systems the likes of Linux. It's a major "oversight" of this technology and why I don't personally support it.

It's however extremely effective and this I cannot deny. So there's really here a conflict of interests if there ever was one. On one hand proprietary operating systems have all reasons plus one to want to adopt UEFI SB. On the other hand free and open source operating systems don't. A real shame we've got ourselves into this. It feels like going back in time to non compatible hardware between operating systems.

Even with the ability to choose on the UEFI whether to enable or disable Secure Boot, we have essentially to compromise one OS feature in order to install another. I don't see an easy fix for this, although I'm more confident than the Ars editorthat all board bios will include the on/off option.

Meanwhile this will also present a new point of concern for virtualization and its users. Somehow SB has to be made into the virtualization stack. Not doing it presents real security issues to virtualization server/client topologies since they no longer faithfully represent the same secure model of real machines.

We should not discard however the possibility that payed distros will be SB bootable. I don't see why that business model couldn't be implemented with the likes of Red Hat Enterprise Linux, Novel's Enterprise Server and SUSE Linux Enterprise. As noted, the licensing mechanism actually allows for this.

 

[MacMan]

So, what I want to know is: what-in-hell is the difference between EFI and UEFI?

 

[marfig]

EFI was the name of the former specification. It was changed to UEFI (U standing for Unified) when Intel ceased its development of this technology and allowed for a consortium of companies (which it also belongs) to expand on their former work.

This consortium is called Unified EFI Forum. UEFI is the specification coming of this consortium and that succeeded EFI 1.10.

 

[MacMan]

EFI was the name of the former specification. It was changed to UEFI (U standing for Unified) when Intel ceased its development of this technology and allowed for a consortium of companies (which it also belongs) to expand on their former work.

This consortium is called Unified EFI Forum. UEFI is the specification coming of this consortium and that succeeded EFI 1.10.

Thanks!

 

[Kougar]

The problem with the UEFI Secure Boot protocol is the digital certificate from a recognized CA, which frankly cannot work for operating systems the likes of Linux. It's a major "oversight" of this technology and why I don't personally support it.

After reading up on this, I would have to disagree. Most mainboard makers will include the option within UEFI to disable the secure boot option. If someone wants to install Linux then they will know how to do this.

The only real issue is OEM venders... system venders may very well prefer to lock out users from installing their own OS's. Some may include the option to disable secure boot and others may not. Linux users should be able to research which OEMs do and don't before buying prebuit PCs, and while it's not a perfect solution I think the better security is by far worth the tradeoff.

 

[marfig]

Yup, I agree most board vendors will include the on/of option. But that's not what I was trying to address. The issue here is that you'll have to give up on a OS feature in order to install another OS in the machine. Something that we thought we were over with.

If you disable SB because you require to install Linux (it has to be disabled so Linux can be installed), you cannot protect your Windows version with SB, for instance. Thankfully the problem is mitigated somehow because multi-boot has been declining in favor of VM or dedicated machines (computers are so cheap these days, it's not such an issue as it used to be). But the problem is still there that we sort of regressed in terms hardware cross-compatibility.

 

[Kougar]

Windows users could just turn it back on, though. I'll grant it's tedious but unless the user frequently boots back and forth it should be manageable. As I understand it, Secure Booting only needs to be disabled during the Linux install or boot process... it can be turned back on when working with Windows.

I've not heard nor seen of a better design, alas, but the security is badly needed with Windows machines giving the tens of millions of infected botnet PCs, many of which utilize rootkits or boot tinkering. Keys seems to be the only route security seems to be working with, and until a better method is devised issues like this one will continue to crop up every now and then.

 

[marfig]

I've not heard nor seen of a better design, alas, but the security is badly needed with Windows machines giving the tens of millions of infected botnet PCs, many of which utilize rootkits or boot tinkering.

Won't certainly dispute that.

Keys seems to be the only route security seems to be working with, and until a better method is devised issues like this one will continue to crop up every now and then.

ARM uses a chain of trust method based on a public key signature protocol, for which Ellipsys-SB was developed. There's also the AEGIS secure bootstrap process (pdf link), developed at the University of Pennsylvania.

These are two examples, of which I'm unsure of their comparative capabilities to UEFI SB own implementation. There are indeed other methods that can be applied that don't need to rely on a CA and that, by virtue of this, don't segregate operating systems based on their licensing limitations.

InfoWorld published yesterday a summary of an ongoing debate between Red Hat and Microsoft over this very issue. Worth a read. Clicking on the links therein is also a must. Personally I think Red Hat is taking this the wrong way. I don't see this as a Microsoft move to remove competition from the PC platform. Makes very little sense that reasoning to me. It however is true that Microsoft certification program hasn't done anything to force OEMs to add on/off functionality. One would expect this to be a requirement for the Logo Program.