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
