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

[Bernhard Reutner-Fischer]

On Tue, 12 Apr 2022 21:07:36 +0200
"Jason A. Donenfeld" <Jason at zx2c4.com> wrote:

> Hi Bernhard,
> 
> On Tue, Apr 12, 2022 at 8:37 PM Bernhard Reutner-Fischer
> <rep.dot.nop at gmail.com> wrote:
> >
> > Hi Jason!
> > I'm a bit surprised that even if i give -n the seed is moved to
> > seed.credit. The next boot/run will find the now creditable seed and
> > happily add it, IIUC, despite i wanted it to not be credited?
> > Is this intentional?  
> 
> Yes. You misunderstand the purpose of the utility. It creates a
> creditable seed when the kernel is able to produce safe random
> numbers. In that case, the creditability or non-creditability of the
> previous seed does not matter.

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.]

> >
> > PPS: I'm attaching some fiddle on top of your v8 which would give a
> > relative savings of  
> 
> I'm not _super_ comfortable with all of these, and I don't know if I
> feel good about attaching them to the original commit. At this

Sure.

If we want a robust implementation then IMO we'd need to bite the
bullet and trade some size penalty for an implementation that works
reliably.
The bar for x86_64 with gcc-12 and aforementioned additional fiddle was
circa
$ size util-linux/seedrng.o*
   text	   data	    bss	    dec	    hex	filename
   1658	      0	      0	   1658	    67a	util-linux/seedrng.o

I guess we should get away with an estimated additional 150 bytes of
robustification, maybe even a tiny bit less than that.

> late-stage of golfing, we really risk introducing excessively brittle
> code and bringing along new bugs with it. These additional strokes
> need to be considered very carefully and individually. So I think at
> this point, I'm done on the green, and I think what you ought to do is
> commit my v8, and then send your patches as a series, and I'll take
> the time to look very carefully at each one individually and comment
> on them. And by keeping those as separate commits, if we both do miss
> something, it'll be easier to revert and for others to notice the
> error too. Does that plan sound okay to you? Commit v8, and then tee
> off a new golfing series?

I think that we want to manually inline seed_from_file_if_exists anyway.
And that loop was about the only ugly thing, from a cosmetic POV.

Care to send an updated patch? Feel free to incorporate any of the
additional size-tweaks as you see fit.

thanks and cheers,