5 ms·

It appears to me that both System.Fundamentals.Firmware.FirmwareSupportsUSBDevices System.Fundamentals.Firmware.FirmwareSupportsBootingFromDVDDevice are r

by kogir 13y ago

It appears to me that both System.Fundamentals.Firmware.FirmwareSupportsUSBDevices System.Fundamentals.Firmware.FirmwareSupportsBootingFromDVDDevice are required for Windows Logo Certification for both Windows 7 and 8: http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/jj1... 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?

mjg59 13y ago
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.
- kogir 13y ago
  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.
  - mjg59 13y ago
    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…
- vidarh 13y ago
  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?
  - mjg59 13y ago
    Apparently, yes, which is something I hadn't noticed before.
  - FireBeyond 13y ago
    I wouldn't have thought so - I'd think that Linux would be perfectly capable of utilizing the same 'fast boot' logic as Windows has. I think it only applies to "getting into a USB boot / install environment".
    - mjg59 13y ago
      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.
      - gizmo686 13y ago
        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.
- deleted 13y ago
  [deleted]
morpher 13y ago
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?
- comex 13y ago
  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.
  - Zr40 13y ago
    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.
    - asdfs 13y ago
      Not if the default is to boot from an SSD soldered onto the mainboard, or tucked away in a device that is not designed to be opened.
    - rbanffy 13y ago
      > a physically present user (mentioned by the requirement of point 18) can disconnect the boot device in order to prevent Windows from booting. I believe that would void most warranties.

by kogir 13y ago

mjg59 13y ago

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.

kogir 13y ago
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.
- mjg59 13y ago
  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…
vidarh 13y ago
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?
- mjg59 13y ago
  Apparently, yes, which is something I hadn't noticed before.
- FireBeyond 13y ago
  I wouldn't have thought so - I'd think that Linux would be perfectly capable of utilizing the same 'fast boot' logic as Windows has. I think it only applies to "getting into a USB boot / install environment".
  - mjg59 13y ago
    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.
    - gizmo686 13y ago
      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.
deleted 13y ago
[deleted]

morpher 13y ago

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?

comex 13y ago
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.
- Zr40 13y ago
  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.
  - asdfs 13y ago
    Not if the default is to boot from an SSD soldered onto the mainboard, or tucked away in a device that is not designed to be opened.
  - rbanffy 13y ago
    > a physically present user (mentioned by the requirement of point 18) can disconnect the boot device in order to prevent Windows from booting. I believe that would void most warranties.