[Toybox] You've seen the /dev/random shenanigans, right?

[enh]

On Tue, Sep 19, 2023 at 4:07 AM Rob Landley <rob at landley.net> wrote:
>
> Looks like the kernel devs rewrote stuff in 2022 to make it more dependent on
> systemd, and now writing to /dev/random not only doesn't credit entropy (so it
> still blocks) but has an arbitrary delay about even mixing the data in.
>
> https://lwn.net/Articles/889452/

we do have EntropyMixer (+Eric Biggers for that), but it just writes
to /dev/urandom, and doesn't call the ioctl()...
"""
A more insidious problem, perhaps, is that a seed written to the RNG
before it initializes will not actually be used until after the pool
is initialized properly; "you might write in a perfectly good seed to
/dev/urandom, but what you read out for the subsequent seed may be
complete deterministic crap", Donenfeld said. The data that gets
written to the device is not credited with any entropy unless the
RNDADDTOENTCNT ioctl() command is used, but that also means the fast
initialization pool is not updated with the seed data, so the random
numbers returned from the non-blocking /dev/urandom before it is
initialized are much worse. That behavior has been true for quite some
time, he said, but it makes the "innocuous pattern" of writing a seed
and reading a new one into a potentially serious flaw; he thought he
had a "quick unobtrusive fix" for that.
"""

> Apparently busybox copied code from systemd to do the same thing via a different
> API as if that's an improvement:
>
> http://lists.busybox.net/pipermail/busybox/2022-April/089559.html
>
> And I just noticed because somebody mentioned Android involvement. (I still try
> to check that mailing list twice/month for anything of obvious interest.)
>
> http://lists.busybox.net/pipermail/busybox/2023-September/090471.html

(i think they were just talking about the busybox-for-android configuration?)

> Might not matter on systems with a hardware random number generator with a
> kernel driver hooked up to it, but it breaks the embedded world. (Then again the
> embedded linux projects I've seen recently have been reverting _back_ to the 2.6
> kernel...)

yeah, our high- and mid-end devices usually have a hw rng, but the
lowest of the low-end devices don't even necessarily have an rtc that
survives reboots. (i've definitely helped weaken CTS tests a few times
to allow this kind of thing.)

+Pete Bentley as the other person who might be interested in this
stuff. (because of prng_seeder, which is what boringssl-based stuff
uses, but which might also care about us not calling the ioctl()?)

> I'm trying to figure out if I should add something like an "rngcredit" command
> to call the gratuitous ioctl to supply data you used to be able to write into
> proc before they made /dev/random world writeable and decided doing so was a
> threat vector but that it should still totally allow it...
>
> Rob_______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net