Re: [PATCH 2/2] Add single-threaded fast path to rand()

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2024-03-22 14:05, Adhemerval Zanella Netto wrote:
> 
> 
> On 22/03/24 12:30, Zack Weinberg wrote:
>> On Fri, Mar 22, 2024, at 10:46 AM, Adhemerval Zanella Netto wrote:
>>> On 22/03/24 11:27, Zack Weinberg wrote:
>>>> On Thu, Mar 21, 2024, at 11:53 AM, Adhemerval Zanella Netto wrote:
>>>>> And even if arc4random is explicit a non CPRNG, there were some worries that
>>>>> users might misuse the interface and thus add some security issues.
>>>>
>>>> No opinion about anything else in this thread, but if we add arc4random at all
>>>> it MUST be a CSPRNG.  That's a documented guarantee on all the systems that
>>>> do have it, and applications rely on it.
>>>
>>> Yeah, this is another point of contention where one might consider that a
>>> userland CPRNG that has no feedback from kernel to where/how to properly
>>> reseed might not be considered a CPRNG.
>>
>> I would describe that as a "CSPRNG with a known bug that makes it unsuitable
>> for use under some conditions", but not as "not a CSPRNG".  I would only
>> call it "not a CSPRNG" if the cryptographic primitives were no good
>> (e.g. RC4 or Xorshift or something even more predictable) or if there was
>> a way to leak or clone the state *in a single-threaded program that does
>> not fork*.
> 
> I tend to agree, but the contention point was really 'that makes it unsuitable
> for use under some conditions' was a deal breaker in face that kernel provides
> an API with better guarantees.
> 
>>
>> On a related note, why is MADV_WIPEONFORK not adequate "feedback from the
>> kernel"?
> 
> If I recall correctly, the problem was not only state wipe on fork (with
> MADV_WIPEONFORK should take care), but rather when the state needs to be
> reseed due various situations outside of the userland knowledge (on the
> arc4random thread Jason gave us some examples, I don't really recall all
> of them by hearth). That's why the idea of providing the arc4random through
> a vDSO primitive (where kernel can reseed any time it likes).

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.

This would allow many userspace PRNG libraries to use this facility
within a process, as there would be no single per-library location the
kernel needs to reset, and would remove all knowledge of the PRNG
internal state from the kernel.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com