From: Greg KH <greg@kroah.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: stable@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: for stable -- random: use chacha20 for get_random_int/long
Date: Mon, 10 Apr 2017 17:04:27 +0200 [thread overview]
Message-ID: <20170410150427.GB18751@kroah.com> (raw)
In-Reply-To: <CAHmME9pT9hZAXZGT8tq07mzxecitmzSKqQE-kDaBB6njs8V+BQ@mail.gmail.com>
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 <Jason@zx2c4.com>
> 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 <Jason@zx2c4.com>
> Suggested-by: Theodore Ts'o <tytso@mit.edu>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Seems reasonable to me, now queued up, thanks!
greg k-h
prev parent reply other threads:[~2017-04-10 15:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 3:27 Jason A. Donenfeld
2017-04-10 15:04 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170410150427.GB18751@kroah.com \
--to=greg@kroah.com \
--cc=Jason@zx2c4.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome