Re: [PATCH] crypto/gcrypt: prefer kernel as direct source of entropy

[Daniel P . Berrangé]

On Mon, Jan 22, 2024 at 05:08:16PM -0300, Cristian Rodríguez wrote:
> On Mon, Jan 22, 2024 at 11:48 AM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
> 
> > On Fri, Jan 19, 2024 at 05:39:40PM -0300, Cristian Rodríguez wrote:
> > > gcrypt by default uses an userspace RNG, which cannot know
> > > when it is time to discard/invalidate its buffer
> > > (suspend, resume, vm forks, other corner cases)
> > > as a "when to discard" event is unavailable to userspace.
> >
> > So in this scenario QEMU is impacted when QEMU is running inside
> > another VM. ie the L0 QEMU "forks" the guest, and the L1 QEMU
> > needs to re-init its RNG.
> >
> > > Set GCRYCTL_SET_PREFERRED_RNG_TYPE to GCRY_RNG_TYPE_SYSTEM
> > > which must be done before the first call to gcry_check_version()
> >
> > QEMU is just one out of many applications that use libgcrypt and
> > I see no reason why QEMU should be special cased in this respect.
> >
> > Updating each application to hardcode use of GCRY_RNG_TYPE_SYSTEM
> > does not feel like a good solution. If this was a good default
> > to use everywhere, then gcrypt should have set this default
> > already, rather than requiring every app to solve the forking
> > problem itself.
> >
> 
> this default is because either other OSs had problems or in the past the
> linux rng was not as performant as it is right now,
>  now it outputs 100's of MB per second on a potato.
> 
> Updating every app that uses gcrypt is not really practical
> > in terms of time investment anyway.
> >
> 
> Yeah, it will be pretty time consuming so I have so far only sent a few
> patches for things I consider important.
> 
> >
> > If gcrypt doesn't want to make this its global default, then
> > I would suggest that gcrypt should make its default be
> > configurable. I see from its docs:
> >
> >
> > https://gnupg.org/documentation/manuals/gcrypt/Configuration.html#Configuration
> >
> > that it already supports a /etc/gcrypt/random.conf file.
> > Perhaps they would extend that to allow selection of the
> > default RNG backend, system-wide.
> 
> 
> And things will remain problematic by default , because of all the
> obscurity and that FIPS mode overrides
> all defaults you choose anyways, including if I hardcode the preference in
> the source code like I did here.

If the DRBG is required for FIPS compliance, and QEMU hardcoded
the system RNG, then QEMU can't be used in a FIPS environment.
So I still think this question of defaults is something to be
fixed in the gcrypt code centrally, not in individual apps.


With 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 :|