[PATCH v2] seedrng: limit poolsize to 256 bytes and document flock() and fsync() usage

[Denys Vlasenko]

On Sun, May 1, 2022 at 3:07 PM David Laight <David.Laight at aculab.com> wrote:
> Using the same file twice is better than having nothing at all.
> At least different systems use different values.
> Unless you have a remote 'dos' attack that can crash the system
> at exactly the right point in the boot sequence this is an
> entirely 'academic' error.
>
> What is much more likely is that the file where the entropy
> is saved is just a memory overlay on top of a read-only image.
>
> That is much more likely for an embedded system than any of
> the 'failure' cases you've considered.
>
> I also wonder how sane it is to do 'new_key = f(old_key)'.
> That doesn't seem significantly better than using the same key.
>
> For a really embedded system the only persistent storage
> could easily be a small serial EEPROM with a very limited
> number of write cycles.
> This requires special code to read/write and care to avoid
> hitting the write cycle count on a small number of memory cells.
> No amount of faffing about with filesystem accesses will
> help here at all.

Exactly why I want to hear about real-world cases
where it was demonstrably difficult to initialize RNG properly.

Need to separate fiction and exaggerations from reality.

> There is also the case (that on my systems at least) udev
> initialisation reads from /dev/[u]random well before the S20
> script loads any saved entropy.
> I've not tried to find out what the value is used for.