rnd.4: Explain why libraries should use kern.arandom over /dev/urandom

share/man/man4/rnd.4

@@ -1,4 +1,4 @@
-.\"	$NetBSD: rnd.4,v 1.29 2020/04/30 03:28:18 riastradh Exp $
+.\"	$NetBSD: rnd.4,v 1.30 2020/05/01 12:30:16 nia Exp $
 .\"
 .\" Copyright (c) 2014-2019 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -51,10 +51,32 @@ Will block early at boot if the system's state is known to be
 predictable.
 .El
 .Pp
-Applications should read from
+Applications can read from
 .Pa /dev/urandom
 when they need randomly generated data, e.g. key material for
-cryptography or seeds for simulations.
+cryptography or seeds for simulations, and the device is known
+to be available.
+.Pp
+A
+.Xr sysctl 7
+variable,
+.Li kern.arandom ,
+provides equivalent functionality to
+.Pa /dev/urandom
+and will never block.  However, it only returns up to 256 bytes per call.
+This is expected to be enough for seeding most cryptographically secure
+random number generators and ciphers, and if more data is required the
+variable can be queried again.
+.Pp
+Applications should read from the sysctl variable when a high level of
+reliability is required, or the runtime environment cannot be predicted,
+e.g. in a library.  It is possible that
+.Pa /dev/urandom
+is unavailable due to the application being in a
+.Xr chroot 8
+environment, or when other restrictions such as those enforced by
+.Xr setrlimit 2
+apply.
 .Pp
 Systems should be engineered to judiciously read at least once from
 .Pa /dev/random
@@ -485,6 +507,7 @@ pools and consolidated into a global pool.
 Keys for
 .Pa /dev/random ,
 .Pa /dev/urandom ,
+.Li kern.arandom ,
 and the in-kernel
 .Xr cprng 9
 subsystem are extracted from the global pool.