Re: [libvirt PATCH] kbase: Always explicitly enable secure-boot firmware feature

On Wed, Aug 03, 2022 at 05:29:15PM +0100, Daniel P. Berrangé wrote: Mh. From a practical standpoint, the scenarios * firmware has secure boot support but there are no enrolled keys * firmware doesn't have secure boot support are pretty much equivalent: either way, unsigned code will be allowed to run. And, although that doesn't seem the case anywhere at the moment, I can imagine that at some point a distro will decide to only ship a single firmware build. That would be comparable to how you can't really find a motherboard that doesn't come with secure boot support at this point, and your only choice is whether you want the feature to be active. So I don't disagree with you, but I'm also not completely convinced that we should *not* document a way to disable secure boot while still picking a firmware build that contains the feature. Would squashing the diff below be a good enough compromise in your opinion? diff --git a/docs/kbase/secureboot.rst b/docs/kbase/secureboot.rst index 5fa59ad5e2..68732701df 100644 --- a/docs/kbase/secureboot.rst +++ b/docs/kbase/secureboot.rst @@ -19,7 +19,17 @@ ask for Secure Boot to be enabled with </firmware> </os> -and for it to be disabled with +and for it to be disabled with either + +:: + + <os firmware='efi'> + <firmware> + <feature enabled='no' name='secure-boot'/> + </firmware> + </os> + +or :: @@ -30,8 +40,8 @@ and for it to be disabled with </firmware> </os> -These configuration will cause unsigned guest operating systems to -be rejected and allowed respectively. +The first configuration will cause unsigned guest operating systems +to be rejected, while the remaining two will allow running them. Older libvirt versions -- Andrea Bolognani / Red Hat / Virtualization