[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2575012.qQ3uE1GZEQ@tauon.atsec.com>
Date: Tue, 21 Jun 2016 18:34:01 +0200
From: Stephan Mueller <smueller@...onox.de>
To: John Stultz <john.stultz@...aro.org>
Cc: Arnd Bergmann <arnd@...db.de>,
Herbert Xu <herbert@...dor.apana.org.au>,
Alexander Kuleshov <kuleshovmail@...il.com>,
y2038 Mailman List <y2038@...ts.linaro.org>,
lkml <linux-kernel@...r.kernel.org>,
linux-crypto@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Kees Cook <keescook@...omium.org>
Subject: Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime
Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz:
Hi John,
> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <arnd@...db.de> wrote:
> > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
> >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
> > Compared to the previous __getnstimeofday(), the difference is
> >
> > - using "monotonic" timebase instead of "real", so the zero time
> >
> > is when the system booted rather than Jan 1 1970
>
> I haven't looked at the details of the calling code, but I'd worry for
> crypto uses, especially if its being used for entropy collection,
> using the monotonic clock instead of the realtime clock might be
> problematic.
Funnily it does not seem like that. All tests that I have conducted show that
monotonic clocks behave equally as realtime clocks, because the uncertainty
lies in the execution time of a set of instructions. All we need to do is to
measure it with a timer that has a resolution that allows detecting these
variations.
>
> > - "raw" means we don't honor updates for the rate based on ntp,
> >
> > which is probably better as the ntp state might be observable
> > over the net (it probably doesn't matter, but it can't hurt)
>
> So... this feels like a very vague explanation, and the lack of
> frequency correction here probably need a really good comment. Keeping
> multiple time domains is usually asking for trouble, but we added the
> MONOTONIC_RAW clock to address a few cases where people really wanted
> an abstract hardware counter, which was unaffected by frequency
> corrections. I'd really make sure its clear why this is what you want
> vs the standard system time domain so we don't run into problems
> understanding it later.
Perfect, that is what I would be interested in.
>
> > - "fast" means that in very rare cases, the time might appear
> >
> > to go backwards (it probably can't happen here because you are not
> > called in an NMI).
>
> "fast" really means "safe-for-nmi wrt to locking". The tradeoff being
> that when frequency adjustments occur, and if your code is delayed,
> you might see time go backwards by a small amount. This allows
My code would not see that as an issue.
> tracing/sched code (or other code called from NMI) to not have to
> duplicate the timekeeping infrastructure.
>
> I think without a much better explanation, using the "fast" method
> isn't really warranted here.
Thanks a lot. With that, I would think that the proposed ktime_get_raw_fast_ns
is good for use, which is supported with testing on my system.
>
> thanks
> -john
Ciao
Stephan
Powered by blists - more mailing lists