Description of problem: In Virtual Machine -> Details -> Boot Mode, there are these options: 1. BIOS 2. UEFI 3. UEFI (Secure) Note [2] sets the VM as: firmware: bootloader: efi: {} But results in SecureBoot /usr/libexec/qemu-kvm -name guest=openshift-cnv_fedora-y130ab1457eie7uw,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-openshift-cnv_fedora/master-key.aes"} -blockdev {"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"} And [3] sets the VM as: firmware: bootloader: efi: secureBoot: true Which is the same, also SecureBoot enabled: /usr/libexec/qemu-kvm -name guest=openshift-cnv_fedora-y130ab1457eie7uw,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-openshift-cnv_fedora/master-key.aes"} -blockdev {"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"} This means it is always enabling SecureBoot, even if the user sets is to option [2] in the UI. According to https://kubevirt.io/user-guide/virtual_machines/virtual_hardware/#biosuefi ~~~ Enabling EFI automatically enables Secure Boot, unless the secureBoot field under efi is set to false. ~~~ Its a bit odd, as SecureBoot is usually opt-in and not opt-out, maybe the UI also expected that. But because the default is enabled, the UI should: For option [2] firmware: bootloader: efi: secureBoot: false For option [3] firmware: bootloader: efi: secureBoot: true OR firmware: bootloader: efi: {} Version-Release number of selected component (if applicable): OCP 4.12.8 CNV 4.12.1 How reproducible: Always Steps to Reproduce: 1. Set VM to UEFI (not Secure) 2. Boot it 3. Check SecureBoot is enabled
Failed to verify the bug on kubevirt-console-plugin-rhel9-container-v4.14.0-1047 which includes the fix.
Hi Guohua, could you please add some more details about what went wrong when verifying the bug? Thanks.
(In reply to Hilda Stastna from comment #3) > Hi Guohua, > > could you please add some more details about what went wrong when verifying > the bug? Thanks. The issue is still reproduced. Create a VM with Bootmode UEFI, the VM is started with SecureBoot enabled.
Hi, could you please add more details? How exactly were you reproducing the bug? Thanks.
I am attaching the screenshots showing the bug is not reproducible anymore, already fixed.
Note that you have to restart the VM once you change the boot mode, to apply the change successfully.
(In reply to Guohua Ouyang from comment #4) > (In reply to Hilda Stastna from comment #3) > > Hi Guohua, > > > > could you please add some more details about what went wrong when verifying > > the bug? Thanks. > > The issue is still reproduced. Create a VM with Bootmode UEFI, the VM is > started with SecureBoot enabled. The reproduce steps are: 1. create the Fedora VM from catalog 2. the default bootmode of the VM is UEFI 3. check the VM YAML, the bootmode section is firmware: bootloader: efi: {} 4. wait for the VM become running or start it if it's not started yet. 5. the VM is started with SecureBoot enabled However, if open the bootmode modal either in catalog(before VM is created) or in VM details tab (after VM is created) and save it, the value is saved correctly: firmware: bootloader: efi: secureBoot: false So the issue only happens when creating VM from a template which has the UEFI as bootmode.
Thanks for the details, it was very useful. From the info you've provided it seems the bug is in the original YAML of the selected template. I can take a look, but I am not sure if we can influence how the default/Red Hat templates look like.
Hi Guohua, according to the fact we cannot change (and shouldn't) default/Red Hat templates, do you agree on such fix, that I'd update the basic yaml (creates "example" VM Template) the way that secure boot will be disabled plus I'd update the UI the way that it will show "UEFI (secure)" in case that "efi: {}" will be in the YAML. WDYT?
Note that I am not sure if we should change the default template. Maybe not. Anyway, changing the UI to show "UEFI (secure)" for both "efi: {}" and "efi: secureBoot: true" could solve the problem the way that the user would see the correct value corresponding with the yaml, no matter how the templates look like or what is the default value.
(In reply to Hilda Stastna from comment #13) > Note that I am not sure if we should change the default template. Maybe not. > Anyway, changing the UI to show "UEFI (secure)" for both "efi: {}" and "efi: > secureBoot: true" > could solve the problem the way that the user would see the correct value > corresponding with the yaml, > no matter how the templates look like or what is the default value. I meant for both VMs and VM Templates, because the issue is in both places (VM and Template Details > Boot mode).
Maybe we should ask the backend team to fix the issue, not boot the VM with secureBoot when it's "efi: {}", then no changes are needed from templates and UI.
It would be helpful if the backend fixed it the way that only "efi: secureBoot: true" would represent the secure boot enabled. But till they fix it, we need to make a change in the UI anyway, because it doesn't display the values properly in Templates Details. In other words, I found just now that we need to put the rest of the UI to harmony with my previous fix: https://github.com/kubevirt-ui/kubevirt-plugin/pull/1236 This is true till both "efi: {}" and "efi: secureBoot: true" represent the secure boot enabled (and from our experience after we create, boot such VMs with such settings and check boot mode, they do).
I'm fine with this fix as the backend treat `efi: {}` as UEFI secure boot. https://kubevirt.io/user-guide/virtual_machines/virtual_hardware/#biosuefi
Guohua, I think they already do (otherwise this BZ wouldn't exist). The actual problem is that both "efi: secureBoot: true" and "efi: {}" represent secure boot enabled. It would be helpful if the backend fixed it the way that only "efi: secureBoot: true" would represent the secure boot enabled, IMO. Then we wouldn't need 2 PRs I've created to UI.
Verified on kubevirt-console-plugin-rhel9-container-v4.14.0-1283, the UI mark the `efi: {}` as UEFI secure boot.
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 (Important: OpenShift Virtualization 4.14.0 Images security and bug fix 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/RHSA-2023:6817