[MODERATED] Re: [PATCH 2/3] V5 more sampling fun 2

On Mon, Apr 06, 2020 at 03:14:13PM -0700, speck for Luck, Tony wrote:
> On Mon, Apr 06, 2020 at 08:37:56PM +0200, speck for Greg KH wrote:
> > On Mon, Apr 06, 2020 at 11:34:17AM -0700, speck for Kees Cook wrote:
> > > > +			By default, this issue is mitigated by
> > > > +			microcode.  However, the microcode fix can cause
> > > > +			the RDRAND and RDSEED instructions to become
> > > > +			much slower.  Among other effects, this will
> > > > +			result in reduced throughput from /dev/urandom.
> > > 
> > > This is this true about /dev/urandom? I thought the RDRAND dependency
> > > had been removed?
> > 
> > That dependancy will be removed in 5.7-rc1 and I will be backporting
> > that to the stable kernels "soon".
> > 
> 
> Is that still somee patch pending for the merge window?  I see
> Jason Donendfeld's patch to speed up the internal get_random_u32()
> and get_random_u64(). But that patch doesn't help /dev/urandom
> of the getrandom(2) syscalls.
> 
> urandom_read() or SYSCALL_DEFINE3(getrandom)
>     urandom_read_nowarn()
> 	extract_crng_user()
> 	    extract_crng()
> 		_extract_crng()
> 		    arch_get_random_long()

The commit I am referring to is 69efea712f5b ("random: always use
batched entropy for get_random_u{32,64}") which removes the direct
output of RDRAND for the internal kernel "give me some random data"
calls, which is what we need to do today.

But yes, you are right in that we still hit RDRAND on the urandom_read()
path, that's just feeding the data into the pool so we should be "safe"
from a data point of view, and you are right in that it does slow things
down too.

Have you all tried running benchmarks to see if getrandom() does slow
down with this microcode change?  And if it really makes it unusable, we
should just take RDRAND out of that code path entirely, which is what I
think Jason was talking about doing anyway, but you would have to ask
him about that.

thanks,

greg k-h