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

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi Florian,

On Mon, Apr 4, 2022 at 4:51 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Cristian Rodríguez:
>
> > On Wed, Mar 30, 2022 at 1:30 PM Noah Goldstein via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> >
> >> Thanks, I can add patches for sparc/powerpc64le/ia64. Still feel that
> >> since it takes testing and there are optimization cases that we mayf
> >> want to make it's still best to have a seperate file.
> >
> > What is really needed is to get some sort of randomness function
> > exposed through the VDSO, so there is no syscall overhead and all this
> > magic can be dropped. I'm not even sure if that is possible.  that or
> > a reliable prng usable even by the dynamic linker.
>
> We'd need to allocate some per-thread data, register it with the kernel
> (so that the kernel can apply fork protection), and pass it to the vDSO
> function.  It's fairly involved.
>
> And we'd still need to implement fallback if we want to expose a
> mostly-non-failing arc4random to applications.

Indeed it's involved. But not impossible and something I'd consider working on.

_However_, based on what people have said in this thread, this all
seems highly unnecessary, since you just need some boring
statistically uniform randomness without any crypto or security
requirements of any kind, and it simply needs to be fast and dumb. If
that's the wrong set of requirements for this problem (I still have no
idea what the bigger picture here is), please pipe up. Assuming it's
true, however, some dumb xorshift thing like https://א.cc/xrAIhCvy/c
seems probably fine?

Jason