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 ; 01 Mar 2019 22:39:07 -0000 Received: from mx1.redhat.com ([209.132.183.28]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gzqo6-0005X1-59 for speck@linutronix.de; Fri, 01 Mar 2019 23:39:06 +0100 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E8D6183F45 for ; Fri, 1 Mar 2019 22:38:59 +0000 (UTC) Received: from sky.random (ovpn-121-1.rdu2.redhat.com [10.10.121.1]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B6B1060856 for ; Fri, 1 Mar 2019 22:38:59 +0000 (UTC) Date: Fri, 1 Mar 2019 17:38:59 -0500 From: Andrea Arcangeli Subject: [MODERATED] Re: [patch V5 09/14] MDS basics 9 Message-ID: <20190301223859.GT14294@redhat.com> References: <20190227150939.605235753@linutronix.de> <20190227152037.818666801@linutronix.de> <20190301140415.pjv7qjellvqrlbw5@treble> <20190301164022.uxpvtuzwlfdylqri@treble> <20190301183914.y3kvjyneyncgwki7@treble> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: Hello, On Fri, Mar 01, 2019 at 08:15:36PM +0100, speck for Thomas Gleixner wrote: > On Fri, 1 Mar 2019, speck for Josh Poimboeuf wrote: > > On Fri, Mar 01, 2019 at 10:40:22AM -0600, Josh Poimboeuf wrote: > > > On Fri, Mar 01, 2019 at 05:03:39PM +0100, speck for Thomas Gleixner wrote: > > > > On Fri, 1 Mar 2019, speck for Josh Poimboeuf wrote: > > > > > Andrea brought up a good question privately -- this patch mitigates > > > > > MSBDS for HT, but HT will still be susceptible to the other two MDS > > > > > issues. So what's the point? It seems this patch only protects people > > > > > who don't care about MDS in the first place. > > > > > > > > Indeed for most CPU models it's pointless. > > > > > > > > The ones which are only affected by MSBDS are Atom Silvermont/Airmont which > > > > are all single threaded and the XEON PHIs. > > > > > > > > For XEON PHI it actually makes sense because XEON PHI does not have L1TF > > > > either. > > > > > > > > But yes, for everything else it's just window dressing. > > > > > > Makes sense. I didn't realize that some CPUs were affected by MSBDS and > > > not other MDSes. > > > > > > Can you add that justification to the documentation and/or patch > > > description? > > > > Or even better, can we only do the idle clearing on XEON PHI? > > > > Also it sounds like the mds vulnerabilities file shouldn't ever show > > "SMT vulnerable" for XEON PHI. > > Yeah. So maybe this patch should be moved to the end of the series flagged as an incremental XEON PHI optimization by also adding the other XEON PHI specific change for the l1tf default mitigation and the respective alteration of the vulnerabilities mds/l1tf sysfs file outputs. Is the verw measurable before mwait/hlt? I was just afraid this could hurt who needs to keep HT on for performance reasons and that won't be safe anyway if HT is kept on. Unless we also alter the vulnerabilites file like Josh suggested, XEON PHI owners not reading the fineprint (assuming it's reachable for them) may decide then to disable HT for security reasons anyway and they won't even benefit from the XEON PHI mwait/hlt specific static key to keep HT enabled safely. > > So I was looking at that table again and found the following stepping > related info: > > 06_8EH,06_9EH <=B Kaby/Coffe Lake Yes Yes Yes Yes > 06_9E 0xC Coffee Lake No Yes Yes Yes > 06_8E 0xB Whiskey Lake(ULT) No Yes Yes Yes > > 06_8E 0xC Whiskey L (ULT refresh) No No No No > 06_9E 0xD Whiskey Lake (Deskto) No No No No > > > 06_55H 5 Cascade Lake No Yes Yes Yes > > 06_55H 6 Cascade Lake No No No No > > Will these 'fixed' steppings have MDS_NO set? I couldn't understand the table, so I'm can't answer this one. Thanks, Andrea