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

[Alexandre Belloni]

On 19/09/2026 11:16:29+0200, Arnd Bergmann wrote:
> 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.

Well, this is how the issue has been discovered but this is a real y2038
issue.

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

I gave it some thought for the past month as this is an issue that is
regularly brought up.

The first thing is that this is an issue that disappears as soon as
RTC_HCTOSYS is not used. RTC_HCTOSYS has plenty of issue and one of
those is that is doesn't actually work well with NTP. There is a fix for
this and it would slow down every boot by a second or two.

The main issue is that systemd decided to mandate RTC_HCTOSYS when
raising up the issue, the answer is that it is unacceptable to have logs
that are not properly dated until userspace sets the system time. But
letting userspace set the system time simply solves the issue as it will
always set a time that it can handle, even if not correct.

So, my backup plan was to unconditionally enable the limit so we also
handle the 32bit userspace on 64bit systems and have a new kernel
parameter that would opt-out of the limit. I guess we could have a
warning and point to some documentation if the parameter is missing. We
can avoid the warning when the parameter is present and explicitly opts
in.

Thoughts?

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com