Reporting Issues
Bug 2923 - Selecting the Secure Boot Mode = "Custom Mode" is never saved
Summary: Selecting the Secure Boot Mode = "Custom Mode" is never saved
Status: RESOLVED INVALID
Alias: None
Product: EDK2
Classification: Unclassified
Component: Code (show other bugs)
Version: Current
Hardware: All All
: Lowest normal
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-23 04:42 UTC by Daniel Black
Modified: 2020-08-26 21:03 UTC (History)
2 users (show)

See Also:
EDK II Code First industry standard specifications: ---
Branch URL:
Release(s) the issue is observed:
The OS the target platform is running: ---
Package: OvmfPkg
Release(s) the issues must be fixed:
Tianocore documents:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Black 2020-08-23 04:42:36 UTC
Compiled master 5a6d764e1d073d28e8f398289ccb5592bf9a72ba SECURE_BOOT_ENABLE=TRUE

Followed these steps https://bugzilla.redhat.com/show_bug.cgi?id=1871403 to attempt to set a Custom Mode and still fails to save in the latest version.

Due to #2922 I didn't get a fw where "Attempt Secure Boot" could actually be enabled (was greyed out).
Comment 1 Laszlo Ersek 2020-08-24 13:24:16 UTC
repeating my comment
<https://bugzilla.redhat.com/show_bug.cgi?id=1871403#c2> here:

"Custom Mode" is not defined in the UEFI specification, it is an
edk2-specific Secure Boot operational mode.

"Custom Mode" means that updates to the PK, KEK, db, and dbx
authenticated UEFI variables are not verified.

Therefore, you certainly do *not* want to boot a guest operating system
in "Custom Mode" (as long as you care for Secure Boot at all, that is,
with that particular guest OS). Because in "Custom Mode", the guest OS
could trivially replace the certificates and hashes that control Secure
Boot.

"Custom Mode" is therefore a shortcut for a "trusted agent" to enroll
PK, KEK, db, dbx, without being subject to verification against existent
PK, KEK, etc contents.

Thus, "Custom Mode" is temporary. Once you have your certificates
enrolled, the SB operational mode flips back to "Standard Mode" --
meaning that *further* updates against those authenticated UEFI
variables will be verified (as they should).


The visual form on which you manipulate these settings in the Setup TUI
is implemented in edk2 by the
"SecurityPkg/VariableAuthenticated/SecureBootConfigDxe" driver. In
"SecureBootConfigImpl.c", function SecureBootCallback(), which is sort
of the "user action handler" for the form
(EFI_HII_ACCESS_FORM_CALLBACK), we have the following snippet:

>|   } else if (Action == EFI_BROWSER_ACTION_FORM_CLOSE) {
>|     //
>|     // Force the platform back to Standard Mode once user leave the setup screen.
>|     //
>|     GetVariable2 (EFI_CUSTOM_MODE_NAME, &gEfiCustomModeEnableGuid, (VOID**)&SecureBootMode, NULL);
>|     if (NULL != SecureBootMode && *SecureBootMode == CUSTOM_SECURE_BOOT_MODE) {
>|       IfrNvData->SecureBootMode = STANDARD_SECURE_BOOT_MODE;
>|       SetSecureBootMode(STANDARD_SECURE_BOOT_MODE);
>|     }

(This comes from historical commit f71ed839e1b5, dated 2013-01-09, which
says "Set the secure boot state to Standard Mode when user leaving
secure boot setup page".)

Another example, from "OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c":

>|   //
>|   // Enter Custom Mode so we can enroll PK, KEK, db, and dbx without signature
>|   // checks on those variable writes.
>|   //
>| ...
>|   //
>|   // Leave Custom Mode, so that updates to PK, KEK, db, and dbx require valid
>|   // signatures.
>|   //
>| ...

So the behavior you are seeing is by design -- "Custom Mode" is not a
permanent setting, but a temporary mode for agents such as
SecureBootConfigDxe, and OVMF's "EnrollDefaultKeys.efi".


At the end of "EnrollDefaultKeys/EnrollDefaultKeys.c", there is a
"diagram" which attempts to organize the SB-related "control variables"
into a tree:

>|   //                                 [SetupMode]
>|   //                        (read-only, standardized by UEFI)
>|   //                                /                \_
>|   //                               0               1, default
>|   //                              /                    \_
>|   //                      PK enrolled                   no PK enrolled yet,
>|   //              (this is called "User Mode")          PK enrollment possible
>|   //                             |
>|   //                             |
>|   //                     [SecureBootEnable]
>|   //         (read-write, edk2-specific, boot service only)
>|   //                /                           \_
>|   //               0                         1, default
>|   //              /                               \_
>|   //       [SecureBoot]=0                     [SecureBoot]=1
>|   // (read-only, standardized by UEFI)  (read-only, standardized by UEFI)
>|   //     images are not verified         images are verified, platform is
>|   //                                      operating in Secure Boot mode
>|   //                                                 |
>|   //                                                 |
>|   //                                           [CustomMode]
>|   //                          (read-write, edk2-specific, boot service only)
>|   //                                /                           \_
>|   //                          0, default                         1
>|   //                              /                               \_
>|   //                      PK, KEK, db, dbx                PK, KEK, db, dbx
>|   //                    updates are verified          updates are not verified

"Standard mode" is just a symbolic name for CustomMode=0.

This upstream tracker does not have a NOTABUG resolution, so I'm closing
this ticket as INVALID. Please reopen it if you encounter further
issues. Thanks!
Comment 2 Daniel Black 2020-08-26 21:03:28 UTC
Thanks for the detailed explanation.