[PATCH v1 1/2] random-bits: Factor out entropy generating function

[Adhemerval Zanella]

On 31/03/2022 07:08, Cristian Rodríguez wrote:
> On Thu, Mar 31, 2022 at 1:45 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
>> Can someone provide some context on this? I've actually looked into
>> having some megafast userspace RNG component in the vDSO, and I'm not
>> fundamentally opposed to the idea. I think there's interesting
>> potential there and something worth considering. But what's the
>> context of you asking for this now? Under what circumstances are you
>> finding that calling getrandom(0) or similar is too high overhead or
>> otherwise problematic?
> 
> I'm not sure in what scenario the syscall overhead is too big, Maybe
> it is if called in a loop..but I guess the argument here is that
> getrandom(0) may block  or that in a non-bleeding edge system it might
> be too slow. (Im aware of the recent massive speedups)

Current internal glibc usage where some entropy is required is not performant
critical, so calling a syscall is not really a problem.  However, we are
evaluating tuning the mutex fastpath for PTHREAD_MUTEX_ADAPTIVE_NP, where
a syscall most likely defeats the optimization.

They might be other entropy usages where a userspace source would be 
nice thing to have, for instance on malloc hardening.

> 
> I believe what is needed is a PRNG, no need to guarantee to be
> cryptographically secure, that can be used without having to seed it
> from userspace, mega fast, never blocks and can be used by the dynamic
> linker for example. Now it will be awesome if it is all of that and
> CSPRNG.

Florian has sent a arc4random proposal somes years ago [1], the idea was
pretty much what you summarized: get some entropy from kernel, initialize
a PNRG, and keep a internal buffer to avoid too much overhead by the calls.
It was suggested to use AES (mainly to use hardware instructions on some
architecture), but I think we can use to any algorithm currently used.

There are still some discussion on which is the best strategy to handle
fork resets and if we need per thread buffers to optimize multithread
access.

An I am not sure if a vDSO would be the best interface here, it would
most likely require some complicate synchronization to handle multithread
access like io_ring besides limiting access if kernel provides it.  I
think such interface would be better to be handle by glibc itself.

[1] https://sourceware.org/pipermail/libc-alpha/2018-March/092081.html