[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <6A9EC058-7F06-48B4-988F-CF621B0D00A6@icloud.com>
Date: Sun, 23 Aug 2026 16:21:11 +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 23. Aug 2026, at 16:08, Rich Felker <dalias@...c.org> wrote:
>
> On Sun, Aug 23, 2026 at 03:38:52PM +0200, Jonas Böttiger wrote:
>>> 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.
>
> Is the vdso approach even reentrant/AS-safe? It seems like that would
> be difficult. How does it deal with a situation where a signal
> interrupts execution, and the signal handler then calls back into
> getrandom?
It is, it uses a simple atomic flag around the state and falls back
to the syscall when that is set.[1] glibc additionally uses pointer
tagging to mark the opaque state pointer as in-use, and similarly
falls back to the syscall.[2]
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/vdso/getrandom.c?h=v7.2#n125
[2]: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getrandom.c;h=b3c13f858f4bcd9269819df889684f960ec3ae48;hb=HEAD#l194
> If I were doing this in userspace as the fallback implementation for
> kernels that lack SYS_getrandom, rather than as a performance
> enhancement like the vdso is aiming for, I would just block signals
> across the critical section and use a global lock.
>
> But I think it's good that this topic came up, as it sheds light on
> "userspace csprng for performance" and "userspace csprng for fallback"
> might have very different requirements.
>
> For what it's worth, POSIX getentropy is not specified to be AS-safe.
> So maybe we don't even care about that. It's a matter of whether the
> Linux getrandom is intended/assumed to be...
>
> Rich
As far as I can tell, getrandom isn't specified as AS-safe either,
but since there isn't really a reasonable way for it not to be so
in practice, there are probably people that assume it to be.
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.
