[PATCH 2/2] Add single-threaded fast path to rand()
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Thu Mar 21 15:53:33 GMT 2024
On 21/03/24 10:33, Cristian Rodríguez wrote:
> On Thu, Mar 21, 2024 at 4:39 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Adhemerval Zanella Netto:
>>
>>> On 20/03/24 11:18, Cristian Rodríguez wrote:
>>>> On Wed, Mar 20, 2024 at 9:31 AM Adhemerval Zanella Netto
>>>> <adhemerval.zanella@linaro.org> wrote:
>>>>
>>>>
>>>>> I don't have a strong opinion on this rand patch, if this idea is to
>>>>> have it as an workbench for a possible single-thread lock optimization
>>>>> it should be fine. It is just that I don't see much gain in optimizing
>>>>> such a bad interface (although we still lack a proper userland PRNG).
>>>>
>>>> Yeah, it should be no surprise this interfaces are bad,
>>>> I thought this was common knowledge.
>>>>
>>>> we need something like https://github.com/C2SP/C2SP/blob/main/chacha8rand.md
>>>> which prety much outperforms even non-CS algorithms in at least 64 bit x86.
>>>> but the question of the state remains.global? TLS? how to discard it
>>>> in all the appropriate occasions?
>>>
>>> And this is the arc4random in userspace discussion all over again.
>>
>> Agreed. But what has changed that we know now that Linux won't provide
>> us with vDSO acceleration for arc4random. So I think it wouldn't be
>> unreasonable to roll our own. Right now, the switch to arc4random
>> provided by glibc is a massive performance regression compared to other
>> implementations.
>
>
> Afaik the other path that hasn't been tried is rseq no ? could the
> kernel provide a random state this way that it is cleared on the right
> conditions..
If I recall correctly the main issues with initial arc4random implementation,
and which lead us to roll back the chacha20 optimized ones (similar to what
other OS do); was when and how to reset the state (there are other minor
hardening, like to no spill out state on memory that vDSO experiment also
did). The initial attempt used some heuristics, like when it reached a certain
limits of byes; plus some obvious points (like fork); that might not be
sufficient for all cases.
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. I had to
check again, but last time I checked on how OpenBSD uses this interface was
mainly for hardening (for instance on malloc and other stuff) and to provide
fast PRNG for simulation and such.
More information about the Libc-alpha
mailing list