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 16:19:07 -0000 Received: from mail.kernel.org ([198.145.29.99]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j4oXV-0002X4-A0 for speck@linutronix.de; Thu, 20 Feb 2020 17:19:06 +0100 Date: Thu, 20 Feb 2020 17:18:51 +0100 From: Greg KH Subject: [MODERATED] Re: [PATCH 0/2] more sampling fun 0 Message-ID: <20200220161851.GA3441591@kroah.com> References: <20200220081420.GA3328448@kroah.com> <20200220142720.GA3433900@kroah.com> <20200220154007.GC58564@mtg-dev.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20200220154007.GC58564@mtg-dev.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 07:40:07AM -0800, speck for mark gross wrote: > On Thu, Feb 20, 2020 at 03:27:20PM +0100, speck for Greg KH wrote: > > On Thu, Feb 20, 2020 at 09:14:20AM +0100, speck for Greg KH wrote: > > > On Wed, Feb 19, 2020 at 02:45:22PM -0800, speck for mark gross wrote: > > > > From: mark gross > > > > Subject: [PATCH 0/2] Special Register Buffer Data Sampling patch set > > > > > > > > Special Register Buffer Data Sampling is a sampling type of vulnerability that > > > > leaks data across cores sharing the HW-RNG for vulnerable processors. > > > > > > > > This leak is fixed by a microcode update and is enabled by default. > > > > > > > > This new microcode serializes processor access during execution of RDRAND > > > > or RDSEED. It ensures that the shared buffer is overwritten before it > > > > is released for reuse. > > > > > > > > The mitigation impacts the throughput of the RDRAND and RDSEED instructions > > > > and latency of RT processing running on the socket while executing RDRAND or > > > > RDSEED. The micro bechmark of calling RDRAND many times shows a 10x slowdown. > > > > > > 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. > > > > > > 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. > > > > Note, the author of that patch has reached out to me to say they found > > this same issue. He did so independantly so odds are others already > > know about this. He found it because he was wondering why rdrand was so > > slow on newer systems, and then traced things backwards like all the > > other researchers in this area. > Are you saying the author has seen the RNG data leaking across processors or > the slowdown? slowdown from what? Relative to older processors, yes. Leaking across, yes, I think so. > > So, what's the timeline here? Looks like this is already "in the wild" > > from what I can tell. > > > The uCode mitigation is coming out with the 2020.1 IPU (intel platform update) > (fist ucode update of 2020) that I belive is slated for an official May > disclosure. {sigh} That's a long time, we should just fix up the kernel internally to not worry about this now so that we are not sitting on this any longer. thanks, greg k-h