On Wed, Aug 03, 2022 at 05:29:15PM +0100, Daniel P. Berrangé wrote:
> On Wed, Aug 03, 2022 at 06:15:24PM +0200, Andrea Bolognani wrote:
> > <os firmware='efi'>
> > <firmware>
> > + <feature enabled='yes' name='secure-boot'/>
> > <feature enabled='no' name='enrolled-keys'/>
> > </firmware>
> > </os>
>
> If we want secureboot disabled, this looks wrong. It just enables
> secureboot, but without any keys. We need enabled=no to ask for
> a firmware without SecureBoot at all.
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
