From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 20 Feb 2020 22:59:39 -0000 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1j4unC-00016F-3Q for speck@linutronix.de; Thu, 20 Feb 2020 23:59:38 +0100 Received: by mail-pf1-x430.google.com with SMTP id b185so128249pfb.7 for ; Thu, 20 Feb 2020 14:59:38 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id y76sm616231pfc.87.2020.02.20.14.59.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2020 14:59:29 -0800 (PST) Date: Thu, 20 Feb 2020 14:59:28 -0800 From: Kees Cook Subject: [MODERATED] Re: [PATCH 0/2] more sampling fun 0 Message-ID: <202002201458.22F000666@keescook> References: <20200220081420.GA3328448@kroah.com> <20200220145510.GE160988@tassilo.jf.intel.com> <20200220215132.vl6mrauahldbzkfm@treble> <20200220221522.GK160988@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20200220221522.GK160988@tassilo.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: 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