On Mo, 16.09.19 13:21, Theodore Y. Ts'o (tytso@xxxxxxx) wrote: > We could create a new flag, GRND_INSECURE, which never blocks. And > that that allows us to solve the problem for silly applications that > are using getrandom(2) for non-cryptographic use cases. Use cases > might include Python dictionary seeds, gdm for MIT Magic Cookie, UUID > generation where best efforts probably is good enough, etc. The > answer today is they should just use /dev/urandom, since that exists > today, and we have to support it for backwards compatibility anyway. > It sounds like gdm recently switched to getrandom(2), and I suspect > that it's going to get caught on some hardware configs anyway, even > without the ext4 optimization patch. So I suspect gdm will switch > back to /dev/urandom, and this particular pain point will probably go > away. The problem is that reading from /dev/urandom at a point where it's not initialized yet results in noisy kernel logging on current kernels. If you want people to use /dev/urandom then the logging needs to go away, because it scares people, makes them file bug reports and so on, even though there isn't actually any problem for these specific purposes. For that reason I'd prefer GRND_INSECURE I must say, because it indicates people grokked "I know I might get questionnable entropy". Lennart
