[PATCH 2/2] Add single-threaded fast path to rand()
Mathieu Desnoyers
mathieu.desnoyers@efficios.com
Mon Mar 25 14:09:07 GMT 2024
On 2024-03-23 11:23, Mathieu Desnoyers wrote:
> On 2024-03-23 10:01, Zack Weinberg wrote:
>
> [...]
>
>> ...
>>> If the goal is to let userspace know that it needs to reseed due to
>>> various kernel events happening, one way I see we could extend rseq
>>> to support this would be to add a 64-bit "seed generation counter"
>>> in the struct rseq per-thread area which would be incremented by the
>>> kernel when the seed needs to be updated in userspace.
>>
>> I don't know hardly anything about rseq. I think that sounds workable
>> from libc's side of the fence; the remaining questions I see are
>>
>> 1) Will the kernel take your patch?
>
> I can start by creating a proof-of-concept patch. If there are
> use-cases justifying its integration, I don't see why the other
> rseq co-maintainers would object.
Reading the follow-up discussion on the thread, I now understand
that a generation counter is probably not sufficient. Or maybe there
are more than one use-case here ?
If the intended purpose is to have the kernel wipe out the keys
before going to sleep/hibernate, then you'll want an integration
similar to madvise MADV_WIPEONFORK, but with a new semantic that
also wipes on sleep/hibernate and other relevant events.
If the intent is to make sure that random numbers get re-seeded
after those kernel events, then rseq with a generation counter
would work.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
More information about the Libc-alpha
mailing list