[PATCH v8] seedrng: import SeedRNG utility for kernel RNG seed files

Bernhard Reutner-Fischer rep.dot.nop at gmail.com
Tue Apr 19 09:33:00 UTC 2022


On Tue, 19 Apr 2022 08:48:50 +0000
David Laight <David.Laight at ACULAB.COM> wrote:

> > So to go back to the underlying issue.
> > In v8 we cannot guarantee that we really got a seed from
> > the kernel, let alone trustworthy. It could have been data from about
> > any file, including /dev/zero or other unhelpful, no-random data. I
> > think that adding and crediting a block of 0 is not what we want.
> > 
> > Ignoring interference from other processes with CAP_SYS_ADMIN, to
> > somewhat tighten this up, we'd need to open /dev/random once and do our
> > stuff with this rnd_fd, including an fstat to ensure we are really
> > reading from the random character device 1,8 or chardev 1,9 for
> > urandom. [Can we ioctl on urandom to RNDADDENTROPY to the pool btw? ah
> > yes, we can; only read is different in fops. That's handy and
> > simplifies the flow.]  
> 
> Does any of that matter at all?
> If anything can change what the startup script/program does then they
> can do something completely different instead.

I was not refering to the startup scripts but to the possibility that
we read data from the path /dev/random, close the fd and only later
open it again for issuing the ioctl. The first read could easily hit a
file with e.g. c 1 5, i.e. zero to inject non-random data into the pool.
This would be avoided if we'd open random only once (and even ensure it
really is the random chardev) and issue the ioctl on this very fd.

It's a question of QOI.

thanks,


More information about the busybox mailing list