Re: [PATCH 0/7] Add arc4random support

[Noah Goldstein <goldstein.w.n@gmail.com>]

On Thu, Apr 14, 2022 at 2:26 PM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
>
> 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.

We could best-effort per-cpu without rseq (select arena based on current
cpu) and have a truly optimized version if rseq is supported. Either way
it's likely to be an improvement if this function is hot.

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