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

[Andrea Bolognani]

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