Re: for stable -- random: use chacha20 for get_random_int/long

[Greg KH]

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

Re: for stable -- random: use chacha20 for get_random_int/long

[Greg KH]

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

for stable -- random: use chacha20 for get_random_int/long

[Jason A. Donenfeld]

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 

for stable -- random: use chacha20 for get_random_int/long

[Jason A. Donenfeld]

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