Doesn't that directly contradict the hypothetical scenario presented in the article? Additionally, there's Windows 8 hardware out there already. Can the author provide no examples of this happening in real life?
From System.Fundamentals.Firmware.FirmwareSupportsUSBDevices:
The USB controller and USB devices must be fully enumerated when:
* Anything other than the Windows Boot Manager is at the top of the system boot order.
* A boot next variable has been set to boot to something other than the Windows Boot Manager.
* On a system where the Windows Boot Manager is at the top of the list, an error case has been hit, such that the firmware fails over from the Windows Boot Manager to the next item in the list.
* Resuming from hibernate, if the system was hibernated when booted from USB.
* Firmware Setup is accessed.
ie, it's not required for most normal boots on systems that already have Windows installed. System.Fundamentals.Firmware.FirmwareSupportsBootingFromDVDDevice merely states that the system must support booting from DVD, not that it must attempt to by default. And yes, I've observed this behaviour on real hardware.
I believe you, but can you please name and shame? I'd hate to accidentally purchase hardware which by design makes entering firmware setup impossible[1]. With online ordering this isn't always something you can check in advance.
[1] I'm assuming that if a working OS install is required to access it, should anything go wrong you're screwed.
The Microsoft spec says that any fallback to the Windows rescue environment should trigger full USB enumeration. The Samsung Series 5 I tested had this behaviour, but given I had to return it after managing to kill the firmware I can't give you the exact model number…
Does this mean that the hardware is pretty much guaranteed to boot slower if not booting Windows too, in order to do USB initialisation, even when not going to the boot screen?
The spec says that the feature should be disabled if any UEFI boot entry other than "Windows Boot Manager" is chosen. Whether that's actually implemented, I don't know.
Regardless, it should be possible for the third party loader to claim to be "Windows Boot Manager".
I can't imagine that there would be any cryptographic verification that the boot loader is actually "Windows Boot Manager". This is because the crypto logic is essential to check that the binary is signed by a trusted key. This process would happen before the UEFI thinks about entering the boot loader. It would also not make sense for the crypto section to make any associations between the keys and who signed them (apart from giving the user information).
Still, it seems like a bad spec to create special cases for named hardware. Hopefully, we will arrive at a standard where the OS can signal if the feature should be disabled, or make it a toggleable setting (which, from what I understand of UEFI, the OS can toggle). Unfourtuantly, depending on how strict MS is with their certification standards, this would prevent the computers from being certified.
It's entirely possible to do that, but that's a string that's (often) visible to the user. Now I'd have to remember which "Windows Boot Manager" is Windows and which is Linux.
This is a perfect example of why I don't want UEFI; I spent a long time learning how to do all of this in GRUB, and now they are putting these basic features in the firmware where they belong. Get off my lawn.
Anyway, if this is a problem, you should still be able to use a bootloader to provide the selection menu. I think it should be possible for this bootloader to leverage UEFI to avoid increasing the boot time noticeably. But I do agree that hardcoding names like "Windows Boot Manager" is horrible spec design (and maybe grounds for an anti-trust suit?).
A think I am more open to this type of workaround because I already have set up simmilar systems on my computer. For example, Java does not play nice with window managers that do not re-parent. This caused a problem in Sun's window manager "LG3D", which was non-re-parenting, so they hardcoded a special case for LG3D so things would work. So now, if software asks, I am running LG3D.
You can also look through the Linux kernel device drivers for many special cases.
Additionally, as point (18) on the page you linked to states:
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.
Doesn't this mean that (definitely on certified non-ARM systems, and possibly on some ARM systems) you can just enter the UEFI, disable secure boot, and boot your OS of choice?
As the article (clearly) says, since USB is not set up fast enough to recognize a keyboard before the bootloader has handed control to the OS, there's no way to interrupt boot to do so; Windows will let you reboot to another OS, but only after you click through a license agreement.
Surely a physically present user (mentioned by the requirement of point 18) can disconnect the boot device in order to prevent Windows from booting. The firmware then has ample time to set up USB and allow the user to enter firmware setup.
Alternatively, as a workaround, find someone who has already accepted said agreement elsewhere and have them accept it on your device, disable secure boot and wipe the boot device.
Have you looked at an Ultrabook? Getting at the hard drive involves disassembling the entire machine, something that's almost impossible to do without either specialised tools or a willingness to inflict some amount of cosmetic damage.
This is idiotic. The requirement should be that the user can disable it entirely OR replace the private key. And it should require implementation of an optional password protection.
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".
Doesn't that directly contradict the hypothetical scenario presented in the article? Additionally, there's Windows 8 hardware out there already. Can the author provide no examples of this happening in real life?