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 ; 26 Feb 2020 22:11:08 -0000 Received: from mga07.intel.com ([134.134.136.100]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j74tW-0007JK-LQ for speck@linutronix.de; Wed, 26 Feb 2020 23:11:07 +0100 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id A82956361 for ; Wed, 26 Feb 2020 22:11:01 +0000 (UTC) Date: Wed, 26 Feb 2020 14:11:02 -0800 From: mark gross Subject: [MODERATED] Re: [PATCH v2 1/2] v2: more sampling fun 1 Message-ID: <20200226221102.GB116192@mtg-dev.jf.intel.com> Reply-To: mgross@linux.intel.com References: <20200226110737.GB17448@zn.tnic> <20200226171103.GA114268@mtg-dev.jf.intel.com> <20200226175950.GD17448@zn.tnic> MIME-Version: 1.0 In-Reply-To: <20200226175950.GD17448@zn.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Feb 26, 2020 at 06:59:50PM +0100, speck for Borislav Petkov wrote: > On Wed, Feb 26, 2020 at 09:11:03AM -0800, speck for mark gross wrote: > > Yeah, Andi pointed it out to me on an internal review. I don't know what tool > > is using it. > > Then how do you write a patch and state in the commit message that > something is an ABI without knowing what the situation actually is?! Easily, I trusted Andi's feedback. I'm good with it as I think he initially created that data structure. I'll get specific user mode users of the structure and call it out in the commit comment for the next version. > > > FWIW doing it this way made a cleaner patch without touching a dozen other > > files using that structure. I'd rather stay with the way it is but, if you > > feel strongly I can do a version of what I had before only adding the new > > members to the end. Please let me know. > > Looking at that table again - cpu_vuln_whitelist - that is a > *whitelist*. See how all the bits start with "NO_"? Except maybe > MSBDS_ONLY. > > What you're doing is, you're misusing it to match models and steppings > to set SRBDS* bug flags. > > What you should actually be doing is setting those bug flags in > early_init_intel() where you can go wild with the steppings checking and > then you won't need to touch x86_cpu_id at all. I can certainly make a new table elsewhere if you want all the special case / hard-coded vulnerabilities spread around the kernel source tree as opposed to one centralized place. --mark