Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function

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

On 31/03/2022 08:25, Cristian Rodríguez wrote:
> On Thu, Mar 31, 2022 at 8:17 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
> 
>> There are still some discussion on which is the best strategy to handle
>> fork resets and if we need per thread buffers to optimize multithread
>> access.
> 
> What about giving up on this and making the state small and use thread
> local storage for it ?
> I believe all this complexity to handle that cases is not worth it.

That what the per-thread buffer is about, we will need to define how much
buffer would ideal, how to allocate (extending the TCB or using TLS), if
the size would be tunable, which cipher to use, how to handle failures
internally if the source of entropy is not available (Florian patch [1]
used getrandom or /dev/random, and using AT_RANDOM might limit other
usages like guard and stack pointer hardening).

The AES implementation proposed uses a somewhat large state (about 300
bytes), which might add some overhead it would a per-thread buffer. And
afaik other cyphers like Chacha20 have a even larger state (512 bytes).
Florian patch tries to implement some lock-free access to the common
buffer to decrease the state size, it might be a better option indeed.

But if you check Florian's patch, most of the complexity come from
fork detections where even with a per-thread buffer we will need
to handle (for the forked thread).


[1] https://sourceware.org/legacy-ml/libc-alpha/2018-05/msg00891.html