linux-kernel - Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON

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: <20151020085934.GB4919@axis.com>
Date:	Tue, 20 Oct 2015 10:59:34 +0200
From:	Jesper Nilsson <jesper.nilsson@...s.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	John Stultz <john.stultz@...aro.org>,
	Jesper Nilsson <jespern@...s.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	Michael Kerrisk <mtk@...7.org>,
	Miroslav Lichvar <mlichvar@...hat.com>,
	Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with
 relative timeouts

On Tue, Oct 20, 2015 at 10:18:22AM +0200, Arnd Bergmann wrote:
> On Monday 19 October 2015 11:53:25 John Stultz wrote:
> > 
> > But yea. At the same time I get you want to avoid user-pain like in
> > the case of the badly initialized RTC, but in that case would
> > returning 0 for RTC reads greater then y2038 on 32 bit systems be a
> > more sane fix?
> 
> I like that idea. In theory we could go further and check that the RTC
> is somewhere between 2015 and 2037 (or higher on 64-bit systems) but
> return 0 (1970) for anything that is outside of that range. That might
> have side-effects for users that have a legitimate reason to backdate
> their clocks though.

This is how the RTC framework used to handle it before the referenced
patch in my original mail, so a reversal (conditional on 32bit)
would solve that part of the problem.

It also looks like Miroslav's patch will handle the other cases of a
accidental user initiated set of a bad date or a maliciously set NTP.
Though, from my point of view, a wrap-around to 1970 would be just as valid
as a jump one week in the past.

What's the current status of that patch?

> 	Arnd

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@...s.com
--
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/