linux-kernel - Re: [Y2038] [PATCH] crypto: Jitter RNG

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:	Tue, 21 Jun 2016 21:37:03 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	y2038@...ts.linaro.org
Cc:	John Stultz <john.stultz@...aro.org>,
	Stephan Mueller <smueller@...onox.de>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Alexander Kuleshov <kuleshovmail@...il.com>,
	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: Jitter RNG - use ktime_get_raw_ns as fallback

On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote:
> On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller <smueller@...onox.de> wrote:
> > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz:
> >
> > Hi John,
> >
> >> I don't see in the above an explanation of *why* you're using
> >> ktime_get_raw_ns() instead of ktime_get_ns().
> >
> > Could you help me understand what the difference is or point me to some
> > documentation? I understood that we only talked about the _raw variant.
> 
> Using specialized interfaces with subtle semantics w/o understanding
> them is sort of my concern here.
> 
> There are reasons why you might want to use the ktime_get_raw_ns()
> interface over ktime_get_ns(), but they have not been made clear in
> the comment. Arnd discussed some potential concerns that the freq
> adjustment done by ntp might be somewhat predictable/controlled by
> remote parties, which could have some effect in the calculation. That
> feels a little overly vague to me, but I'm no crypto expert, so if
> that is a reasonable concern, then it should be a conscious and
> documented decision.

My original patch changed __getnstimeofday() to __getnstimeofday64(),
which kept the original semantics of not warning in case the clock
source is suspended (which is the only different to the normal
getnstimeofday{,64}().

I did the patch a while time ago along with a number of other patches
that I never sent out until last week, so I don't remember the
reasoning for suggesting ktime_get_raw_fast_ns() over ktime_get_raw_ns(),
but I sure wanted to keep the non-warning behavior, and ktime_get_ns()
warns on timekeeping_suspended() while the other two don't.

If we don't care about the non-warning aspect, ktime_get_ns() makes
most sense here, and the original code should probably have used
getnstimeofday() as well.

	Arnd