From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752656AbcFUQwc (ORCPT ); Tue, 21 Jun 2016 12:52:32 -0400 Received: from mail.eperm.de ([89.247.134.16]:37690 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750998AbcFUQwT (ORCPT ); Tue, 21 Jun 2016 12:52:19 -0400 From: Stephan Mueller To: John Stultz Cc: Arnd Bergmann , Herbert Xu , Alexander Kuleshov , y2038 Mailman List , lkml , linux-crypto@vger.kernel.org, "David S. Miller" , Kees Cook Subject: Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime Date: Tue, 21 Jun 2016 18:51:32 +0200 Message-ID: <12040808.ISNuLM4SqW@tauon.atsec.com> User-Agent: KMail/4.14.10 (Linux/4.4.9-300.fc23.x86_64; KDE/4.14.20; x86_64; ; ) In-Reply-To: References: <20160617155952.1021006-1-arnd@arndb.de> <2575012.qQ3uE1GZEQ@tauon.atsec.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz: Hi John, > On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: > > > > Hi John, > > > >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann 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. > > Ok. If you're only using it for interval measurements, then either way > shouldn't matter. I just wanted to make sure the entropy wasn't coming > from the actual time. > > >> > - "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. > > But documenting *why* clearly is the thing I'd very strongly suggest. > If we need to make some slight semantic change for whatever reason, I > don't want folks worried "we can't do that because the crypto code is > using it for voodoo". I hope my explanation is sufficient to not count as voodoo: I only need an interval measurement capability which has a sufficient high resolution similar or better than RDTSC on x86. > > >> > - "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. > > So.. again, I'd avoid using the "fast" accessor unless there is a > clear need or obvious benefit. Which should be documented. So, you suggest ktime_get_raw_ns? If yes, let me test that for one use case. Thanks Stephan