RTC hctosys disabled for 32-bit systems

[Alexandre Belloni]

On 01/09/2022 15:12:57+0200, Arnd Bergmann wrote:
> On Thu, Sep 1, 2022, at 2:49 PM, Alexandre Belloni wrote:
> > On 01/09/2022 13:55:19+0200, Arnd Bergmann wrote:
> >> 
> >> The only reliable fix I can see would be to disable
> >> CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan
> >> for the long run anyway, but I don't know if there has been any
> >> progress in convincing distros to turn it off.
> >> 
> >
> > This is still my plan but systemd mandates RTC_HCTOSYS and I couldn't
> > convince Lennart otherwise.
> 
> 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?
> 

Well, it doesn't actually need it. It could as well go and read the RTC
and decide what to do with the time it gets. The main reason they want
it is because the log timestamps are correct earlier when the kernel does
it.

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

The safe thing to do is really to not use hctosys and have a systemd
unit that reads the RTC from userspace. See
https://github.com/systemd/systemd/issues/17737 for the whole
discussion.

> 
> As far as I remember, the workaround was only needed for
> certain devices that may set the time to something after 2038
> on a depleted battery, but other devices would have a better
> failure case, right?
> 

Yes, this is the main cause, anything able to set the system time after
2038 with a 32bit userspace will cause that (and basically I think this
is only hctosys). The issue is that many RTCs don't have a default value
for the time registers after power failure. This is usually not an issue
as there is also a bit allowing to detect whether the time is correct.
note that this will also be an issue once we actually reach 2038 with a
32bit userspace.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com