Blogs

RSS FeedBlogs
RSS FeedSubscribe to this blog
About Author
Glyn Moody

Glyn Moody's look at all levels of the enterprise open source stack. The blog will look at the organisations that are embracing open source, old and new alike (start-ups welcome), and the communities of users and developers that have formed around them (or not, as the case may be).

Is Microsoft Blocking Linux Booting on ARM Hardware?

Article comments

Back in September last year, there was a bit of a to-do about Microsoft’s UEFI Secure Boot technology in Windows 8, when a Red Hat engineer <a href=http://mjg59.dreamwidth.org/5552.html>posted the following:

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.

He then went on to explore possible ways around this:

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.

The concern here, of course, is that Microsoft’s approach seems to be making it hard if not impossible to install GNU/Linux on hardware systems certified for Windows 8.

Microsoft <a href=http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx>responded to these issues at some length:

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

That last point is crucial: Microsoft says that it doesn’t tell OEMs what the firmware setup should be, which presumably means that if they wish they can offer the option to disable Secure Boot and allow alternative operating systems to be installed.

In December 2011, Microsoft <a href=http://msdn.microsoft.com/en-us/library/windows/hardware/hh748200.aspx>published a document entitled “Windows Hardware Certification Requirements” for client and server systems. As the introduction explains:

This release to web (RTW) document contains the Windows Hardware Certification requirements for Windows 8 Certified Systems. These requirements are Microsoft’s guidelines for designing systems which successfully meet Windows performance, quality, and feature criteria, to assure the optimum Windows 8 computing experience. Successfully following this guidance will allow a partner to receive certification for their system.

On page 116 of this document, there are some details about the circumstances under which Secure Boot can be disabled:

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.

This confirms that it is indeed possible to disable Secure Boot – but only on non-ARM systems (i.e. traditional PCs.) In other words, it would appear that Microsoft is still locking out GNU/Linux from installation on ARM-based Windows 8 machines.

So this leaves me confused. The document was published some time after Microsoft’s post where it states “Microsoft does not mandate or control the settings on PC firmware that control or enable secured boot from any operating system other than Windows”, and yet it seems to contradict it. So what’s going here? Was Microsoft’s blog statement only about non-ARM systems, as the new documentation suggests? And if so, why the discrimination? And finally, is ARM really happy to see Microsoft apparently locking out GNU/Linux from its systems in this way? Let’s hope Microsoft can clarify this situation as it did on the previous occasion.

Follow me @glynmoody on Twitter or identi.ca, and on Google+

Share:

Send to a friend

Email this article to a friend or colleague:


PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.


We use cookies to provide you with a better experience. If you continue to use this site, we'll assume you're happy with this. Alternatively, click here to find out how to manage these cookies

hide cookie message

ComputerworldUK Knowledge Vault

ComputerworldUK
Share
x
Open