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é <berra...@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 :|
