+++ This bug was initially created as a clone of Bug #2181920 +++

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

— Additional comment from Germano Veit Michel on 2023-03-27 06:30:34 CST —

No customers, but I'll set this to high and IMHO deserves a backport.
Spent hours to find out why PXE booting was not working.

— Additional comment from Guohua Ouyang on 2023-04-28 12:05:53 CST —

Failed to verify the bug on kubevirt-console-plugin-rhel9-container-v4.14.0-1047 which includes the fix.

— Additional comment from Hilda Stastna on 2023-04-28 17:51:45 CST —

Hi Guohua,

could you please add some more details about what went wrong when verifying the bug? Thanks.

— Additional comment from Guohua Ouyang on 2023-04-28 18:12:38 CST —

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

— Additional comment from Hilda Stastna on 2023-04-29 00:32:14 CST —

Hi,

could you please add more details? How exactly were you reproducing the bug? Thanks.

— Additional comment from Hilda Stastna on 2023-04-29 00:44:50 CST —

I am attaching the screenshots showing the bug is not reproducible anymore, already fixed.

— Additional comment from Hilda Stastna on 2023-04-29 00:48:18 CST —

— Additional comment from Hilda Stastna on 2023-04-29 00:49:38 CST —

— Additional comment from Hilda Stastna on 2023-04-29 00:50:15 CST —

Note that you have to restart the VM once you change the boot mode, to apply the change successfully.

— Additional comment from Guohua Ouyang on 2023-04-29 07:26:45 CST —

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

— Additional comment from Hilda Stastna on 2023-04-29 18:21:31 CST —

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.

— Additional comment from Hilda Stastna on 2023-05-02 19:17:13 CST —

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?

— Additional comment from Hilda Stastna on 2023-05-02 19:57:37 CST —

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.

— Additional comment from Hilda Stastna on 2023-05-02 20:19:16 CST —

(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).

— Additional comment from Guohua Ouyang on 2023-05-02 20:54:45 CST —

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.

— Additional comment from Hilda Stastna on 2023-05-02 21:12:05 CST —

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

— Additional comment from Guohua Ouyang on 2023-05-03 07:30:17 CST —

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

— Additional comment from Hilda Stastna on 2023-05-03 16:39:36 CST —

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.