GNU C Library 2.36 released

The article talking about this is https://lwn.net/Articles/887207/ (Random numbers and virtual-machine forks).

geofft had distinguished process forking from VM cloning. The implication of my comment was that the only remaining issue is VM cloning, or more generically a mechanism by which the kernel could asynchronously trigger reseeding of user PRNG state upon exogenous events. In theory another madvise flag could be added, e.g. MADV_EPHEMERALSECRET, to wipe a mapping on VM resume or similar event in addition to clone/fork. But a vDSO seems like a much better idea long-term, particularly because it would mean applications could benefit from future changes independent of libc version.

There's also the related debate about keeping *any* PRNG state visible within the process. But IMO that seems like a regression back toward a bifurcated world of cryptographically strong and non-cryptographically strong interfaces, and we know that's a world that didn't work out--it's the whole reason for arc4random. The getrandom syscall may be fast, but it's never going to be fast enough. If the gettimeofday syscall isn't fast enough--and it isn't, at least by most people's priorities--then neither could getrandom be fast enough. Many modern protocols and applications consume randomness as heavily or more heavily than gettimeofday--e.g. on every message, every event loop, etc. People would continue bundling their own CSPRNGs just as they do now, which puts us back at square 0. And the value seems especially unclear considering that getrandom remains available all the same.