historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 2/3] V5 more sampling fun 2
Date: Tue, 7 Apr 2020 09:51:21 +0200	[thread overview]
Message-ID: <20200407075121.GB268725@kroah.com> (raw)
In-Reply-To: <20200406221413.GA19501@agluck-desk2.amr.corp.intel.com>

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

  reply	other threads:[~2020-04-07  7:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-06 17:52 [MODERATED] [PATCH 0/3] V5 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 2/3] V5 more sampling fun 2 mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 3/3] V5 more sampling fun 3 mark gross
2020-03-17  0:56 ` [MODERATED] [PATCH 1/3] V5 more sampling fun 1 mark gross
     [not found] ` <5e8b7166.1c69fb81.4c99a.3619SMTPIN_ADDED_BROKEN@mx.google.com>
2020-04-06 18:31   ` [MODERATED] " Kees Cook
     [not found] ` <5e8b71d8.1c69fb81.64075.43abSMTPIN_ADDED_BROKEN@mx.google.com>
2020-04-06 18:34   ` [MODERATED] Re: [PATCH 2/3] V5 more sampling fun 2 Kees Cook
2020-04-06 18:37     ` Greg KH
2020-04-06 20:56       ` mark gross
2020-04-06 22:14       ` Luck, Tony
2020-04-07  7:51         ` Greg KH [this message]
2020-04-06 18:52     ` mark gross
     [not found] ` <5e8b71af.1c69fb81.d8b8.ac6bSMTPIN_ADDED_BROKEN@mx.google.com>
2020-04-06 18:34   ` [MODERATED] Re: [PATCH 3/3] V5 more sampling fun 3 Kees Cook
2020-04-06 22:07 ` [MODERATED] Re: [PATCH 2/3] V5 more sampling fun 2 Josh Poimboeuf
2020-04-07  0:34   ` mark gross
2020-04-07 12:39     ` Josh Poimboeuf
2020-04-08 20:26       ` mark gross
2020-04-08 22:14   ` mark gross
2020-04-08 22:58     ` mark gross
2020-04-07 15:17 ` Thomas Gleixner
2020-04-08 20:33   ` [MODERATED] " mark gross
2020-04-08 23:21     ` Thomas Gleixner

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=20200407075121.GB268725@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=speck@linutronix.de \
    --subject='[MODERATED] Re: [PATCH 2/3] V5 more sampling fun 2' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).