In kernel 5.6, the semantics of reading from /dev/random were changed significantly [1][2]. If my understanding of [1] is correct -- and perhaps it is not, I am not claiming any expertise -- /dev/random now behaves essentially like /dev/urandom, except that it blocks only in the case of insufficient initial entropy during boot, but never blocks thereafter. A few quick experiments using kernel 5.14.14 seem to confirm that understanding. This is a significant behavioral change but it does not seem to be reflected in either random.4 or random.7 from man-pages release 5.13 (as provided in Arch Linux man-pages 5.13-1). In looking thru the change history of those pages, it does not seem that there have been any updates to either since man-pages 4.10. I'd be happy to offer a patch, but the required changes are not trivial and am hestitant to contribute language on something that I don't have sufficient familiarity with. Based on my quick experiments with kernel 5.14.14, at least the following statements in random.4 seem to be entirely invalidated by the post 5.6 behavior: A read(2) from /dev/random will return at most 512 bytes (340 bytes on Linux kernels before version 2.6.12): Observed behavior with 5.14.14: It returns up to 32MB, just as /dev/urandom does. The subsection describing read_wakeup_threshold: This pseudo-file read_wakeup_threshold no longer exists in /proc/sys/kernel/random. - Glenn [1] https://github.com/torvalds/linux/commit/30c08efec8884fb106b8e57094baa51bb4c44e32 [2] https://lwn.net/Articles/808575/
Ha, can confirm. Was putting my nose through these things starting with https://words.filippo.io/dispatches/linux-csprng/. Things to change: ## random.7 * We should remove the concept of a "blocking pool". * GRND_RANDOM is no longer a thing. Remove the two rows. filippo also questions the wisdom of recommending people to roll their own PRNG, now that the ChaCha stuff is much faster. I don't know. filippo reports that 5.4 (commit https://github.com/torvalds/linux/commit/50ee7529ec4500c88f8664560770a7a1b65db72b) has some magic to get entropy from jitter. We should document this behavior so people know blocking will not be that bad. ## random.4 Yep, that's gonna be painful. I recommend adding a sub section for "pre-5.6 behavior". ## getrandom.2 Removal of GRND_RANDOM shall be noted.
Created attachment 304322 [details] An attempt at an edit. I feel like writing, so here goes my attempt at a patch. Basically what was requested by the reporter and myself in the preceding comment. random.4: * have the DESCRIPTION section rearranged such that the old and new random behavior is split into two paragraphs. That will make reading easier. * interface size changes & proc removal, as requested * mention blocking time, as I requested * I did NOT touch the comment in USAGE a lot. Old kernels will refuse to die for a long time, so even though /dev/random acts exactly like getrandom() now, we cannot tell people to expect that. So let's keep calling it a legacy interface. random.7: Ho boy this is where most of it goes. * Table demolition, as promised. * Added table entry for GRND_INSECURE. * Add mention of the unfortunate compromise that made /dev/urandom fast. I say unfortunate, but we are all laughing because now we can dd that hard drive FAST. * "Choice of random source" revised to remove any recommendation of /dev/random. We would make an incorrect impression that the new change is somehow less secure otherwise. * "The old blocking pool" section added to further explain that removal was not the mistake, /dev/random was.
Created attachment 306038 [details] Patch set as of 2024-03-25 I am not functioning well enough to do man pages right now. The attached tarball contains the current progress of my tree. It contains three patches suitable for the current HEAD at c6a68aef7334f32ffffb74050702b8b53b064f37: * The first is basically #304322, which changes a bunch of things. It's been e-mailed, but I honestly don't recall whether I've done the requested changes. * The second is a small change. It has also been emailed, and I also don't know if the formatting issues have been fixed. * The third is new. It addresses a pool size change and a write_wakeup_threshold obsoletion. It could have addressed the obsolete "urandom_min_reseed_secs" too, but I don't want to hunt down when it appeared and when it stopped working.
Created attachment 306039 [details] signature.asc Hi Mingye, On Mon, Mar 25, 2024 at 12:44:08PM +0000, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=214885 > > Mingye Wang (arthur200126@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Attachment #304322 [details]|0 |1 > is obsolete| | > > --- Comment #3 from Mingye Wang (arthur200126@gmail.com) --- > Created attachment 306038 [details] > --> https://bugzilla.kernel.org/attachment.cgi?id=306038&action=edit > Patch set as of 2024-03-25 > > I am not functioning well enough to do man pages right now. The attached > tarball contains the current progress of my tree. It contains three patches > suitable for the current HEAD at c6a68aef7334f32ffffb74050702b8b53b064f37: > > * The first is basically #304322, which changes a bunch of things. It's been > e-mailed, but I honestly don't recall whether I've done the requested > changes. > * The second is a small change. It has also been emailed, and I also don't > know > if the formatting issues have been fixed. > * The third is new. It addresses a pool size change and a > write_wakeup_threshold obsoletion. It could have addressed the obsolete > "urandom_min_reseed_secs" too, but I don't want to hunt down when it appeared > and when it stopped working. Thanks! I don't take patches from bugzilla. Would you mind sending the patches following the instructions in <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING>? Have a lovely day! Alex