linux-kernel - Re: Setting monotonic 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: <alpine.DEB.2.21.1810030812550.1435@nanos.tec.linutronix.de>
Date:   Wed, 3 Oct 2018 08:14:44 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
cc:     Arnd Bergmann <arnd@...db.de>, avagin@...tuozzo.com,
        dima@...sta.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        0x7f454c46@...il.com, adrian@...as.de,
        Andy Lutomirski <luto@...nel.org>,
        Christian Brauner <christian.brauner@...ntu.com>,
        gorcunov@...nvz.org, "H. Peter Anvin" <hpa@...or.com>,
        Ingo Molnar <mingo@...hat.com>, Jeff Dike <jdike@...toit.com>,
        Oleg Nesterov <oleg@...hat.com>, xemul@...tuozzo.com,
        Shuah Khan <shuah@...nel.org>,
        containers@...ts.linux-foundation.org, criu@...nvz.org,
        Linux API <linux-api@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        linux-kselftest@...r.kernel.org
Subject: Re: Setting monotonic time?

On Wed, 3 Oct 2018, Thomas Gleixner wrote:
> On Wed, 3 Oct 2018, Eric W. Biederman wrote:
> > Direct access to hardware/drivers and not through an abstraction like
> > the vfs (an abstraction over block devices) can legitimately be handled
> > by hotplug events.  I unplug one keyboard I plug in another.
> > 
> > I don't know if the input layer is more of a general abstraction
> > or more of a hardware device.  I have not dug into it but my guess
> > is abstraction from what I have heard.
> > 
> > The scary difficulty here is if after restart input is reporting times
> > in CLOCK_MONOTONIC and the applications in the namespace are talking
> > about times in CLOCK_MONOTONIC_SYNC.  Then there is an issue.  As even
> > with a fixed offset the times don't match up.
> > 
> > So a time namespace absolutely needs to do is figure out how to deal
> > with all of the kernel interfaces reporting times and figure out how to
> > report them in the current time namespace.
> 
> So you want to talk to Arnd who is leading the y2038 effort. He knowns how
> many and which interfaces are involved aside of the obvious core timer
> ones. It's quite an amount and the problem is that you really need to do
> that at the interface level, because many of those time stamps are taken in
> contexts which are completely oblivious of name spaces. Ditto for timeouts
> and similar things which are handed in through these interfaces.

Plus you have to make sure, that any new interface will have that
treatment. For y2038 that's easy as we just require to use timespec64 for
new ones. For your problem that's not so trivial.

Thanks,

	tglx