aboutsummaryrefslogtreecommitdiff
path: root/manual
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2022-07-26 21:58:22 +0200
committerAdhemerval Zanella <adhemerval.zanella@linaro.org>2022-07-27 08:58:27 -0300
commiteaad4f9e8f07fc43618f6c8635a7e82831a423dd (patch)
tree3797516dc1f679d844b37a843b64811dd33af80d /manual
parent3a380458201262ed01d913a1d9e3ff73d0166043 (diff)
downloadglibc-eaad4f9e8f07fc43618f6c8635a7e82831a423dd.zip
glibc-eaad4f9e8f07fc43618f6c8635a7e82831a423dd.tar.gz
glibc-eaad4f9e8f07fc43618f6c8635a7e82831a423dd.tar.bz2
arc4random: simplify design for better safety
Rather than buffering 16 MiB of entropy in userspace (by way of chacha20), simply call getrandom() every time. This approach is doubtlessly slower, for now, but trying to prematurely optimize arc4random appears to be leading toward all sorts of nasty properties and gotchas. Instead, this patch takes a much more conservative approach. The interface is added as a basic loop wrapper around getrandom(), and then later, the kernel and libc together can work together on optimizing that. This prevents numerous issues in which userspace is unaware of when it really must throw away its buffer, since we avoid buffering all together. Future improvements may include userspace learning more from the kernel about when to do that, which might make these sorts of chacha20-based optimizations more possible. The current heuristic of 16 MiB is meaningless garbage that doesn't correspond to anything the kernel might know about. So for now, let's just do something conservative that we know is correct and won't lead to cryptographic issues for users of this function. This patch might be considered along the lines of, "optimization is the root of all evil," in that the much more complex implementation it replaces moves too fast without considering security implications, whereas the incremental approach done here is a much safer way of going about things. Once this lands, we can take our time in optimizing this properly using new interplay between the kernel and userspace. getrandom(0) is used, since that's the one that ensures the bytes returned are cryptographically secure. But on systems without it, we fallback to using /dev/urandom. This is unfortunate because it means opening a file descriptor, but there's not much of a choice. Secondly, as part of the fallback, in order to get more or less the same properties of getrandom(0), we poll on /dev/random, and if the poll succeeds at least once, then we assume the RNG is initialized. This is a rough approximation, as the ancient "non-blocking pool" initialized after the "blocking pool", not before, and it may not port back to all ancient kernels, though it does to all kernels supported by glibc (≥3.2), so generally it's the best approximation we can do. The motivation for including arc4random, in the first place, is to have source-level compatibility with existing code. That means this patch doesn't attempt to litigate the interface itself. It does, however, choose a conservative approach for implementing it. Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Florian Weimer <fweimer@redhat.com> Cc: Cristian Rodríguez <crrodriguez@opensuse.org> Cc: Paul Eggert <eggert@cs.ucla.edu> Cc: Mark Harris <mark.hsj@gmail.com> Cc: Eric Biggers <ebiggers@kernel.org> Cc: linux-crypto@vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Diffstat (limited to 'manual')
-rw-r--r--manual/math.texi13
1 files changed, 3 insertions, 10 deletions
diff --git a/manual/math.texi b/manual/math.texi
index 76132e9..7f0499a 100644
--- a/manual/math.texi
+++ b/manual/math.texi
@@ -1993,17 +1993,10 @@ This section describes the random number functions provided as a GNU
extension, based on OpenBSD interfaces.
@Theglibc{} uses kernel entropy obtained either through @code{getrandom}
-or by reading @file{/dev/urandom} to seed and periodically re-seed the
-internal state. A per-thread data pool is used, which allows fast output
-generation.
+or by reading @file{/dev/urandom} to seed.
-Although these functions provide higher random quality than ISO, BSD, and
-SVID functions, these still use a Pseudo-Random generator and should not
-be used in cryptographic contexts.
-
-The internal state is cleared and reseeded with kernel entropy on @code{fork}
-and @code{_Fork}. It is not cleared on either a direct @code{clone} syscall
-or when using @theglibc{} @code{syscall} function.
+These functions provide higher random quality than ISO, BSD, and SVID
+functions, and may be used in cryptographic contexts.
The prototypes for these functions are in @file{stdlib.h}.
@pindex stdlib.h