Looking over this PRNG code, I wonder how carefully it's been thought through. The big question is "why have this code in the erne at all? Can't it just be a user-space feature?" SP800-90 and X9.17 both specify CPRNGs with anti-backtracking protection. At the end of each generate operation is a step which performs an irreversible transformation on the state so prior output is irretrievable even if the state is later captured. What makes the whole thing tricky is that the standards are written with the model of a single-threaded application. Mapping this to a kernel device with multiple simultaneous (mutually distrustful) users is not entirely obvious. Not entirely obvious in two ways: *how* to do it, and *whether* to do it. Why take something that's a bad fit for the kernel and jam it in there? One issue that jumpsout at me is that the minimal requirement for providing anti-backtracking to users is that the output is wiped from kernel buffers after it's copied to userspace, but prng_sha512_read() doesn't do that. More generally, there are several ways to map the generator to a device driver, and while the chosen one is plausible, there's no discussion of how it was decided on. SP800-90 makes a strong distinction between output from the same generate operation vs. different generate operations. There are also separate limits: 2^19 bits max (1024 hashes) per generate operation, 2^48 generate operations per reseed. The question is, should that distinction be made visible to users of the kernel device? The current code does not; it generates 256 bytes (4 hashes) at a time and serves all comers from that. When that runs out (possibly in the middle of a read), it runs a new generate operation for the rest. You could alternatively have each read be a separate generate, or each open() be a separate generate. But when trying to figure out what the right thing to do is, I keep not understanding the use case. What is this code trying to achieve?
