[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C5D0DF51-3AB8-4BAE-A56F-BA44C4B5649C@icloud.com>
Date: Sun, 23 Aug 2026 16:43:20 +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:28, Rich Felker <dalias@...c.org> 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
Yes, although that will obviously decrease performance
if multiple threads call it at the same time. I'll leave the
complexity of it up to you, but I want to note that the only
things required for a per-thread state are an added pointer
in the pthread struct and a call to the cleanup function on
thread exit, which doesn't have any dependencies apart
from munmap.
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.
