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:58:29 -0000 Received: from p5492e5b8.dip0.t-ipconnect.de ([84.146.229.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gzr6q-0005qJ-3W for speck@linutronix.de; Fri, 01 Mar 2019 23:58:28 +0100 Date: Fri, 1 Mar 2019 23:58:27 +0100 (CET) From: Thomas Gleixner Subject: Re: [patch V5 09/14] MDS basics 9 In-Reply-To: <20190301223859.GT14294@redhat.com> Message-ID: References: <20190227150939.605235753@linutronix.de> <20190227152037.818666801@linutronix.de> <20190301140415.pjv7qjellvqrlbw5@treble> <20190301164022.uxpvtuzwlfdylqri@treble> <20190301183914.y3kvjyneyncgwki7@treble> <20190301223859.GT14294@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, 1 Mar 2019, speck for Andrea Arcangeli wrote: > On Fri, Mar 01, 2019 at 08:15:36PM +0100, speck for Thomas Gleixner wrote: > > > 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. I already did those changes to the sysfs file and updated documentation accordingly. Will send an updated series soon. > > 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. Sorry I dropped the first line: Family_model, Stepping, Codename, MFBDS, MSBDS, MLPDS Vector, MLPDS Split line. So the thing is that newer steppings are fixed vs. all of the issues. I surely hope that these have MDS_NO set in MSR_IA32_ARCH_CAPABILITIES. If that's not the case, then we'll end up with stepping specific quirks which would be an utter mess. Can anyone @Intel please answer this question? Thanks, tglx