allend |
10-19-2015 08:24 AM |
Quote:
The highlighted sections are the parts relevant to OEM resellers. It can be interpreted reversely: it is not demanded of the OEM anymore that they allow the Secure Boot to be disabled.
|
It did not take the wisdom of Solomon to see that coming.
Quote:
At least there is a demand to be compliant to version 2.3.1 or greater of the UEFI specification, which is a good thing IMO as so providers of EFI images and applications now know what they should expect from the firmware of such machines.
|
Perhaps your glee will be subdued by considering how M$ is manoeuvring in this space. Consider the requirements for Windows 10 on SoC. https://msdn.microsoft.com/en-us/lib...v=vs.8529.aspx
Under Security requirements -> UEFI secure boot
Quote:
Requirement 5: MANDATORY. A Microsoft-provided UEFI KEK shall be included in the UEFI KEK database. No additional KEKs shall be present.
|
which according to http://www.uefi.org/sites/default/fi...Spec_2_3_1.pdf Section 27.5 p 1444 translates to an OEM can only ship Windows 10 with no other OS installed. With the historical close link between M$ and OEMs, that becomes a given.
Quote:
Requirement 7: MANDATORY. The initial signature databases shall be stored in firmware flash and may be updated only with an OEM-signed firmware update or through UEFI authenticated variable write.
|
Updating the signature database is being pushed to the OEMs discretion.
Quote:
Requirement 8: MANDATORY. Images in the boot path that fails signature verification must not be executed, and the reason for the failure shall be added to the EFI_IMAGE_EXECUTION_TABLE. Further, the recommended approach in these situations is that the UEFI boot manager initiates recovery according to an OEM-specific strategy.
|
What is to stop the OEM from simply deleting the offending image?
Quote:
Requirement 9: MANDATORY. Physically present user override must not be permitted for UEFI images that fail signature verification.
|
The user is no longer in charge.
Quote:
Requirement 10: OPTIONAL. An OEM may implement the ability for a physically present user to turn off Secure Boot either with access to the PKpriv or with Physical Presence through the firmware setup. Access to the firmware setup may be protected by platform specific means (administrator password, smart card, static configuration, etc.)
|
The ability to turn off Secure Boot is at the OEMs discretion, not mandatory as per previous.
Quote:
Requirement 11: MANDATORY if requirement 10 is implemented. If Secure Boot is turned off then all existing UEFI variables shall not be accessible.
|
The user has no recourse.
Requirements 12 to 21 do not seem quite so draconian.
Have a nice day!
|