[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <96A05BFC-F1DA-460B-9174-0420B9C14345@icloud.com>
Date: Fri, 14 Aug 2026 18:51:15 +0200
From: Jonas Böttiger <jonasboettiger@...oud.com>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>,
"AWilcox@...cox-tech.com" <AWilcox@...cox-Tech.com>,
jason@...c4.com
Subject: Re: vDSO-based getrandom
My mail system reported an error, sorry if this message arrives twice.
> On 14. Aug 2026, at 17:17, Rich Felker <dalias@...c.org> wrote:
>
> 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.
I’m not a cryptography expert, so perhaps I’m missing something, but
the reasoning given in the kernel patch seems pretty sound. As Jason
writes, the problem with such userspace RNGs is that they have no
way of knowing when it is necessary to reseed. E.g. failing to reseed in
response to a VM fork will probably result in a cryptographic catastrophe
as both instances will generate the same keys/nonces/…
The cool thing about speeding up getrandom via the vDSO is that it makes
getrandom’s performance equivalent to such userspace CSPRNG while
offering the same security properties as the syscall.
> 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.
I don’t think that’s entirely reasonable – if you don’t trust the kernel to
make good decisions in regards to its entropy sources, then you shouldn’t
be seeding the CSPRNG using getrandom in the first place. Also, the
vDSO implementation does use a software CSPRNG, the only major
difference between it and other userspace RNGs is that it checks whether
the kernel entropy pool generation has changed and reseeds in response
to that.
> There is a conversa[t]ion 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.
While, yes, getentropy is now in the UNIX standard, the interface that people
currently seem to be drifting towards is arc4random_buf, since it doesn't limit
its output size – which is the major problem with getentropy. To quote Daniel
J. Bernstein:[1]
My mail system reported an error, sorry if this mail arrives duplicated.
> A simpler approach, taken in NaCl, is for the cryptographic library to simply
> use the kernel RNG without maintaining another RNG layer. Obviously this
> approach uses less code and is easier to audit; I see no security justification
> for OpenBSD saying "getentropy() is not intended for regular code" and limiting
> the getentropy() output to 256 bytes. The syscall might be a speed problem in
> some post-quantum systems, but if this turns into a real-world problem then
> I see several ways to deal with it without the current mess of non-kernel RNG
> code.
A well implemented arc4random_buf, such as the one from FreeBSD,[2]
operates in exactly the same way that the vDSO getrandom does in that
it uses a userspace CSPRNG to expand a seed retrieved from the kernel,
but also reseeds in response to a kernel entropy pool generation change,[3]
which in turn necessitates some vDSO-like mechanism for the kernel to
make that information available. Linux, for better or worse, has chosen to
keep the CSPRNG part in the kernel (well, vDSO) too. So when implementing
arc4random_buf (as an aside, it would be great to have that in musl),
the only way to make it secure is by using getrandom – which I want to note
is what glibc does nowadays.[4]
Hi Jason, I’ve taken the liberty of CCing you here and would highly appreciate
your input – I hope I’m not mischaracterising anything here.
[1] https://blog.cr.yp.to/20170723-random.html
[2] https://cgit.freebsd.org/src/tree/lib/libc/gen/arc4random.c
[3] https://cgit.freebsd.org/src/tree/lib/libc/gen/arc4random.h#n142
[4] https://inbox.sourceware.org/libc-alpha/20220726195822.1223048-1-Jason@zx2c4.com/
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.
