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: <6269543.oe8MmZQUmX@wuerfel>
Date:	Mon, 22 Feb 2016 16:44:32 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	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 Monday 22 February 2016 13:43:19 One Thousand Gnomes wrote:
> On Mon, 22 Feb 2016 14:00:14 +0100
> Alexandre Belloni <alexandre.belloni@...e-electrons.com> wrote:
> > I can also agree that systemd could be a bit more robust there but
> > you'll have to convince Lennart...
> 
> That's a systemd problem. If their code isn't robust then the
> distributiosn will just have to keep patching it.
> 
> The only problem that can actually be "fixed" is the case where it isn't
> 2038 yet and the user has a scrambled RTC. In that case your init tools
> need to be robust enough to handle the problem or use APIs that don't
> break. The kernel can't actually "fix" this because it never knows
> whether your userspace is sane or not.
> 
> I'd argue btw that any code using timerfd_create with TFD_TIMER_ABSTIME
> and passing it a value that wraps the range permitted by that time
> representation *is* buggy. It's the applications responsibility to use
> values that are within the defined behavioural range of the function.

IIRC, the problem is that user space passes in TIME_T_MAX and the kernel
is considering that to be in the past because the clock is set beyond 2038.

I find it hard to blame user space for that, but I don't have a good
idea for solving this either.

In case of systemd, it is literally the first thing that runs on the kernel
after booting, so we could fall back to setting the time to some known
working state (1970 or 2016 or something), but that would be a rather
bad default policy once the system has been running for a while.

The best we can do for a workaround localized to timerfd might be
to make absolute timers behave differently when they come from a 32-bit
process and the current time has already overflown.

> Far more constructive would I think be to add a TFD_TIME64 flag to
> timerfd_create that allows the use of 64bit time in timerfd_*. Systemd
> can then adopt that safely even on 32bit legacy systems, while on 64bit
> TFD_TIME64 would presumably be 0 and the 64/32bit time structs would
> match.

I should really dust off my syscall series, I'd rather not have any
partial solutions to merged here.

	Arnd