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

[Jason A. Donenfeld]

Hi Bernhard,

On Tue, Apr 19, 2022 at 10:31 AM Bernhard Reutner-Fischer
<rep.dot.nop at gmail.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.

This isn't really considered an issue anywhere at all. If /dev/urandom
is aliased to /dev/zero, there's a major API configuration issue.
devtmpfs even populates it. If you're actually concerned, I can fstat
the chardev to verify. But no other code anywhere ever does this. And
it will just bloat the binary size. If you still think this is a
problem, please point to a security analysis from anywhere at all
other than your mind that's at all similar to this.

> If we want a robust implementation then IMO we'd need to bite the

I think your concerns about the chardev being wrong is bogus actually.
Besides, if /dev/[u]random is /dev/zero, writing into it won't credit
anything. If it's changed in between opens, then the permissions on
/dev are wrong, and a local attacker can easily escalate to root.
Again: show me some real security analysis here if I'm to take this
seriously.

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

Why manually inline that? It just increases code size. The compiler does better.

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

I'll send one last patch, but I must say: I'm finding your pedentry
here to be increasingly unimpressive in terms of what it's yielding.
Anyway, I'll golf this for another round and we'll see how small it
gets.

Jason