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] [day] [month] [year] [list]

Message-Id: <67ae5c7b-18bb-47c4-b0ee-ceaf397ffe8d@app.fastmail.com>
Date: Fri, 28 Jun 2024 08:53:53 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: Stefan Müller-Klieser <S.Mueller-Klieser@...tec.de>,
 "Leonard Anderweit" <L.Anderweit@...tec.de>,
 "Alexandre Belloni" <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

On Fri, Jun 28, 2024, at 08:33, Stefan Müller-Klieser wrote:
> 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.

Ok

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

My guess is that this is still an issue with glibc still relying
on time32 system calls to be present. I have not looked at it
in a while, but the most common time32 syscall that everyone
relies on is futex(). With COMPAT_32BIT_TIME disabled, you
need to call futex_time64() instead even if there is a NULL
timeout. There may also be other time32 syscalls in use here.

The way I would debug this is to run a 32-bit scarthgap
userspace in a chroot on a 64-bit kernel with COMPAT_32BIT_TIME=n,
to see what kernel interfaces are missing while still being
able to run normal 64-bit debugging tools.
You can do this either on an arm64 or x86_64 host, whichever is
easier for you to get set up.

I don't see anything in systemd itself that relies on time32
syscalls, it does not appear to directly call futex or any
of the other ones, and the seccomp filters in there look like
they take time64 syscalls into account correctly.

       Arnd