[PATCH v2 8/8] elf: Scrub and reseed the AT_RANDOM bytes after deriving the guards (BZ 34197)

Florian Weimer fweimer@redhat.com
Tue Jun 16 19:07:14 GMT 2026


* Adhemerval Zanella Netto:

> On 16/06/26 15:59, Florian Weimer wrote:
>> * Adhemerval Zanella Netto:
>> 
>>> On 16/06/26 15:41, Florian Weimer wrote:
>>>> * Adhemerval Zanella:
>>>>
>>>>> +/* The stack and pointer guards have been derived from the 16 AT_RANDOM
>>>>> +   bytes pointed to by DL_RANDOM.  Scrub them first, so the guards cannot be
>>>>> +   recovered even if the refill below fails, then refill them with fresh
>>>>> +   entropy unrelated to the guards so that getauxval (AT_RANDOM) keeps
>>>>> +   returning random bytes.  */
>>>>> +static inline void __attribute__ ((always_inline))
>>>>> +_dl_reseed_random (void **dl_random)
>>>>> +{
>>>>> +  if (*dl_random == NULL)
>>>>> +    return;
>>>>> +  memset (*dl_random, '\0', 16);
>>>>> +  __asm__ __volatile__ ("" : : "r" (*dl_random) : "memory");
>>>>> +
>>>>> +  __getrandom_nocancel_nostatus_direct (*dl_random, 16, GRND_NONBLOCK);
>>>>> +  *dl_random = NULL;
>>>>> +}
>>>>
>>>> I'm afraid this fails in the wrong direction: it replaces a potential
>>>> randomness leak with guaranteed predictable randomness.  (The generic
>>>> version is worse, of course).
>>>>
>>>> We expose the value through getauxval (AT_RANDOM).  We shouldn't turn
>>>> that into a constant.
>> 
>>> I did not fully grasp the issue here, what do you mean by 'guaranteed
>>> predictable randomness' here?
>> 
>> I'm worried there are kernels where applications will observe a
>> zero-byte buffer returned from getauxval (AT_RANDOM) when the pool
>> entropy is low and getrandom would block.
>> 
>> I think it's better not clear first.
>
> Do mean for the case where __getrandom_nocancel_nostatus_direct could not
> fill the whole buffer, like early boot? I think we can drop the memset
> and only write on the dl_random if getrandom does return 16 bytes.

Yes, I think it's better to run with what's in the buffer before.  Even
if it's a mix between and old and overwritten values.

Thanks,
Florian



More information about the Libc-alpha mailing list