Hi David (and Linus), On Tue, Mar 22, 2022 at 8:16 PM David Laight <David.Laight@xxxxxxxxxx> wrote: > Never mind scripts that try to immediately save a new seedfile [1]. > > What about code run by later startup scripts that wants random numbers. > They really do want the seedfile data to be used. > If it isn't used then they are likely to get very weak random numbers. > > You can't really expect startup scripts to be issuing ioctl requests. To be clear, this "expect[ation]" of yours is very much a new expectation. Crediting bits has required an ioctl since forever. Those shell scripts have been broken forever. The proposal here is to add new behavior to support those old broken shell scripts. Fortunately, it seems sort of fixable. But only sort of. There are also a lot of complications, as detailed above. Part of it is that some people use /dev/urandom writes expecting it not to credit, while others use that and then later manually credit it with the ioctl. Both of those in general seem like not a very good interface for seeding the rng. The correct interface to use is RNDADDENTROPY, which takes both the data and whether it should be credited, since then the kernel knows what the intentions are and can do something smart with it. Barring that knowledge, we're in this vague middle ground where it's unclear what the user intends to do. "But I want my shell scripts to work, even if they have never worked," you fairly protest. I'll do my best here to figure something out, but note that introducing sane behavior to /dev/urandom writes might imply breaking compatibility with the behavior /dev/urandom writes have always had in the past. So the "perfect" solution for a shell script seeding interface might prove elusive, and we'll be left with something merely, "not terrible." However, if you do think you have a "perfect" solution that takes into account all these concerns and doesn't break any prior contracts, please do pipe up. Two more thoughts, also for Linus' consideration: - Had we not needed to revert the /dev/urandom + /dev/random unification patch, we wouldn't be facing this problem. So a last minute creative solution to save that effort would be quite welcome. I'm not optimistic about us finding that right away, but if a lightbulb goes off, I'd be quite happy. - Since these seeding shell scripts have always been broken, because this is how the rng has always been, rather than trying to bolt on a very imperfect fix in the kernel for something that never worked right, we could suggest shell scripts take the path that I implemented for systemd: https://github.com/systemd/systemd/commit/da2862ef06f22fc8d31dafced6d2d6dc14f2ee0b In shell, this would look like: #!/bin/bash cat seedfile > /dev/urandom { cat seedfile; head -c 32 /dev/urandom; } | sha256sum | cut -d ' ' -f 1 > seedfile This seems better in nearly every way to trying to retroactively fix it in the kernel by changing the semantics of an extremely old interface. The more I think about it, the more I'm inclined to go with this "do nothing" approach. Open to hearing your thoughts though. Jason
