Senior Member
Well!Originally Posted by Kristian Joensen
If every single board manufacturer will have such a comprehensive menu for managing the UEFI Secure Boot feature I say this is essentially a complete non-issue already. Just delete the keys and we're good to go with the machine back to being a complete blank slate.
Keyword being 'IF'.
Senior Member
Well this is the implementation by American Megatrends Incorporated (AMI).
So I guess it will look pretty much same on all motherboard vendors and OEM who use that, unless for some reason they remove that.
Also, we're yet to see if Phoenix Technologies (AwardBIOS) implements it like this too.
Then there is Insyde BIOS though, but its less commonly used, I believe. I don't know if Insyde have any UEFI solution, but I can guess they do.
Kanotix Developer
It is so uncommon that the very small company asus uses Insyde - btw. i just found a new bug in it. Using the 3402 firmware version for my p8z68-v board boot entries are removed with the same filename (efibootmgr -l option) - it does not matter if the label or the options used are different. only the last entry is kept. a bit stupid when you want to use differnt boot options but the same kernel. i filled out a support form but did not yet get a response... if somebody wants to verify that with a newer board let me know.
Last edited by Kano; 07-11-2012 at 08:20 AM.
Red Hat
Interesting. Clearly not the type of implementation we'll see on Win8 machines, though, as it defaults to off and no Microsoft key is enrolled. Thanks for the catch! I don't follow Google+.
Red Hat
I have a weird Insyde firmware on my Sony laptop. It's actually a UEFI firmware but it _only_ allows you to use BIOS emulation; you can't force it to do a native UEFI install of anything, it just won't. Oddness. That's a couple years old, though.
Red Hat
The Windows 8 certification requirements explicitly require that there be a simple toggle for turning Secure Boot off. In practice, it's _not_ going to be a problem at all on Windows 8 systems for anyone comfortable with going into firmware config screens. They'll all have an 'off' switch.
The requirements also say that the user must be able to manage keys, to some extent, but the requirement is written in a pretty odd way that would be compatible with some really dumb implementations. So I'm sure we'll see some.
Here's the full text, if anyone's interested. 17 is the requirement that user must be able to manage keys. 18 is the requirement that user must be able to disable secure boot. See http://msdn.microsoft.com/en-us/libr...dware/jj128256 .
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:
* 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 puts the system into setup mode.
* If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off.
* 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.
Kanotix Developer
Well thats known for long time. Just add instructions on your website how to disable Secure Boot and forget about it?
Red Hat
Kano: known to us, maybe, but it's painfully clear from (to a lesser extent) this thread and (to a greater extent) others I've seen lately that lots of people don't know about it at all...
There've been three problems identified with the 'document it and forget it' approach so far:
1) Some people just aren't comfortable fiddling in the firmware config _at all_
2) Some people might be okay with that, but not with disabling a function with 'Secure' in its name. 'Why do I have to turn off security to install Linux? Is Linux insecure?'
3) 'Documenting it' is likely to be rather harder to do than it is to suggest, going on the history of firmware configuration interfaces - OEMs seem to delight in customizing their firmware config interfaces for no readily apparent benefit. Even though there's only four or five major firmware vendors who all the OEMs contract their firmware implementations out to, the OEMs retain the right to request a customized user interface, and they often do. You can buy five systems with Award firmwares - from the same vendor, even - and get five different interfaces. Sadly, we won't just be able to stick one or two step-by-steps on a Wiki page and call it good. We'll probably have to print hundreds of the damn things. For experienced firmware twiddlers we can just give vague instructions - 'find the Secure Boot setting and turn it off' - but that's not enough for many. We could tell people to read the motherboard manual, but...yeah, I don't think I need to explain the problems with that. =)
Kanotix Developer
What you say is definitely WRONG for most OEM boxes, only those you can get preinstalled with Win8. There the gui is usually limited to a minimum of options and it should be straight forward to find the needed settings. Did you really look into oem setups? You can setup basically no advanced option at all. If you document that you have to disable Secure Boot then it should be really enough. Those ppl who want to use Linux know that term for over 6 months now, you talk about full noobs only. I did never see an OEM system with graphical setup, did you? Guess why? Because it is not used in marketing like it is for retail motherboards for overclockers. There they add "simple" overclocking features even in the basic setup. Use a slider to enable overclocking, done. But those boards will not enable Secure Boot by default, you can not even buy one with UEFI 2.3.1 support when you forget about the outdated s1156 board from Intel which has got a development kit for it.
Posting Permissions
Reply With Quote