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 ; 25 Oct 2019 09:12:19 -0000 Received: from esa5.hc3370-68.iphmx.com ([216.71.155.168]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iNvdo-0003kX-Sz for speck@linutronix.de; Fri, 25 Oct 2019 11:12:18 +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> <2ca83125-fed2-116a-41f9-608eeb7f5911@citrix.com> From: Andrew Cooper Message-ID: Date: Fri, 25 Oct 2019 10:12:04 +0100 MIME-Version: 1.0 In-Reply-To: <2ca83125-fed2-116a-41f9-608eeb7f5911@citrix.com> Content-Type: multipart/mixed; boundary="q1MthDqImMg6HES8A6bX8byVX6XWKamAG"; protected-headers="v1" To: speck@linutronix.de List-ID: --q1MthDqImMg6HES8A6bX8byVX6XWKamAG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 24/10/2019 21:48, speck for Andrew Cooper wrote: > 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 wrot= e: >>> 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 wr= ote: >>>>> 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 N= O_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 calc= ulable >>>>> 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 mea= n 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 = be >>> considered a superset of MDS.=C2=A0 On parts which predate MDS_NO, th= e >>> existing VERW flushing will mitigate this sidechannel as well. >>> >>> On parts which contain MDS_NO, the lack of VERW flushing means that a= n >>> attacker can still target microarchitectural buffers to leak secrets.= >>> Therefore, we consider TAA to be the set of parts which have MDS_NO b= ut >>> lack TAA_NO. >>> ---8<--- >>> >>> The simplifying fact is that vulnerability to TAA doesn't matter on C= PUs >>> which don't advertise MDS_NO, because you're already doing VERW and >>> disabling hyperthreading, *and* can't turn TSX off if it actually ava= ilable. >>> >>> 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 peop= le > wondering the same, and it won't do any downstream users any good if > they see conflicting descriptions from software vendors. Preliminary feedback suggests that some vendors are definitely going with TAA being a disjoint set to MDS, and other vendors are leaning in that direction. We should wait a bit longer for more views and opinions, as I think my question was fairly late US time anyway yesterday. ~Andrew --q1MthDqImMg6HES8A6bX8byVX6XWKamAG--