Re: [PATCH 0/7] Add arc4random support

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 14/04/2022 08:49, Cristian Rodríguez wrote:
> If this interface is gonna added, GNU extensions that return uint64_t
> of arc4random and arc4random_uniform will be extremely cool.
> Even cooler if there is no global state.

I don't think adding a uint64_t interface for arc4random would improve
much, specially because a simple wrapper using arc4random_buf should
be suffice.  It would also require portable code to handle another
GNU extension over a BSD defined interface that is presented in multiple
systems.  Also performance-wise I think it would be much different than
arc4random_buf. It make some sense for arc4random_uniform, but I don't
have a strong opinion.

The global state adds some hardening by 'slicing up the stream' since
multiple consumers getting different pieces add backtracking and prediction
resistance. Theo de Raadt explains a bit why OpenBSD has added this 
concept [1] (check about minute 26) on its arc4random implementation.
As he puts, there is no formal proof, but I agree that the ideas are
reasonable.

Also, not using a global state means we will need to add a per-thread or
per-cpu state which is at least one page (due MADV_WIPEONFORK). The
per-cpu state is only actually possible on newer Linux kernels that
support rseq.  We might just not care about MADV_WIPEONFORK and use
a malloc buffer which would be reset by the atfork internal handler.

[1] https://www.youtube.com/watch?v=gp_90-3R0pE