[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