Bug 2112154

Hello Emma:

Here I can successfully disable secure boot. My cmd is:

# virt-install  \
-l http://download.eng.pek2.redhat.com/rhel-8/composes/RHEL-8/RHEL-8.7.0-20220727.0/compose/BaseOS/x86_64/os/    \
--boot loader=/usr/share/edk2/ovmf/OVMF_VARS.fd,loader.readonly=yes,loader.type=pflash,nvram.template=/usr/share/edk2/ovmf/OVMF_VARS.fd,loader_secure=no

Can this meet your requirement?

Also, I think we need double check with @jjongsma. Jonathon, Can you help check the description, to see if is a bug or not? Thanks.

See reply from Andrea on upstream mailing list: https://listman.redhat.com/archives/virt-tools-list/2022-August/017613.html

Does this help?

Thanks Jonathon, Now I am able to disable secure boot.

Here is my cmd:

# virt-install  -l http://download.eng.pek2.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.1.0-20220802.1/compose/BaseOS/x86_64/os/  --boot uefi,firmware.feature0.name=enrolled-keys,firmware.feature0.enabled=no

The equivalent XML snippet is:

...
<os>
    <type arch='x86_64' machine='pc-q35-rhel9.0.0'>hvm</type>
    <firmware>
      <feature enabled='no' name='enrolled-keys'/>
      <feature enabled='yes' name='secure-boot'/>
    </firmware>
    <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.cc.fd</loader>
    <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.fd'>/var/lib/libvirt/qemu/nvram/rhel9-3_VARS.fd</nvram>
...
</os>

After the installation finished, login to the guest and check with mokutil

# mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode

@xiawu Hello, Can this method works for you?

Based on my experiences, In way[1], if you run the cmd below in your uefi guest, it will say "secure boot disabled"
# mokutil --sb-state

But in way[2], the out put will be "secure boot not supported"

So, you might be right. I also think we better use the way[1] to disable secboot unless the user never want use secure boot. I think maybe we can rewrite the description for how to disable secure boot on https://libvirt.org/kbase/secureboot.html, point out that way[1] is to disable secure boot but supports, so we can enable it when we need. way[2] means secure boot is not supported.

How do you think?

(In reply to Hongzhou Liu from comment #9)
> Based on my experiences, In way[1], if you run the cmd below in your uefi
> guest, it will say "secure boot disabled"
> # mokutil --sb-state
> 
> But in way[2], the out put will be "secure boot not supported"

Yes, you are right. Thanks.

> 
> So, you might be right. I also think we better use the way[1] to disable
> secboot unless the user never want use secure boot. I think maybe we can
> rewrite the description for how to disable secure boot on
> https://libvirt.org/kbase/secureboot.html, point out that way[1] is to
> disable secure boot but supports, so we can enable it when we need. way[2]
> means secure boot is not supported.
> 
> How do you think?

I agree with you, and I found the information you mentioned has been added to https://libvirt.org/kbase/secureboot.html.

Please refer to "Additional information" paragraph. Thanks.

(In reply to Xueqiang Wei from comment #8)
> In way [2], I found using the OVMF_CODE.cc.fd instead of the general purpose
> one (OVMF_CODE.secboot.fd) in the XML snippet.
> OVMF_CODE.cc.fd build intended for Confidential Computing, used for SEV(ES)
> non-measured boot in features amd-sev and amd-sev-es.
> 
> According to my understanding, OVMF_CODE.secboot.fd has secure boot support,
> so it's used in way[1].
> OVMF_CODE.cc.fd doesn't have secure boot support, so it's used in way[2]. Am
> I right? Thanks.

It's a bit complicated :)

libvirt discovers firmware through JSON description files installed
into /usr/share/qemu/firmware. On Fedora 36, the edk2-ovmf package
contains the following firmware description files:

  40-edk2-ovmf-sb.json
  50-edk2-ovmf-amdsev.json
  50-edk2-ovmf-cc.json
  50-edk2-ovmf-inteltdx.json
  50-edk2-ovmf.json
  60-edk2-ovmf-microvm.json
  60-edk2-ovmf-nosb.json

The RHEL 9 version should be roughly equivalent.

The alphabetical order is meaningful: files that sort earlier are
considered to have higher priority than those that sort later, with
everything else being equal.

When asking for

  <os firmware='efi'>
    <firmware>
      <feature enabled='no' name='secure-boot'/>
    </firmware>
  </os>

you're saying that you want a firmware that doesn't implement the
secure-boot feature. The contents of 50-edk2-ovmf-cc.json match this
requirement, and so it get picked instead of 60-edk2-ovmf-nosb.json,
which has lower priority.

I believe that the current sorting is suboptimal, and we should have
something like

  40-edk2-ovmf-sb.json
  50-edk2-ovmf.json
  60-edk2-ovmf-nosb.json
  70-edk2-ovmf-cc.json
  70-edk2-ovmf-amdsev.json
  70-edk2-ovmf-inteltdx.json
  70-edk2-ovmf-microvm.json

instead, that is, general purpose firmware images are preferred to
ones that are intended for specific purposes. I have been meaning to
look into addressing this in Fedora and RHEL, but haven't found the
time yet :)

The alternative configuration

  <os firmware='efi'>
    <firmware>
      <feature enabled='yes' name='secure-boot'/>
      <feature enabled='no' name='enrolled-keys'/>
    </firmware>
  </os>

does what you'd expect, because it picks a general purpose build of
edk2 due to the secure-boot feature being enabled, and an empty nvram
template due to the enrolled-keys feature being disabled.

> And according to man page of virt-install (--boot related snippets), I think
> we'd better use way[1] and specify "--boot loader" in command lines to
> disable secure boot when testing other features except amd-sev(es), because
> OVMF_CODE.cc.fd is used for SEV(ES), we are not sure whether it will be
> modified in the future. What's your opinion? Thanks.
> 
> the command lines:
> --boot
> uefi,firmware.feature0.name=enrolled-keys,firmware.feature0.enabled=no,
> firmware.feature1.name=secure-boot,firmware.feature1.enabled=yes \
> --boot
> loader=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd,loader.readonly=yes,loader.
> type=pflash,nvram.template=/usr/share/edk2/ovmf/OVMF_VARS.fd,
> loader_secure=no \

As of libvirt 8.6.0, this configuration will be rejected.

The idea behind feature-based firmware autoselection is that users
shouldn't have to care about implementation details such as where the
various files are located, and should instead be able to just ask for
a certain set of features to (not) be present.

In the past, this distinction was not strictly enforced, but now it
is, and so attempting to use feature-based firmware autoselection
while at the same time providing paths to specific firmware files
will result in an error.

> --boot snippet in man page:
> 
> ......
> --boot uefi
> --boot 
> loader=/.../OVMF_CODE.fd,loader.readonly=yes,loader.type=pflash,nvram.tem‐
>        plate=/.../OVMF_VARS.fd,loader_secure=no
> ......

The virt-install documentation should probably be updated to reflect
the current best practices for enabling / disabling secure boot, as
documented in

  https://libvirt.org/kbase/secureboot.html

(In reply to Hongzhou Liu from comment #9)
> Based on my experiences, In way[1], if you run the cmd below in your uefi
> guest, it will say "secure boot disabled"
> # mokutil --sb-state
> 
> But in way[2], the out put will be "secure boot not supported"
> 
> So, you might be right. I also think we better use the way[1] to disable
> secboot unless the user never want use secure boot. I think maybe we can
> rewrite the description for how to disable secure boot on
> https://libvirt.org/kbase/secureboot.html, point out that way[1] is to
> disable secure boot but supports, so we can enable it when we need. way[2]
> means secure boot is not supported.
> 
> How do you think?

Generally speaking, even if you've configured your VM to use a
firmware that contains Secure Boot support, you can't simply flip
its status on and off the same way you'd do on a physical machine.

Changing from one to the other requires changing the contents of the
NVRAM file in non-trivial ways. As documented in

  https://libvirt.org/kbase/secureboot.html#changing-an-existing-vm

your best bet is likely changing the configuration to its desired
state and asking for the NVRAM to be regenerated from the appropriate
template the next time the VM is booted.

So, other than perhaps changing the manpage for virt-install to describe how to accomplish this more clearly, is there anything else that needs to happen for this bug?

(In reply to Jonathon Jongsma from comment #13)
> So, other than perhaps changing the manpage for virt-install to describe how
> to accomplish this more clearly, is there anything else that needs to happen
> for this bug?

I think that will be enough, maybe just put this link under the --boot part https://libvirt.org/kbase/secureboot.html , Thanks.

(In reply to Andrea Bolognani from comment #12)

> Generally speaking, even if you've configured your VM to use a
> firmware that contains Secure Boot support, you can't simply flip
> its status on and off the same way you'd do on a physical machine.
> 
> Changing from one to the other requires changing the contents of the
> NVRAM file in non-trivial ways. As documented in
> 
>   https://libvirt.org/kbase/secureboot.html#changing-an-existing-vm
> 
> your best bet is likely changing the configuration to its desired
> state and asking for the NVRAM to be regenerated from the appropriate
> template the next time the VM is booted.

This might change with Gerd's virt-firmware tool, which may be able to modify non-volatile UEFI variables (for offline domains) from the host side.

Consider the following "dependency graph" of UEFI variables, controlling various aspects of Secure Boot:

                                [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, Microsoft-specific, boot service only)
                                  /                                \
                            0, default                              1
                                /                                    \
                        KEK, DB, DBX updates               KEK, DB, DBX updates
                         are verified                       are not verified


If you have Secure Boot (the operational mode) "up and running", and want to disable it temporarily (without un-enrolling keys etc), you only need to toggle "SecureBootEnable". This could be doable with Gerd's virt-firmware tool.

> If you have Secure Boot (the operational mode) "up and running", and want to
> disable it temporarily (without un-enrolling keys etc), you only need to
> toggle "SecureBootEnable". This could be doable with Gerd's virt-firmware
> tool.

virt-fw-vars \
  --input /var/lib/libvirt/qemu/nvram/${guest}_VARS.fd \
  --output /var/lib/libvirt/qemu/nvram/${guest}_VARS.fd \
  --set-false SecureBootEnable

There is a --set-true too in case you've changed your mind ;)

<ad>

It is also possible to generate a new varstore from the template

virt-fw-vars \
  --input /usr/share/edk2/ovmf/OVMF_VARS.fd \
  --output /var/lib/libvirt/qemu/nvram/${guest}_VARS.fd \
  --enroll-redhat --secure-boot

(this is how OVMF_VARS.secboot.fd is generated on fedora btw).

If you wanna play with some more interesting secure boot cases
try this:

virt-fw-vars \
  --input /usr/share/edk2/ovmf/OVMF_VARS.fd \
  --output /var/lib/libvirt/qemu/nvram/${guest}_VARS.fd \
  --enroll-redhat --secure-boot \
  --no-microsoft \
  --distro-keys rhel \
  --append-boot-filepath /EFI/redhat/shimx64-redhat.efi

</ad>

enjoy!

Keeping this open for eventual man page (other doc) adjustments.

upstream PR: https://github.com/virt-manager/virt-manager/pull/484

See also

  https://github.com/virt-manager/virt-manager/pull/467

which I have created a few weeks ago.

Unfortunately at the time I have failed to update Bug 2112154 with
the information, and only linked to the PR in Bug 2149971, leading to
this duplication of effort :( Sorry!

Looking at both side by side, I think I like my version better O:-)

But the idea of linking to the libvirt kbase article for Secure Boot
is a good one, so I might just steal it ;)

Jonathon, how do you think we should proceed?

Oops, I clearly should have looked more carefully first. I prefer yours as well. I'll cancel my PR.

*** Bug 2149971 has been marked as a duplicate of this bug. ***

Patches merged upstream.

  commit 33ff193ee9fcfdb74f95d946a1b93239a1a12a61
  Author: Andrea Bolognani <abologna>
  Date:   Mon Dec 12 19:38:22 2022 +0100

    virt-install: Document Secure Boot setups
    
    Provide ready to use recipes for explicitly enabling and
    explicitly disabling Secure Boot, as well as a pointer to
    the more extensive information found on the libvirt website.
    
    Setting loader_secure=yes is only one part of a proper Secure
    Boot setup, so stop documenting it in the section about manual
    firmware selection to avoid confusion.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=2112154
    https://bugzilla.redhat.com/show_bug.cgi?id=2149971
    
    Signed-off-by: Andrea Bolognani <abologna>

  v4.1.0-32-g33ff193e

https://gitlab.com/redhat/centos-stream/src/virt-manager/-/merge_requests/11

Verify this bug with virt-install-4.1.0-4.el9.noarch
For virt-install man page the description for boot secure part now is:

       --boot uefi,firmware.feature0.name=secure-boot,firmware.feature0.en‐abled=yes,
              firmware.feature1.name=enrolled-keys,firmware.feature1.enabled=yes
              Configure the VM to boot from UEFI  with  Secure  Boot  support  enabled.
              Only  signed  operating systems will be able to boot with this configura‐
              tion.

       --boot uefi,firmware.feature0.name=secure-boot,firmware.feature0.enabled=no
              Configure the VM to boot from UEFI with  Secure  Boot  support  disabled.
              This  configuration  allows both signed and unsigned operating systems to
              run.

              Additional information about the secure-boot and  enrolled-keys  firmware
              features  and  how  they  can  be used to influence firmware selection is
              available at https://libvirt.org/kbase/secureboot.html

       --boot                                     loader=/.../OVMF_CODE.fd,loader.read‐
          only=yes,loader.type=pflash,nvram.template=/.../OVMF_VARS.fd,loader_secure=no
              Specify  that  the  virtual  machine  use  the custom OVMF binary as boot
              firmware, mapped as a virtual flash chip. In addition, request that  lib‐
              virt   instantiate   the   VM-specific  UEFI  varstore  from  the  custom
              "/.../OVMF_VARS.fd" varstore template. This setup is not recommended, and
              should only be used if --boot uefi doesn't know about your UEFI binaries.

       Use  --boot=?  to  see a list of all available sub options.  Complete details at
       https://libvirt.org/formatdomain.html#elementsOS

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt-manager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2255

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days