[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <55A98D02-732F-478A-BB4A-422B7DEA7713@Wilcox-Tech.com>
Date: Fri, 14 Aug 2026 11:23:11 -0500
From: Anna Wilcox <AWilcox@...cox-Tech.com>
To: musl@...ts.openwall.com
Cc: Jonas Böttiger <jonasboettiger@...oud.com>,
Rich Felker <dalias@...c.org>
Subject: Re: vDSO-based getrandom
On Aug 14, 2026, at 10:17, Rich Felker <dalias@...c.org> wrote:
>
> 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
The vDSO is specifically designed to be cryptographically secure,
following the lead of getrandom(2) itself.
https://lwn.net/Articles/978601/
Hope this helps.
Best,
-Anna
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.
