After the update to kernel 5.10.119, /proc/sys/kernel/random/poolsize went from 4096 to 256. # cat /proc/sys/kernel/random/poolsize 256 The /proc/sys/kernel/random/entropy_avail used to be above 3000 and changes with the activity on the computer, it became stuck at 256. # cat /proc/sys/kernel/random/entropy_avail 256 From the code in "random.c", I can see where this number 256 came from: BLAKE2S_HASH_SIZE = 32 POOL_BITS = BLAKE2S_HASH_SIZE * 8, static int sysctl_poolsize = POOL_BITS; { .procname = "poolsize", .data = &sysctl_poolsize, .maxlen = sizeof(int), .mode = 0444, .proc_handler = proc_dointvec, }, My code test for high available entropy (>3000) before using the random functions. This change broke it.
CC'ing Jason A. Donenfeld who worked on this.
entropy_avail is always ≤ poolsize. That's how that API works. When entropy_avail=poolsize, then the pool is full. Since entropy estimation is an impossible task to begin with, I wouldn't read too much into any particular numerology here. Of course, 256 bits is all you need for doing secure crypto. But when it says 256, that's probably a gross under estimate anyway. Additionally, the best way to know if the random functions can be used is the getrandom(0) syscall. Anyway, this is not a bug. The 4096-bit LFSR is not coming back any time soon. We're instead using a 256-bit cryptographic hash function.