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

Zack Weinberg zack@owlfolio.org
Fri Mar 22 15:30:37 GMT 2024


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

On a related note, why is MADV_WIPEONFORK not adequate "feedback from the
kernel"?

zw


More information about the Libc-alpha mailing list