From b253c2e96a80aac8e2bc67b425bf007ed78d4d8c Mon Sep 17 00:00:00 2001 From: Karl Mehltretter Date: Tue, 20 Oct 2026 09:59:21 +0200 Subject: [PATCH] rtc: class: Make the time32 hctosys limit configurable 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] ---- I ended up rewriting most of the text but kept Karl's ownership as he did the original patch. 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 Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20261020080026.2461578-1-arnd@kernel.org Signed-off-by: Alexandre Belloni --- 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 243edd37c0d7..1e863f1d36fd 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);