| |||||||||||||
SUSE and Secure Boot: The Details (SUSE Blog)SUSE and Secure Boot: The Details (SUSE Blog)Posted Aug 12, 2012 2:56 UTC (Sun) by theophrastus (guest, #80847)In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by mjg59 Parent article: SUSE and Secure Boot: The Details (SUSE Blog)
Is there no hope and possibility that a motherboard maker will offer a non-UEFI (BIOS) option? i suppose it'll be said that merciless market forces will eliminate this when the IT departments of *all* businesses will insist upon it?
but otherwise... where is the sticking point in the following scenario?
(Log in to post comments)
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 3:19 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
All Windows 8 certified x86 systems will let you disable Secure Boot in the firmware configuration. You'll still be running UEFI, but it'll boot anything you want it to.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:38 UTC (Sun) by tonyblackwell (subscriber, #43641) [Link]
Sounds good in theory. In terms of our current needs to buy motherboards, I've discussed this with ASUS and Gigabyte - with whoever there would respond to my attempts at communication. As I understand their replies, neither company has any system at all for disabling secure boot and no plans to do so. Does anyone have inside contacts?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:41 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
If hardware vendors want to prevent their boards being used for anything other than Windows 8, that's a thing they can do. They won't be able to sell those boards to anyone who wants to build Windows 8 certified systems and they'll be locking themselves out of the corporate market for the forseeable future, so it doesn't seem like a likely thing for them to do - it seems much more likely that whoever you're talking to just has no idea what they're talking about.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 7:16 UTC (Sun) by steveriley (subscriber, #83540) [Link]
Windows Hardware Certification Requirements - Client and Server Systems
http://msdn.microsoft.com/en-US/library/windows/hardware/...
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.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 4:19 UTC (Sun) by geofft (subscriber, #59789) [Link]
UEFI and Secure Boot are two different things. We've been having EFI machines forever (look at your nearest Mac for an example); it's just that the EFI standard is maturing into UEFI now and is something that can be reasonably implemented, and also that the legacy BIOS boot mechanism is a sufficiently crappy and '80s way to boot a PC that you couldn't implement Secure Boot on it even if you tried, so the forces that want Secure Boot are designing it as part of UEFI.
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.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 4:54 UTC (Sun) by theophrastus (guest, #80847) [Link]
thank you.
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) [Link]
Then presumably you also don't understand why the large commercial Linux distributors think its important to distribute software which is cryptographically locked with a pre-enrolled certificate chain?
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:38 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
Given the combination of how inaccurate that is and how many times this conversation has been had with you, it's difficult to believe you're being anything other than wilfully dishonest at this point. Anything we're distributing will permit the installation of keys by the end user - nothing is cryptographically locked to the shipped keys.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 6:45 UTC (Sun) by gmaxwell (subscriber, #30048) [Link]
Your ad hominem now forces me to respond to what is seemingly becoming a pointless subthread—but don't be confused: I'm speaking only to defend my good name and to help clarify for anyone who was confused. I apologize in advance for repeating things almost everyone knows.
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.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 15:09 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
The implementation will use any keys used in db, and the Suse approach lets us extend this to a separate key database with a consistent and non-arcane management UI. This is a far cry from being "cryptographically locked with a pre-enrolled certificate chain" - it's cryptographically locked with whatever set of keys you want to use.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 13, 2012 2:58 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] I'm delighted to see how open you are to adopting improvements proposed by competitors; it's a refreshing change from the "NIH" attitudes I see so often.
SUSE and Secure Boot: The Details (SUSE Blog) Posted Aug 12, 2012 5:37 UTC (Sun) by rahvin (subscriber, #16953) [Link]
The major OEMs might allow adding new keys with secure boot, it really depends on how many enterprise customers want the ability. But if you buy your components separately and put them together yourself I fully expect the manufacturers to not only allow turning of secure boot but adding keys and probably even deleting and modifying the system in-line with the specification.
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.
|
|||||||||||||