Re: [PATCH] rtc: class: Make the time32 hctosys limit configurable

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

On Wed, Sep 16, 2026, at 00:37, Karl Mehltretter wrote:
> On Tue, Sep 15, 2026 at 07:48:12AM +0100, Arnd Bergmann wrote:
>> On Mon, Sep 14, 2026, at 23:25, Karl Mehltretter wrote:
>> > On 32-bit systems with RTC_HCTOSYS enabled, rtc_hctosys() rejects
>> > RTC dates whose seconds value exceeds INT_MAX, even when userspace
>> > uses a 64-bit time_t. This leaves system time uninitialized by the RTC.
>> >
>> > Commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow
>> > time_t") introduced this limit to protect time32 userspace from future
>> > RTC dates that can break boot. The same limit prevents systems with
>> > time64 userspace from initializing the clock from valid post-2038 dates.
>> 
>> What about the reverse: if COMPAT_32BIT_TIME is disabled, I don't
>> see why we'd want to allow turning this on, so maybe
>
> I tried this and found a case where the limit may still be useful
> with COMPAT_32BIT_TIME=n. Glibc can use time64 kernel interfaces
> for applications with a 32-bit time_t. Conversion to time32 fails
> with EOVERFLOW when the date is out of range.
>
> I tested a small clock_gettime() program using Debian glibc 2.41
> on 32-bit ARM in QEMU, with identical kernel configurations and
> initramfs. With RTC_HCTOSYS=y, COMPAT_32BIT_TIME=n and RTC in 2040:
>
>   Kernel                 System year  time32 clock_gettime()
>   ---------------------  -----------  ---------------------
>   Baseline               1970         success
>   Patch with dependency  2040         -1, errno=EOVERFLOW

I think this is technically a bug in glibc: a task that calls the
time32 clock_gettime() is supposed to fail with
COMPAT_32BIT_TIME=n regardless of the date, according to the
original design. I understand that this is hard to do in
glibc based on how it deals with the three kernel variants
(time32 only v5.0 and older, time64-only with COMPAT_32BIT_TIME=n,
both present), but I still hope that we can one day do this
e.g. by having allowing glibc to be built without the time32
library interfaces to force a link failure.

> The legacy clock_gettime syscall returned ENOSYS in both cases.
> The same program built with a 64-bit time_t succeeded on both
> kernels. Both builds also succeeded with the RTC in 2026. Both
> kernels booted with time64 init.
>
> Disabling legacy syscalls therefore does not establish that all
> applications use a 64-bit time_t. The dependency would remove the
> existing safeguard automatically and prevent restoring it without
> re-enabling the legacy ABI.

I'm not following your logic here, what is the safeguard?

With a fixed C library, COMPAT_32BIT_TIME=n should act as a safeguard
to ensure that no interfaces can be used that limit time to y2038
and break unexpectedly in the future. The RTC_HCTOSYS interface
has so far always thrown a wrench into that because it still truncates
an important interface inside of the kernel. Your patch makes it
possible to do the right thing here, but one still has to know
that the Kconfig option exists and turn it off in order to
actually make it work. Since we have COMPAT_32BIT_TIME as a global
option already, it makes a lot of sense to actually use it here
as well.

       Arnd