[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260814151715.GY27423@brightrain.aerifal.cx>
Date: Fri, 14 Aug 2026 11:17:16 -0400
From: Rich Felker <dalias@...c.org>
To: Jonas Böttiger <jonasboettiger@...oud.com>
Cc: musl@...ts.openwall.com
Subject: Re: vDSO-based getrandom
On Fri, Aug 14, 2026 at 03:19:56PM +0200, Jonas Böttiger wrote:
> Please CC me on any responses, I’m not subscribed to the mailing list.
>
> Dear all,
>
> I’m a member of the T-libs team maintaining Rust's standard library.
> We’re in the process of stabilising support for random number
> generation (see [1]). The proposed API works quite similar to
> OpenBSD’s arc4random_buf[2] function in that it allows users to fill
> a buffer with random data suited for cryptography. To provide the
> best security (and make our job as maintainers easier), the Linux
> implementation of this (see [3]) tries to call getrandom and falls
> back to reading from /dev/urandom if the syscall doesn’t exist. The
> recent addition of vDSO acceleration for getrandom[4] makes this
> implementation sufficiently performant on glibc even in the face of
> users making loads of tiny requests – which they’ll probably do
> given that the proposed SystemRng is the de-facto default that we
> point people towards.
>
> Thus my request: would it be possible to add vDSO support to musl’s
> getrandom shim? glibc already has support for it[5], but musl is
> quite a popular target among Rust developers too…
As I understand it, getrandom is intended as an interface to obtain
seed entropy, not as one to call repeatedly for each new random
number. The vdso function seems misguided and undesirable to use. At
best, it's the same as if we just made getrandom only use the syscall
on the first invocation for seed purposes, then used a suitable CSPRNG
in userspace for subsequent calls. This is something we may already
need to do if we're going to fix missing getentropy on old kernels.
At worst, though, using the vdso might result in a misguided kernel
trying to "optimize performance" giving us random numbers from an
insecure source like RDRAND rather than from a verifiable software
CSPRNG.
As such, I think it's irresponsible to use the vdso here.
There is a conversaion that's been left incomplete on what, if any,
interfaces we should be providing userspace CSPRNG for. At one time
POSIX was pursuing the posix_random proposal, which would have been
the natural layer for it to be at, but that was abandoned in favor of
adopting the BSD (glibc and musl also have it) getentropy, which
amounts to a simpler version of getrandom and is presently implemented
as a wrapper around it.
In the mean time, the right behavior for applications seems to still
be using getrandom to seed a CSPRNG of their own if they need a large
volume of random bits, and falling back to /dev/urandom or other
approaches on ENOSYS.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
