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

[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.

I recall that I though about it, but to have a better solution it would
require to mimic what arc4random does.

I will send a fix.