On Mon, Jun 24, 2019 at 05:14:23PM +0200, Laszlo Ersek wrote:
> On 06/24/19 16:53, Laszlo Ersek wrote:
> > (+Daniel)
> >
> > On 06/20/19 14:21, Philippe Mathieu-Daudé wrote:
>
> >> $ qemu-system-x86_64 \
> >> --object edk2_crypto,id=https,\
> >> ciphers=/etc/crypto-policies/back-ends/openssl.config,\
> >> cacerts=/etc/pki/ca-trust/extracted/edk2/cacerts.bin
>
> (12) Regarding the command line. It just occurs to me that Daniel
> suggested [*] that libvirt should not be taught about this feature
> specifically.
Oh yes, thank you for reminding me of this point.
Essentially this is the same use case as with the GNUTLS default crypto
policy in QEMU.
The tls-creds-x409 object type in QEMU has a "priority" property which
lets you set a GNUTLS priority string eg
--object tls-creds-x509,id=tls0,priority=@SYSTEM
In practice, however, libvirt never uses this because the QEMU configure
script has a --tls-priority arg and distros will use that arg to set the
desired priority at build time. eg Fedora/RHEL build QEMU with the
"--tls-priority=@QEMU,SYSTEM" string and libvirt hasn't bothered to
make use of the 'priority' arg for tls-creds-x509 as a result.
I'd expect similar to be done with EDK2 priority where Fedora/RHEL sets
a compile time ciphers/cacerts list in RPM build.
Contrary to what we did with GNUTLS though, libvirt might still allow
this to be overridden at runtime, since the handling of the ciphers
is not as smart as we get with GNUTLS priority setting.
> Thus, I think we need properties that are "smarter" than plain
> user-specified strings:
>
> - they should have default values (the ones your example includes above)
>
> - for each of the properties: if the default pathname fails to identify
> a file, then treat it as a normal situation (leave the corresponding
> fields NULL)
>
> - if the user overrides the default, and the pathname resolution fails,
> then that should generate an error
>
> - the user should be permitted to override the default such that the
> corresponding setting is disabled (i.e. no error, but also no loading)
>
>
> It's too bad that I'm not sure about the right way to implement this. It
> reminds me of On/Off/Auto, but only vaguely.
>
> In fact, if we never want to teach libvirt about this feature, then we
> essentially expect QEMU to auto-load these files, whenever they exist --
> even if the guest ends up booting something other than edk2 firmware!
>
> [*] https://bugzilla.redhat.com/show_bug.cgi?id=1536624#c11 --
> unfortunately, this is a private RHBZ :(
>
> Thanks
> Laszlo
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
