[gnutls-devel] delaying the initialization of random generator

Nikos Mavrogiannopoulos n.mavrogiannopoulos at gmail.com
Mon Oct 31 09:31:58 CET 2016

 Since version 3.5.3, gnutls uses the getrandom() system call on the
kernels that it is available, replacing the /dev/urandom based
initialization of the included RNG. However, that comes with few
side-effects. Because getrandom() blocks prior to the linux kernel RNG
being initialized (unlike /dev/urandom), that means that applications
that load early on boot and link with gnutls will be blocked until
that kernel initialization.

This has been already been seen in VMs, on the cases linked by [0]. A
work-around that can be applied to gnutls is delaying the internal RNG
initialization to the first call of gnutls_rnd(). That will allow
applications which do not use the RNG immediately to load faster,
while on the other hand introduces some complexity and does not
address the problem when for example the system is in FIPS140-2 mode
which requires some on-library-load tests which need to call
gnutls_rnd(). -(here I'm also worried about future additions that may
require random numbers on library load and negate any fixes for that

Any opinions on that? The bottom line, is that we cannot completely
solve the blocking issue, but we can improve it on the occasions
mentioned above. Should we try and introduce some complexity, or
should we ignore it and expect the kernel to address it?


[0]. https://gitlab.com/gnutls/gnutls/merge_requests/111

More information about the Gnutls-devel mailing list