Canonical and UEFI: possibly "better" than Red Hat?

[SteveRiley]

Yay, Mr. Shuttleworth, you appear clueful!

We've been working to provide an alternative to the Microsoft key, so that the entire free software ecosystem is not dependent on Microsoft's goodwill for access to modern PC hardware. We originally flagged the UEFI / SecureBoot transition as a major problem for free software, we lead the efforts to shape the specification in a more industry-friendly way, and we're pressing OEM partners for options that will be more broadly acceptable than Red Hat's approach.

SecureBoot retains flaws in its design that will ultimately mandate that Microsoft's key is on every PC (because of core UEFI driver signing). That, and the inability of SecureBoot to support multiple signatures on critical elements means that options are limited but we continue to seek a better result.

So please, please, answer Matthew's question, mmkay?

So Canonical will be providing a signing service using their key?

...crickets...

Sigh. I guess not. Why, on why, on $DEITY's green Earth, would you imagine an alternative that actually reeks of stronger lockin than the behemoth of Redmond? If I were to take the time to travel from Seattle to [strike]Cape Town[/strike] Isle of Man, would you at least listen to my arguments as to why I think you can, with one simple change of direction, right all the wrongs of the world?

[Teunis]

http://linux.slashdot.org/story/12/0...efi-secureboot
Let's see how this pans out.
In case some vendors are going to lock out alternative Operating Systems they might have to deal with Ms Kroes of the EU.

MS requires OEM's to allow for disabling of the UEFI protection but it's still open how they (MS) do with their own hardware.

[SteveRiley]

they might have to deal with Ms Kroes of the EU.

One can hope.

MS requires OEM's to allow for disabling of the UEFI protection

Not quite. While Microsoft is prohibiting the ability to disable secure boot on ARM machines with pre-installed Windows, the same restriction does not apply to x86 machines. Microsoft encourages OEMs to permit users to disable secure boot on such hardware, but is not requiring that they do so.

[SteveRiley]

MS requires OEM's to allow for disabling of the UEFI protection

Not quite... Microsoft encourages OEMs to permit users to disable secure boot on such hardware, but is not requiring that they do so.

I need to correct myself here.

Because of all the news and commentary today, I decided to check the actual requirements as documented in "Windows Hardware Certification Requirements - Client and Server Systems." The section System.Fundamentals.Firmware.UEFISecureBoot contains the following:

16. Mandatory. Secure Boot Variable. The firmware shall implement the SecureBoot variable as documented in Section 3.2 "Globally Defined Variables' of UEFI Specification Version 2.3.1 Errata B"

17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:

1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx) which will put the system into setup mode.

2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with SecureBoot turned off.

3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.

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.

It would appear that all the speculation since September of last year has become so wild that I had allowed it to taint my own understanding.

[Teunis]

However wrong I find it that it's MS setting these rules instead of a neutral standards- or industry body I can probably live with the requirements for x86.
Remains the question if they can get away with their demands on ARM systems or maybe someone will manufacturer ARM systems without MS pre-installed...
I still wonder what will be the case with the MS designed Surface, can we run something non-MS on it?

[SteveRiley]

Nothing prevents a manufacturer of ARM-based systems from releasing products without an operating system. But for logo certification, ARM machines will be built with the OS embedded into the silicon in something called system on a chip.

The article "Building Windows for the ARM processor" on the Windows 8 blog explains thusly:

Developing WOA begins as a partnership with companies that make ARM processors and package them together with the subsystems required to deliver the equivalent of a motherboard. Unlike the boards many are familiar with, you can think of a WOA board as a silicon package—a series of silicon layers bound together in an incredibly small form factor, called a System on Chip or SoC.

Each ARM licensee building these packages takes a different approach to selecting features, making product trade-offs, and designing the complete silicon package. These choices are what bring the diversity of different products built on ARM to the market. There is no single ARM experience, and as we have seen with other operating systems, even the same ARM CPU combined with different components, drivers, and software can yield different types or qualities of experiences. That is why from the start of the WOA project, we have been working with three ARM licensees: NVIDIA, Qualcomm, and Texas Instruments. Each brings different expertise and different approaches, and all will make a unique contribution to WOA. All of them have extremely successful ARM-based products in the market today, from tablets to smart phones to e-readers to embedded devices. We are fortunate to have the support of such amazing partners, and WOA is unique in working with such diversity.

A SoC package by itself is just the beginning. Delivering WOA PCs is a partnership with PC manufacturers who bring their expertise in manufacturing, system engineering, and industrial design and combine that with the engineering work of ARM partners to develop a complete PC. PC makers also bring expertise at selling PCs to consumers and businesses through a variety of channels and supporting those purchases over time.

Microsoft’s role in this partnership is to deliver a Windows operating system that is tuned to this new type of hardware, new scenarios, and new engineering challenges. Our goal is to make sure that a reimagined Windows delivers a seamless experience from the chipset through firmware, through hardware, through the OS, through applications, and ultimately to the person interacting with the PC. This is a new level of involvement that brings with it a new level of engineering work across all of the parties involved. This new approach is about delivering a unique combination of choice, experiences, and a reliable end-to-end experience over the life of the PC.

[PhilT]

It appears the FSF has problems with Canonical's approach : http://www.groklaw.net/article.php?s...12070213044413

The summary: (I particularly like Point 3 -- )

....." The best solution currently available for operating system distributions includes:

1) fully supporting user-generated keys, including providing tools and full documentation for booting and installing both modified and official versions of the distribution using this method;

2) using a GPLv3-covered bootloader to help protect users against the dangers of Restricted Boot;

3) avoiding requiring or encouraging users to trust Microsoft or any company which makes proprietary software; and

4) joining the FSF and the broader free software movement in pressuring computer distributors to facilitate easy and independent installation of free software operating systems on any computer.

I thought it was an important enough worry for all of us in the FOSS community that it should be reproduced here in full, so you have it when making your own decisions on what you personally wish to do. I am, of course, disgusted that once again Microsoft is making it harder to use FOSS, but we've also seen over time that the community is resourceful. If Groklaw can be helpful in making documentation clearer, for example, I certainly will be happy to help out. No doubt you feel the same. ... "

[SteveRiley]

Frankly, neither approach is really very satisfactory. I guess it's yet another example of choosing which one you think sucks less.