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

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

On Sat, Sep 19, 2026, at 02:10, Karl Mehltretter wrote:
> On Wed, Sep 16, 2026 at 08:56:02AM +0100, Arnd Bergmann wrote:
>> > existing safeguard automatically and prevent restoring it without
>> > re-enabling the legacy ABI.
>> 
>> I'm not following your logic here, what is the safeguard?
>
> I meant the existing RTC cutoff. In my glibc test, accepting the
> 2040 RTC date changes time32 clock_gettime() from success to
> EOVERFLOW.

I see. I would just not call that a safeguard, it's more of a
time bomb ;-)

Note that the cutoff was never meant to help systems actually
run beyond 2038, but instead is only needed on very rare systems
with a broken RTC implementation that have a random reset
value if the RTC is enabled in devicetree but the backup battery
is absent or depleted.

>> 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
>
> Should we try adding an option to build glibc and other libcs without
> time32 interfaces? Looking at musl's source, its time32 clock_gettime()
> wrapper also calls the time64 implementation and checks whether the
> result fits [1].

I think that would be great, we can certainly try again, at least
with glibc, where at the time the concern was more about the timing
of behavior changes.

There are two separate questions here:

a) Having a libc build only against the time64 interfaces. As far
   as I understand, glibc has used linux-3.2 headers as the
   baseline for kernel compatibility for a long time but one can
   choose a later version. Building with 5.10+ as the minimum
   should already avoid the time32 syscalls, but that could at
   some point be made the minimum header version for 32-bit targets
   or everything.
   musl does not specify a minimum kernel version at all and tries
   to go back as far as possible, so the fallback code is likely
   to stay indefinitely. Rich also does not like the idea of setting
   CONFIG_COMPAT_32BIT_TIME=n (ever), and an unpatched musl
   build will fail in that configuration.
   
b) providing 32-bit interfaces to applications: both libraries
   already provide these as wrappers around the 64-bit internal
   functions, which is part of the problem here but does mean that
   it should be possible to just leave those out. On musl this
   should be very easy (just skip building the compat/time32/
   directory), on glibc I expect this to be much harder as it
   interferes with their idea of having __TIMESIZE=64 vs
   __TIMESIZE=32 as a hardcoded per-architecture setting.

>> 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.
>
> Could we use COMPAT_32BIT_TIME for the default, but still allow the
> limit to be enabled? I could split the update into two patches:
>
> 1. Add RTC_HCTOSYS_TIME32_LIMIT with default y, as posted. This keeps
>    the existing RTC date acceptance by default.
>
> 2. Change the default, keeping the dependency unchanged:
>
>        depends on RTC_HCTOSYS && !64BIT
>        default COMPAT_32BIT_TIME
>
> With RTC_HCTOSYS=y on a 32-bit kernel, the default would allow
> post-2038 RTC dates when COMPAT_32BIT_TIME=n. Integrators could still
> enable the limit without re-enabling legacy syscalls.
>
> I suggest nominating the first patch for stable. Would default
> COMPAT_32BIT_TIME also be suitable for stable?

I think the 'default COMPAT_32BIT_TIME' would absolutely make
sense for stable, since that can only really be set by users that
have a fully 64-bit userspace already and the limit will
cause problems for them.
I would still go one step further and make this

config RTC_HCTOSYS_TIME32_LIMIT
	bool "Reject RTC dates after the 2038 cutoff"
	depends on RTC_HCTOSYS && !64BIT && COMPAT_32BIT_TIME
	default y

to completely disallow it. I think we should wait for Alexandre
to comment here, as it's his subsystem in the end and I'm sure
he has an opinion on the matter.

     Arnd