Bug 1871403 - OVMF_CODE.secboot.fd cannot set Secure Boot Mode = Custom Mode
Summary: OVMF_CODE.secboot.fd cannot set Secure Boot Mode = Custom Mode
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: edk2
Version: 32
Hardware: x86_64
OS: All
unspecified
medium
Target Milestone: ---
Assignee: Paolo Bonzini
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-23 05:30 UTC by Daniel Black
Modified: 2020-08-24 17:22 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-24 17:22:17 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
virsh xml defination of windows guest using ovmf firmware (9.88 KB, text/plain)
2020-08-23 05:30 UTC, Daniel Black
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1844726 0 unspecified CLOSED viostor causes Windows 10 boot failure if Secure Boot is enabled 2023-10-03 11:30:25 UTC
TianoCore 2921 0 None None None 2020-08-23 05:30:51 UTC
TianoCore 2923 0 None None None 2020-08-23 08:44:29 UTC

Description Daniel Black 2020-08-23 05:30:51 UTC
Created attachment 1712253 [details]
virsh xml defination of windows guest using ovmf firmware

Description of problem:

Cannot set a Custom Secure boot mode and register your own keys.

Version-Release number of selected component (if applicable):

Name         : edk2-ovmf
Version      : 20200201stable
Release      : 1.fc32
Architecture : noarch
Size         : 6.8 M
Source       : edk2-20200201stable-1.fc32.src.rpm

How reproducible:


Steps to Reproduce:
1. create vm (e.g. attached virsh dumpxml defination)
2. cp /usr/share/edk2/ovmf/OVMF_VARS.secboot.fd 
/var/lib/libvirt/qemu/nvram/win2k19_VARS.fd
3. permission fix on copied file
ls -laZ /var/lib/libvirt/qemu/nvram/win2k19_VARS.fd
-rw-------. 1 dan qemu system_u:object_r:svirt_image_t:s0:c596,c1010 131072 Aug 23 14:32 /var/lib/libvirt/qemu/nvram/win2k19_VARS.fd
4. start vm - esc/del to get bios
Select Device Manager -> Secure Boot Configuration -> Secure Boot Mode -> change to "Custom Mode" - F10 - "Y" (Confirm save)
5. escape to go back menu, enter "Secure Boot Configuration" again.


Actual results:

Secure Boot mode is back at "Standard Mode".

Alternate path from 5:

5a Customer Secure Boot Options -> DB Options -> Enroll Signature -> Enroll Signature Using File
6a Select 509 Der certificate (in this case the Red Hat one that I extracted from the virtio-win sys files).
7a Commit Chnages and Exit
8a esc - Back at "Secure Boot Confiugration" where it has reverted to "Secure Boot Mode: Standard Mode" again.

Expected results:

Still on "Custom Mode"

Comment 1 Daniel Black 2020-08-23 08:44:30 UTC
Repeatable behaviour in upstream code as reported:

https://bugzilla.tianocore.org/show_bug.cgi?id=2923

Comment 2 Laszlo Ersek 2020-08-24 17:22:17 UTC
Hello Daniel,

some words about "Custom Mode":

"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.

I'm closing this as NOTABUG now; please reopen it if you encounter
further issues. Thanks!


Note You need to log in before you can comment on or make changes to this bug.