Linux 5.6 Seeing Random Changes, New "Insecure" Option With GRND_INSECURE
The recent work by longtime kernel developer Andy Lutomirski on improving Linux's random APIs and introducing a new "GRND_INSECURE" option is now queued into the random dev queue ahead of the Linux 5.6 cycle.
These changes to the random number generation add a new GRND_INSECURE flag for getentropy() and removes the blocking pool (though /dev/random can still block after the system has booted). These changes provide for some code cleanups and GRND_INSECURE allows returning potentially "insecure" random data.
Depending upon the system state, GRND_INSECURE output may not meet the standards for being cryptographically random but is enough for the kernel providing the best random output it can when requested. GRND_INSECURE is sufficient for "best-effort non-cryptographic bytes" when users may not necessarily need strong random output.
The patch series deletes a lot of code associated with the random blocking pool now that it's removed. These random changes were queued overnight into Ted's random.git dev branch making it material for the upcoming Linux 5.6 cycle should no issues come up with these changes -- it's not anticipated that these low-level changes should break any existing programs.
These changes to the random number generation add a new GRND_INSECURE flag for getentropy() and removes the blocking pool (though /dev/random can still block after the system has booted). These changes provide for some code cleanups and GRND_INSECURE allows returning potentially "insecure" random data.
Depending upon the system state, GRND_INSECURE output may not meet the standards for being cryptographically random but is enough for the kernel providing the best random output it can when requested. GRND_INSECURE is sufficient for "best-effort non-cryptographic bytes" when users may not necessarily need strong random output.
The patch series deletes a lot of code associated with the random blocking pool now that it's removed. These random changes were queued overnight into Ted's random.git dev branch making it material for the upcoming Linux 5.6 cycle should no issues come up with these changes -- it's not anticipated that these low-level changes should break any existing programs.
12 Comments