linux-kernel - Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time

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: <20151009103421.GC2166@localhost>
Date:	Fri, 9 Oct 2015 12:34:21 +0200
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	y2038@...ts.linaro.org, John Stultz <john.stultz@...aro.org>,
	Prarit Bhargava <prarit@...hat.com>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t
 overflow

On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote:
> On Thu, 8 Oct 2015, Miroslav Lichvar wrote:
> > Applications are not allowed to rely on system time being sane?
> > To me the current behavior looks like the kernel is throwing the
> > applications off a cliff, while it's the only thing that can fly :).
> 
> As Arnd said, you are creating a wrong sense of safety. They fall off
> the cliff with your changes as well. The fall is just different. Think
> about timeouts, user space overflows of time_t etc.

I think vast majority of them won't fall. It doesn't prevent all
problems, but at least the userspace agrees with kernel on what the
current time it is, that looks to me like the most difficult one to
fix in applications.

> We need to fix all of it, no matter what.

Yeah, that would be nice, but I don't think it's realistic.

Do you feel the same about preventing the time from reaching
KTIME_MAX?

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/