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:
1. 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 will put the system into
setup mode.
2. If the user ends up deleting the PK then, upon exiting the
Custom Mode firmware setup, the system will be operating in
Setup Mode with SecureBoot turned off.
3. 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.
PK is the "platform key". It is the key used by the firmware to identify the platform owner, and is used by the platform owner to enroll the "key exchange key" (KEK). The KEK is used for the firmware and the operating system to establish a secure channel. DB is the database of authorized signatures and certificates. DBX is the database of banned signatures and certificates.
UEFI has two modes, "User Mode" and "Setup Mode". It is in User Mode when there is a PK enrolled, and in that mode the secure boot policy is enforced. When in Setup Mode, no secure boot policy is enforced, and PK, KEK, DB, and DBX are writeable without any authentication required.
In other words, in Setup Mode, you can put your own set of signatures and certificates in. You should be able to even put Microsoft's certificates and signatures in DBX and thus prevent people from installing Windows on your box. (Or, more practically, put Microsoft's keys in DB along with yours, so you can dual boot).
Also:
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.
The relevant parts for this discussion are:
PK is the "platform key". It is the key used by the firmware to identify the platform owner, and is used by the platform owner to enroll the "key exchange key" (KEK). The KEK is used for the firmware and the operating system to establish a secure channel. DB is the database of authorized signatures and certificates. DBX is the database of banned signatures and certificates.UEFI has two modes, "User Mode" and "Setup Mode". It is in User Mode when there is a PK enrolled, and in that mode the secure boot policy is enforced. When in Setup Mode, no secure boot policy is enforced, and PK, KEK, DB, and DBX are writeable without any authentication required.
In other words, in Setup Mode, you can put your own set of signatures and certificates in. You should be able to even put Microsoft's certificates and signatures in DBX and thus prevent people from installing Windows on your box. (Or, more practically, put Microsoft's keys in DB along with yours, so you can dual boot).
Also: