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]

Date: Fri, 28 Jun 2024 06:33:35 +0000
From: Stefan Müller-Klieser
	<S.Mueller-Klieser@...tec.de>
To: Leonard Anderweit <L.Anderweit@...tec.de>, "arnd@...db.de"
	<arnd@...db.de>, "alexandre.belloni@...tlin.com"
	<alexandre.belloni@...tlin.com>
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

Am Freitag, dem 28.06.2024 um 08:01 +0200 schrieb Arnd Bergmann:
> 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?

We have a Yocto scarthgap with glibc 2.39 and systemd 255.4.

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

We wanted to, but this still keeps systemd from booting. We are
debugging this currently.

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

With the patch and COMPAT_32BIT_TIME enabled, it seems to work,
at least our test cases do.

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

Yocto also seems to have the basics in place and some sanity checks
available for scarthgap but as said, we cannot disable the 32 bit api.
Regards, Stefan

> 
>       Arnd
>