From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 12 Dec 2018 22:37:14 -0000 Received: from userp2120.oracle.com ([156.151.31.85]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gXD7w-0003ES-AS for speck@linutronix.de; Wed, 12 Dec 2018 23:37:13 +0100 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wBCMXndY142398 for ; Wed, 12 Dec 2018 22:37:05 GMT Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2pb7tf0xtn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 12 Dec 2018 22:37:05 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wBCMaxmE006823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 12 Dec 2018 22:36:59 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wBCMaxJL019597 for ; Wed, 12 Dec 2018 22:36:59 GMT Date: Wed, 12 Dec 2018 17:36:58 -0500 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [PATCH v2 4/8] MDSv2 0 Message-ID: <20181212223658.GE7946@char.us.oracle.com> References: <20181212214506.GT9077@char.us.oracle.com> <20181212220946.GJ25620@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20181212220946.GJ25620@tassilo.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Dec 12, 2018 at 02:09:46PM -0800, speck for Andi Kleen wrote: > On Wed, Dec 12, 2018 at 04:45:06PM -0500, speck for Konrad Rzeszutek Wilk wrote: > > On Mon, Dec 10, 2018 at 09:53:36AM -0800, speck for Andi Kleen wrote: > > > From: Andi Kleen > > > Subject: x86/speculation/mds: Add sysfs reporting > > > > > > Report mds mitigation state in sysfs vulnerabilities. > > > > > > Signed-off-by: Andi Kleen > > > --- > > > .../ABI/testing/sysfs-devices-system-cpu | 1 + > > > arch/x86/kernel/cpu/bugs.c | 16 ++++++++++++++++ > > > drivers/base/cpu.c | 8 ++++++++ > > > 3 files changed, 25 insertions(+) > > > > > > diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu > > > index 73318225a368..02b7bb711214 100644 > > > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu > > > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu > > > @@ -477,6 +477,7 @@ What: /sys/devices/system/cpu/vulnerabilities > > > /sys/devices/system/cpu/vulnerabilities/spectre_v2 > > > /sys/devices/system/cpu/vulnerabilities/spec_store_bypass > > > /sys/devices/system/cpu/vulnerabilities/l1tf > > > + /sys/devices/system/cpu/vulnerabilities/mds > > > Date: January 2018 > > > Contact: Linux kernel mailing list > > > Description: Information about CPU vulnerabilities > > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c > > > index 8200b41b8db9..accab3279068 100644 > > > --- a/arch/x86/kernel/cpu/bugs.c > > > +++ b/arch/x86/kernel/cpu/bugs.c > > > @@ -1175,6 +1175,16 @@ static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr > > > if (boot_cpu_has(X86_FEATURE_L1TF_PTEINV)) > > > return l1tf_show_state(buf); > > > break; > > > + > > > + case X86_BUG_MDS: > > > + /* Assumes Hypervisor exposed HT state to us if in guest */ > > > + if (boot_cpu_has(X86_FEATURE_MB_CLEAR)) { > > > + if (cpu_smt_control != CPU_SMT_ENABLED) > > > + return sprintf(buf, "Mitigation: MB_CLEAR\n"); > > > > I am not sure if a normal system admin would understand what MB_CLEAR means. Is there a way to > > make this more ..grokked? > > You mean they are somehow unable to use Google? Why do we want to have sharp corners? What is so wrong with making it well rounded and self explanatory?