RFE: virt-install should add secure-boot convenience options

[andreabolognani]

Right now, enabling and disabling Secure Boot requires fairly unwieldy incantations such as --boot uefi,firmware.feature0.name=secure-boot,firmware.feature0.enabled=yes,firmware.feature1.name=enrolled-keys,firmware.feature1.enabled=yes.

It would be great if virt-install implemented more user-friendly shorthands for that, such as --boot uefi,firmware.secure-boot=yes.

Where things get hairy is that you have two ways to disable Secure Boot: get libvirt to pick either a firmware that contains the feature but doesn't have certificates enrolled, or one where the feature is absent altogether. Depending on the firmware shipped with your distro, you might want one or the other. So maybe a sort of tristate would be more fitting, with the accepted option being enabled, disabled and absent.

Ideally this would also be wired up in the GUI: firmware type (UEFI/BIOS) is already one of the choices that you're presented with, and having one more knob for the UEFI case doesn't seem unreasonable.

Another idea that's floating around is the possibility of enrolling specific Secure Boot certificates at VM creation time. That could be handled by a second key, along the lines of secure-boot-enroll=microsoft, secure-boot-enroll=redhat, secure-boot-enroll=path/to/custom/certs. Probably too specialized to be exposed via the GUI.

[andreabolognani]

It could also be useful to have an option in virt-xml that can be used to flip the status of Secure Boot after the VM has been installed.

[crobinso]

@andreabolognani so I just took a look at this, but fedora x86 doesn't seem to ship any non-secureboot ovmf builds? So trying to toggle secureboot off via the features XML just throws errors: Unable to find 'efi' firmware that is compatible with the current configuration Failed.

Not necessarily a blocker to adding convenience options to virt-install, but makes me wonder if world has changed since this was filed and toggling secureboot off is now less practical...

Another case that this would be useful is for toggling on the firmware.json verbose-static feature to get debug output out of aarch64 boots, but it doesn't look like libvirt supports that in the feature list?

[phrdina]

@crobinso That is strange. On my Fedora 40 package edk2-ovmf-20240813-2.fc40.noarch provides /usr/share/qemu/firmware/50-edk2-ovmf-4m-qcow2-x64-nosb.json that describes OVMF without SB+SMM and points to /usr/share/edk2/ovmf/OVMF_CODE_4M.qcow2 firmware.

I also managed to get a working VM using:

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

[andreabolognani]

Yup, what Pavel reports matches my expectations. Is it possible that you have messed with the contents of your /usr/share/qemu/firmware/ directory for testing purpose? That has happened to me several times O:-)

I agree that it would be nice to make it possible for the user to pick a verbose build. We probably want to have a verbose feature at the libvirt level, and match it to either verbose-dynamic (x86) or verbose-static (aarch64) in the firmware descriptor.

[crobinso]

Ah ok I have it working now. I was trying to edit an existing VM and just toggle those values 'off', which indeed doesn't work. But it works when you also clear <nvram> and <loader> sections at least

[andreabolognani]

Right, updating the configuration only partially can't work because in that case libvirt will try to find a firmware that satisfies the requested features (Secure Boot disabled) but also matches the existing path (Secure Boot enabled).

This fact is documented though maybe it just doesn't have enough visibility.

This raises an interesting question though: should virt-install (or rather virt-xml) have special handling to ensure that setting firmware features resets any existing firmware selection?