[PATCH] urandom-seed: use seedrng for seeding the random number generator

[Etienne Champetier]

Hey Jason,

Le lun. 28 mars 2022 à 13:04, Jason A. Donenfeld <Jason at zx2c4.com> a écrit :
>
> Hey Etienne,
>
> On Mon, Mar 28, 2022 at 10:19 AM Etienne Champetier
> <champetier.etienne at gmail.com> wrote:
> >
> > Hi All, Jason,
> >
> > @Petr Štetiar this merge was a bit too fast to get reviews ...
> > Some comments inline
>
> We can apply fixups on top, no big deal.
>
> > When urandom-seed was introduced in 2016 it was decided during review
> > that writing on each boot might cause too much wear to the flash.
> > Maybe we can say that 6 years later this is not a problem anymore, but
> > would love to have more devs comment
> > Old thread: https://www.mail-archive.com/lede-dev@lists.infradead.org/msg01225.html
> >
> > Now if I understand correctly, with this patch we are writing a seed
> > to flash twice per boot, in preinit/81_urandom_seed and in
> > init.d/urandom_seed.
> > Also there are good chances we will never have a seed.credit at all on
> > many devices,
> > would be great if seedrng had an option "writeseed" that blocks on getrandom().
>
> Oh that's an interesting set of considerations and it's possible I
> didn't understand some aspect of this. Most OSes should call seedrng
> once at boot and once at shutdown.

As routers are always on devices, it's rare to have clean shutdown.
Personally, my routers boot after an upgrade or after a power loss,
so they almost never shutdown properly.

> It's also fine to call seedrng at
> any other specific time during runtime too. Because it's involved with
> crediting, it always always removes the seed file after reading but
> before using, and after it's used, it immediately writes a new seed
> file.
>
> It sounds like what you might want here is, perhaps, the original
> behavior? Namely, the seed is never credited, but it never changes
> either? That won't help you initialize the RNG, but since you're not
> crediting it, you can argue that all new rng inputs are good inputs,
> even if they've been used before.
>
> So these are the two schemes to choose from:
>
> 1) read seed into memory, delete seed from disk, write into rng &
> credit if good seed, write new seed to disk; repeat at shutdown/some
> other time
> 2) read seed into memory, write into rng w/o crediting, re-use the
> same seed next boot

Before this patch we had 2 and users could opt-in to renew seed on
each boot, so closer to 1.

> If the second scheme is what you prefer, then your original bug report
> suggesting this was an issue for OpenWRT might not really be so, and
> we can just go back to what we were doing before. OTOH, if you want to
> have a good mechanism that actually initializes the RNG, perhaps we
> can move forward with some tweaks to seedrng.

Looking at random.c, I would love add_device_randomness() behavior.
Maybe it was already answered on LKML,
but why can't writes to /dev/urandom from a process with CAP_SYS_ADMIN
be mixed in right away a la add_device_randomness() without being credited ?
This would not init the RNG faster, but this would make early
/dev/urandom reads "safer".

I'm fine with writing on each boot, but as we can't rely on shutdown,
what we could do with the seeds:
1) load seed.no-credit, leave it on disk
2) mv seed.credit seed.no-credit && load seed.no-credit (and credit it)
3) read from getrandom a new seed.credit

This would allow to always keep a seed on disk, only use seed.credit once,
and actually write seed.credit.
I would get rid of the whole hashing part as all our seeds would come
from getrandom().

> > > +
> > > +#define SEED_DIR "/etc/seedrng"
> >
> > If we worry about seed reuse, we should not use /etc as it can be
> > restored from a backup
>
> Indeed you're right. Most other distros use /var/lib/seedrng; is
> /var/lib available on OpenWRT?

/var is a symlink to /tmp

> Is there a different place for it that would be good?

Maybe we can leave it in etc and just make sure to exclude it from backups

Etienne

>
> Jason