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

[Adhemerval Zanella Netto]

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).