linux-kernel - Re: Question about [PATCH] [RFC] rtc: y2038: remove broken RTC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1d82ecbb-c9fa-49e0-8432-7fd152e01440@app.fastmail.com>
Date: Fri, 28 Jun 2024 08:01:30 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Alexandre Belloni" <alexandre.belloni@...tlin.com>,
 "Leonard Anderweit" <L.Anderweit@...tec.de>
Cc: "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "upstream@...tec.de" <upstream@...tec.de>
Subject: Re: Question about [PATCH] [RFC] rtc: y2038: remove broken RTC_HCTOSYS
 workaround

On Fri, Jun 28, 2024, at 00:43, Alexandre Belloni wrote:
> On 24/06/2024 11:41:41+0000, Leonard Anderweit wrote:
>> Hi,
>> 
>> I found this patch [1] which is necessary for a project I'm currently
>> working on. I'm using phyboard-wega [2] with an am335 ARM SoC which I
>> want to make y2038 proof.
>> Is there any reason it was never accepted?

Sorry for not having replied earlier. I'm definitely interested
in helping to make this work better, having spent a lot of time
on the kernel side of the y2038 work.

Which combination of distro, libc and init system are you using
in your work?

Are you running with COMPAT_32BIT_TIME disabled? This is something
you probably want in order to better test for corner cases that
still use time32 kernel ABIs somewhere, but it still requires
adding a few more workarounds in libc and other userspace
sources.

> The systemd maintainer think the kernel is well placed to take a
> decision it can't actually take so they won't fix a bug where systemd is
> crashing when userspace is 32bit.
>
> The whole situation is frustrating and honestly, nobody should use the
> hctosys insanity anyway. Obviously systemd mandates its usage and this
> is yet another topic on which they think the kernel is better placed to
> take decisions that are actually userspace policy.
>
> I've been arguing for a while and gave up.

I thought that systemd had at least fix the bug where it would
crash when a random 64-bit time was set, so we could try again
with this patch and see what breaks?

An important difference now is that Debian is finally changing
to a time64 userspace, which both avoids the problem that
the broken rtc_hctosys() time truncation was trying to work
around (all times returned here are now valid) and it means
that there is a much higher incentive to actually make
a systemd based userland work past 2038.

      Arnd