Microsoft Corp.'s (MSFT) UEFI Secure Boot technology -- the long-awaited BIOS replacement -- has some people concerned due to its digital rights management features, which can be used by OEMs to prevent dual-booting to other operating systems like Linux.

There have been some comments about how Microsoft implemented secure boot and unfortunately these seemed to synthesize scenarios that are not the case so we are going to use this post as a chance to further describe how UEFI enables secure boot and the options available to PC manufacturers. The most important thing to understand is that we are introducing capabilities that provide a no-compromise approach to security to customers that seek this out while at the same time full and complete control over the PC continues to be available. Tony Mangefeste on our Ecosystem team authored this post. --Steven

Quick summary

UEFI allows firmware to implement a security policy

Secure boot is a UEFI protocol not a Windows 8 feature

UEFI secure boot is part of Windows 8 secured boot architecture

Windows 8 utilizes secure boot to ensure that the pre-OS environment is secure

Secure boot doesn’t “lock out” operating system loaders, but is a policy that allows firmware to validate authenticity of components

OEMs have the ability to customize their firmware to meet the needs of their customers by customizing the level of certificate and policy management on their platform

Microsoft does not mandate or control the settings on PC firmware that control or enable secured boot from any operating system other than Windows.

In other words, Microsoft isn't forcing laptop and desktop makers to ban Linux, though it's giving them the tools to do so.

Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. The two alternatives here are for Windows to be signed with a Microsoft key and for the public part of that key to be included with all systems, or alternatively for each OEM to include their own key and sign the pre-installed versions of Windows. The second approach would make it impossible to run boxed copies of Windows on Windows logo hardware, and also impossible to install new versions of Windows unless your OEM provided a new signed copy. The former seems more likely.

A system that ships with only OEM and Microsoft keys will not boot a generic copy of Linux.

...

Now, obviously, we could provide signed versions of Linux. This poses several problems. Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM.

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. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure MUST NOT be possible on ARM systems.

In other words dual-booting Linux on a standard x86 desktop should be no issue. But if you were hoping to load dual-booting Android and Windows kernels on a Windows 8 tablet (which will likely have an ARM) CPU or on certain notebooks with ARM chips, think again. Microsoft could soften its stance and/or users could find a way to break its DRM protections -- but there's no guarantee of either outcome.

As an Android user, admittedly I haven't done ICS yet, it isn't much of a loss to not be able to implement Win8 in dual boot with Android.

Now, I would like that option, and think Microsoft needs to fix this error in judgement. One reason I refuse to purchase Apple products is their refusal to allow their customers to fully customize the user experience.

I'm hoping that I'll be able to eventually install Win8 on a Tegra2 based tablet.

quote: One reason I refuse to purchase Apple products is their refusal to allow their customers to fully customize the user experience. I'm hoping that

How so? There are a large number of desktop UI and shell customization tools available, alternatives to Finder or any of the other standard interface applications, as many included options as Windows to tweak the interface or settings from within the OS, and if you're so inclined you even can go into the Terminal and make tweaks from there. It is highly configurable.

quote: I'll be able to eventually install Win8 on a Tegra2 based tablet.

Why? Tegra 2 and 3 are really slow, it barely handles Honeycomb well. I figure you'd want something much more capable by the time Windows 8 drops.

quote: Now, I would like that option, and think Microsoft needs to fix this error in judgement.

I agree, it is highly restrictive, even Apple hardware has allowed for installation of other operating systems given that they are PPC or x86 compatible. It is surprising given that Windows has never disallowed for other operating system to be installed via hardware restrictions. They did disallow this in the 90s via force and threats against hardware vendors in the 90s, but the DOJ shut that down ages ago. I can't imagine it would fly 15 years later, they'd get hit with anti-trust lawsuits again.

Now, if Microsoft decided to make their own tablets just like they make their own game consoles, that's a different story, but they've already said that Win8 tablets will be made by other companies, so yeah.