Re: [PATCH v3] Define in_int32_t_range to check if the 64 bit time_t syscall should be used

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 08/11/22 08:39, Florian Weimer wrote:
> * Arnd Bergmann:
> 
>> On Tue, Nov 8, 2022, at 12:17, Florian Weimer wrote:
>>> * Arnd Bergmann:
>>>> On Tue, Nov 8, 2022, at 05:49, YunQiang Su wrote:
>>>>> Currently glibc uses in_time_t_range to detects time_t overflow,
>>>>> and if it occurs fallbacks to 64 bit syscall version.
>>>>>
>>>>> The function name is confusing because internally time_t might be
>>>>> either 32 bits or 64 bits (depending on __TIMESIZE).
>>>>>
>>>>> This patch refactors the in_time_t_range by replacing it with
>>>>> in_int32_t_range for the case to check if the 64 bit time_t syscall
>>>>> should be used.
>>>>>
>>>>> The in_time_t range is used to detect overflow of the
>>>>> syscall return value.
>>>>
>>>> It looks like the fallback logic has another flaw, I don't
>>>> see how this works on kernels with COMPAT_32BIT_TIME disabled,
>>>> as these only have the time64 syscalls available.
>>>
>>> Isn't that an invalid kernel configuration?
>>
>> No, this is what we will use anyway after 2038 (possibly
>> earlier), so the option is useful to ensure that all userspace
>> has been converted away from the time32 interfaces.
> 
> What happened to not breaking userspace?
> 
> Those with 32-bit applications will want to run their legacy stuff in a
> time-shifted environment, so these system calls must remain supported
> outside specialized applications.
> 
> Thanks,
> Florian

I agree and the time64 support was added based on this assumption.  I
understand that this simplifies the code and kernel attack surface,
but it a userspace breakage anyhow.