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: <20160220204715.GJ2222@piout.net>
Date:	Sat, 20 Feb 2016 21:47:15 +0100
From:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	rtc-linux@...glegroups.com,
	Alessandro Zummo <a.zummo@...ertech.it>,
	Arnd Bergmann <arnd@...db.de>, 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 19:43:10 +0000, One Thousand Gnomes wrote :
> On Sat, 20 Feb 2016 20:10:44 +0100
> Alexandre Belloni <alexandre.belloni@...e-electrons.com> wrote:
> 
> > hctosys is setting the system time from the kernel. This means that 32bit
> > system can get their time set to a date after the 31bit time_t overflow.
> > 
> > This is currently an issue as userspace is not yet ready to handle those
> > dates and may break. For example systemd's usage of timerfd shows that the
> > timerfd will always fire immediately because it can't be set at a date
> > after the current date.
> > 
> > The new RTC_INVALID_2038 option will make sure that date after 03:09:07 on
> > Jan 19 2038 are invalid. This is 5 minutes before the 31bit overflow. This
> > leaves enough time for userspace to react and is short enough to make the
> > issue visible.
> 
> This is kind of pointless. You replace loading the RTC and discovering
> the time isn't supported by your system with not loading he RTC and
> discovering your system clock is magically and almost un-debuggably
> wrong, and when something like NTP syncs it, breaks anyway.
> 
> The only way to deal with 2038 is to fix your user space. People need to
> deal with reality, even if it's not all pink unicorns and rainbows.
> 

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

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