[gnutls-devel] delaying the initialization of random generator

[Jaak Ristioja]

On 31.10.2016 10:31, Nikos Mavrogiannopoulos wrote:
> Hi,
>  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
> issue).
> 
> 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?

I'm no big expert on this issue, but I think that by delaying the
blockage from link-time to application logic one risks blocking in
mission critical application code. In my opinion, it would be better to
let the kernel address it for both physical machines and VMs. I suspect
that sooner or later they will (have to) address this anyway, e.g. by
using paravirtualized RNGs in VMs or, on physical machines allow
initialization of the entropy pool from some hardware RNG, or similar.

Best regards,
Jaak Ristioja