Using arc4random() in the library (was Re: [PATCH] malloc: Use __getrandom_nocancel during tcache initiailization)

[Florian Weimer]

* Yann Droneaud:

> Hi,
>
> Le 01/08/2022 à 12:35, Florian Weimer via Libc-alpha a écrit :
>> Cancellation currently cannot happen at this point because dlopen
>> as used by the unwind link always performs additional allocations
>> for libgcc_s.so.1, even if it has been loaded already as a dependency
>> of the main executable.  But it seems prudent not to rely on this
>> quirk.
>>
>> ---
>>   malloc/malloc.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/malloc/malloc.c b/malloc/malloc.c
>> index bd3c76ed31..430d204156 100644
>> --- a/malloc/malloc.c
>> +++ b/malloc/malloc.c
>> @@ -254,6 +254,7 @@
>>   /* For tcache double-free check.  */
>>   #include <random-bits.h>
>>   #include <sys/random.h>
>> +#include <not-cancel.h>
>>     /*
>>     Debugging:
>> @@ -3153,7 +3154,7 @@ static uintptr_t tcache_key;
>>   static void
>>   tcache_key_initialize (void)
>>   {
>> -  if (__getrandom (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
>> +  if (__getrandom_nocancel (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
>
>
> Is this a place where arc4random() could be used in the future ?
>
> aka. is there a policy on using arc4random() instead of getrandom() in
> the library ?

Currently there is not much of a difference between arc4random_buf and
getrandom on current kernels.  We'll see where getrandom is heading (and
if vDSO acceleration will end up in the kernel), and if it will involve
malloc in some way.  If it does, we can't use arc4random from malloc, we
have to use the system call.

Thanks,
Florian