Received: by 10.223.176.46 with SMTP id f43csp2236098wra; Thu, 25 Jan 2018 06:59:25 -0800 (PST) X-Google-Smtp-Source: AH8x227+GSjQCpJqQ6h/T3GuBrFoS3bubvEILYnvbo9mesvkoMb3GhtQzV1G4Oe465gLWGg7kIof X-Received: by 2002:a17:902:b68b:: with SMTP id c11-v6mr11420622pls.95.1516892365176; Thu, 25 Jan 2018 06:59:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516892365; cv=none; d=google.com; s=arc-20160816; b=nmkyWYJ8B8x0kmEBShA59y7bKNPBy2pseYTYIfJYJaujU4J9cbO/wX0bqc+3wqy/JB OS24Npqpyy1bB8zp0T8GA1So0ZVzFyrbCy7hNt/MB6qg0aZzS+2aIQPCUCSn++14a03S TijMSv7xjncMeF0UT8WpK1nXCM3u5XSZMJHMvykipPG9O8Kwa0OtbpoOGDS9dJ1S5657 EIDvGwhbrge3hbA6KYIUJL/rxkK9HHOOrf9uRGRQgt8jEDrijVnY0REwpW3YZcZ9aaGY diHZZfmdvkVxa6/S3fPS8AlE9PxHzmHRzYjNwMDpW1hJfHBeY25Nkc1aJNzxPpi5coaT roOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=1SzivvP9bDFDcsw1rgELmLIruol6IiSPFCG6FGczBLM=; b=qPIm45ZDA7zHv4fU5YFlvn7skCDOXag9jF/EYD6DbtnUvMmGRyeoe+jZ7T4KoUyeT3 ndJZqhHmv9e7v64puc60fNY/XvOPkgktu7ZM9QMV/CwdVruTo7yXWR65FREjDlMw3BHn UDWwvXbj+YFI/fFELRm+3ZyCoUV7kWArpiqlZxGeea4+7E314tO9nw9+eiG9rrxUmqi9 JPzTWi6QsheRAOq/2s7exNBKY6TtBXuGqOmkysdwCKZWgvkuVi1mR9GmPuB+fdi1i5Ur lI49ZpcCz9kVNPwRyICk7bjyujPU1E8PUJRYVyFCx5vkcc90dbN4KobMZoNbkaBPJgkZ GR0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f25si1661963pge.163.2018.01.25.06.59.10; Thu, 25 Jan 2018 06:59:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751538AbeAYO6o (ORCPT + 99 others); Thu, 25 Jan 2018 09:58:44 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:35308 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940AbeAYO6l (ORCPT ); Thu, 25 Jan 2018 09:58:41 -0500 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eeiwT-0002tE-N3; Thu, 25 Jan 2018 15:55:53 +0100 Date: Thu, 25 Jan 2018 15:58:35 +0100 (CET) From: Thomas Gleixner To: David Woodhouse cc: arjan@linux.intel.com, karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com, bp@alien8.de, peterz@infradead.org, pbonzini@redhat.com, ak@linux.intel.com, torvalds@linux-foundation.org, gregkh@linux-foundation.org, dave.hansen@intel.com, gnomes@lxorguk.ukuu.org.uk, ashok.raj@intel.com, mingo@kernel.org Subject: Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes In-Reply-To: <1516887714.30244.121.camel@infradead.org> Message-ID: References: <1516872189-16577-1-git-send-email-dwmw@amazon.co.uk> <1516872189-16577-7-git-send-email-dwmw@amazon.co.uk> <1516876994.30244.51.camel@infradead.org> <1516879213.30244.74.camel@infradead.org> <1516887714.30244.121.camel@infradead.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 25 Jan 2018, David Woodhouse wrote: > On Thu, 2018-01-25 at 12:34 +0100, Thomas Gleixner wrote: > > > > This stuff is really a master piece of trainwreck engineering. > > > > So yeah, whatever we do we end up with a proper mess. Lets go for a > > blacklist and hope that we'll have something which holds at some > > foreseeable day in the future. > > > > The other concern I have is IBRS vs. IBPB. Are we sufficiently sure that > > IBPB is working on those IBRS blacklisted ucode revisions? Or should we > > just play safe and not touch any of this at all when we detect a > > blacklisted one? > > That isn't sufficiently clear to me. I've changed it back to blacklist > *everything* for now, to be safe. If at any point Intel want to get > their act together and give us coherent information to the contrary, we > can change to separate IBPB/IBRS blacklists. Thanks for that. That's the only sensible approach as long as we have to deal with the current Quality Assumptions... Thanks, tglx