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 5:00 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Jason A. Donenfeld via Libc-alpha:
>
> > _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.
>
> If we can make a cryptographically secure generator fast enough, it
> would relieve programmers of the need to choose between that and another
> generator that just gives some random-looking bits fast.  If programmers
> don't have to make a choice, they can't choose incorrectly (introducing
> performance bugs or security bugs).
>
> For example, the system call overhead could be prohibitive for things
> like hash map keys if these hash maps are not used much before they are
> discarded again.

Yes, if we want a general interface it's something we should do well
and have it be cryptographically secure with no downsides bla bla bla.
As mentioned, we can design something fancy with the vDSO if you think
there's a compelling use case for this.

Until your comments, though, everybody on this thread told me this was
just some dinky internal interface only used for some sort of
threading semantic. In that case, just name it
"dinky_threading_id_thinger()" and call it a day? We are all talking
about the same thing, right? Could you confirm/clarify the focus here?
And if you've misunderstood what this is about, please say so too. I
see the subsequent messages are now veering off into lala land since
yours, so I'd like to make sure we're all on the same page, lest we
waste time over nothing.

Thanks,
Jason