![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Updated 22/06/2012: Reference to Canonical's response
A couple of people have asked me about the Ubuntu ODM UEFI requirements, specifically the secure boot section. This is aimed at hardware vendors who explicitly want to support Ubuntu, so it's not necessarily the approach Canonical will be taking for installing Ubuntu on average consumer hardware. But it's still worth looking at.
In a nutshell, the requirements for secure boot are:
It's basically the same set of requirements as Microsoft have, except with an Ubuntu key instead of a Microsoft one.
The significant difference between the Ubuntu approach and the Microsoft approach is that there's no indication that Canonical will be offering any kind of signing service. A system carrying only the Ubuntu signing key will conform to these requirements and may be certified by Canonical, but will not boot any OS other than Ubuntu unless the user disables secure boot or imports their own key database. That is, a certified Ubuntu system may be more locked down than a certified Windows 8 system.
(Practically speaking this probably isn't an issue for desktops, because you'll need to carry the Microsoft key in order to validate drivers on any PCI cards. But laptops are unlikely to run external option ROMs, so mobile hardware would be viable with only the Ubuntu key)
There's two obvious solutions for this:
This kind of problem is why we didn't argue for a Fedora-specific signing key. While it would have avoided a dependence on Microsoft, it would have created an entirely different kind of vendor lock-in.
Update: Canonical have now provided their full plans. They won't be providing a signing service, but will be requiring that all Ubuntu-certified hardware ship with the Microsoft key
A couple of people have asked me about the Ubuntu ODM UEFI requirements, specifically the secure boot section. This is aimed at hardware vendors who explicitly want to support Ubuntu, so it's not necessarily the approach Canonical will be taking for installing Ubuntu on average consumer hardware. But it's still worth looking at.
In a nutshell, the requirements for secure boot are:
- The system must have an Ubuntu key preinstalled in each of KEK and db
- It must be possible to disable secure boot
- It must be possible for the end user to reconfigure keys
It's basically the same set of requirements as Microsoft have, except with an Ubuntu key instead of a Microsoft one.
The significant difference between the Ubuntu approach and the Microsoft approach is that there's no indication that Canonical will be offering any kind of signing service. A system carrying only the Ubuntu signing key will conform to these requirements and may be certified by Canonical, but will not boot any OS other than Ubuntu unless the user disables secure boot or imports their own key database. That is, a certified Ubuntu system may be more locked down than a certified Windows 8 system.
(Practically speaking this probably isn't an issue for desktops, because you'll need to carry the Microsoft key in order to validate drivers on any PCI cards. But laptops are unlikely to run external option ROMs, so mobile hardware would be viable with only the Ubuntu key)
There's two obvious solutions for this:
- Canonical could offer a signing service. Expensive and awkward, but obviously achievable. However, this isn't a great solution. The Authenticode format used for secure boot signing only permits a single signature. Anything signed with the Ubuntu key cannot also be signed with any other key. So if, say, Fedora wanted to install on these systems without disabling secure boot first, you'd need to have two sets of install media - one signed with the Ubuntu key for Ubuntu hardware, one signed with the Microsoft key for Windows hardware.
- Require that ODMs include the Microsoft key as well as the Ubuntu key. This maintains compatibility with other operating systems.
This kind of problem is why we didn't argue for a Fedora-specific signing key. While it would have avoided a dependence on Microsoft, it would have created an entirely different kind of vendor lock-in.
Update: Canonical have now provided their full plans. They won't be providing a signing service, but will be requiring that all Ubuntu-certified hardware ship with the Microsoft key
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Different ways
Date: 2012-06-19 06:18 pm (UTC)Wish them good luck...
Date: 2012-06-19 06:53 pm (UTC)And for system76 ?
Date: 2012-06-19 07:09 pm (UTC)However, after reading 3 times, I do not see where this is written that secureboot must be enabled by default. Did I missed something ?
Re: And for system76 ?
Date: 2012-06-20 12:53 pm (UTC)no subject
Date: 2012-06-19 07:26 pm (UTC)It is a no-win situation
Date: 2012-06-19 07:26 pm (UTC)Every option sucks.
Re: It is a no-win situation
Date: 2012-06-20 12:36 am (UTC)If Google decided to do what Canonical did.. avoiding MS as a signing service.. that will really bring home the limitation inherent in the single allowed signature on driver blobs. Microsoft and Google standing themselves as different signatories for drivers is going to mean double the work. for all mobile device manufacturers. No offense to Canonical but they aren't one of the 500 lb gorillas and unfriendly vendors will just ignore Canonical's requirements. Nobody in the ARMs-race can ignore Google. And as gross as this issue is on intel "PC" hardware the real fight is going to be ARM as MS tries to muscle in and lockin there.
-jef
no subject
Date: 2012-06-19 09:40 pm (UTC)Thawte anyone?
Disabling secureboot
Date: 2012-06-19 09:47 pm (UTC)That sounds like a very simple solution to me. What are the disadvantages of asking users to disable secure boot when they want to install a different OS?
Re: Disabling secureboot
Date: 2012-06-19 11:42 pm (UTC)Yes.
"That sounds like a very simple solution to me. What are the disadvantages of asking users to disable secure boot when they want to install a different OS?"
To some users, it's scary and complicated. And, of course, you lose the security benefits it offers.
If you're happy with poking about in the UEFI configuration screens, and you don't mind about the security of secure boot, then just turning it off is an entirely satisfactory solution.
-adamw (posting anon because openid posting to dreamwidth seems to be broken)
Re: Disabling secureboot
Date: 2012-06-20 03:46 pm (UTC)Any device running Windows 8 RT (i.e Windows 8 on ARM hardware) you CANNOT disable secure boot.
Thats ANY Windows 8 RT device (tablet, laptop, server, desktop)
Can you know see where the problems occur?
Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-19 10:33 pm (UTC)As I understand this issue, Microsoft rather coyly does not in fact include this (ie. a requirement that the user (owner) be able to manage Secure Boot keys in their UEFI) in the Windows certification requirements -- which is the substantial basis for it being an issue in the first place.
If the user can reliably manage keys in the UEFI (or even just "reconfigure" "a" key, which would be less satisfactory but not really horribly broken), then doesn't the fundamental problem go away?
Ubuntu wouldn't need to supply a signing service, because users could sign their own software (or maybe even use some key supplied by some other particular distro -- even one from Fedora or Red Hat).
Of course, Microsoft is already insisting that Windows-certified ARM hardware shall not permit key management or even disabling Secure Boot.
B. Swiss
Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-20 01:30 am (UTC)Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-20 02:43 am (UTC)Has Microsoft changed their Secure Boot (x86) requirements once again, so as to not only require that disabling Secure Boot is a user option, but to also require such key management be be available to the user?
I haven't heard anything about it -- which is a little surprising, considering that this was the big problem that everyone was upset about.
PS: I just took a quick look at the Ubuntu document you linked:
Any machine shipped with Ubuntu must support reconfiguration of the keys used in the secure boot process, to allow users to use secure boot with their own keys and custom boot images. The firmware interface should allow a physically-present user to enter the machine in to setup mode, or manually load KEK, db and dbx entries from disk or removable storage. This require-ment is compatible with the Windows 8 Hardware Certification Requirements [WIN8HCR], ยง System.Fundamentals.Firmware.UEFI SecureBoot, item 20.
(page 26)
That does not appear to say that the Ubuntu Certification requirements are the same as Microsoft's Certification requirements, but rather that Ubuntu's additional requirement for user-accessible key management features is compatible with Microsoft's Secure Boot specification (which I presume is true, as Microsoft has not yet forbidden user-manageable Secure Boot keys -- at least not for x86 hardware).
B. Swiss
Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-20 02:45 am (UTC)Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-20 05:06 am (UTC)Thank you, Matthew, for that information.
I appear to have found the relevant portion of the specification (page 122 of the May 9, 2012 version of Microsoft's Windows Hardware Certification Requirements document -- assuming I actually understand it properly).
This change in the Windows 8 certification requirements appears to have received very little coverage in the popular tech press (certainly a lot less than the previous concerns that those requirements would effectively undermine sensible, OS-neutral implementations). I have heard nothing about this in my regular on-line haunts -- and it appears that I am not the only one.
I suppose I should do some review, and refresh my understanding of the whole matter. As a non-techie Linux-user, all that PKPub, PKPriv and KEK stuff gets easily jumbled -- and now it looks like I might actually have cause to keep the details straight :-P. Ah well -- better that than remain both misinformed and ignorant.
So, good luck getting it all ironed out and practicable! Your work is appreciated.
Bernard Swiss
Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-22 08:33 pm (UTC)"""
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:
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.
"""
It looks like some vendors will have the option to be lazy and just allow the secure boot stuff to be cleared -- I don't see where a vendor going that route has to provide a subsequent means to edit the cleared database.
Microsoft says it is mandatory to be able to go into a custom secure boot mode and then they say that the implantation of this custom secure boot mode can simply consist of an option which clears the databases and sends you back to setup mode with secure boot off -- so not really custom mode at all!
This is my biggest concern, that any free operating system that doesn't get involved in the microsoft signing scheme is going to be in a second class position where they can't get the benefit of secure boot. (the hassle of self installing keys is okay for me as long as the option really is there)
I agree with Matthew that secure boot isn't security theatre, so being forced to disable it instead of being able to fully control it and use it for your purposes is a substantially inferior position to be in.
I could live with a crappy firmware that meets this silly description of custom mode if such firmwares also allowed me to take flash my own firmware with my own secure boot implementation. That way I could still get the benefits of secure boot for myself and wouldn't be buying hardware that (in theory) gives one group of operating systems better security than any other.
Somebody tell me that I'm reading this wrong and that the mandatory custom mode for windows 8 certification really does have to live up to its name and must consist of real customizations to stored keys.
Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-22 08:47 pm (UTC)Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-22 10:36 pm (UTC)The words setup mode and SetupMode only appear a few times in the Microsoft document (pages 119, 122, 124), and it's never described well there as to what capabilities it does and does not give the user.
So we're relying on transitivity of mandatoryness here? Microsoft has made some aspects of UEFI re setup mode mandatory and those parts of UEFI make it mandatory for setup mode to have this feature?
Transitivity of mandatoryness makes me less confident that the MS certification process will actually produce this outcome in shipped hardware. I'll believe it when I see it.
Looking at the UEFI spec, I only see setup mode discussed in section 3.2 Globally Defined Variables and section 27 Security - Secure boot.
All I can read into the UEFI re setup mode is that yes, it is intended for this kind of thing. It's hard to find a clear mandate in UEFI that setup mode must include a real user interface for actually putting key changes into practice. The UEFI spec is very API oriented, e.g. "The platform owner enrols the public half of the Platform Key (PKpub) by calling the UEFI Boot Service SetVariable()".
It's hard to appreciate what setup mode will actually entail in terms of relevant user interfaces being when reading the UEFI spec.
It's not going to be fun if code is present in the firmware for changing the platform key but there's not an actual user interface to let you use that code.
But this isn't my nightmare "second class" scenario as long as long as firmware can load your own code and allow you to use the firmware API to change the platform key. (presumably the firmware enters setup mode and stays in setup mode as your code takes over?). It is the extensible firmware interface after all, right?
(But we'll still be prevented from installing our own firmware or firmware signing key by the time our own code kicks in, so coreboot is still locked out?)
And, assuming UEFI machines can stay in setup mode (or equivalent) while also loading your own code to take advantage of setup mode, I wonder, will my code be able to come from removable media (cd, hd, USB?) or will I need something like an option ROM to run my own setup mode code to make the UEFI calls for changing the platform key?
A slight ray of hope can be found in section 27.5 of UEFI:
"While in setup mode, the platform firmware shall not require authentication in order to modify the Platform Key or the Key Enrolment Key database."
but its a leap for me to read that and conclude "real user interface for making change" -- all I can read into is that if a such a user interface does exist it can't have authentication in the way.
Thank you Matthew in advance for any insight on the prospects of the Win 8 certified mandated setup mode being meaningful and useful to end users for key installation vs being a mirage.
Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-22 10:48 pm (UTC)Re: Isn't there a key difference from Microsoft's requirements?
Date: 2012-06-23 03:33 am (UTC)Its good to hear we'll have the ability to run our own code in setup mode and to make real system changes that way -- not having to rely on upstream hardware vendors any more than necessary is a very good.
I know this isn't directly a MS Win 8 or UEFI matter, but I'm still feeling sad that many hardware vendors will disallow user-provided firmware updates (e.g. coreboot) in setup mode -- at least the reality of control over secure boot makes this a wish-had item over a must-have.
I appreciate why it is a good feature for a system owner who worries about other physically present people tampering with the system -- operating a chip programmer can be a more daunting matter, if I understand correctly this is especially hard when a surface mounted flash chip is involved without special programming pins available on the main board.
no subject
Date: 2012-06-19 10:59 pm (UTC)Being cynical, Microsoft has no incentive to do that, and the hardware vendors have little incentive to do anything beyond what Microsoft wants. Possibly the EU will in due course insist on something happening to avoid this constituting an anti-competitive practice?
Sure.
Date: 2012-06-19 11:44 pm (UTC)Sense? Sure. Commercial sense? Not so much.
"Maybe two or three of the CAs would like to do it."
Where's the profit? How many organizations in the world, total, ship operating systems? There's your customer base. It's not very big.
no subject
Date: 2012-06-19 11:48 pm (UTC)No worries, it will all work out
Date: 2012-06-22 03:25 pm (UTC)Re: No worries, it will all work out
Date: 2012-06-22 03:26 pm (UTC)One thought...
Date: 2012-07-27 06:14 am (UTC)I certainly have a dreadful feeling that at some point in time Microsoft will attempt to require the evil restrictions they impose on ARM for future x86/x64 Windows certification (no disabling secure boot, no changing keys).
The more OEMs who include Canonical's (and other free OS people's) key, the better it will be for the lot of us in the future.
Re: One thought...
Date: 2012-07-27 01:41 pm (UTC)Re: One thought...
Date: 2012-07-28 05:40 am (UTC)Re: One thought...
Date: 2012-07-28 05:45 am (UTC)