[Bug 214885] New: random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6

[Bug 214885] New: random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=214885

            Bug ID: 214885
           Summary: random.{4,7} [man-pages 5.13] do not reflect changes
                    to /dev/random semantics since kernel 5.6
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: low
          Priority: P1
         Component: man-pages
          Assignee: documentation_man-pages@kernel-bugs.osdl.org
          Reporter: kerbug@zplane.com
        Regression: No

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/

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 214885] random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=214885

G. Golden (kerbug@zplane.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|low                         |normal

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 214885] random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=214885

Mingye Wang (arthur200126@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arthur200126@gmail.com

--- Comment #1 from Mingye Wang (arthur200126@gmail.com) ---
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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 214885] random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=214885

--- Comment #2 from Mingye Wang (arthur200126@gmail.com) ---
Created attachment 304322
  --> https://bugzilla.kernel.org/attachment.cgi?id=304322&action=edit
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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Mingye Wang]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

Hi Alex,

I am still struggling with getting my mail client to send through a
proxy. The attached patch is the same as the bugzilla one, except that
the commit message has been expanded.

[-- Attachment #2: 0001-random.-4-7-getrandom.2-Adapt-to-Linux-5.6-changes.patch --]
[-- Type: application/octet-stream, Size: 9389 bytes --]

From 343b2ad76dc6d78daa529405f2ec7f9a3e2e65bf Mon Sep 17 00:00:00 2001
From: Mingye Wang <arthur200126@gmail.com>
Date: Thu, 25 May 2023 20:21:08 +0800
Subject: [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes
In-Reply-To: <bug-214885-11311-M5kG7tptAp@https.bugzilla.kernel.org/>
X-Unsent: 1

Linux kernel 5.6 no longer has a blocking random pool.  This commit
updates all relevant references to reflect this change.

* random.7: Remove references to the blocking pool in the table.  Add a
  note about the blocking pool.
* random.7: Revise "choice of random source" to remove any recommen-
  dationof the blocking pool.  Stop suggesting that the blocking pool is
  safer (it's not after initialization).
* random.7: Add table entry for GRND_INSECURE.
* random.7: Weaken performance recommendation following the Linux 4.8
  CSPRNG speedup.
* getrandom.2: Add flag entry for GRND_INSECURE.
* getrandom.2: Add removal note to GRND_RANDOM.
* random.4: Split DESCRIPTION paragraph on /dev/random into two, one
  for the new behavior and the other for the old.
* random.4: Adjust size limits and /proc list for 5.6.
* random.4: Mention blocking resolution by high-precision timer entropy.

Changes not made:
* random.4: USAGE section largely unchanged.  Old kernels will stick
  around for a while.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214885
Signed-Off-By: Mingye Wang <arthur200126@gmail.com>
---
 man2/getrandom.2 |  9 +++++
 man4/random.4    | 30 +++++++++-------
 man7/random.7    | 89 ++++++++++++++++++++++++++----------------------
 3 files changed, 75 insertions(+), 53 deletions(-)

diff --git a/man2/getrandom.2 b/man2/getrandom.2
index dbd23a0a6..fb2e948be 100644
--- a/man2/getrandom.2
+++ b/man2/getrandom.2
@@ -64,6 +64,8 @@ argument is a bit mask that can contain zero or more of the following values
 ORed together:
 .TP
 .B GRND_RANDOM
+.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
+Ignored since Linux 5.6.
 If this bit is set, then random bytes are drawn from the
 .I random
 source
@@ -105,6 +107,13 @@ does not block in these cases, but instead immediately returns \-1 with
 .I errno
 set to
 .BR EAGAIN .
+.TP GRND_INSECURE
+.\" commit 75551dbf112c992bc6c99a972990b3f272247e23
+Added in Linux 5.6.
+Request best-effort, non-cryptographic-quality random bytes.
+If this bit is set, then
+.BR getrandom ()
+will never block or fail due to a lack of entropy.
 .SH RETURN VALUE
 On success,
 .BR getrandom ()
diff --git a/man4/random.4 b/man4/random.4
index edd047b77..6ce9992fe 100644
--- a/man4/random.4
+++ b/man4/random.4
@@ -58,16 +58,20 @@ If this is of concern in your application, use
 .BR getrandom (2)
 or \fI/dev/random\fP instead.
 .PP
-The \fI/dev/random\fP device is a legacy interface which dates back to
-a time where the cryptographic primitives used in the implementation
-of \fI/dev/urandom\fP were not widely trusted.
-It will return random bytes only within the estimated number of
-bits of fresh noise in the entropy pool, blocking if necessary.
-\fI/dev/random\fP is suitable for applications that need
+.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
+As of Linux 5.6, \fI/dev/random\fP is identical to \fI/dev/urandom\fP,
+except that it blocks during early boot.  A jitter-based seeding technique
+added in Linux 5.4 should help to reduce block time. 
+.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
+.PP
+The pre-5.6 \fI/dev/random\fP device is a legacy interface which dates
+back to a time where the cryptographic primitives used in the implementation
+of \fI/dev/urandom\fP were not widely trusted. It would return random bytes
+only within the estimated number of bits of fresh noise in the entropy pool,
+blocking until additional environmental noise is gathered.
+This old \fI/dev/random\fP is suitable for applications that need
 high quality randomness, and can afford indeterminate delays.
 .PP
-When the entropy pool is empty, reads from \fI/dev/random\fP will block
-until additional environmental noise is gathered.
 Since Linux 5.6, the
 .B O_NONBLOCK
 flag is ignored as
@@ -116,15 +120,16 @@ A
 .BR read (2)
 from
 .I /dev/random
-will return at most 512 bytes
+has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
+the maximum size was 512 bytes. (340 bytes before Linux 2.6.12)
 .\" SEC_XFER_SIZE in drivers/char/random.c
-(340 bytes before Linux 2.6.12).
+
 .PP
 Writing to \fI/dev/random\fP or \fI/dev/urandom\fP will update the
 entropy pool with the data written, but this will not result in a
 higher entropy count.
 This means that it will impact the contents
-read from both files, but it will not make reads from
+read from both files, but it will not make reads from a pre-5.6
 \fI/dev/random\fP faster.
 .SS Usage
 The
@@ -145,7 +150,7 @@ soon as it is reloaded in the boot sequence, and perfectly adequate for
 network encryption session keys.
 (All major Linux distributions have saved the seed file across reboots
 since 2000 at least.)
-Since reads from
+Since reads from a pre-5.6
 .I /dev/random
 may block, users will usually want to open it in nonblocking mode
 (or perform a read with timeout),
@@ -246,6 +251,7 @@ It contains the value 4096.
 .RE
 .TP
 .I read_wakeup_threshold
+Removed in Linux 5.6.
 This file
 contains the number of bits of entropy required for waking up processes
 that sleep waiting for entropy from
diff --git a/man7/random.7 b/man7/random.7
index 69e6c2403..e80a1328e 100644
--- a/man7/random.7
+++ b/man7/random.7
@@ -59,17 +59,16 @@ The kernel collects bits of entropy from the environment.
 When a sufficient number of random bits has been collected, the
 entropy pool is considered to be initialized.
 .SS Choice of random source
-Unless you are doing long-term key generation (and most likely not even
-then), you probably shouldn't be reading from the
+Unless your program may run at early-boot, before the entropy pool
+is initialized, there is no longer any palpable difference between
 .I /dev/random
-device or employing
-.BR getrandom (2)
-with the
-.B GRND_RANDOM
-flag.
-Instead, either read from the
+and
 .I /dev/urandom
-device or employ
+since Linux 5.6. (See the table below.)
+.PP.
+On older kernels, either read from the
+.I /dev/urandom
+device or (especially if you are concerned with early boot) employ
 .BR getrandom (2)
 without the
 .B GRND_RANDOM
@@ -77,18 +76,6 @@ flag.
 The cryptographic algorithms used for the
 .I urandom
 source are quite conservative, and so should be sufficient for all purposes.
-.PP
-The disadvantage of
-.B GRND_RANDOM
-and reads from
-.I /dev/random
-is that the operation can block for an indefinite period of time.
-Furthermore, dealing with the partially fulfilled
-requests that can occur when using
-.B GRND_RANDOM
-or when reading from
-.I /dev/random
-increases code complexity.
 .\"
 .SS Monte Carlo and other probabilistic sampling applications
 Using these interfaces to provide large quantities of data for
@@ -99,6 +86,13 @@ need cryptographically secure random numbers.
 Instead, use the interfaces described in this page to obtain
 a small amount of data to seed a user-space pseudorandom
 number generator for use by such applications.
+.PP
+.\" commit e192be9d9a30555aae2ca1dc3aad37cba484cd4a
+.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
+Since Linux 4.8, the random interfaces are backed by a much faster
+NUMA-aware ChaCha20 CSPRNG.
+It is still discouraged to use the random interfaces for sampling,
+but if you do, the performance will be much better than before.
 .\"
 .SS Comparison between getrandom, /dev/urandom, and /dev/random
 The following table summarizes the behavior of the various
@@ -122,9 +116,9 @@ T}
 T{
 .I /dev/random
 T}	T{
-Blocking pool
+CSPRNG output
 T}	T{
-If entropy too low, blocks until there is enough entropy again
+Never blocks
 T}	T{
 Blocks until enough entropy gathered
 T}
@@ -149,17 +143,6 @@ Blocks until pool ready
 T}
 T{
 .BR getrandom ()
-.B GRND_RANDOM
-T}	T{
-Same as
-.I /dev/random
-T}	T{
-If entropy too low, blocks until there is enough entropy again
-T}	T{
-Blocks until pool ready
-T}
-T{
-.BR getrandom ()
 .B GRND_NONBLOCK
 T}	T{
 Same as
@@ -171,21 +154,45 @@ T}	T{
 T}
 T{
 .BR getrandom ()
-.B GRND_RANDOM
-+
-.B GRND_NONBLOCK
+.B GRND_INSECURE
 T}	T{
 Same as
-.I /dev/random
+.I /dev/urandom
 T}	T{
-.B EAGAIN
-if not enough entropy available
+Never blocks
 T}	T{
-.B EAGAIN
+Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
 T}
 .TE
 .ad
 .\"
+.SS The old blocking pool
+The above table describes the behavior of the interfaces since
+Linux 5.6.  In older kernels, the
+.I /dev/random
+used a separate blocking pool, and
+.BR getrandom () 
+had a
+.B GRND_RANDOM
+flag for reading from the blocking pool.
+.\"
+.PP
+The older blocking pool was a vestige of a time when the CSPRNG
+was not trusted.
+It assumed that entropy can run out by reading the CSPRNG.
+This has never been the case.
+Instead, programs using 
+.B GRND_RANDOM
+and
+.I /dev/random
+had to deal with operations blocking indefinitely.
+Furthermore, dealing with the partially fulfilled
+requests that can occur when using
+.B GRND_RANDOM
+or when reading from
+.I /dev/random
+increases code complexity.
+.\"
 .SS Generating cryptographic keys
 The amount of seed material required to generate a cryptographic key
 equals the effective key size of the key.
-- 
2.40.0

Re: [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 11403 bytes --]

Hi Mingye,

On 5/29/23 10:50, Mingye Wang wrote:
> Hi Alex,
> 
> I am still struggling with getting my mail client to send through a
> proxy. The attached patch is the same as the bugzilla one, except that
> the commit message has been expanded.

Okay; no problem.

> From 343b2ad76dc6d78daa529405f2ec7f9a3e2e65bf Mon Sep 17 00:00:00 2001
> From: Mingye Wang <arthur200126@gmail.com>
> Date: Thu, 25 May 2023 20:21:08 +0800
> Subject: [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes
> In-Reply-To: <bug-214885-11311-M5kG7tptAp@https.bugzilla.kernel.org/>
> X-Unsent: 1
> 
> Linux kernel 5.6 no longer has a blocking random pool.  This commit
> updates all relevant references to reflect this change.
> 
> * random.7: Remove references to the blocking pool in the table.  Add a
>   note about the blocking pool.
> * random.7: Revise "choice of random source" to remove any recommen-
>   dationof the blocking pool.  Stop suggesting that the blocking pool is
>   safer (it's not after initialization).
> * random.7: Add table entry for GRND_INSECURE.
> * random.7: Weaken performance recommendation following the Linux 4.8
>   CSPRNG speedup.

If some changes come from Linux 4.8, I prefer having two separate patches.

> * getrandom.2: Add flag entry for GRND_INSECURE.
> * getrandom.2: Add removal note to GRND_RANDOM.
> * random.4: Split DESCRIPTION paragraph on /dev/random into two, one
>   for the new behavior and the other for the old.
> * random.4: Adjust size limits and /proc list for 5.6.
> * random.4: Mention blocking resolution by high-precision timer entropy.
> 
> Changes not made:
> * random.4: USAGE section largely unchanged.  Old kernels will stick
>   around for a while.
> 
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214885
> Signed-Off-By: Mingye Wang <arthur200126@gmail.com>
> ---
>  man2/getrandom.2 |  9 +++++
>  man4/random.4    | 30 +++++++++-------
>  man7/random.7    | 89 ++++++++++++++++++++++++++----------------------
>  3 files changed, 75 insertions(+), 53 deletions(-)
> 
> diff --git a/man2/getrandom.2 b/man2/getrandom.2
> index dbd23a0a6..fb2e948be 100644
> --- a/man2/getrandom.2
> +++ b/man2/getrandom.2
> @@ -64,6 +64,8 @@ argument is a bit mask that can contain zero or more of the following values
>  ORed together:
>  .TP
>  .B GRND_RANDOM
> +.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
> +Ignored since Linux 5.6.
>  If this bit is set, then random bytes are drawn from the
>  .I random
>  source
> @@ -105,6 +107,13 @@ does not block in these cases, but instead immediately returns \-1 with
>  .I errno
>  set to
>  .BR EAGAIN .
> +.TP GRND_INSECURE
> +.\" commit 75551dbf112c992bc6c99a972990b3f272247e23
> +Added in Linux 5.6.
> +Request best-effort, non-cryptographic-quality random bytes.
> +If this bit is set, then
> +.BR getrandom ()
> +will never block or fail due to a lack of entropy.
>  .SH RETURN VALUE
>  On success,
>  .BR getrandom ()
> diff --git a/man4/random.4 b/man4/random.4
> index edd047b77..6ce9992fe 100644
> --- a/man4/random.4
> +++ b/man4/random.4
> @@ -58,16 +58,20 @@ If this is of concern in your application, use
>  .BR getrandom (2)
>  or \fI/dev/random\fP instead.
>  .PP
> -The \fI/dev/random\fP device is a legacy interface which dates back to
> -a time where the cryptographic primitives used in the implementation
> -of \fI/dev/urandom\fP were not widely trusted.
> -It will return random bytes only within the estimated number of
> -bits of fresh noise in the entropy pool, blocking if necessary.
> -\fI/dev/random\fP is suitable for applications that need
> +.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
> +As of Linux 5.6, \fI/dev/random\fP is identical to \fI/dev/urandom\fP,
> +except that it blocks during early boot.

Just wondering:  how is this description of /dev/urandom different from
GRND_INSECURE?

>  A jitter-based seeding technique
> +added in Linux 5.4 should help to reduce block time. 
> +.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
> +.PP
> +The pre-5.6 \fI/dev/random\fP device is a legacy interface which dates
> +back to a time where the cryptographic primitives used in the implementation
> +of \fI/dev/urandom\fP were not widely trusted. It would return random bytes

Please use semantic newlines.  See man-pages(7):
   Use semantic newlines
       In the source of a manual page, new sentences should be started
       on  new  lines,  long  sentences  should be split into lines at
       clause breaks (commas, semicolons, colons, and so on), and long
       clauses should be split at phrase boundaries.  This convention,
       sometimes known as "semantic newlines", makes it easier to  see
       the  effect of patches, which often operate at the level of in‐
       dividual sentences, clauses, or phrases.

> +only within the estimated number of bits of fresh noise in the entropy pool,
> +blocking until additional environmental noise is gathered.
> +This old \fI/dev/random\fP is suitable for applications that need
>  high quality randomness, and can afford indeterminate delays.
>  .PP
> -When the entropy pool is empty, reads from \fI/dev/random\fP will block
> -until additional environmental noise is gathered.
>  Since Linux 5.6, the
>  .B O_NONBLOCK
>  flag is ignored as
> @@ -116,15 +120,16 @@ A
>  .BR read (2)
>  from
>  .I /dev/random
> -will return at most 512 bytes
> +has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
> +the maximum size was 512 bytes. (340 bytes before Linux 2.6.12)
>  .\" SEC_XFER_SIZE in drivers/char/random.c
> -(340 bytes before Linux 2.6.12).
> +

Blank lines are wrong.

Cheers,
Alex

>  .PP
>  Writing to \fI/dev/random\fP or \fI/dev/urandom\fP will update the
>  entropy pool with the data written, but this will not result in a
>  higher entropy count.
>  This means that it will impact the contents
> -read from both files, but it will not make reads from
> +read from both files, but it will not make reads from a pre-5.6
>  \fI/dev/random\fP faster.
>  .SS Usage
>  The
> @@ -145,7 +150,7 @@ soon as it is reloaded in the boot sequence, and perfectly adequate for
>  network encryption session keys.
>  (All major Linux distributions have saved the seed file across reboots
>  since 2000 at least.)
> -Since reads from
> +Since reads from a pre-5.6
>  .I /dev/random
>  may block, users will usually want to open it in nonblocking mode
>  (or perform a read with timeout),
> @@ -246,6 +251,7 @@ It contains the value 4096.
>  .RE
>  .TP
>  .I read_wakeup_threshold
> +Removed in Linux 5.6.
>  This file
>  contains the number of bits of entropy required for waking up processes
>  that sleep waiting for entropy from
> diff --git a/man7/random.7 b/man7/random.7
> index 69e6c2403..e80a1328e 100644
> --- a/man7/random.7
> +++ b/man7/random.7
> @@ -59,17 +59,16 @@ The kernel collects bits of entropy from the environment.
>  When a sufficient number of random bits has been collected, the
>  entropy pool is considered to be initialized.
>  .SS Choice of random source
> -Unless you are doing long-term key generation (and most likely not even
> -then), you probably shouldn't be reading from the
> +Unless your program may run at early-boot, before the entropy pool
> +is initialized, there is no longer any palpable difference between
>  .I /dev/random
> -device or employing
> -.BR getrandom (2)
> -with the
> -.B GRND_RANDOM
> -flag.
> -Instead, either read from the
> +and
>  .I /dev/urandom
> -device or employ
> +since Linux 5.6. (See the table below.)
> +.PP.
> +On older kernels, either read from the
> +.I /dev/urandom
> +device or (especially if you are concerned with early boot) employ
>  .BR getrandom (2)
>  without the
>  .B GRND_RANDOM
> @@ -77,18 +76,6 @@ flag.
>  The cryptographic algorithms used for the
>  .I urandom
>  source are quite conservative, and so should be sufficient for all purposes.
> -.PP
> -The disadvantage of
> -.B GRND_RANDOM
> -and reads from
> -.I /dev/random
> -is that the operation can block for an indefinite period of time.
> -Furthermore, dealing with the partially fulfilled
> -requests that can occur when using
> -.B GRND_RANDOM
> -or when reading from
> -.I /dev/random
> -increases code complexity.
>  .\"
>  .SS Monte Carlo and other probabilistic sampling applications
>  Using these interfaces to provide large quantities of data for
> @@ -99,6 +86,13 @@ need cryptographically secure random numbers.
>  Instead, use the interfaces described in this page to obtain
>  a small amount of data to seed a user-space pseudorandom
>  number generator for use by such applications.
> +.PP
> +.\" commit e192be9d9a30555aae2ca1dc3aad37cba484cd4a
> +.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
> +Since Linux 4.8, the random interfaces are backed by a much faster
> +NUMA-aware ChaCha20 CSPRNG.
> +It is still discouraged to use the random interfaces for sampling,
> +but if you do, the performance will be much better than before.
>  .\"
>  .SS Comparison between getrandom, /dev/urandom, and /dev/random
>  The following table summarizes the behavior of the various
> @@ -122,9 +116,9 @@ T}
>  T{
>  .I /dev/random
>  T}	T{
> -Blocking pool
> +CSPRNG output
>  T}	T{
> -If entropy too low, blocks until there is enough entropy again
> +Never blocks
>  T}	T{
>  Blocks until enough entropy gathered
>  T}
> @@ -149,17 +143,6 @@ Blocks until pool ready
>  T}
>  T{
>  .BR getrandom ()
> -.B GRND_RANDOM
> -T}	T{
> -Same as
> -.I /dev/random
> -T}	T{
> -If entropy too low, blocks until there is enough entropy again
> -T}	T{
> -Blocks until pool ready
> -T}
> -T{
> -.BR getrandom ()
>  .B GRND_NONBLOCK
>  T}	T{
>  Same as
> @@ -171,21 +154,45 @@ T}	T{
>  T}
>  T{
>  .BR getrandom ()
> -.B GRND_RANDOM
> -+
> -.B GRND_NONBLOCK
> +.B GRND_INSECURE
>  T}	T{
>  Same as
> -.I /dev/random
> +.I /dev/urandom
>  T}	T{
> -.B EAGAIN
> -if not enough entropy available
> +Never blocks
>  T}	T{
> -.B EAGAIN
> +Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
>  T}
>  .TE
>  .ad
>  .\"
> +.SS The old blocking pool
> +The above table describes the behavior of the interfaces since
> +Linux 5.6.  In older kernels, the
> +.I /dev/random
> +used a separate blocking pool, and
> +.BR getrandom () 
> +had a
> +.B GRND_RANDOM
> +flag for reading from the blocking pool.
> +.\"
> +.PP
> +The older blocking pool was a vestige of a time when the CSPRNG
> +was not trusted.
> +It assumed that entropy can run out by reading the CSPRNG.
> +This has never been the case.
> +Instead, programs using 
> +.B GRND_RANDOM
> +and
> +.I /dev/random
> +had to deal with operations blocking indefinitely.
> +Furthermore, dealing with the partially fulfilled
> +requests that can occur when using
> +.B GRND_RANDOM
> +or when reading from
> +.I /dev/random
> +increases code complexity.
> +.\"
>  .SS Generating cryptographic keys
>  The amount of seed material required to generate a cryptographic key
>  equals the effective key size of the key.
> -- 
> 2.40.0


-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Mingye Wang]

Hi Alex,

On Thu, Jun 1, 2023 at 6:20 AM Alejandro Colomar <alx.manpages@gmail.com> wrote:
> If some changes come from Linux 4.8, I prefer having two separate patches.

Will do.

> Just wondering:  how is this description of /dev/urandom different from
> GRND_INSECURE?

It isn't! I reckon that they added the flag to give device file parity.

> Blank lines are wrong.

Will fix.

Thanks,
Mingye

Re: [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Mingye Wang]

[-- Attachment #1: Type: text/plain, Size: 84 bytes --]

Hi Alex,

attached are two patches split and revised as requested.

Regards,
Mingye

[-- Attachment #2: 0002-random.7-weaken-performance-recommendation-for-4.8.patch --]
[-- Type: application/octet-stream, Size: 1123 bytes --]

From 2ac4bc3606b4062823e766528a87800e6f5f3b65 Mon Sep 17 00:00:00 2001
From: Mingye Wang <arthur200126@gmail.com>
Date: Mon, 5 Jun 2023 11:13:07 +0800
Subject: [PATCH 2/2] random.7: weaken performance recommendation for 4.8

---
 man7/random.7 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/man7/random.7 b/man7/random.7
index 23aecf2a2..d1abc0c91 100644
--- a/man7/random.7
+++ b/man7/random.7
@@ -86,6 +86,13 @@ need cryptographically secure random numbers.
 Instead, use the interfaces described in this page to obtain
 a small amount of data to seed a user-space pseudorandom
 number generator for use by such applications.
+.PP
+.\" commit e192be9d9a30555aae2ca1dc3aad37cba484cd4a
+.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
+Since Linux 4.8, the random interfaces are backed by a much faster
+NUMA-aware ChaCha20 CSPRNG.
+It is still discouraged to use the random interfaces for sampling,
+but if you do, the performance will be much better than before.
 .\"
 .SS Comparison between getrandom, /dev/urandom, and /dev/random
 The following table summarizes the behavior of the various
-- 
2.40.0


[-- Attachment #3: 0001-random.-4-7-getrandom.2-Adapt-to-Linux-5.6-changes.patch --]
[-- Type: application/octet-stream, Size: 8475 bytes --]

From 582732e6e583decc20bf003688386c0e0036f4ab Mon Sep 17 00:00:00 2001
From: Mingye Wang <arthur200126@gmail.com>
Date: Mon, 5 Jun 2023 11:10:12 +0800
Subject: [PATCH 1/2] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes
 In-Reply-To: <bug-214885-11311-M5kG7tptAp@https.bugzilla.kernel.org/>

Linux kernel 5.6 no longer has a blocking random pool.  This commit
updates all relevant references to reflect this change.

* random.7: Remove references to the blocking pool in the table.  Add a
  note about the blocking pool.
* random.7: Revise "choice of random source" to remove any recommen-
  dationof the blocking pool.  Stop suggesting that the blocking pool is
  safer (it's not after initialization).
* random.7: Add table entry for GRND_INSECURE.
* getrandom.2: Add flag entry for GRND_INSECURE.
* getrandom.2: Add removal note to GRND_RANDOM.
* random.4: Split DESCRIPTION paragraph on /dev/random into two, one
  for the new behavior and the other for the old.
* random.4: Adjust size limits and /proc list for 5.6.
* random.4: Mention blocking resolution by high-precision timer entropy.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214885
Signed-Off-By: Mingye Wang <arthur200126@gmail.com>
---
 man2/getrandom.2 |  9 ++++++
 man4/random.4    | 30 +++++++++++-------
 man7/random.7    | 82 ++++++++++++++++++++++++------------------------
 3 files changed, 68 insertions(+), 53 deletions(-)

diff --git a/man2/getrandom.2 b/man2/getrandom.2
index dbd23a0a6..fb2e948be 100644
--- a/man2/getrandom.2
+++ b/man2/getrandom.2
@@ -64,6 +64,8 @@ argument is a bit mask that can contain zero or more of the following values
 ORed together:
 .TP
 .B GRND_RANDOM
+.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
+Ignored since Linux 5.6.
 If this bit is set, then random bytes are drawn from the
 .I random
 source
@@ -105,6 +107,13 @@ does not block in these cases, but instead immediately returns \-1 with
 .I errno
 set to
 .BR EAGAIN .
+.TP GRND_INSECURE
+.\" commit 75551dbf112c992bc6c99a972990b3f272247e23
+Added in Linux 5.6.
+Request best-effort, non-cryptographic-quality random bytes.
+If this bit is set, then
+.BR getrandom ()
+will never block or fail due to a lack of entropy.
 .SH RETURN VALUE
 On success,
 .BR getrandom ()
diff --git a/man4/random.4 b/man4/random.4
index edd047b77..8e5b7152b 100644
--- a/man4/random.4
+++ b/man4/random.4
@@ -58,16 +58,21 @@ If this is of concern in your application, use
 .BR getrandom (2)
 or \fI/dev/random\fP instead.
 .PP
-The \fI/dev/random\fP device is a legacy interface which dates back to
-a time where the cryptographic primitives used in the implementation
-of \fI/dev/urandom\fP were not widely trusted.
-It will return random bytes only within the estimated number of
-bits of fresh noise in the entropy pool, blocking if necessary.
-\fI/dev/random\fP is suitable for applications that need
+.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
+As of Linux 5.6, \fI/dev/random\fP is identical to \fI/dev/urandom\fP,
+except that it blocks during early boot.
+A jitter-based seeding technique added in Linux 5.4 should help reduce
+block time. 
+.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
+.PP
+The pre-5.6 \fI/dev/random\fP device is a legacy interface which dates
+back to a time where the cryptographic primitives used in the implementation
+of \fI/dev/urandom\fP were not widely trusted. It would return random bytes
+only within the estimated number of bits of fresh noise in the entropy pool,
+blocking until additional environmental noise is gathered.
+This old \fI/dev/random\fP is suitable for applications that need
 high quality randomness, and can afford indeterminate delays.
 .PP
-When the entropy pool is empty, reads from \fI/dev/random\fP will block
-until additional environmental noise is gathered.
 Since Linux 5.6, the
 .B O_NONBLOCK
 flag is ignored as
@@ -116,15 +121,15 @@ A
 .BR read (2)
 from
 .I /dev/random
-will return at most 512 bytes
+has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
+the maximum size was 512 bytes. (340 bytes before Linux 2.6.12)
 .\" SEC_XFER_SIZE in drivers/char/random.c
-(340 bytes before Linux 2.6.12).
 .PP
 Writing to \fI/dev/random\fP or \fI/dev/urandom\fP will update the
 entropy pool with the data written, but this will not result in a
 higher entropy count.
 This means that it will impact the contents
-read from both files, but it will not make reads from
+read from both files, but it will not make reads from a pre-5.6
 \fI/dev/random\fP faster.
 .SS Usage
 The
@@ -145,7 +150,7 @@ soon as it is reloaded in the boot sequence, and perfectly adequate for
 network encryption session keys.
 (All major Linux distributions have saved the seed file across reboots
 since 2000 at least.)
-Since reads from
+Since reads from a pre-5.6
 .I /dev/random
 may block, users will usually want to open it in nonblocking mode
 (or perform a read with timeout),
@@ -246,6 +251,7 @@ It contains the value 4096.
 .RE
 .TP
 .I read_wakeup_threshold
+Removed in Linux 5.6.
 This file
 contains the number of bits of entropy required for waking up processes
 that sleep waiting for entropy from
diff --git a/man7/random.7 b/man7/random.7
index 69e6c2403..23aecf2a2 100644
--- a/man7/random.7
+++ b/man7/random.7
@@ -59,17 +59,16 @@ The kernel collects bits of entropy from the environment.
 When a sufficient number of random bits has been collected, the
 entropy pool is considered to be initialized.
 .SS Choice of random source
-Unless you are doing long-term key generation (and most likely not even
-then), you probably shouldn't be reading from the
+Unless your program may run at early-boot, before the entropy pool
+is initialized, there is no longer any palpable difference between
 .I /dev/random
-device or employing
-.BR getrandom (2)
-with the
-.B GRND_RANDOM
-flag.
-Instead, either read from the
+and
 .I /dev/urandom
-device or employ
+since Linux 5.6. (See the table below.)
+.PP.
+On older kernels, either read from the
+.I /dev/urandom
+device or (especially if you are concerned with early boot) employ
 .BR getrandom (2)
 without the
 .B GRND_RANDOM
@@ -77,18 +76,6 @@ flag.
 The cryptographic algorithms used for the
 .I urandom
 source are quite conservative, and so should be sufficient for all purposes.
-.PP
-The disadvantage of
-.B GRND_RANDOM
-and reads from
-.I /dev/random
-is that the operation can block for an indefinite period of time.
-Furthermore, dealing with the partially fulfilled
-requests that can occur when using
-.B GRND_RANDOM
-or when reading from
-.I /dev/random
-increases code complexity.
 .\"
 .SS Monte Carlo and other probabilistic sampling applications
 Using these interfaces to provide large quantities of data for
@@ -122,9 +109,9 @@ T}
 T{
 .I /dev/random
 T}	T{
-Blocking pool
+CSPRNG output
 T}	T{
-If entropy too low, blocks until there is enough entropy again
+Never blocks
 T}	T{
 Blocks until enough entropy gathered
 T}
@@ -149,17 +136,6 @@ Blocks until pool ready
 T}
 T{
 .BR getrandom ()
-.B GRND_RANDOM
-T}	T{
-Same as
-.I /dev/random
-T}	T{
-If entropy too low, blocks until there is enough entropy again
-T}	T{
-Blocks until pool ready
-T}
-T{
-.BR getrandom ()
 .B GRND_NONBLOCK
 T}	T{
 Same as
@@ -171,21 +147,45 @@ T}	T{
 T}
 T{
 .BR getrandom ()
-.B GRND_RANDOM
-+
-.B GRND_NONBLOCK
+.B GRND_INSECURE
 T}	T{
 Same as
-.I /dev/random
+.I /dev/urandom
 T}	T{
-.B EAGAIN
-if not enough entropy available
+Never blocks
 T}	T{
-.B EAGAIN
+Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
 T}
 .TE
 .ad
 .\"
+.SS The old blocking pool
+The above table describes the behavior of the interfaces since
+Linux 5.6.  In older kernels, the
+.I /dev/random
+used a separate blocking pool, and
+.BR getrandom ()
+had a
+.B GRND_RANDOM
+flag for reading from the blocking pool.
+.\"
+.PP
+The older blocking pool was a vestige of a time when the CSPRNG
+was not trusted.
+It assumed that entropy can run out by reading the CSPRNG.
+This has never been the case.
+Instead, programs using
+.B GRND_RANDOM
+and
+.I /dev/random
+had to deal with operations blocking indefinitely.
+Furthermore, dealing with the partially fulfilled
+requests that can occur when using
+.B GRND_RANDOM
+or when reading from
+.I /dev/random
+increases code complexity.
+.\"
 .SS Generating cryptographic keys
 The amount of seed material required to generate a cryptographic key
 equals the effective key size of the key.
-- 
2.40.0

Re: [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 10113 bytes --]

On 6/5/23 05:13, Mingye Wang wrote:
> Hi Alex,
> 
> attached are two patches split and revised as requested.
> 
> Regards,
> Mingye

Hi!  Here go some comments for one of the patches:

> Author: Mingye Wang <arthur200126@gmail.com>
> Date:   Mon Jun 5 11:10:12 2023 +0800
> 
>     random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes In-Reply-To: <bug-214885-11311-M5kG7tptAp@https.bugzilla.kernel.org/>
>     
>     Linux kernel 5.6 no longer has a blocking random pool.  This commit
>     updates all relevant references to reflect this change.
>     
>     * random.7: Remove references to the blocking pool in the table.  Add a
>       note about the blocking pool.
>     * random.7: Revise "choice of random source" to remove any recommen-

Don't hyphenate words here.

>       dationof the blocking pool.  Stop suggesting that the blocking pool is
>       safer (it's not after initialization).
>     * random.7: Add table entry for GRND_INSECURE.
>     * getrandom.2: Add flag entry for GRND_INSECURE.
>     * getrandom.2: Add removal note to GRND_RANDOM.
>     * random.4: Split DESCRIPTION paragraph on /dev/random into two, one
>       for the new behavior and the other for the old.
>     * random.4: Adjust size limits and /proc list for 5.6.
>     * random.4: Mention blocking resolution by high-precision timer entropy.
>     
>     Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214885
>     Signed-Off-By: Mingye Wang <arthur200126@gmail.com>
> 
> diff --git a/man2/getrandom.2 b/man2/getrandom.2
> index dbd23a0a6..fb2e948be 100644
> --- a/man2/getrandom.2
> +++ b/man2/getrandom.2
> @@ -64,6 +64,8 @@ .SH DESCRIPTION
>  ORed together:
>  .TP
>  .B GRND_RANDOM
> +.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
> +Ignored since Linux 5.6.
>  If this bit is set, then random bytes are drawn from the
>  .I random
>  source
> @@ -105,6 +107,13 @@ .SH DESCRIPTION
>  .I errno
>  set to
>  .BR EAGAIN .
> +.TP GRND_INSECURE
> +.\" commit 75551dbf112c992bc6c99a972990b3f272247e23
> +Added in Linux 5.6.
> +Request best-effort, non-cryptographic-quality random bytes.
> +If this bit is set, then
> +.BR getrandom ()
> +will never block or fail due to a lack of entropy.
>  .SH RETURN VALUE
>  On success,
>  .BR getrandom ()
> diff --git a/man4/random.4 b/man4/random.4
> index edd047b77..8e5b7152b 100644
> --- a/man4/random.4
> +++ b/man4/random.4
> @@ -58,16 +58,21 @@ .SH DESCRIPTION
>  .BR getrandom (2)
>  or \fI/dev/random\fP instead.
>  .PP
> -The \fI/dev/random\fP device is a legacy interface which dates back to
> -a time where the cryptographic primitives used in the implementation
> -of \fI/dev/urandom\fP were not widely trusted.
> -It will return random bytes only within the estimated number of
> -bits of fresh noise in the entropy pool, blocking if necessary.
> -\fI/dev/random\fP is suitable for applications that need
> +.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
> +As of Linux 5.6, \fI/dev/random\fP is identical to \fI/dev/urandom\fP,
> +except that it blocks during early boot.
> +A jitter-based seeding technique added in Linux 5.4 should help reduce
> +block time. 

Please use semantic newlines.  See man-pages(7):

    Use semantic newlines
        In  the  source of a manual page, new sentences should be
        started on new lines, long sentences should be split into
        lines at clause breaks (commas, semicolons,  colons,  and
        so on), and long clauses should be split at phrase bound‐
        aries.   This  convention,  sometimes  known as "semantic
        newlines", makes it easier to see the effect of  patches,
        which often operate at the level of individual sentences,
        clauses, or phrases.

> +.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
> +.PP
> +The pre-5.6 \fI/dev/random\fP device is a legacy interface which dates
> +back to a time where the cryptographic primitives used in the implementation
> +of \fI/dev/urandom\fP were not widely trusted. It would return random bytes
> +only within the estimated number of bits of fresh noise in the entropy pool,
> +blocking until additional environmental noise is gathered.
> +This old \fI/dev/random\fP is suitable for applications that need
>  high quality randomness, and can afford indeterminate delays.
>  .PP
> -When the entropy pool is empty, reads from \fI/dev/random\fP will block
> -until additional environmental noise is gathered.
>  Since Linux 5.6, the
>  .B O_NONBLOCK
>  flag is ignored as
> @@ -116,15 +121,15 @@ .SH DESCRIPTION
>  .BR read (2)
>  from
>  .I /dev/random
> -will return at most 512 bytes
> +has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
> +the maximum size was 512 bytes. (340 bytes before Linux 2.6.12)
>  .\" SEC_XFER_SIZE in drivers/char/random.c
> -(340 bytes before Linux 2.6.12).
>  .PP
>  Writing to \fI/dev/random\fP or \fI/dev/urandom\fP will update the
>  entropy pool with the data written, but this will not result in a
>  higher entropy count.
>  This means that it will impact the contents
> -read from both files, but it will not make reads from
> +read from both files, but it will not make reads from a pre-5.6

To make it easier to grep, prefix verions with the software name (this
is done consistently in the pages).  So something like 'pre-Linux 5.6' 
would work.

Thanks,
Alex

>  \fI/dev/random\fP faster.
>  .SS Usage
>  The
> @@ -145,7 +150,7 @@ .SS Usage
>  network encryption session keys.
>  (All major Linux distributions have saved the seed file across reboots
>  since 2000 at least.)
> -Since reads from
> +Since reads from a pre-5.6
>  .I /dev/random
>  may block, users will usually want to open it in nonblocking mode
>  (or perform a read with timeout),
> @@ -246,6 +251,7 @@ .SS /proc interfaces
>  .RE
>  .TP
>  .I read_wakeup_threshold
> +Removed in Linux 5.6.
>  This file
>  contains the number of bits of entropy required for waking up processes
>  that sleep waiting for entropy from
> diff --git a/man7/random.7 b/man7/random.7
> index 69e6c2403..23aecf2a2 100644
> --- a/man7/random.7
> +++ b/man7/random.7
> @@ -59,17 +59,16 @@ .SS Initialization of the entropy pool
>  When a sufficient number of random bits has been collected, the
>  entropy pool is considered to be initialized.
>  .SS Choice of random source
> -Unless you are doing long-term key generation (and most likely not even
> -then), you probably shouldn't be reading from the
> +Unless your program may run at early-boot, before the entropy pool
> +is initialized, there is no longer any palpable difference between
>  .I /dev/random
> -device or employing
> -.BR getrandom (2)
> -with the
> -.B GRND_RANDOM
> -flag.
> -Instead, either read from the
> +and
>  .I /dev/urandom
> -device or employ
> +since Linux 5.6. (See the table below.)
> +.PP.
> +On older kernels, either read from the
> +.I /dev/urandom
> +device or (especially if you are concerned with early boot) employ
>  .BR getrandom (2)
>  without the
>  .B GRND_RANDOM
> @@ -77,18 +76,6 @@ .SS Choice of random source
>  The cryptographic algorithms used for the
>  .I urandom
>  source are quite conservative, and so should be sufficient for all purposes.
> -.PP
> -The disadvantage of
> -.B GRND_RANDOM
> -and reads from
> -.I /dev/random
> -is that the operation can block for an indefinite period of time.
> -Furthermore, dealing with the partially fulfilled
> -requests that can occur when using
> -.B GRND_RANDOM
> -or when reading from
> -.I /dev/random
> -increases code complexity.
>  .\"
>  .SS Monte Carlo and other probabilistic sampling applications
>  Using these interfaces to provide large quantities of data for
> @@ -122,9 +109,9 @@ .SS Comparison between getrandom, /dev/urandom, and /dev/random
>  T{
>  .I /dev/random
>  T}     T{
> -Blocking pool
> +CSPRNG output
>  T}     T{
> -If entropy too low, blocks until there is enough entropy again
> +Never blocks
>  T}     T{
>  Blocks until enough entropy gathered
>  T}
> @@ -149,17 +136,6 @@ .SS Comparison between getrandom, /dev/urandom, and /dev/random
>  T}
>  T{
>  .BR getrandom ()
> -.B GRND_RANDOM
> -T}     T{
> -Same as
> -.I /dev/random
> -T}     T{
> -If entropy too low, blocks until there is enough entropy again
> -T}     T{
> -Blocks until pool ready
> -T}
> -T{
> -.BR getrandom ()
>  .B GRND_NONBLOCK
>  T}     T{
>  Same as
> @@ -171,21 +147,45 @@ .SS Comparison between getrandom, /dev/urandom, and /dev/random
>  T}
>  T{
>  .BR getrandom ()
> -.B GRND_RANDOM
> -+
> -.B GRND_NONBLOCK
> +.B GRND_INSECURE
>  T}     T{
>  Same as
> -.I /dev/random
> +.I /dev/urandom
>  T}     T{
> -.B EAGAIN
> -if not enough entropy available
> +Never blocks
>  T}     T{
> -.B EAGAIN
> +Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
>  T}
>  .TE
>  .ad
>  .\"
> +.SS The old blocking pool
> +The above table describes the behavior of the interfaces since
> +Linux 5.6.  In older kernels, the
> +.I /dev/random
> +used a separate blocking pool, and
> +.BR getrandom ()
> +had a
> +.B GRND_RANDOM
> +flag for reading from the blocking pool.
> +.\"
> +.PP
> +The older blocking pool was a vestige of a time when the CSPRNG
> +was not trusted.
> +It assumed that entropy can run out by reading the CSPRNG.
> +This has never been the case.
> +Instead, programs using
> +.B GRND_RANDOM
> +and
> +.I /dev/random
> +had to deal with operations blocking indefinitely.
> +Furthermore, dealing with the partially fulfilled
> +requests that can occur when using
> +.B GRND_RANDOM
> +or when reading from
> +.I /dev/random
> +increases code complexity.
> +.\"
>  .SS Generating cryptographic keys
>  The amount of seed material required to generate a cryptographic key
>  equals the effective key size of the key.


-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[Bug 214885] random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=214885

Mingye Wang (arthur200126@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #304322|0                           |1
        is obsolete|                            |

--- Comment #3 from Mingye Wang (arthur200126@gmail.com) ---
Created attachment 306038
  --> 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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 214885] random.{4,7} [man-pages 5.13] do not reflect changes to /dev/random semantics since kernel 5.6

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=214885

--- Comment #4 from Alejandro Colomar (alx@kernel.org) ---
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|0                           |1
>         is obsolete|                            |
> 
> --- Comment #3 from Mingye Wang (arthur200126@gmail.com) ---
> Created attachment 306038
>   --> 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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Mingye Wang]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

Hi Alex,

Apologies for being so slow (1.75 years! wow) at fixing my patch. I've corrected
your mentioned deficits (linebreak, version number) and rebased my patch to the
current HEAD at 46b7bca (Feb 27). Please check my work and tell me
what you think.

Thanks,
Mingye Wang

On Sun, Jul 9, 2023 at 3:07 AM Alejandro Colomar <alx@kernel.org> wrote:
>
> On 6/5/23 05:13, Mingye Wang wrote:
> > Hi Alex,
> >
> > attached are two patches split and revised as requested.
> >
> > Regards,
> > Mingye
>
> Hi!  Here go some comments for one of the patches:
>
> >     * random.7: Revise "choice of random source" to remove any recommen-
>
> Don't hyphenate words here.
>
> > +.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
> > +As of Linux 5.6, \fI/dev/random\fP is identical to \fI/dev/urandom\fP,
> > +except that it blocks during early boot.
> > +A jitter-based seeding technique added in Linux 5.4 should help reduce
> > +block time.
>
> Please use semantic newlines.  See man-pages(7):
>
>     Use semantic newlines
>         In  the  source of a manual page, new sentences should be
>         started on new lines, long sentences should be split into
>         lines at clause breaks (commas, semicolons,  colons,  and
>         so on), and long clauses should be split at phrase bound‐
>         aries.   This  convention,  sometimes  known as "semantic
>         newlines", makes it easier to see the effect of  patches,
>         which often operate at the level of individual sentences,
>         clauses, or phrases.
>
> > +.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
> > +.PP
> > +The pre-5.6 \fI/dev/random\fP device is a legacy interface which dates
> > +back to a time where the cryptographic primitives used in the implementation
> > +of \fI/dev/urandom\fP were not widely trusted. It would return random bytes
> > -read from both files, but it will not make reads from
> > +read from both files, but it will not make reads from a pre-5.6
>
> To make it easier to grep, prefix verions with the software name (this
> is done consistently in the pages).  So something like 'pre-Linux 5.6'
> would work.
>
> Thanks,
> Alex

[-- Attachment #2: 0001-random.-4-7-getrandom.2-Adapt-to-Linux-5.6-changes.patch --]
[-- Type: application/octet-stream, Size: 7720 bytes --]

From e5f38ace3ef79349e35ee393a4f8daea5d471d65 Mon Sep 17 00:00:00 2001
From: Mingye Wang <arthur200126@gmail.com>
Date: Mon, 5 Jun 2023 11:10:12 +0800
Subject: [PATCH 1/3] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

Linux kernel 5.6 no longer has a blocking random pool.  This commit
updates all relevant references to reflect this change.

* random.7: Remove references to the blocking pool in the table.  Add a
  note about the blocking pool.
* random.7: Revise "choice of random source" to remove any recommendation
  of the blocking pool.  Stop suggesting that the blocking pool is
  safer (it's not after initialization).
* random.7: Add table entry for GRND_INSECURE.
* getrandom.2: Add flag entry for GRND_INSECURE.
* getrandom.2: Add removal note to GRND_RANDOM.
* random.4: Split DESCRIPTION paragraph on /dev/random into two, one
  for the new behavior and the other for the old.
* random.4: Adjust size limits and /proc list for 5.6.
* random.4: Mention blocking resolution by high-precision timer entropy.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214885
Signed-Off-By: Mingye Wang <arthur200126@gmail.com>
---
 man/man2/getrandom.2 |  9 ++++++
 man/man4/random.4    | 26 +++++++++++-----
 man/man7/random.7    | 70 ++++++++++++++++++++++++++------------------
 3 files changed, 68 insertions(+), 37 deletions(-)

diff --git a/man/man2/getrandom.2 b/man/man2/getrandom.2
index 094093b..805daaa 100644
--- a/man/man2/getrandom.2
+++ b/man/man2/getrandom.2
@@ -64,6 +64,8 @@ argument is a bit mask that can contain zero or more of the following values
 ORed together:
 .TP
 .B GRND_RANDOM
+.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
+Ignored since Linux 5.6.
 If this bit is set, then random bytes are drawn from the
 .I random
 source
@@ -105,6 +107,13 @@ does not block in these cases, but instead immediately returns \-1 with
 .I errno
 set to
 .BR EAGAIN .
+.TP GRND_INSECURE
+.\" commit 75551dbf112c992bc6c99a972990b3f272247e23
+Added in Linux 5.6.
+Request best-effort, non-cryptographic-quality random bytes.
+If this bit is set, then
+.BR getrandom ()
+will never block or fail due to a lack of entropy.
 .SH RETURN VALUE
 On success,
 .BR getrandom ()
diff --git a/man/man4/random.4 b/man/man4/random.4
index 880c9fc..d01219e 100644
--- a/man/man4/random.4
+++ b/man/man4/random.4
@@ -58,12 +58,20 @@ If this is of concern in your application, use
 .BR getrandom (2)
 or \fI/dev/random\fP instead.
 .P
-The \fI/dev/random\fP device is a legacy interface which dates back to
-a time where the cryptographic primitives used in the implementation
+.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
+As of Linux 5.6, \fI/dev/random\fP is identical to \fI/dev/urandom\fP,
+except that it blocks during early boot.
+A jitter-based seeding technique added in Linux 5.4 should help reduce
+block time.
+.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
+.P
+The pre-Linux 5.6 \fI/dev/random\fP device is a legacy interface which dates
+back to a time where the cryptographic primitives used in the implementation
 of \fI/dev/urandom\fP were not widely trusted.
-It will return random bytes only within the estimated number of
-bits of fresh noise in the entropy pool, blocking if necessary.
-\fI/dev/random\fP is suitable for applications that need
+It would return random bytes only within the estimated number of bits of fresh
+noise in the entropy pool, blocking until additional environmental noise is
+gathered.
+This old \fI/dev/random\fP is suitable for applications that need
 high quality randomness, and can afford indeterminate delays.
 .P
 When the entropy pool is empty, reads from \fI/dev/random\fP will block
@@ -116,7 +124,8 @@ A
 .BR read (2)
 from
 .I /dev/random
-will return at most 512 bytes
+has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
+the maximum size was 512 bytes. (340 bytes before Linux 2.6.12)
 .\" SEC_XFER_SIZE in drivers/char/random.c
 (340 bytes before Linux 2.6.12).
 .P
@@ -124,7 +133,7 @@ Writing to \fI/dev/random\fP or \fI/dev/urandom\fP will update the
 entropy pool with the data written, but this will not result in a
 higher entropy count.
 This means that it will impact the contents
-read from both files, but it will not make reads from
+read from both files, but it will not make reads from a pre-Linux 5.6
 \fI/dev/random\fP faster.
 .SS Usage
 The
@@ -145,7 +154,7 @@ soon as it is reloaded in the boot sequence, and perfectly adequate for
 network encryption session keys.
 (All major Linux distributions have saved the seed file across reboots
 since 2000 at least.)
-Since reads from
+Since reads from a pre-Linux 5.6
 .I /dev/random
 may block, users will usually want to open it in nonblocking mode
 (or perform a read with timeout),
@@ -246,6 +255,7 @@ It contains the value 4096.
 .RE
 .TP
 .I read_wakeup_threshold
+Removed in Linux 5.6.
 This file
 contains the number of bits of entropy required for waking up processes
 that sleep waiting for entropy from
diff --git a/man/man7/random.7 b/man/man7/random.7
index 5062b19..258964c 100644
--- a/man/man7/random.7
+++ b/man/man7/random.7
@@ -59,17 +59,16 @@ The kernel collects bits of entropy from the environment.
 When a sufficient number of random bits has been collected, the
 entropy pool is considered to be initialized.
 .SS Choice of random source
-Unless you are doing long-term key generation (and most likely not even
-then), you probably shouldn't be reading from the
+Unless your program may run at early-boot, before the entropy pool
+is initialized, there is no longer any palpable difference between
 .I /dev/random
-device or employing
-.BR getrandom (2)
-with the
-.B GRND_RANDOM
-flag.
-Instead, either read from the
+and
+.I /dev/urandom
+since Linux 5.6. (See the table below.)
+.PP.
+On older kernels, either read from the
 .I /dev/urandom
-device or employ
+device or (especially if you are concerned with early boot) employ
 .BR getrandom (2)
 without the
 .B GRND_RANDOM
@@ -122,9 +121,9 @@ T}
 T{
 .I /dev/random
 T}	T{
-Blocking pool
+CSPRNG output
 T}	T{
-If entropy too low, blocks until there is enough entropy again
+Never blocks
 T}	T{
 Blocks until enough entropy gathered
 T}
@@ -149,17 +148,6 @@ Blocks until pool ready
 T}
 T{
 .BR getrandom ()
-.B GRND_RANDOM
-T}	T{
-Same as
-.I /dev/random
-T}	T{
-If entropy too low, blocks until there is enough entropy again
-T}	T{
-Blocks until pool ready
-T}
-T{
-.BR getrandom ()
 .B GRND_NONBLOCK
 T}	T{
 Same as
@@ -171,21 +159,45 @@ T}	T{
 T}
 T{
 .BR getrandom ()
-.B GRND_RANDOM
-+
-.B GRND_NONBLOCK
+.B GRND_INSECURE
 T}	T{
 Same as
-.I /dev/random
+.I /dev/urandom
 T}	T{
-.B EAGAIN
-if not enough entropy available
+Never blocks
 T}	T{
-.B EAGAIN
+Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
 T}
 .TE
 .ad
 .\"
+.SS The old blocking pool
+The above table describes the behavior of the interfaces since
+Linux 5.6.  In older kernels, the
+.I /dev/random
+used a separate blocking pool, and
+.BR getrandom ()
+had a
+.B GRND_RANDOM
+flag for reading from the blocking pool.
+.\"
+.PP
+The older blocking pool was a vestige of a time when the CSPRNG
+was not trusted.
+It assumed that entropy can run out by reading the CSPRNG.
+This has never been the case.
+Instead, programs using
+.B GRND_RANDOM
+and
+.I /dev/random
+had to deal with operations blocking indefinitely.
+Furthermore, dealing with the partially fulfilled
+requests that can occur when using
+.B GRND_RANDOM
+or when reading from
+.I /dev/random
+increases code complexity.
+.\"
 .SS Generating cryptographic keys
 The amount of seed material required to generate a cryptographic key
 equals the effective key size of the key.
-- 
2.45.2


[-- Attachment #3: 0002-random.7-weaken-performance-recommendation-for-4.8.patch --]
[-- Type: application/octet-stream, Size: 1139 bytes --]

From 2e7ddf0a4432707acd31982e7956be83c07d7c9c Mon Sep 17 00:00:00 2001
From: Mingye Wang <arthur200126@gmail.com>
Date: Mon, 5 Jun 2023 11:13:07 +0800
Subject: [PATCH 2/3] random.7: weaken performance recommendation for 4.8

---
 man/man7/random.7 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/man/man7/random.7 b/man/man7/random.7
index 258964c..c812ccf 100644
--- a/man/man7/random.7
+++ b/man/man7/random.7
@@ -98,6 +98,13 @@ need cryptographically secure random numbers.
 Instead, use the interfaces described in this page to obtain
 a small amount of data to seed a user-space pseudorandom
 number generator for use by such applications.
+.PP
+.\" commit e192be9d9a30555aae2ca1dc3aad37cba484cd4a
+.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
+Since Linux 4.8, the random interfaces are backed by a much faster
+NUMA-aware ChaCha20 CSPRNG.
+It is still discouraged to use the random interfaces for sampling,
+but if you do, the performance will be much better than before.
 .\"
 .SS Comparison between getrandom, /dev/urandom, and /dev/random
 The following table summarizes the behavior of the various
-- 
2.45.2


[-- Attachment #4: 0003-random.4-update-for-Linux-5.17-and-5.18.patch --]
[-- Type: application/octet-stream, Size: 1411 bytes --]

From c0033d7d5f31bbe162b5af0b46a0f83f4b6465cc Mon Sep 17 00:00:00 2001
From: Mingye Wang <arthur200126@gmail.com>
Date: Mon, 25 Mar 2024 20:38:42 +0800
Subject: [PATCH 3/3] random.4: update for Linux 5.17 and 5.18

There are two further important changes to the procfs interface.
---
 man/man4/random.4 | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/man/man4/random.4 b/man/man4/random.4
index d01219e..539b148 100644
--- a/man/man4/random.4
+++ b/man/man4/random.4
@@ -248,10 +248,16 @@ Normally, this file will have the value 512, but it is writable,
 and can be changed to any value for which an algorithm is available.
 The choices are 32, 64, 128, 256, 512, 1024, or 2048.
 .TP
-Linux 2.6 and later:
+Linux 2.6 to Linux 5.17:
 This file is read-only, and gives the size of the entropy pool in
 .IR bits .
 It contains the value 4096.
+.TP
+.\" 6e8ec2552c7d13991148e551e3325a624d73fac6
+Linux 5.17 and later:
+This file is read-only, and gives the size of the entropy pool in
+.IR bits .
+It contains the value 256.
 .RE
 .TP
 .I read_wakeup_threshold
@@ -272,6 +278,9 @@ or
 for write access to
 .IR /dev/random .
 These values can be changed by writing to the files.
+.\" 489c7fc44b5740d377e8cfdbf0851036e493af00
+In Linux 5.18 and later, wakeup always happens after entropy write.
+This file remains writable, but no longer has any effect.
 .TP
 .I uuid
 .TQ
-- 
2.45.2

Re: [PATCH] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]

Hi Mingye,

On Tue, Mar 04, 2025 at 10:29:48PM +0800, Mingye Wang wrote:
> Hi Alex,
> 
> Apologies for being so slow (1.75 years! wow) at fixing my patch.

Thanks!  No problem.  :-)

> I've corrected
> your mentioned deficits (linebreak, version number) and rebased my patch to the
> current HEAD at 46b7bca (Feb 27). Please check my work and tell me
> what you think.

Would you mind sending each patch in a separate mail?  As
git-send-email(1) does?  It makes it much easier to read and reply to
each patch.  Thanks!  See also:
<https://web.git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING>


Have a lovely day!
Alex

> 
> Thanks,
> Mingye Wang
> 
> On Sun, Jul 9, 2023 at 3:07 AM Alejandro Colomar <alx@kernel.org> wrote:
> >
> > On 6/5/23 05:13, Mingye Wang wrote:
> > > Hi Alex,
> > >
> > > attached are two patches split and revised as requested.
> > >
> > > Regards,
> > > Mingye
> >
> > Hi!  Here go some comments for one of the patches:
> >
> > >     * random.7: Revise "choice of random source" to remove any recommen-
> >
> > Don't hyphenate words here.
> >
> > > +.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
> > > +As of Linux 5.6, \fI/dev/random\fP is identical to \fI/dev/urandom\fP,
> > > +except that it blocks during early boot.
> > > +A jitter-based seeding technique added in Linux 5.4 should help reduce
> > > +block time.
> >
> > Please use semantic newlines.  See man-pages(7):
> >
> >     Use semantic newlines
> >         In  the  source of a manual page, new sentences should be
> >         started on new lines, long sentences should be split into
> >         lines at clause breaks (commas, semicolons,  colons,  and
> >         so on), and long clauses should be split at phrase bound‐
> >         aries.   This  convention,  sometimes  known as "semantic
> >         newlines", makes it easier to see the effect of  patches,
> >         which often operate at the level of individual sentences,
> >         clauses, or phrases.
> >
> > > +.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
> > > +.PP
> > > +The pre-5.6 \fI/dev/random\fP device is a legacy interface which dates
> > > +back to a time where the cryptographic primitives used in the implementation
> > > +of \fI/dev/urandom\fP were not widely trusted. It would return random bytes
> > > -read from both files, but it will not make reads from
> > > +read from both files, but it will not make reads from a pre-5.6
> >
> > To make it easier to grep, prefix verions with the software name (this
> > is done consistently in the pages).  So something like 'pre-Linux 5.6'
> > would work.
> >
> > Thanks,
> > Alex





-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH 1/3] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Mingye Wang]

Linux kernel 5.6 no longer has a blocking random pool.  This commit
updates all relevant references to reflect this change.

* random.7: Remove references to the blocking pool in the table.  Add a
  note about the blocking pool.
* random.7: Revise "choice of random source" to remove any recommendation
  of the blocking pool.  Stop suggesting that the blocking pool is
  safer (it's not after initialization).
* random.7: Add table entry for GRND_INSECURE.
* getrandom.2: Add flag entry for GRND_INSECURE.
* getrandom.2: Add removal note to GRND_RANDOM.
* random.4: Split DESCRIPTION paragraph on /dev/random into two, one
  for the new behavior and the other for the old.
* random.4: Adjust size limits and /proc list for 5.6.
* random.4: Mention blocking resolution by high-precision timer entropy.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214885
Signed-Off-By: Mingye Wang <arthur200126@gmail.com>
---
 man/man2/getrandom.2 |  9 ++++++
 man/man4/random.4    | 30 ++++++++++++++-----
 man/man7/random.7    | 70 ++++++++++++++++++++++++++------------------
 3 files changed, 72 insertions(+), 37 deletions(-)

diff --git a/man/man2/getrandom.2 b/man/man2/getrandom.2
index 9e782e6..5f0a2da 100644
--- a/man/man2/getrandom.2
+++ b/man/man2/getrandom.2
@@ -62,6 +62,8 @@ argument is a bit mask that can contain zero or more of the following values
 ORed together:
 .TP
 .B GRND_RANDOM
+.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
+Ignored since Linux 5.6.
 If this bit is set, then random bytes are drawn from the
 .I random
 source
@@ -103,6 +105,13 @@ does not block in these cases, but instead immediately returns \-1 with
 .I errno
 set to
 .BR EAGAIN .
+.TP GRND_INSECURE
+.\" commit 75551dbf112c992bc6c99a972990b3f272247e23
+Added in Linux 5.6.
+Request best-effort, non-cryptographic-quality random bytes.
+If this bit is set, then
+.BR getrandom ()
+will never block or fail due to a lack of entropy.
 .SH RETURN VALUE
 On success,
 .BR getrandom ()
diff --git a/man/man4/random.4 b/man/man4/random.4
index 0a651b0..95200bc 100644
--- a/man/man4/random.4
+++ b/man/man4/random.4
@@ -56,17 +56,29 @@ or
 .I /dev/random
 instead.
 .P
-The
+.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
+As of Linux 5.6,
+.I /dev/random
+is identical to
+.I /dev/urandom
+except that it blocks during early boot.
+A jitter-based seeding technique added in Linux 5.4 should help reduce
+block time.
+.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
+.P
+The pre-Linux 5.6
 .I /dev/random
-device is a legacy interface which dates back to
+device was a legacy interface which dates back to
 a time where the cryptographic primitives used in the implementation
 of
 .I /dev/urandom
 were not widely trusted.
-It will return random bytes only within the estimated number of
-bits of fresh noise in the entropy pool, blocking if necessary.
+It would return random bytes only within the estimated number of bits of fresh
+noise in the entropy pool, blocking until additional environmental noise is
+gathered.
+This old
 .I /dev/random
-is suitable for applications that need
+was suitable for applications that need
 high quality randomness, and can afford indeterminate delays.
 .P
 When the entropy pool is empty, reads from
@@ -121,7 +133,8 @@ A
 .BR read (2)
 from
 .I /dev/random
-will return at most 512 bytes
+has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
+the maximum size was 512 bytes. (340 bytes before Linux 2.6.12)
 .\" SEC_XFER_SIZE in drivers/char/random.c
 (340 bytes before Linux 2.6.12).
 .P
@@ -133,7 +146,7 @@ will update the
 entropy pool with the data written, but this will not result in a
 higher entropy count.
 This means that it will impact the contents
-read from both files, but it will not make reads from
+read from both files, but it will not make reads from a pre-Linux 5.6
 .I /dev/random
 faster.
 .SS Usage
@@ -158,7 +171,7 @@ soon as it is reloaded in the boot sequence, and perfectly adequate for
 network encryption session keys.
 (All major Linux distributions have saved the seed file across reboots
 since 2000 at least.)
-Since reads from
+Since reads from a pre-Linux 5.6
 .I /dev/random
 may block, users will usually want to open it in nonblocking mode
 (or perform a read with timeout),
@@ -262,6 +275,7 @@ It contains the value 4096.
 .RE
 .TP
 .I read_wakeup_threshold
+Removed in Linux 5.6.
 This file
 contains the number of bits of entropy required for waking up processes
 that sleep waiting for entropy from
diff --git a/man/man7/random.7 b/man/man7/random.7
index fda408d..c5e959f 100644
--- a/man/man7/random.7
+++ b/man/man7/random.7
@@ -54,17 +54,16 @@ The kernel collects bits of entropy from the environment.
 When a sufficient number of random bits has been collected, the
 entropy pool is considered to be initialized.
 .SS Choice of random source
-Unless you are doing long-term key generation (and most likely not even
-then), you probably shouldn't be reading from the
+Unless your program may run at early-boot, before the entropy pool
+is initialized, there is no longer any palpable difference between
 .I /dev/random
-device or employing
-.BR getrandom (2)
-with the
-.B GRND_RANDOM
-flag.
-Instead, either read from the
+and
+.I /dev/urandom
+since Linux 5.6. (See the table below.)
+.PP.
+On older kernels, either read from the
 .I /dev/urandom
-device or employ
+device or (especially if you are concerned with early boot) employ
 .BR getrandom (2)
 without the
 .B GRND_RANDOM
@@ -117,9 +116,9 @@ T}
 T{
 .I /dev/random
 T}	T{
-Blocking pool
+CSPRNG output
 T}	T{
-If entropy too low, blocks until there is enough entropy again
+Never blocks
 T}	T{
 Blocks until enough entropy gathered
 T}
@@ -144,17 +143,6 @@ Blocks until pool ready
 T}
 T{
 .BR getrandom ()
-.B GRND_RANDOM
-T}	T{
-Same as
-.I /dev/random
-T}	T{
-If entropy too low, blocks until there is enough entropy again
-T}	T{
-Blocks until pool ready
-T}
-T{
-.BR getrandom ()
 .B GRND_NONBLOCK
 T}	T{
 Same as
@@ -166,21 +154,45 @@ T}	T{
 T}
 T{
 .BR getrandom ()
-.B GRND_RANDOM
-+
-.B GRND_NONBLOCK
+.B GRND_INSECURE
 T}	T{
 Same as
-.I /dev/random
+.I /dev/urandom
 T}	T{
-.B EAGAIN
-if not enough entropy available
+Never blocks
 T}	T{
-.B EAGAIN
+Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
 T}
 .TE
 .ad
 .\"
+.SS The old blocking pool
+The above table describes the behavior of the interfaces since
+Linux 5.6.  In older kernels, the
+.I /dev/random
+used a separate blocking pool, and
+.BR getrandom ()
+had a
+.B GRND_RANDOM
+flag for reading from the blocking pool.
+.\"
+.PP
+The older blocking pool was a vestige of a time when the CSPRNG
+was not trusted.
+It assumed that entropy can run out by reading the CSPRNG.
+This has never been the case.
+Instead, programs using
+.B GRND_RANDOM
+and
+.I /dev/random
+had to deal with operations blocking indefinitely.
+Furthermore, dealing with the partially fulfilled
+requests that can occur when using
+.B GRND_RANDOM
+or when reading from
+.I /dev/random
+increases code complexity.
+.\"
 .SS Generating cryptographic keys
 The amount of seed material required to generate a cryptographic key
 equals the effective key size of the key.
-- 
2.51.0

Re: [PATCH 1/3] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 9618 bytes --]

CC += Andy, Ted

Hi Mingye,

On Sun, Nov 09, 2025 at 10:36:00AM +0800, Mingye Wang wrote:
> Linux kernel 5.6 no longer has a blocking random pool.  This commit
> updates all relevant references to reflect this change.
> 
> * random.7: Remove references to the blocking pool in the table.  Add a
>   note about the blocking pool.
> * random.7: Revise "choice of random source" to remove any recommendation
>   of the blocking pool.  Stop suggesting that the blocking pool is
>   safer (it's not after initialization).
> * random.7: Add table entry for GRND_INSECURE.
> * getrandom.2: Add flag entry for GRND_INSECURE.
> * getrandom.2: Add removal note to GRND_RANDOM.
> * random.4: Split DESCRIPTION paragraph on /dev/random into two, one
>   for the new behavior and the other for the old.
> * random.4: Adjust size limits and /proc list for 5.6.
> * random.4: Mention blocking resolution by high-precision timer entropy.
> 
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214885
> Signed-Off-By: Mingye Wang <arthur200126@gmail.com>
> ---
>  man/man2/getrandom.2 |  9 ++++++
>  man/man4/random.4    | 30 ++++++++++++++-----
>  man/man7/random.7    | 70 ++++++++++++++++++++++++++------------------
>  3 files changed, 72 insertions(+), 37 deletions(-)
> 
> diff --git a/man/man2/getrandom.2 b/man/man2/getrandom.2
> index 9e782e6..5f0a2da 100644
> --- a/man/man2/getrandom.2
> +++ b/man/man2/getrandom.2
> @@ -62,6 +62,8 @@ argument is a bit mask that can contain zero or more of the following values
>  ORed together:
>  .TP
>  .B GRND_RANDOM
> +.\" commit 48446f198f9adcb499b30332488dfd5bc3f176f6
> +Ignored since Linux 5.6.
>  If this bit is set, then random bytes are drawn from the
>  .I random
>  source
> @@ -103,6 +105,13 @@ does not block in these cases, but instead immediately returns \-1 with
>  .I errno
>  set to
>  .BR EAGAIN .
> +.TP GRND_INSECURE

.TP should have the tag in the next line (see the hunk above, for
example).

	.TP
	.B GRND_INSECURE

> +.\" commit 75551dbf112c992bc6c99a972990b3f272247e23
> +Added in Linux 5.6.

We usually put this either in the HISTORY section, or in the same line
as the tag:

	.TP
	.BR GRND_INSECURE " (since Linux 5.6)"

> +Request best-effort, non-cryptographic-quality random bytes.
> +If this bit is set, then
> +.BR getrandom ()
> +will never block or fail due to a lack of entropy.
>  .SH RETURN VALUE
>  On success,
>  .BR getrandom ()
> diff --git a/man/man4/random.4 b/man/man4/random.4
> index 0a651b0..95200bc 100644
> --- a/man/man4/random.4
> +++ b/man/man4/random.4
> @@ -56,17 +56,29 @@ or
>  .I /dev/random
>  instead.
>  .P
> -The
> +.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
> +As of Linux 5.6,

For consistency:

	Since Linux 5.6,

> +.I /dev/random
> +is identical to
> +.I /dev/urandom

Missing comma:

	.IR /dev/urandom ,

> +except that it blocks during early boot.
> +A jitter-based seeding technique added in Linux 5.4 should help reduce
> +block time.
> +.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
> +.P
> +The pre-Linux 5.6
>  .I /dev/random
> -device is a legacy interface which dates back to
> +device was a legacy interface which dates back to
>  a time where the cryptographic primitives used in the implementation
>  of
>  .I /dev/urandom
>  were not widely trusted.
> -It will return random bytes only within the estimated number of
> -bits of fresh noise in the entropy pool, blocking if necessary.
> +It would return random bytes only within the estimated number of bits of fresh
> +noise in the entropy pool, blocking until additional environmental noise is
> +gathered.
> +This old
>  .I /dev/random
> -is suitable for applications that need
> +was suitable for applications that need
>  high quality randomness, and can afford indeterminate delays.
>  .P
>  When the entropy pool is empty, reads from
> @@ -121,7 +133,8 @@ A
>  .BR read (2)
>  from
>  .I /dev/random
> -will return at most 512 bytes
> +has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
> +the maximum size was 512 bytes. (340 bytes before Linux 2.6.12)
>  .\" SEC_XFER_SIZE in drivers/char/random.c
>  (340 bytes before Linux 2.6.12).
>  .P
> @@ -133,7 +146,7 @@ will update the
>  entropy pool with the data written, but this will not result in a
>  higher entropy count.
>  This means that it will impact the contents
> -read from both files, but it will not make reads from
> +read from both files, but it will not make reads from a pre-Linux 5.6
>  .I /dev/random
>  faster.
>  .SS Usage
> @@ -158,7 +171,7 @@ soon as it is reloaded in the boot sequence, and perfectly adequate for
>  network encryption session keys.
>  (All major Linux distributions have saved the seed file across reboots
>  since 2000 at least.)
> -Since reads from
> +Since reads from a pre-Linux 5.6
>  .I /dev/random
>  may block, users will usually want to open it in nonblocking mode
>  (or perform a read with timeout),
> @@ -262,6 +275,7 @@ It contains the value 4096.
>  .RE
>  .TP
>  .I read_wakeup_threshold
> +Removed in Linux 5.6.
>  This file
>  contains the number of bits of entropy required for waking up processes
>  that sleep waiting for entropy from
> diff --git a/man/man7/random.7 b/man/man7/random.7
> index fda408d..c5e959f 100644
> --- a/man/man7/random.7
> +++ b/man/man7/random.7
> @@ -54,17 +54,16 @@ The kernel collects bits of entropy from the environment.
>  When a sufficient number of random bits has been collected, the
>  entropy pool is considered to be initialized.
>  .SS Choice of random source
> -Unless you are doing long-term key generation (and most likely not even
> -then), you probably shouldn't be reading from the
> +Unless your program may run at early-boot, before the entropy pool
> +is initialized, there is no longer any palpable difference between
>  .I /dev/random
> -device or employing
> -.BR getrandom (2)
> -with the
> -.B GRND_RANDOM
> -flag.
> -Instead, either read from the
> +and
> +.I /dev/urandom
> +since Linux 5.6. (See the table below.)
> +.PP.
> +On older kernels, either read from the
>  .I /dev/urandom
> -device or employ
> +device or (especially if you are concerned with early boot) employ
>  .BR getrandom (2)
>  without the
>  .B GRND_RANDOM
> @@ -117,9 +116,9 @@ T}
>  T{
>  .I /dev/random
>  T}	T{
> -Blocking pool
> +CSPRNG output
>  T}	T{
> -If entropy too low, blocks until there is enough entropy again
> +Never blocks
>  T}	T{
>  Blocks until enough entropy gathered
>  T}
> @@ -144,17 +143,6 @@ Blocks until pool ready
>  T}
>  T{
>  .BR getrandom ()
> -.B GRND_RANDOM
> -T}	T{
> -Same as
> -.I /dev/random
> -T}	T{
> -If entropy too low, blocks until there is enough entropy again
> -T}	T{
> -Blocks until pool ready
> -T}
> -T{
> -.BR getrandom ()
>  .B GRND_NONBLOCK
>  T}	T{
>  Same as
> @@ -166,21 +154,45 @@ T}	T{
>  T}
>  T{
>  .BR getrandom ()
> -.B GRND_RANDOM
> -+
> -.B GRND_NONBLOCK
> +.B GRND_INSECURE
>  T}	T{
>  Same as
> -.I /dev/random
> +.I /dev/urandom
>  T}	T{
> -.B EAGAIN
> -if not enough entropy available
> +Never blocks

Does /dev/urandom block when reading with read(2) before the pool is
ready?  I assume it blocks.  This probably means the pool of
GRND_INSECURE is the same as /dev/urandom only after the pool is ready,
and before it uses a different pool.  And because this flag is intended
to be used before the /dev/urandom pool is ready (IIUC), it would be
important to document this difference.

CC += Andy, Ted

>  T}	T{
> -.B EAGAIN
> +Returns output from uninitialized CSPRNG (may be low entropy and unsuitable for cryptography)
>  T}
>  .TE
>  .ad
>  .\"
> +.SS The old blocking pool
> +The above table describes the behavior of the interfaces since
> +Linux 5.6.  In older kernels, the

Please use semantic newlines.  See man-pages(7):

$ MANWIDTH=72 man man-pages | sed -n '/Use semantic newlines/,/^$/p'
   Use semantic newlines
     In the source of a manual page, new sentences should be started on
     new lines, long sentences should be split  into  lines  at  clause
     breaks  (commas,  semicolons, colons, and so on), and long clauses
     should be split at phrase boundaries.  This convention,  sometimes
     known as "semantic newlines", makes it easier to see the effect of
     patches, which often operate at the level of individual sentences,
     clauses, or phrases.

> +.I /dev/random
> +used a separate blocking pool, and
> +.BR getrandom ()
> +had a
> +.B GRND_RANDOM
> +flag for reading from the blocking pool.
> +.\"
> +.PP

Should be '.P'.

> +The older blocking pool was a vestige of a time when the CSPRNG
> +was not trusted.
> +It assumed that entropy can run out by reading the CSPRNG.
> +This has never been the case.
> +Instead, programs using

Instead of what?  I think it reads better if we just remove that word.

> +.B GRND_RANDOM
> +and
> +.I /dev/random
> +had to deal with operations blocking indefinitely.
> +Furthermore, dealing with the partially fulfilled
> +requests that can occur when using
> +.B GRND_RANDOM
> +or when reading from
> +.I /dev/random
> +increases code complexity.
> +.\"

Have a lovely day!
Alex

>  .SS Generating cryptographic keys
>  The amount of seed material required to generate a cryptographic key
>  equals the effective key size of the key.
> -- 
> 2.51.0
> 

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v4 1/3] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Mingye Wang]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

On Mon, Nov 10, 2025 at 11:05 AM Mingye Wang <arthur200126@gmail.com> wrote:
>
> > Does /dev/urandom block when reading with read(2) before the pool is
> ready?  I assume it blocks.
>
> From what I've heard it does not. Working on other comments.

Done working on the review comments, but git send-email is not working
for me again (it accepts no proxy settings and tunnels are flakey;
worse, it doesn't save my multi-sentence edited heading, or my
in-reply to string which I need to copy again, or the recipient
list...). I apologize but I am sending it as an attachment.

I am sending only the revised version of the patch you commented on
(the one that touches three files, random.{4,7}, getrandom.2). You
might notice that this patch is much larger. This is because when
editing the table I noticed that there's really no reason to keep the
"Pool" column around for 5.6+, but removing it also felt off. In the
end I just made two separate tables, but with identical cell-width
settings.

Speaking of cell-width settings, the existing version was not filling
the entire screen, which contravenes what man-pages(7) says about
using lbx. Adding an "x" does make it look nicer too.

(I have no idea whether this is the fourth version, but it's
definitely after the third and five seems too many. In any case, I
will be incrementing this number in future patch submissions to keep
things navigable.)

Regards,
Mingye Wang (Artoria2e5)

[-- Attachment #2: 0001-random.-4-7-getrandom.2-Adapt-to-Linux-5.6-changes.patch --]
[-- Type: application/x-patch, Size: 7689 bytes --]

Re: [PATCH v4 1/3] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

Hi Mingye,

On Mon, Nov 10, 2025 at 11:51:30AM +0800, Mingye Wang wrote:
> On Mon, Nov 10, 2025 at 11:05 AM Mingye Wang <arthur200126@gmail.com> wrote:
> >
> > > Does /dev/urandom block when reading with read(2) before the pool is
> > ready?  I assume it blocks.
> >
> > From what I've heard it does not. Working on other comments.
> 
> Done working on the review comments, but git send-email is not working
> for me again (it accepts no proxy settings and tunnels are flakey;
> worse, it doesn't save my multi-sentence edited heading, or my
> in-reply to string which I need to copy again, or the recipient
> list...). I apologize but I am sending it as an attachment.

This might be helpful:

	$ cat CONTRIBUTING.d/git | sed -n '/^   git-send-email/,+9p'
	   git-send-email(1)
	       If mutt(1) or neomutt(1) are configured in the system,
	       git-send-email(1) can be configured to use any of them as a
	       driver.  Recent versions of neomutt(1) can enable crypto with -C.

		   $ git config --global \
			   sendemail.sendmailcmd 'neomutt -C -H - && true';
	       or
		   $ git config --global sendemail.sendmailcmd 'mutt -H - && true';

That's what I use to sign my email containing patches.  I use
git-send-email(1) on the command line, but it calls neomutt(1) for the
actual sending.  If you use mutt(1) or neomutt(1), you could do this.

> I am sending only the revised version of the patch you commented on
> (the one that touches three files, random.{4,7}, getrandom.2). You
> might notice that this patch is much larger. This is because when
> editing the table I noticed that there's really no reason to keep the
> "Pool" column around for 5.6+, but removing it also felt off. In the
> end I just made two separate tables, but with identical cell-width
> settings.

I'd prefer that change in a separate patch.  I'll confirm when I see
the patch, but in general, I'd like to avoid putting actual changes with
formatting changes in the same commit, unless they're somehow tied
together for a good reason.

> 
> Speaking of cell-width settings, the existing version was not filling
> the entire screen, which contravenes what man-pages(7) says about
> using lbx. Adding an "x" does make it look nicer too.

Okay.  Although I'd prefer that as a separate patch.

> (I have no idea whether this is the fourth version, but it's
> definitely after the third and five seems too many. In any case, I
> will be incrementing this number in future patch submissions to keep
> things navigable.)

Okay, that's fine.

> 
> Regards,
> Mingye Wang (Artoria2e5)

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v4 1/3] random.{4,7}, getrandom.2: Adapt to Linux 5.6 changes

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 5004 bytes --]

Hi Mingye,

On Mon, Nov 10, 2025 at 11:51:30AM +0800, Mingye Wang wrote:
> On Mon, Nov 10, 2025 at 11:05 AM Mingye Wang <arthur200126@gmail.com> wrote:
> >
> > > Does /dev/urandom block when reading with read(2) before the pool is
> > ready?  I assume it blocks.
> >
> > From what I've heard it does not. Working on other comments.
> 
[...]
> 
> I am sending only the revised version of the patch you commented on
> (the one that touches three files, random.{4,7}, getrandom.2). You
> might notice that this patch is much larger. This is because when
> editing the table I noticed that there's really no reason to keep the
> "Pool" column around for 5.6+, but removing it also felt off. In the
> end I just made two separate tables, but with identical cell-width
> settings.

Please split into more patches.  I think this patch could be broken into
a set of many small patches, each of which does one thing.  5 or 10
patches would be okay.

> Speaking of cell-width settings, the existing version was not filling
> the entire screen, which contravenes what man-pages(7) says about
> using lbx. Adding an "x" does make it look nicer too.
> 
> (I have no idea whether this is the fourth version, but it's
> definitely after the third and five seems too many. In any case, I
> will be incrementing this number in future patch submissions to keep
> things navigable.)
> 
> Regards,
> Mingye Wang (Artoria2e5)

Some review of v4:

	diff --git a/man/man4/random.4 b/man/man4/random.4
	index 0a651b03f..071fc99ef 100644
	--- a/man/man4/random.4
	+++ b/man/man4/random.4
	@@ -56,17 +56,29 @@ .SH DESCRIPTION
	 .I /dev/random
	 instead.
	 .P
	-The
	+.\" commit 30c08efec8884fb106b8e57094baa51bb4c44e32
	+Since Linux 5.6,
	 .I /dev/random
	-device is a legacy interface which dates back to
	+is identical to
	+.IR /dev/urandom ,
	+except that it blocks during early boot.
	+A jitter-based seeding technique added in Linux 5.4 should help reduce
	+block time.
	+.\" commit 50ee7529ec4500c88f8664560770a7a1b65db72b
	+.P
	+The pre-Linux 5.6
	+.I /dev/random
	+device was a legacy interface which dates back to

I'd prefer 'Before Linux 5.6,' instead of 'The pre-Linux 5.6'.

	 a time where the cryptographic primitives used in the implementation
	 of
	 .I /dev/urandom
	 were not widely trusted.
	-It will return random bytes only within the estimated number of
	-bits of fresh noise in the entropy pool, blocking if necessary.
	+It would return random bytes only within the estimated number of bits of fresh
	+noise in the entropy pool, blocking until additional environmental noise is
	+gathered.
	+This old
	 .I /dev/random

Please use semantic newlines.  See man-pages(7):

$ MANWIDTH=72 man man-pages | sed -n '/Use semantic newlines/,/^$/p'
   Use semantic newlines
     In the source of a manual page, new sentences should be started on
     new lines, long sentences should be split  into  lines  at  clause
     breaks  (commas,  semicolons, colons, and so on), and long clauses
     should be split at phrase boundaries.  This convention,  sometimes
     known as "semantic newlines", makes it easier to see the effect of
     patches, which often operate at the level of individual sentences,
     clauses, or phrases.

I'd write it as:

```
It would return random bytes
only within the estimated number of bits of fresh noise
in the entropy pool,
blocking until additional environmental noise is gathered.
```

Same here:

	@@ -121,7 +133,8 @@ .SH DESCRIPTION
	 .BR read (2)
	 from
	 .I /dev/random
	-will return at most 512 bytes
	+has the same maximum size since Linux 5.6. Between Linux 3.16 and 5.5,
	+the maximum size was 512 bytes
	 .\" SEC_XFER_SIZE in drivers/char/random.c
	 (340 bytes before Linux 2.6.12).
	 .P

Use .P instead of .PP here:

	diff --git a/man/man7/random.7 b/man/man7/random.7
	index fda408d38..65e21a07e 100644
	--- a/man/man7/random.7
	+++ b/man/man7/random.7
	@@ -54,17 +54,16 @@ .SS Initialization of the entropy pool
	 When a sufficient number of random bits has been collected, the
	 entropy pool is considered to be initialized.
	 .SS Choice of random source
	-Unless you are doing long-term key generation (and most likely not even
	-then), you probably shouldn't be reading from the
	+Unless your program may run at early-boot, before the entropy pool
	+is initialized, there is no longer any palpable difference between
	 .I /dev/random
	-device or employing
	-.BR getrandom (2)
	-with the
	-.B GRND_RANDOM
	-flag.
	-Instead, either read from the
	+and
	 .I /dev/urandom
	-device or employ
	+since Linux 5.6 (see the table below).
	+.PP
	+On older kernels, either read from the
	+.I /dev/urandom
	+device or (especially if you are concerned with early boot) employ
	 .BR getrandom (2)
	 without the
	 .B GRND_RANDOM


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]