linux-kernel - Re: [PATCH 03/32] timens: Introduce CLOCK

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]

Date:   Fri, 8 Feb 2019 10:46:35 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dmitry Safonov <dima@...sta.com>
cc:     linux-kernel@...r.kernel.org, Andrei Vagin <avagin@...nvz.org>,
        Adrian Reber <adrian@...as.de>,
        Andrei Vagin <avagin@...il.com>,
        Andy Lutomirski <luto@...nel.org>,
        Andy Tucker <agtucker@...gle.com>,
        Arnd Bergmann <arnd@...db.de>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Jeff Dike <jdike@...toit.com>, Oleg Nesterov <oleg@...hat.com>,
        Pavel Emelyanov <xemul@...tuozzo.com>,
        Shuah Khan <shuah@...nel.org>,
        containers@...ts.linux-foundation.org, criu@...nvz.org,
        linux-api@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH 03/32] timens: Introduce CLOCK_MONOTONIC offsets

On Thu, 7 Feb 2019, Thomas Gleixner wrote:
> Does this really need to be an out of line call? If you stick this into the
> clock_get() implementations then it boils down to:
> 
> static inline void timens_add_monotonic(struct timespec64 *ts)
> {
> 	struct timens_offsets *ns_offsets = current->nsproxy->time_ns->offsets;
> 
> 	if (ns_offsets)
> 		*ts = timespec64_add(*ts, ns_offsets->monotonic_time_offset);

And this needs to be a special variant of
timespec64-add_safe(). timespec64_add_safe() is not sufficient, because it
assumes that both values are positive, which is not the case here..

In timer_set() implementations you move the timespec_valid() check after
the add. That's wrong because you really want to check the input value from
user space.

Assume that the caller supplied value is valid and the adjustment brings it
out of range then how should the caller understand why it it rejected?

So timespec64_add_namespace() must check for under and overflow. But doing
this with timespecs is a pain. I rather suggest to rework the whole thing
so hrtimer_nanosleep() takes a ktime_t expiry value and move the conversion
to the call sites. Then the whole offset magic becomes:

   expires = timespec64_to_ktime(rqtp);

   if (abstime)
   	expires = timens_to_host_mono(expires);

and that function can nicely do the underflow and overflow detection and
cap the values to 0 on underflow and KTIME_MAX on overflow.

Hmm?

Thanks,

	tglx