Hi Bernhard, On Tue, Apr 19, 2022 at 10:31 AM Bernhard Reutner-Fischer <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
