for stable -- random: use chacha20 for get_random_int/long
From: Jason A. Donenfeld
Date: Thu Apr 06 2017 - 23:28:08 EST
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@xxxxxxxxx>
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@xxxxxxxxx>
Suggested-by: Theodore Ts'o <tytso@xxxxxxx>
Cc: Theodore Ts'o <tytso@xxxxxxx>
Cc: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
Signed-off-by: Theodore Ts'o <tytso@xxxxxxx>