[PATCH 2/2] linux: use __getrandom_nocancel in getentropy

[Adhemerval Zanella Netto]

On 25/11/25 13:50, Cristian Rodríguez wrote:
> On Tue, Nov 25, 2025 at 1:12 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 22/11/25 11:35, Cristian Rodríguez wrote:
>>> On Wed, Feb 12, 2025 at 6:40 PM Cristian Rodríguez
>>> <cristian@rodriguez.im> wrote:
>>>>
>>>> On Wed, Feb 12, 2025 at 9:57 AM Adhemerval Zanella Netto
>>>> <adhemerval.zanella@linaro.org> wrote:
>>>>
>>>>>
>>>>> And remove both sysdeps/mach/hurd/getentropy.c and sysdeps/unix/sysv/linux/getentropy.c
>>>>
>>>>
>>>> OK, Im gonna post an improved version later.
>>>
>>> Went back to this again.. what to do with GETENTROPY_MAX now.. ? Posix says
>>>
>>> {GETENTROPY_MAX}The maximum value of the length argument in calls to
>>> the getentropy() function.
>>> Minimum Acceptable Value: 256
>>>
>>> However since:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e3c1c4fd9e6d14059ed93ebfe15e1c57793b1a05
>>>
>>>  The kernel special case is PAGE_SIZE not 256..and the special 256
>>> never worked in the first place..
>>>
>>> So at least for the linux parts
>>>
>>> - GETENTROPY_MAX == 256 ? and forget such a limit will not be enforced?
>>> -  GETENTROPY_MAX == getpagesize() ? because PAGE_SIZE is not fixed in
>>> userspace?
>>> - Do not define it all.. make the wrapper return EINVAL if bigger than
>>> a pagesize to match the current kernel special case.
>>>
>>> looking forward to your inputs.
>>
>> Can we assume 'GETENTROPY_MAX == getpagesize()' works for older kernels than 5.18?
> 
> as far as I understood, the 256 special case has never worked. the
> kernel never reacted to signals until all bytes were read.
> so it should work.

Right, it might be good to check this empirically on some older kernel.

> 
>> This is really a lot of complexity, and I am not sure it users will really
>> require GETENTROPY_MAX > 256 for most usercases.
> 
> Yeah.. What about using the smallest possible page size as a limit
> then? I think adding further complexity in this case aint worth it.

I think it seems reasonable, assuming it does work as intended in all kernel
version. We don't have an internal minimal page size definition, but we can
assume 4096 (and I don't think it would be worth to make it arch-dependent).