Bug 2193004

Summary:	SecureBoot is always enabled for UEFI VMs
Product:	Container Native Virtualization (CNV)	Reporter:	Guohua Ouyang <gouyang>
Component:	Virtualization	Assignee:	Barak <bmordeha>
Status:	CLOSED NOTABUG	QA Contact:	Kedar Bidarkar <kbidarka>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.12.5	CC:	acardace, gouyang, gveitmic, hstastna, jlejosne, sgott
Target Milestone:	---
Target Release:	4.14.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	2181920	Environment:
Last Closed:	2023-07-17 13:08:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2181920
Bug Blocks:

Comment 1 Guohua Ouyang 2023-05-03 23:40:24 UTC

Clone the bug to virt to seek a fix.
Enabling EFI automatically enables Secure Boot(https://kubevirt.io/user-guide/virtual_machines/virtual_hardware/#biosuefi), it can cause confusions as it enables the secure boot implicitly.

From UI, we expect that the secure boot is only enabled when the secureBoot field under efi is set to true, if secureBoot is not defined as the common templates does, it should not represent secure boot enabled.

Comment 2 Jed Lejosne 2023-07-11 19:31:20 UTC

This is by design, as we picked the secure-by-default approach.
Either way, changing the default value now would silently disable a security feature on existing VMs.

Comment 3 Barak 2023-07-12 07:08:01 UTC

> This is by design, as we picked the secure-by-default approach.
> Either way, changing the default value now would silently disable a security feature on existing VMs.

I agree i think that the current behavior is the right one.

Comment 4 Germano Veit Michel 2023-07-12 10:26:21 UTC

In the original bug BZ2181920 (Verified state), it appears the UI was already fixed to properly understand "efi: {}" as secureboot enabled. So discussing the backend change at this point may not be necessary for the user to have a working system.

Comment 5 sgott 2023-07-17 13:08:03 UTC

Closing this based on the last few comments.