[libvirt PATCH] kbase: Always explicitly enable secure-boot firmware feature
Andrea Bolognani
abologna at redhat.com
Thu Aug 4 10:03:32 UTC 2022
On Thu, Aug 04, 2022 at 10:29:12AM +0100, Daniel P. Berrangé wrote:
> On Thu, Aug 04, 2022 at 03:32:32AM -0500, Andrea Bolognani wrote:
> > 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.
>
> Yes & no - one allows you to enroll custom keys, the other doesn't
> allow it. For most people that distinction doesn't matter but it is
> a significant difference.
>
> I don't mind documenting both, but we should explain why we are
> illustrating two different mechanisms, as when the question is
> "how to I disable secureboot" an answer saying "secure_boot enabled=yes"
> simply looks wrong.
Right :)
There's an underlying issue with naming, because what most people
would think of when talking about the state of secure boot is,
counterintuitively, not actually controlled by the "secure-boot"
firmware feature. That's the reason why I wrote this kbase in the
first place: if the XML mechanism matched people's intuition, it
wouldn't be necessary.
I have tried to explain why there are two firmware features
controlling what is, in most people's mind, a binary knob in the
"additional information" section. I'll attempt to expand upon that
without making it too complicated in v2.
--
Andrea Bolognani / Red Hat / Virtualization
More information about the libvir-list
mailing list