[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260823142823.GK23438@brightrain.aerifal.cx>
Date: Sun, 23 Aug 2026 10:28:23 -0400
From: Rich Felker <dalias@...c.org>
To: Jonas Böttiger <jonasboettiger@...oud.com>
Cc: musl@...ts.openwall.com,
"AWilcox@...cox-tech.com" <AWilcox@...cox-Tech.com>,
jason@...c4.com
Subject: Re: vDSO-based getrandom
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
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.
