[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F6010901-8099-4E69-874D-3A26D82B2CDD@icloud.com>
Date: Sun, 23 Aug 2026 15:38:52 +0200
From: Jonas Böttiger <jonasboettiger@...oud.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com,
"AWilcox@...cox-tech.com" <AWilcox@...cox-Tech.com>,
jason@...c4.com
Subject: Re: vDSO-based getrandom
> On 14. Aug 2026, at 19:22, Rich Felker <dalias@...c.org> wrote:
>
> 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.
Fair enough. While I think it doesn't hurt to guard against it anyway,
it's definitely not a common or desirable usecase.
> 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.
The problem with that is that you need to have a cipher in userspace,
and you need to to keep it updated. In the end, this boils down to a
question of trust and maintainability. In the case of Rust, I'd really,
really like to avoid shipping a CSPRNG in the standard library.
Rust's operating semantics have no concept of const-time arithmetic,
so we'd have to be very, very careful to avoid side-channel attacks by
e.g. writing it in assembly for each platform and target feature. And
if we get it wrong and there is a bug, that won't be fixable by just a
system update, since std is statically linked in all programs so the
implementation would be hard-baked in.
I fully trust the kernel maintainers to take upon themselves all that
work – they already have to worry about all that stuff for the non-
vDSO getrandom, and if the kernel is misconfigured or otherwise
broken, there's nothing we can do about it anyway. And similarly
I trust you and other libc writers to correctly bind to the vDSO.
And so, since the performance of the vDSO CSPRNG doesn't
leave that much to be desired, there is no reason for std to ship
its own, and the other std maintainers and I get to save a ton of
work.
> 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.
Yeah, it's definitely more complicated than the clock_gettime
acceleration. The per-thread stuff is probably required to preserve
the async-signal-safety of getrandom, but the opaque-state caching
can probably be avoided at the cost of just a bit of extra memory.
> 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.
I understand the hesitation well. Hopefully my example is a good
datapoint for why this would be worth the effort.
Jonas
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.
