User: Password:
|
|
Subscribe / Log in / New account

SUSE and Secure Boot: The Details (SUSE Blog)

SUSE and Secure Boot: The Details (SUSE Blog)

Posted Aug 12, 2012 3:19 UTC (Sun) by mjg59 (subscriber, #23239)
In reply to: SUSE and Secure Boot: The Details (SUSE Blog) by theophrastus
Parent article: SUSE and Secure Boot: The Details (SUSE Blog)

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.


(Log in to post comments)

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.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds