Re: [PATCH v6 09/10] stdlib: Add TLS optimization to arc4random

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella via Libc-alpha:

> The arc4random state is moved to TCB, so there is no allocation
> failure.  It adds about 592 bytes struct pthread.
>
> Now that the state is thread private within a shared struct, the
>  MADV_WIPEONFORK usage is removed.  The cipher state reset is done
>  solely by the atfork internal handler.
>
> The state is also cleared on thread exit iff it was initialized (so if
> arc4random is not called it is not touched).
>
> Although it is lock-free, arc4random is still not async-signal-safe
> (the per thread state is not updated
>
> On x86_64 using AVX2 it shows a slight better performance:

Should this be merged with the first patch?

Can we allocate the memory dynamically, and fall back to direct kernel
randomness based on allocation failure?

Those 512 bytes of TCB space could be better used for increasing the
static TLS reserve, I think.
> diff --git a/sysdeps/unix/sysv/linux/tls-internal.c b/sysdeps/unix/sysv/linux/tls-internal.c
> index 6e25b021ab..75bc4b3b48 100644
> --- a/sysdeps/unix/sysv/linux/tls-internal.c
> +++ b/sysdeps/unix/sysv/linux/tls-internal.c
> @@ -1 +1,32 @@

> +void
> +__glibc_tls_internal_free (void)
> +{
> +  struct pthread *self = THREAD_SELF;
> +  free (self->tls_state.strsignal_buf);
> +  free (self->tls_state.strerror_l_buf);
> +
> +  if (self->tls_state.rnd_state.count != -1)
> +    /* Clear any lingering random state prior so if the thread stack is
> +       cached it won't leak any data.  */
> +    memset (&self->tls_state.rnd_state, 0, sizeof self->tls_state.rnd_state);
> +}

I think this should be explicit_bzero (currently for documentation
purposes only).

Thanks,
Florian