[MODERATED] Re: [PATCH 0/2] more sampling fun 0

[Kees Cook <keescook@chromium.org>]

On Thu, Feb 20, 2020 at 02:15:22PM -0800, speck for Andi Kleen wrote:
> On Thu, Feb 20, 2020 at 03:51:32PM -0600, speck for Josh Poimboeuf wrote:
> > On Thu, Feb 20, 2020 at 06:55:10AM -0800, speck for Andi Kleen wrote:
> > > > Then we need to stop using RDRAND internally for our "give me a random
> > > > number api" which has spread to more and more parts of the kernel.
> > > 
> > > Only if that API is called frequently enough. AFAIK it is not. 
> > > 
> > > Normally it's used for rare rekeying of hash tables etc., which
> > > doesn't happen very often.
> > > 
> > > > Here's a patch that does so:
> > > > 	https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> > > > which I'm going to advise get merged now and backported to the stable
> > > > branches.
> > > 
> > > Don't see any reason at this point. Only do it if there's an actual
> > > indication of a problem.
> > 
> > Internal testing of the SRBDS beta microcode on Kaby Lake is showing
> > significant slowdowns in several syscall microbenchmarks.
> > 
> > One pthread_create() microbenchmark had a ~48% slowdown.  We confirmed
> > it was due to RDRAND in get_random_u64().
> > 
> > In this case I think the path was:
> > 
> >  clone()
> >    _do_fork()
> >      copy_process()
> >        dup_task_struct()
> >          get_random_canary() (due to CONFIG_STACKPROTECTOR)
> > 	   get_random_long()
> > 	     get_random_u64()
> > 	       arch_get_random_long()
> > 	         RDRAND
> 
> Okay thanks, then we need the patch Greg pointed out.

Agreed; RDRAND should be used to _seed_ the RNG, not be a replacement
for it.

-- 
Kees Cook