Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
now, if anything, i don't understand the fuss.
SUSE and Secure Boot: The Details (SUSE Blog)
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)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds