Bug 216061
| Summary: | RANDOM: /proc/sys/kernel/random/entropy_avail and poolsize went down to 256 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | JG (email200202) |
| Component: | Other | Assignee: | drivers_other |
| Status: | NEW --- | ||
| Severity: | normal | CC: | Jason |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 5.10.119 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
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. |
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.