linux-kernel - Re: [PATCH] rtc: Add an option to invalidate dates in 2038

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: <20160220231702.GK2222@piout.net>
Date:	Sun, 21 Feb 2016 00:17:02 +0100
From:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	rtc-linux@...glegroups.com,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Willy Tarreau <w@....eu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc: Add an option to invalidate dates in 2038

On 20/02/2016 at 23:16:48 +0100, Arnd Bergmann wrote :
> On Saturday 20 February 2016 21:47:15 Alexandre Belloni wrote:
> > 
> > Actually, I'm not trying to solve the 2038 issue.
> > 
> > But in the current state on 32 bit platforms, while the kernel is able
> > to handle a 64bit date, userspace is not. The main issue is that
> > distributions use HCTOSYS so if the RTC is set to a date after 2038
> > (which we know is currently bogus), the kernel will set a system time to
> > that date.
> > 
> > This result in a system that fails when using timerfd, The timerfd will
> > always fire immediately (until, as some people pointed out, we have
> > relative timers).
> > 
> > This is know to break systemd [1] but I have had reports for other
> > failing applications.
> > 
> > I understand this is a workaround and I plan to switch the default to n
> > once libc and critical userspace is able to handle 64 bit time.
> > 
> > The other way of solving that is to get back to a 32 bit time_t
> > internally until we switch the whole userspace to a 64 bit time_t but I
> > don't think this is practical.
> > 
> > [1] https://github.com/systemd/systemd/issues/1143
> > 
> 
> I think in both cases you introduce a new 2038 problem though:
> as long as you have a kernel that tries to support an old
> 32-bit systemd build, the kernel becomes incompatible with RTC
> times beyond 2038, even on 64-bit systems and 32-bit systems
> that have fixed system call table and fixed user space.
> 

It doesn't change anything for 64-bit systems, I've excluded them by
using "depends on !64BIT". Right now, it doesn't change anything for
32-bit systems because either way, they will fail in 2038.

> This is bad because it means we still have to break systemd
> eventually in order to fix the 2038 overflow.
> 

Won't we have to recompile every application to support 64-bit time on
32-bit system anyway? That will be a good time to remove that option.

> The plan to revert this after glibc has been converted is
> problematic because a lot of 32-bit distros will likely never
> recompile with 64-bit time_t in order to avoid breaking
> backwards compatibility. While we could require that user
> space and kernel must match here (either support 64-bit time_t
> everywhere or nowhere), that makes it much harder to deal
> with the migration, and it has always been a strict requirement
> that none of the changes for y2038 compatibility break existing
> user space (which of course is what happened for RTC and what
> we need to fix here).

If the distribution don't recompile to support a 64-bit time, then the
32-bit systems will break in 2038 anyway and they will absolutely
require my patch or something along those lines to still boot using
systemd.

> 
> Has the problem of random RTC times been observed on more than
> one RTC driver yet? Maybe we can just apply your workaround
> to that one driver that saw it instead.
> 
> Have you figured out whether there is a pattern in the reported
> times? Is it just completely random or could we perhaps
> detect an RTC that reports an invalid time other than by 
> looking at the year?
> 

All the failures seem quite random to me but the reports I get are not
that precise.

I know it happens with PCF8523 and that can be true because the
datasheet says the date is undefined at reset. The handling of the OS
bit (that bit indicates the date is probably wrong) has to be fixed and
I will take care of that.

If that is the only RTC with that particular issue, we clearly don't
need my workaround. But As I say, I can ask but I don't have a clear
list of the affected system and their RTC.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com