[Y2038] Re: RTC hctosys disabled for 32-bit systems

[Arnd Bergmann]

On Thu, Sep 1, 2022, at 3:46 PM, Russell King (Oracle) wrote:
> On Thu, Sep 01, 2022 at 03:12:57PM +0200, Arnd Bergmann wrote:
>> Ah, I forgot that systemd actually needs it. So I guess there is
>> currently no way to use systemd on 32-bit machines that are
>> meant to survive 2038, regardless of whether systemd and glibc are
>> built with a 64-bit time_t or not, right?
>> 
>> Is there perhaps a way to change the logic in a way that
>> it does not depend on the current time but instead depends
>> on a property of the RTC device itself, so we make systems
>> break immediately instead of by surprise in 2038?
>
> Are you seriously suggesting to cause regressions on systems where
> the RTC can send the kernel's timekeeping back to the early 1900s,
> rather than printing a big fat warning message in the kernel log?

I think the systems that can send the timekeeping back into the early
1900s (or at least after 1970) are fine, the problem is the systems
that can randomly send the timekeeping into the post-2038 future.

What kind of warning would you suggest to print here? I don't see
how warning about broken hardware at every boot would help, since
there is no way for users to react to that warning. Similarly,
warning about a time_t value past 2038 does not help because
at that time one either has a bricked system (if using a systemd
with 32-bit time_t)  or it is actually 2038 and the system
reverts back to 1970.

What might work is to have all drivers for broken RTC devices
default to a 1902-2037 (or 1970-2037) date range to ensure
that only those devices are broken in 2038, but still allow
overriding the "start-year" property in DT for machines that
don't use the broken systemd.

      Arnd