Microsoft's
Windows 8 Hardware Certification Requirements,
System.Fundamentals.Firmware.UEFISecureBoot, Item 2, applicable to Windows 8
(x86, x64), Windows RT (ARM) and Windows Server (2012, where using
UEFI):
Mandatory. Secure Boot must ship enabled Configure
UEFI Version 2.3.1 Errata B variables SecureBoot=1 and
SetupMode=0 with a signature database
(EFI_IMAGE_SECURITY_DATABASE) necessary to boot the machine securely pre-
provisioned, and include a PK that is set and a valid KEK
database. The system uses this database to verify that only trusted code
(for example: trusted signed boot loader) is initialized, and that any unsigned
image or an image that is signed by an unauthorized publisher does not execute.
The contents of the signature database is determined by the OEM, based on the
required native and third-party UEFI drivers, respective recovery needs, and the
OS Boot Loader installed on the machine. The following Microsoft-provided
EFI_CERT_X509 signature shall be included in the signature database: [Signatures
deleted]
Bold emphasis in the original, italic bold emphasis
added, two trailing notes not included.
The solution to allow support for
alternative OS's under these constraints is for an OEM to include the ability to
turn off secure boot and/or reset setupmode to '0' (False) or to include an
EFI_CERT_X509 cert for an open source boot loader. The Platform Key (PK) would
be set by the OEM.
Items 17, 18 and 19 make the distinction between ARM and
non-ARM systems. Item 18 requires Secure Boot mode to be enabled or disabled
via firmware setup, meaning to toggle between booting Windows 8 and booting an
alternate OS would require firmware setup window interaction by a physically
present user. Disabling Secure Boot is not possible on ARM systems.
Item
19:
If the firmware is reset to factory, then any customized
Secure Boot variables are also factory reset. If the firmware settings are
reset to factory defaults, all custom-set variables shall be erased and the OEM
PKpub shall be re-established along with the original, manufacturer-provisioned
signature databases.
This provision prevents you from
restoring platform ownership to the physical owner of the product. You may not
supply your own Platform Key. Item 13. requires the OEM to own the Public Key
(PK). The firmware is never left in setupmode=1.
There's also a mandatory
secure Firmware Update process in item 8 which prevents you from changing
firmware to something more open source friendly with the
caveat:
The firmware update process must also protect against
rolling back to insecure versions, or non-production versions that may disable
secure boot or include non- production keys. A physically present user may
however override the rollback protection manually.
Which says the
Platform Provider (the OEM) could provide you with the ability to load alternate
firmware (potentially, non secure, but loaded securely).
The Gist of all
this is either the OEM provides a platform configured for alternate OSes or
provides a secure firmware update enabling non-secure firmware, you do things
the Microsoft Way or you physically remove, reprogram or substitute and replace
the firmware device(s) on a motherboard. You're dependent on the kindness of
the OEM or the good graces of Microsoft.
Of course, there is no Microsoft
requirement that the firmware be physically incapable of being removed and
replaced..., a socket or little daughtercard would do nicely.
In any event
dual boot is dead without passing through a user interface to firmware.
[ Reply to This | Parent | # ]
|
