From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753657AbdDJPFT (ORCPT ); Mon, 10 Apr 2017 11:05:19 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:42500 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753340AbdDJPEh (ORCPT ); Mon, 10 Apr 2017 11:04:37 -0400 X-ME-Sender: X-Sasl-enc: lP4T3gwg5XnwfAKwPiANaRaFhAYJmRTBg7dqv05LXs+M 1491836675 Date: Mon, 10 Apr 2017 17:04:27 +0200 From: Greg KH To: "Jason A. Donenfeld" Cc: stable@vger.kernel.org, "Theodore Ts'o" , LKML Subject: Re: for stable -- random: use chacha20 for get_random_int/long Message-ID: <20170410150427.GB18751@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 07, 2017 at 05:27:40AM +0200, Jason A. Donenfeld wrote: > Given that the below commit isn't very big and adds a nice security > property (in addition to performance), it might be worthwhile to > backport this to 4.9 stable. It's not a candidate for 4.4, since that > kernel doesn't use chacha for the rng at all. > > As this is in random.c, it's Ted's and Greg's judgement call. > > commit f5b98461cb8167ba362ad9f74c41d126b7becea7 > Author: Jason A. Donenfeld > Date: Fri Jan 6 19:32:01 2017 +0100 > > random: use chacha20 for get_random_int/long > > Now that our crng uses chacha20, we can rely on its speedy > characteristics for replacing MD5, while simultaneously achieving a > higher security guarantee. Before the idea was to use these functions if > you wanted random integers that aren't stupidly insecure but aren't > necessarily secure either, a vague gray zone, that hopefully was "good > enough" for its users. With chacha20, we can strengthen this claim, > since either we're using an rdrand-like instruction, or we're using the > same crng as /dev/urandom. And it's faster than what was before. > > We could have chosen to replace this with a SipHash-derived function, > which might be slightly faster, but at the cost of having yet another > RNG construction in the kernel. By moving to chacha20, we have a single > RNG to analyze and verify, and we also already get good performance > improvements on all platforms. > > Implementation-wise, rather than use a generic buffer for both > get_random_int/long and memcpy based on the size needs, we use a > specific buffer for 32-bit reads and for 64-bit reads. This way, we're > guaranteed to always have aligned accesses on all platforms. While > slightly more verbose in C, the assembly this generates is a lot > simpler than otherwise. > > Finally, on 32-bit platforms where longs and ints are the same size, > we simply alias get_random_int to get_random_long. > > Signed-off-by: Jason A. Donenfeld > Suggested-by: Theodore Ts'o > Cc: Theodore Ts'o > Cc: Hannes Frederic Sowa > Cc: Andy Lutomirski > Signed-off-by: Theodore Ts'o Seems reasonable to me, now queued up, thanks! greg k-h