[PATCH 2/2] Add single-threaded fast path to rand()
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Mon Mar 25 17:52:53 GMT 2024
On 25/03/24 11:09, Mathieu Desnoyers wrote:
> 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.
I don't fully recall all the details, but I think that's was Jason
idea with the getrandom vDSO strategy. It used a new syscall to allocate
the state and this syscall used internally a new mmap flag to trigger
the required wipe/reset on the required events. He also wanted to
prevent userland to incorrectly use the syscall, so he moved the
buffer allocation to vDSO as well.
The vDSO implementation used the same cypher as the kernel one
(chacha20, with a extra constraint to avoid leak internal state
on the stack), and subdivides the state region in backets that were
addressed based on thread pointer. Each bucket kept a generation
counter, which was updated by the kernel. Any failure (either in
generation check or contention on backets) fallback to getrandom
syscall.
>
> 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,
More information about the Libc-alpha
mailing list