[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260823195323.GL23438@brightrain.aerifal.cx>
Date: Sun, 23 Aug 2026 15:53:23 -0400
From: Rich Felker <dalias@...c.org>
To: Demi Marie Obenour <demiobenour@...il.com>
Cc: musl@...ts.openwall.com,
Jonas Böttiger <jonasboettiger@...oud.com>,
"AWilcox@...cox-tech.com" <AWilcox@...cox-Tech.com>,
jason@...c4.com
Subject: Re: vDSO-based getrandom
On Sun, Aug 23, 2026 at 03:03:43PM -0400, Demi Marie Obenour wrote:
> 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.
>
> 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.
The strength of the atomics is a good question. If the ones used
internally are not sufficient you could do the same thing around it
with full strength atomics.
I don't think allocating an extra page of memory per thread is very
nice. It cuts the limit on number of threads you can have massively
(quickly hitting vma limit) and doubles the min memory required per
thread.
The whole concept assumes you're using threads for parallelism rather
than for logical flows of execution. A much more reasonable setup
would be allocating per-cpu contexts and choosing the one to use via
vdso getcpu, with racing migrations allowed to contend for the lock
and fallback to syscall.
But all of this is a lot of complexity and coupling with other logical
components for the sake of a dubious-motivation optimization for the
sake of a rather niche usage case.
> 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.
One thing we try to do with musl is get stuff fixed when it's designed
around nonportable assumptions. Is getentropy expected to be
in-userspace fast on the BSDs? For the forseeable future, even those
of us using Linux may very well be sticking to 6.x since 7.x is now
full of unreviewed potentially dangerous changes. Going along with
"everyone can assume it's fast because bleeding-edge Linux+glibc makes
it fast" is user-hostile.
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.
