Re: Consider looking at SeedRNG for RNG initialization

From: Laurent Bercot <>
Date: Fri, 08 Apr 2022 14:19:43 +0000

>Recently I have come across [1] Jason Donenfeld's SeedRNG [2] which provides
>a correct way of handling RNG initialization/seeding in early init and shutdown.
>As the code is meant to be reused and handles the process properly,
>I believe it is worth looking into.
>Maybe it could even be the backbone of s6-fillurandompool if adding the
>requirement of using a seed file is acceptable?

  Yes, Jason contacted me about seedrng and since then I've been thinking
about how to best change skalibs' librandom to adapt to the
It demands some redesign work and I still haven't found an interface
that I'm perfectly happy with. randomness has always been a pain point,
because of the amount of non-portable interfaces, and I'm on the third
redesign at this point - hopefully this one will be the last one.

  My problem with yolo adding seedrng to a toolset is precisely that it
is *not* correct for early init, because it relies on /var/lib being
mounted, or at least on a permanent filesystem being writable, which
is not necessarily the case in early init. So basically, seedrng needs
to be a part of a holistically designed init sequence, being called
right after filesystems are mounted; and there needs to be a special
way of getting randomness before that point, using primitives that
don't need the rng to be seeded. seedrng has its place as a part of
a set of policy files for a service manager, not as a floating thing
in the void.

  Another issue I have is that it's a Linux-only problem. The BSDs have
their RNG seeded by the bootloader, so CSPRNG is available to them in
the very early boot. So a portable interface to getting early randomness
should make it transparent for the BSDs, and only enable the special
casing on Linux - or other systems that need to seed the RNG in user

  It's a lot more convoluted than I would like it to be. But yes, Jason
is doing good work, and I'm working on a way to make sure skaware
behaves correctly (and helps distros behave correctly). :)

Received on Fri Apr 08 2022 - 16:19:43 CEST

This archive was generated by hypermail 2.4.0 : Fri Apr 08 2022 - 16:20:12 CEST