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 b3a5ac42ab ("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: b3a5ac42ab ("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>
Link: https://patch.msgid.link/20261020080026.2461578-1-arnd@kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
This commit is contained in:
Karl Mehltretter 2026-10-20 09:59:21 +02:00 committed by Alexandre Belloni
parent d691a96370
commit b253c2e96a
2 changed files with 26 additions and 3 deletions

View File

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

View File

@ -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);