From: Karl Mehltretter <kmehltretter@gmail.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Karl Mehltretter <kmehltretter@gmail.com>,
linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>
Subject: [PATCH] rtc: class: Make the time32 hctosys limit configurable
Date: Mon, 14 Sep 2026 23:25:37 +0200 [thread overview]
Message-ID: <20260914212537.1452-1-kmehltretter@gmail.com> (raw)
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)
next reply other threads:[~2026-09-14 21:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 21:25 Karl Mehltretter [this message]
2026-09-14 21:29 ` [PATCH] rtc: class: Make the time32 hctosys limit configurable sashiko-bot
2026-09-15 5:48 ` Arnd Bergmann
2026-09-15 22:37 ` Karl Mehltretter
2026-09-16 6:56 ` Arnd Bergmann
2026-09-19 0:10 ` Karl Mehltretter
2026-09-19 9:16 ` Arnd Bergmann
2026-09-22 21:37 ` Alexandre Belloni
2026-09-24 15:07 ` Arnd Bergmann
2026-10-05 13:49 ` Alexandre Belloni
2026-10-06 12:33 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260914212537.1452-1-kmehltretter@gmail.com \
--to=kmehltretter@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.