Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
SUSE and Secure Boot: The Details (SUSE Blog)
Posted Aug 12, 2012 2:56 UTC (Sun) by theophrastus (guest, #80847)
but otherwise... where is the sticking point in the following scenario?
1. acquire motherboard with UEFI in its ROM
2. some blessed group provides patched BIOS for the ROM lacking UEFI
3. flash the ROM
4. install debian (with or without 'customized' kernel)
5. happy times are here again...?
Posted Aug 12, 2012 3:19 UTC (Sun) by mjg59 (subscriber, #23239)
Posted Aug 12, 2012 5:38 UTC (Sun) by tonyblackwell (subscriber, #43641)
Posted Aug 12, 2012 5:41 UTC (Sun) by mjg59 (subscriber, #23239)
Posted Aug 12, 2012 7:16 UTC (Sun) by steveriley (subscriber, #83540)
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.
Posted Aug 12, 2012 4:19 UTC (Sun) by geofft (subscriber, #59789)
Secure Boot is no more an inextricable part of UEFI than, say, cookies are of HTTP. Yes, FTP is a sufficiently crappy and '80s protocol that you can't add cookie support to it, but that doesn't mean we need to go back to FTP to eliminate the threat of tracking cookies.
A good number of machines that have been on the market for months are UEFI with legacy BIOS boot support, and have no idea what Secure Boot is.
In any case, as Matthew mentioned, Secure Boot should be trivially disableable in the BIOS menu (on the one test machine I have, with basically a standard-looking BIOS menu with just a few more knobs, it's as obvious as the option to enable hardware virtualization). The worry is just that that's an additional hoop for people to go through before installing Linux. Anyone competent enough to compile their own kernel will know how to go into their BIOS menu and turn off Secure Boot and turn on hardware virtualization while they're there.
Posted Aug 12, 2012 4:54 UTC (Sun) by theophrastus (guest, #80847)
now, if anything, i don't understand the fuss.
Posted Aug 12, 2012 5:26 UTC (Sun) by gmaxwell (subscriber, #30048)
Posted Aug 12, 2012 5:38 UTC (Sun) by mjg59 (subscriber, #23239)
Posted Aug 12, 2012 6:45 UTC (Sun) by gmaxwell (subscriber, #30048)
Under Red Hat's standing plan (https://fedoraproject.org/wiki/Features/SecureBoot), the system will ship with a bootloader which will only boot a kernel signed by a Red Hat controlled key. This kernel will only load modules signed by a Red Hat controlled key. The early patches to implementing the restrictions are available on your website: http://www.codon.org.uk/~mjg59/tmp/ftsoefi/
The user could replace all the involved keys, but doing so will render their boot chain incompatible with their system unless additional measures are taken. I am assuming that this possible possibility is why you're accusing me of dishonesty?
I know it's hard to tell, but I'm trying to avoid writing a novel in each post. I think it's fair to describe a system as incorporating cryptographic lockdown when it does so, even if there is a convoluted way around it, and especially if even that option may not exist. Otherwise you'd have me saying that the iphone is not locked down— after all, jailbreaking exists for it (and is clearly lawful).
Systems with secureboot enabled will only boot a bootloader signed with an authorized certificate, which the Red Hat one will be signed with. Some systems will likely permit the user to escape from this whole process (by enrolling additional keys in some highly complicated manner, or by disabling the whole thing), but the commercial Linux distributors apparently do not consider this 'jailbreaking' ability to be acceptable—or they would simply avail themselves of it. Regardless, as you pointed out in your very next post, vendors may potentially provide no way to disable it (https://lwn.net/Articles/510827/). This is also what my inquiries have indicated: it won't actually be possible to disable as least in some cases, just as is a _requirement_ for MSFT certification on ARM.
I hope that the inability to disable doesn't turn out to be a common reality, but I am skeptical of the argument that that functionality will deprive these products of Windows 8 certification, in light of the understanding I received (from you) that the original requirements also had the ARM-like limits on x86. Surely there is no reason to believe that Microsoft is obligated to deny their own certification to a vendor who violates their requirements in a manner they are indifferent to. But, even if it is and it remains forever possible to disable this on all PC hardware, I still hold the position that the additional inequality created by access to easy installs is material, and is a violation of the social and economic compromises embodied in copyleft software—but that point is just my opinion.
The rest is just the simple, and I believe fairly uncontroversial facts; and it makes me sad to see you resort to ad hominem here. If you have the spare mental cycles and are willing to be responsive I'd be happy to run all further posts of mine past you for fact checking, because I really do care that I am entirely accurate and not misleading.
Posted Aug 12, 2012 15:09 UTC (Sun) by mjg59 (subscriber, #23239)
Posted Aug 13, 2012 2:58 UTC (Mon) by JoeBuck (subscriber, #2330)
Posted Aug 12, 2012 5:37 UTC (Sun) by rahvin (subscriber, #16953)
Lets not underestimate how much MS would like to lock other OS's out of computers, it has long been speculated that was the goal with palladium and other initiatives. But secure boot can most certainly be used for good. Its possible to secure a system with kernel and a signed key that could be used with and IDS system that would prevent the running of any non signed binary. This could essentially eliminate all trojans as long as the keys are handled securely and if you have access to add the keys yourself you could be fully responsible for locking out every binary you haven't personally signed.
Secure boot isn't evil, it's like any tool though in that it can be used for evil.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds