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

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

[Arnd Bergmann]

From: Karl Mehltretter <kmehltretter@gmail.com>

The RTC_HCTOSYS feature faces an impossible dilemma on 32-bit systems:

 a) systemd requires RTC_HCTOSYS=y with the correct timestamp
    for its intended operation

 b) broken RTC hardware can produce random future timestamps
    beyond 2038 at boot time

 c) time32 userspace immediately hangs if the time is set to a
    date beyond 2038 and requires timestamps to be clamped

 d) time64 userspace is intended to survive the actual 2038
    date and requires timestamps to not be clamped

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 and address constraints a), b) and c),
but broke d) in the process by limiting RTC_HCTOSYS to the time32 range
and falling back to RTC_HCTOSYS=n behavior when the RTC time overflows
that.

Make the behavior configurable with a new RTC_HCTOSYS_TIME32_LIMIT
option that chooses between breaking c) or d). On systems with
COMPAT_32BIT_TIME=n, only RTC_HCTOSYS_TIME32_LIMIT=n is allowed since
userspace can be assumed to be fully built for time64. 64-bit kernels
running 32-bit userland never had the cutoff and continue to not offer
the option.

Warn on rejection with the RTC date and option name so users can
identify the cause and find the setting.

[arnd: reword Kconfig text and patch description,
       add COMPAT_32BIT_TIME dependency]
Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
Link: https://lore.kernel.org/all/20220908115337.1604277-1-arnd@kernel.org/
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
----
I ended up rewriting most of the text but kept Karl's ownership
as he did the original patch.
---
 drivers/rtc/Kconfig | 21 +++++++++++++++++++++
 drivers/rtc/class.c |  8 +++++---
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8d9f4ef92f5a..9b6b0c31eb8e 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -30,6 +30,27 @@ config RTC_HCTOSYS
 	  the value read from a specified RTC device. This is useful to avoid
 	  unnecessary fsck runs at boot time, and to network better.
 
+config RTC_HCTOSYS_TIME32_LIMIT
+	bool "Reject RTC dates after the 2038 cutoff"
+	depends on RTC_HCTOSYS && COMPAT_32BIT_TIME && !64BIT
+	default y
+	help
+	  Reject RTC dates after 03:14:07 UTC on 19 January 2038 when
+	  initializing the system clock in order to work around broken
+	  RTC implementations that produce nondeterministic timestamps
+	  without a working backup battery.
+
+	  A rejected date leaves system time unchanged, normally near
+	  the Unix epoch, and the RTC's hctosys sysfs attribute reads
+	  0. Userspace must supply the time if no other source has
+	  initialized it.
+
+	  Say Y here if the kernel may have to run old time32 userspace on
+	  hardware that can produce unpredictable RTC timestamps.  If the
+	  kernel is intended to only run time64 compatible userspace and
+	  continue working past 2038, you must pick N here in order to
+	  have a working RTC_HCTOSYS functionality.
+
 config RTC_HCTOSYS_DEVICE
 	string "RTC used to set the system time"
 	depends on RTC_HCTOSYS
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 01ba04028f1f..18ea141ab8c2 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -72,12 +72,14 @@ static void rtc_hctosys(struct rtc_device *rtc)
 
 	tv64.tv_sec = rtc_tm_to_time64(&tm);
 
-#if BITS_PER_LONG == 32
-	if (tv64.tv_sec > INT_MAX) {
+	if (IS_ENABLED(CONFIG_RTC_HCTOSYS_TIME32_LIMIT) &&
+	    tv64.tv_sec > INT_MAX) {
+		dev_warn(rtc->dev.parent,
+			 "hctosys: rejecting %ptR UTC due to CONFIG_RTC_HCTOSYS_TIME32_LIMIT=y\n",
+			 &tm);
 		err = -ERANGE;
 		goto err_read;
 	}
-#endif
 
 	err = do_settimeofday64(&tv64);
 
-- 
2.53.0

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

[sashiko-bot]

> From: Karl Mehltretter <kmehltretter@gmail.com>
> 
> The RTC_HCTOSYS feature faces an impossible dilemma on 32-bit systems:
> 
>  a) systemd requires RTC_HCTOSYS=y with the correct timestamp
>     for its intended operation
> 
>  b) broken RTC hardware can produce random future timestamps
>     beyond 2038 at boot time
> 
>  c) time32 userspace immediately hangs if the time is set to a
>     date beyond 2038 and requires timestamps to be clamped
> 
>  d) time64 userspace is intended to survive the actual 2038
>     date and requires timestamps to not be clamped
> [ ... ]
> Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
> Link: https://lore.kernel.org/all/20220908115337.1604277-1-arnd@kernel.org/
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261020080026.2461578-1-arnd@kernel.org?part=1

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

[Alexandre Belloni]

On Tue, 20 Oct 2026 09:59:21 +0200, Arnd Bergmann wrote:
> The RTC_HCTOSYS feature faces an impossible dilemma on 32-bit systems:
> 
>  a) systemd requires RTC_HCTOSYS=y with the correct timestamp
>     for its intended operation
> 
>  b) broken RTC hardware can produce random future timestamps
>     beyond 2038 at boot time
> 
> [...]

Applied, thanks!

[1/1] rtc: class: Make the time32 hctosys limit configurable
      https://git.kernel.org/abelloni/c/b253c2e96a80

Best regards,

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

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

[Karl Mehltretter]

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.

Add RTC_HCTOSYS_TIME32_LIMIT for 32-bit kernels, defaulting to y to
preserve the existing safeguard. Allow integrators to disable it once
their entire userspace, including init, supports post-2038 dates.
Warn on rejection with the RTC date and option name so users can
identify the cause and find the setting.

Keep the option independent of COMPAT_32BIT_TIME. Userspace with a
64-bit time_t may still need legacy syscalls for operations that do
not represent post-2038 dates.

Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
Link: https://lore.kernel.org/all/20220908115337.1604277-1-arnd@kernel.org/
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
Tested this exact patch on SAM9X75 Curiosity (32-bit ARM, rtc0),
using three full kernel builds and six powered warm boots:

  TIME32_LIMIT  COMPAT_32BIT_TIME  RTC in 2026    RTC in 2040
  y             y                 hctosys=1      hctosys=0, epoch + 2 s
  n             y                 hctosys=1      hctosys=1, correct time
  n             n                 hctosys=1      hctosys=1, correct time

The default-limit 2040 boot logged the rejected date and
CONFIG_RTC_HCTOSYS_TIME32_LIMIT=y. The other boots did not warn.
Legacy clock_gettime and futex returned -ENOSYS with COMPAT_32BIT_TIME=n.
Tests used a minimal time64 initramfs without NTP. Current clocks and
all original boot files were restored after testing.

Host tests checked Kconfig defaults and dependencies, the INT_MAX
boundary and error paths.

 drivers/rtc/Kconfig | 23 +++++++++++++++++++++++
 drivers/rtc/class.c |  8 +++++---
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 05b9233b9418..a594c041bc35 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -30,6 +30,29 @@ config RTC_HCTOSYS
 	  the value read from a specified RTC device. This is useful to avoid
 	  unnecessary fsck runs at boot time, and to network better.
 
+config RTC_HCTOSYS_TIME32_LIMIT
+	bool "Reject RTC dates after the 2038 cutoff"
+	depends on RTC_HCTOSYS && !64BIT
+	default y
+	help
+	  Reject RTC dates after 03:14:07 UTC on 19 January 2038 when
+	  initializing the system clock. This preserves the existing
+	  safeguard for userspace using a signed 32-bit time_t.
+
+	  A rejected date leaves system time unchanged, normally near the
+	  Unix epoch, and the RTC's hctosys sysfs attribute reads 0. Userspace
+	  must supply the time if no other source has initialized it.
+
+	  Disable this only if the entire userspace, including the init
+	  system, supports dates beyond 2038. Otherwise, an invalid future
+	  date in the RTC may prevent booting.
+
+	  Disabling this check does not require disabling COMPAT_32BIT_TIME:
+	  userspace with a 64-bit time_t may still use legacy system calls
+	  for operations that do not represent dates beyond 2038.
+
+	  If unsure, say Y.
+
 config RTC_HCTOSYS_DEVICE
 	string "RTC used to set the system time"
 	depends on RTC_HCTOSYS
diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index 01ba04028f1f..18ea141ab8c2 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -72,12 +72,14 @@ static void rtc_hctosys(struct rtc_device *rtc)
 
 	tv64.tv_sec = rtc_tm_to_time64(&tm);
 
-#if BITS_PER_LONG == 32
-	if (tv64.tv_sec > INT_MAX) {
+	if (IS_ENABLED(CONFIG_RTC_HCTOSYS_TIME32_LIMIT) &&
+	    tv64.tv_sec > INT_MAX) {
+		dev_warn(rtc->dev.parent,
+			 "hctosys: rejecting %ptR UTC due to CONFIG_RTC_HCTOSYS_TIME32_LIMIT=y\n",
+			 &tm);
 		err = -ERANGE;
 		goto err_read;
 	}
-#endif
 
 	err = do_settimeofday64(&tv64);
 

base-commit: 587858367581b9c55c3690f4e63382ad622719d4
-- 
2.39.5 (Apple Git-154)

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

[sashiko-bot]

> 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.
> 
> Add RTC_HCTOSYS_TIME32_LIMIT for 32-bit kernels, defaulting to y to
> preserve the existing safeguard. Allow integrators to disable it once
> their entire userspace, including init, supports post-2038 dates.
> Warn on rejection with the RTC date and option name so users can
> identify the cause and find the setting.
> 
> Keep the option independent of COMPAT_32BIT_TIME. Userspace with a
> 64-bit time_t may still need legacy syscalls for operations that do
> not represent post-2038 dates.
> 
> Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
> Link: https://lore.kernel.org/all/20220908115337.1604277-1-arnd@kernel.org/
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914212537.1452-1-kmehltretter@gmail.com?part=1

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

[Arnd Bergmann]

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.

Hi Karl,

Thanks for revisiting this!

> Add RTC_HCTOSYS_TIME32_LIMIT for 32-bit kernels, defaulting to y to
> preserve the existing safeguard. Allow integrators to disable it once
> their entire userspace, including init, supports post-2038 dates.
> Warn on rejection with the RTC date and option name so users can
> identify the cause and find the setting.
>
> Keep the option independent of COMPAT_32BIT_TIME. Userspace with a
> 64-bit time_t may still need legacy syscalls for operations that do
> not represent 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

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

[Technically it would also make sense to enable the option on 64-bit
kernels running 32-bit userspace, which some users do to reduce
memory usage. However, we never supported that case and I'd rather
not start now.]

      Arnd

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

[Karl Mehltretter]

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.
> 
> Hi Karl,
> 
> 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

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 would prefer to preserve existing RTC date acceptance by default
and let integrators opt into later dates once their userspace is
ready. Keeping the posted settings would do that:

    depends on RTC_HCTOSYS && !64BIT
    default y

With RTC_HCTOSYS=y, for RTC dates beyond the cutoff:

D = don't care (y or n gives the same result).
Kernel denotes kernel bitness, regardless of userspace bitness.

With the patch as posted:

  Kernel  COMPAT_32BIT_TIME  RTC_HCTOSYS_TIME32_LIMIT  Allow past cutoff
  ------  -----------------  ------------------------  -----------------
  32-bit  D                  y (default)               n
  32-bit  D                  n                         y
  64-bit  D                  n (unavailable)           y

For reference, the baseline behaves as follows:

  Kernel  COMPAT_32BIT_TIME  Allow past cutoff
  ------  -----------------  -----------------
  32-bit  D                  n
  64-bit  D                  y

Karl

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

[Arnd Bergmann]

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

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

[Karl Mehltretter]

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.

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

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

[1] https://git.musl-libc.org/cgit/musl/tree/compat/time32/clock_gettime32.c

Thanks,
Karl

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

[Arnd Bergmann]

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

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

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

[Arnd Bergmann]

On Tue, Sep 22, 2026, at 23:37, Alexandre Belloni wrote:
> On 19/09/2026 11:16:29+0200, Arnd Bergmann wrote:
>> On Sat, Sep 19, 2026, at 02:10, Karl Mehltretter wrote:
>>
>> 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.

Sure, simply disallowing RTC_HCTOSYS on any build that contains support
for time32 userspace would also avoid this.

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

Not sure what exactly you are suggesting here. Do you mean we should
try again to address this in systemd in order to no longer need
the RTC_HCTOSYS hack?

      Arnd

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

[Alexandre Belloni]

On 24/09/2026 17:07:30+0200, Arnd Bergmann wrote:
> On Tue, Sep 22, 2026, at 23:37, Alexandre Belloni wrote:
> > On 19/09/2026 11:16:29+0200, Arnd Bergmann wrote:
> >> On Sat, Sep 19, 2026, at 02:10, Karl Mehltretter wrote:
> >>
> >> 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.
> 
> Sure, simply disallowing RTC_HCTOSYS on any build that contains support
> for time32 userspace would also avoid this.
> 
> > 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.
> 
> Not sure what exactly you are suggesting here. Do you mean we should
> try again to address this in systemd in order to no longer need
> the RTC_HCTOSYS hack?
> 

Well I guess we'll get the same answer that this is too late in the boot
process.

My proposed solution is to have a way to tell the kernel what size of
time_t userspace actually supports as there is no way to automatically
detect it. That's why I was thinking a kernel cmdline parameter would
fit. This would allow us to be 100% correct.

Else, I'm fine with your last proposal. I guess this would leave us with
two unhandled cases:
 - 64bit systems with 32 bit userspace that you said we don't want to
   support
 - 32bit systems with 64bit time_t userspace that would not work
   properly with the default configuration.

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

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

[Arnd Bergmann]

On Mon, Oct 5, 2026, at 15:49, Alexandre Belloni wrote:
> On 24/09/2026 17:07:30+0200, Arnd Bergmann wrote:
>> On Tue, Sep 22, 2026, at 23:37, Alexandre Belloni wrote:
>> 
>> Not sure what exactly you are suggesting here. Do you mean we should
>> try again to address this in systemd in order to no longer need
>> the RTC_HCTOSYS hack?
>> 
>
> Well I guess we'll get the same answer that this is too late in the boot
> process.

Right

> My proposed solution is to have a way to tell the kernel what size of
> time_t userspace actually supports as there is no way to automatically
> detect it. That's why I was thinking a kernel cmdline parameter would
> fit. This would allow us to be 100% correct.
>
> Else, I'm fine with your last proposal.

Ok, thanks!

A command line argument would work for me as well, if we can make it
have a working default for the COMPAT_32BIT_TIME=n case.

We could of course combine a compile-time and boot-time flag, but
there should not be any need for that.

> I guess this would leave us with
> two unhandled cases:
>  - 64bit systems with 32 bit userspace that you said we don't want to
>    support

Right, as far as I'm concerned this has always done what I want,
so no need to change it.

>  - 32bit systems with 64bit time_t userspace that would not work
>    properly with the default configuration.

At this point it's just part of the platform defconfig, and
users can pick the setting.

       Arnd