On Tue, Sep 19, 2023 at 4:07 AM Rob Landley <r...@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@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
