[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260814172213.GA23438@brightrain.aerifal.cx>
Date: Fri, 14 Aug 2026 13:22:13 -0400
From: Rich Felker <dalias@...c.org>
To: Jonas Böttiger <jonasboettiger@...oud.com>
Cc: musl@...ts.openwall.com,
"AWilcox@...cox-tech.com" <AWilcox@...cox-Tech.com>,
jason@...c4.com
Subject: Re: vDSO-based getrandom
On Fri, Aug 14, 2026 at 06:51:15PM +0200, Jonas Böttiger wrote:
> 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/…
Since when is a "VM fork" something there is any contract to support?
Cloning a system dealing with cryptographically sensitive state is an
inherently unsafe thing to be doing in production. It might make sense
in debugging or reverse engineering, where you'd *want* to clone the
RNG state, but it is grossly irresponsible to be doing this with
actual sensitive data.
> > 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
Unfortunately there is no other root of entropy. Maybe this concern is
misplaced and the kernel is committed to doing this right. My concern
is just that, while the syscall has enough overhead that there is no
motivation to "optimize" it by doing unsafe things, somewhere down the
line (or on a non-Linux kernel hosting Linux userspace) someone might
decide "hey, this would be so much faster if we just use RDRAND!" or
similar. And it's worrying to me that the proposal and documentation,
while they do highlight equivalence now, are not making any promises
NOT to do such a bad implementation or declaring it part of the
contract (which alt kernels would be expected to honor) not to do
that.
> 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.
And the high degree of coupling, and the above caveats about contract.
> > 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]
The limit is a good thing as long as it's a syscall, to limit the
burden placed on the kernel satisfying the request. There is never
really a reason to make a request longer than a symmetric key size.
Beyond that you just request a key and run the cipher in CTR mode or
similar in userspace. You don't even need to worry about storage to
keep the key safe since it's a one-time-use thing that's no more
sensitive than the output bits. This kind of kernel/user split is
entirely decoupled.
> > 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]
I read the introductory text to the kernel patch but not the actual
code.
It looks like using it requires a bit of a headache of managing
allocation of memory and thread-local state (altho maybe you can
decline to use that and just put a lock around it?), rather than just
being a single vdso entry point. This may be better in some ways, but
it means if we want to use it and also want to solve the problem of
supporting old kernels (missing now), we now have 2 nontrivial code
paths on top of the plain syscall one.
None of this is a "hard no", but it's very much something I want to
understand the motivation for and the expected ecosystem effects of
adopting, and which I want to community to understand and be on board
with, before a decision is made.
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.
