rtc: class: Make the time32 hctosys limit configurable

From: Karl Mehltretter <[email protected]>

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.

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

index 8d9f4ef92f5a..9b6b0c31eb8e 100644
@@ -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

index 01ba04028f1f..18ea141ab8c2 100644
@@ -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

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