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

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, Nov 8, 2022, at 12:39, Florian Weimer wrote:
>> On Tue, Nov 8, 2022, at 12:17, Florian Weimer wrote:
>>> * Arnd Bergmann:
>>>> On Tue, Nov 8, 2022, at 05:49, YunQiang Su wrote:
>>>
>>> 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?

It's a configuration option that makes sense for some users
but not others, just like a lot of other conditional system
calls that we have (UID16, IPC, SGETMASK_SYSCALL, FUTEX, EVENTPOLL,
INOTIFY, IO_URING, AIO, TIMERFD, QUOTA, MODULES).

If you turn these compile-time symbols off, you naturally break
compatibility with any applications and libraries that call the
corresponding syscalls, but nevertheless there are embedded
systems that never need to call them and prefer to leave the
symbols disabled.

If you know you run a modern glibc, you probably don't
care about uid16 syscalls or sgetmask/ssetmask and can
leave them disabled. Similarly, system calls that have
not been used for a long time eventually get removed
completely, with extreme caution. Examples include prof(),
lock(), afs_syscall(), pkey_set(), or ftime(). uselib() may
be next on the list.

For embedded systems, being able to turn off the broken
time32 interfaces right now is fairly important, otherwise
it is excessively hard to validate that a system is not
accidentally calling the wrong interfaces or relying on
fallbacks that no longer work after 2038.

For a desktop distro, that obviously does not apply, as
users need to be able to run arbitrary binaries that
were built for time32 or uid16.

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

We have had several discussions about adding time-shifting
for CLOCK_REALTIME to the kernel, and always concluded that
the added complexity is not worth the possible benefit
(unlike shifting CLOCK_MONOTONIC, which has use cases for
checkpoint/restart).

Clearly one can do the same thing using some LD_PRELOAD
library or a virtual machine, but then again if you do this,
you can also have that LD_PRELOAD library do the conversion
to the time64 interfaces, or have the VM run a kernel with
the time32 syscalls still present.

     Arnd