RTC hctosys disabled for 32-bit systems

Arnd Bergmann arnd at arndb.de
Thu Sep 1 08:29:09 PDT 2022


On Thu, Sep 1, 2022, at 3:57 PM, Alexandre Belloni wrote:
> On 01/09/2022 15:12:57+0200, Arnd Bergmann wrote:
>> 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.

The problem is that people are deploying systems already with the
expectation that they will survive y2038, and it is rather unlikely that
the developers that build these systems will be around to update the
systems anywhere close to that. glibc now has the 64-bit time_t support
(and musl has had it for a while), so even if you do unit tests on
your own software to check for bugs, you wouldn't necessarily run into
the issue unless you reboot the system with the RTC set to the future
as part of the testing.

In effect, whatever we will need in 2038, we also need to have today,
so the current code cannot remain unchanged, the question is just
about how to minimize the damage.

Is there any way to find out which RTC drivers are affected by this?

    Arnd



More information about the linux-arm-kernel mailing list