[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9pATF5Csu1q1iwqw0p0wO73P4OTr0YHi54yvsoEyMVhFw@mail.gmail.com>
Date: Sun, 23 Aug 2026 15:12:39 -0600
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Rich Felker <dalias@...c.org>
Cc: Demi Marie Obenour <demiobenour@...il.com>, musl@...ts.openwall.com,
Jonas Böttiger <jonasboettiger@...oud.com>,
AWilcox@...cox-tech.com
Subject: Re: vDSO-based getrandom
On Sun, Aug 23, 2026, 13:53 Rich Felker <dalias@...c.org> wrote:
> 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's not a page per thread. You allocate a page (or pages) and divide it
between threads.
>
>
Content of type "text/html" skipped
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.
