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: <20160222134319.31e77b71@lxorguk.ukuu.org.uk>
Date:	Mon, 22 Feb 2016 13:43:19 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc:	Arnd Bergmann <arnd@...db.de>, 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 Mon, 22 Feb 2016 14:00:14 +0100
Alexandre Belloni <alexandre.belloni@...e-electrons.com> wrote:
.
> But there are long lived products like cars, parking ticket machines,
> insulin pumps, automated external defibrillators, home automation
> controllers, point of sales, etc... Some of those may still be in use in
> 22 years.

And if so their vendors will have provided updates. Your "fix" doesn't
help anything, it just means the user sees it fail in a different way.

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

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.

Alan