RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2112154 - virt-install an EFI guest with "--boot nvram.template=/usr/share/edk2/ovmf/OVMF_VARS.fd" secureboot is enabled
Summary: virt-install an EFI guest with "--boot nvram.template=/usr/share/edk2/ovmf/OV...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: virt-manager
Version: 9.1
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Jonathon Jongsma
QA Contact: Hongzhou Liu
URL:
Whiteboard:
: 2149971 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-29 01:40 UTC by Emma Wu
Modified: 2023-09-18 04:51 UTC (History)
21 users (show)

Fixed In Version: virt-manager-4.1.0-4.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-09 07:39:17 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-129546 0 None None None 2022-07-29 01:40:57 UTC
Red Hat Product Errata RHBA-2023:2255 0 None None None 2023-05-09 07:39:31 UTC

Comment 1 Hongzhou Liu 2022-07-29 05:07:27 UTC
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.

Comment 3 Jonathon Jongsma 2022-08-03 16:07:54 UTC
See reply from Andrea on upstream mailing list: https://listman.redhat.com/archives/virt-tools-list/2022-August/017613.html

Does this help?

Comment 4 Hongzhou Liu 2022-08-04 02:19:46 UTC
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?

Comment 9 Hongzhou Liu 2022-08-22 02:03:08 UTC
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?

Comment 10 Xueqiang Wei 2022-08-22 12:59:35 UTC
(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.

Comment 11 Andrea Bolognani 2022-08-22 14:14:34 UTC
(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

Comment 12 Andrea Bolognani 2022-08-22 14:22:22 UTC
(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.

Comment 13 Jonathon Jongsma 2022-08-23 21:02:38 UTC
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?

Comment 14 Hongzhou Liu 2022-08-24 01:33:25 UTC
(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.

Comment 18 Laszlo Ersek 2022-08-30 11:26:23 UTC
(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.

Comment 19 Gerd Hoffmann 2022-08-31 08:57:04 UTC
> 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!

Comment 20 Jaroslav Suchanek 2022-09-02 11:37:41 UTC
Keeping this open for eventual man page (other doc) adjustments.

Comment 21 Jonathon Jongsma 2023-01-25 22:25:34 UTC
upstream PR: https://github.com/virt-manager/virt-manager/pull/484

Comment 22 Andrea Bolognani 2023-01-26 14:03:20 UTC
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?

Comment 23 Jonathon Jongsma 2023-01-26 15:50:48 UTC
Oops, I clearly should have looked more carefully first. I prefer yours as well. I'll cancel my PR.

Comment 24 Jonathon Jongsma 2023-01-31 16:04:29 UTC
*** Bug 2149971 has been marked as a duplicate of this bug. ***

Comment 25 Andrea Bolognani 2023-02-09 16:52:39 UTC
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

Comment 31 Hongzhou Liu 2023-02-22 03:04:55 UTC
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

Comment 35 errata-xmlrpc 2023-05-09 07:39:17 UTC
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

Comment 36 Red Hat Bugzilla 2023-09-18 04:43:16 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


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