[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <795eabe5-68c3-45b4-9bd2-f073d2795391@gmail.com>
Date: Sun, 23 Aug 2026 15:03:43 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
Jonas Böttiger <jonasboettiger@...oud.com>
Cc: "AWilcox@...cox-tech.com" <AWilcox@...cox-Tech.com>, jason@...c4.com
Subject: Re: vDSO-based getrandom
On 8/23/26 10:28, Rich Felker wrote:
> On Sun, Aug 23, 2026 at 04:21:11PM +0200, Jonas Böttiger wrote:
>>
>>
>>> 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]
>
> Seems like the same approach should work to use it with just one
> global context rather than per-thread context. This would at least
> make supporting it less odious -- no coupling with thread ownership
> and lifetimes, everything isolated to getrandom.c.
>
> Rich
I agree that this would be simpler, but I’m concerned that it could
(a) be racy and (b) be a scalability bottleneck. I suspect the vDSO
doesn’t guarantee that the atomics used have strong enough memory
barriers for multithreaded use. Furthermore, modern server systems
can have a very large number of cores and a global lock could be a
serious scalability bottleneck.
More generally, I would not be surprised if programs are designed
around glibc's performance characteristics, and could unexpectedly
have poor performance when used with an implementation that has
very different characteristics.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
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.
