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 ; 24 Oct 2019 20:48:23 -0000 Received: from esa4.hc3370-68.iphmx.com ([216.71.155.144]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iNk1u-0001Am-Bm for speck@linutronix.de; Thu, 24 Oct 2019 22:48:23 +0200 Subject: [MODERATED] Re: [PATCH 4/9] TAA 4 References: <04f1ef8158e54eca18fc3951d75a00c5d398c429.1571905227.git.bp@suse.de> <20191024153240.26zdyr33r2o632ej@treble> <20191024164329.GE14115@zn.tnic> <20191024185641.scwdwudazlqtmhpg@treble> <20191024194943.rh2qzpnq2uzh3ulo@treble> From: Andrew Cooper Message-ID: <2ca83125-fed2-116a-41f9-608eeb7f5911@citrix.com> Date: Thu, 24 Oct 2019 21:48:12 +0100 MIME-Version: 1.0 In-Reply-To: <20191024194943.rh2qzpnq2uzh3ulo@treble> Content-Type: multipart/mixed; boundary="SdVagAEEWJUBISutIZfclWC6awvKkFVtF"; protected-headers="v1" To: speck@linutronix.de List-ID: --SdVagAEEWJUBISutIZfclWC6awvKkFVtF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 24/10/2019 20:49, speck for Josh Poimboeuf wrote: > On Thu, Oct 24, 2019 at 08:13:44PM +0100, speck for Andrew Cooper wrote= : >> On 24/10/2019 19:56, speck for Josh Poimboeuf wrote: >>> On Thu, Oct 24, 2019 at 07:23:57PM +0100, speck for Andrew Cooper wro= te: >>>> On 24/10/2019 17:43, speck for Borislav Petkov wrote: >>>>> On Thu, Oct 24, 2019 at 10:32:40AM -0500, speck for Josh Poimboeuf = wrote: >>>>>> As I said before this would be a lot nicer if we could just add NO= _TAA >>>>>> to the cpu_vuln_whitelist. >>>>> We're waiting for a list of CPUs from Intel here, right? >>>>> >>>> There is no model list required.=C2=A0 Vulnerability to TAA is calcu= lable >>>> directly from existing architectural sources. >>> Can you elaborate? Earlier I suggested relying on NO_MDS in >>> cpu_vuln_whitelist, but I believe you said that's not sufficient, >>> because some of the non-MDS models don't have TSX, in which case we >>> shouldn't set TAA_BUG. >>> >>> Which models are those? >> Ok.=C2=A0 First things first.=C2=A0 Do you (and by this, I really mean= Linux) want >> to consider TAA an overlapping set with MDS, or a disjoint set? >> >> After considering this for ages, and particularly, how to explain it >> clearly to non-experts in Xen's security advisory, I chose to go with = this: >> >> ---8<--- >> Vulnerability to TAA is a little complicated to quantify. >> >> In the pipeline, it is just another way to get speculative access to >> stale load port, store buffer or fill buffer data, and therefore can b= e >> considered a superset of MDS.=C2=A0 On parts which predate MDS_NO, the= >> existing VERW flushing will mitigate this sidechannel as well. >> >> On parts which contain MDS_NO, the lack of VERW flushing means that an= >> attacker can still target microarchitectural buffers to leak secrets. >> Therefore, we consider TAA to be the set of parts which have MDS_NO bu= t >> lack TAA_NO. >> ---8<--- >> >> The simplifying fact is that vulnerability to TAA doesn't matter on CP= Us >> which don't advertise MDS_NO, because you're already doing VERW and >> disabling hyperthreading, *and* can't turn TSX off if it actually avai= lable. >> >> People who were not taking MDS mitigations in the first place won't >> change their minds because of TAA, either. > Good question. > > The current Linux patches consider them overlapping. But it _might_ > possibly be easier to communicate if we considered them disjoint. I > don't know if there's a good answer, but at this point it might be > easiest to stick with our current overlapping approach. > I'll bring this up with the group.=C2=A0 I bet we are not the only people= wondering the same, and it won't do any downstream users any good if they see conflicting descriptions from software vendors. ~Andrew --SdVagAEEWJUBISutIZfclWC6awvKkFVtF--