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 19:49:55 -0000 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120] helo=us-smtp-1.mimecast.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iNj7K-0007t1-3L for speck@linutronix.de; Thu, 24 Oct 2019 21:49:55 +0200 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6C484107AD31 for ; Thu, 24 Oct 2019 19:49:49 +0000 (UTC) Received: from treble (ovpn-121-225.rdu2.redhat.com [10.10.121.225]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C47C1608C1 for ; Thu, 24 Oct 2019 19:49:45 +0000 (UTC) Date: Thu, 24 Oct 2019 14:49:43 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH 4/9] TAA 4 Message-ID: <20191024194943.rh2qzpnq2uzh3ulo@treble> References: <04f1ef8158e54eca18fc3951d75a00c5d398c429.1571905227.git.bp@suse.de> <20191024153240.26zdyr33r2o632ej@treble> <20191024164329.GE14115@zn.tnic> <20191024185641.scwdwudazlqtmhpg@treble> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: 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 wrote: > >> 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 wrot= e: > >>>> 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 calculable > >> 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? >=20 > Ok.=C2=A0 First things first.=C2=A0 Do you (and by this, I really mean Linu= x) want > to consider TAA an overlapping set with MDS, or a disjoint set? >=20 > 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: >=20 > ---8<--- > Vulnerability to TAA is a little complicated to quantify. >=20 > 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, the > existing VERW flushing will mitigate this sidechannel as well. >=20 > 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 but > lack TAA_NO. > ---8<--- >=20 > The simplifying fact is that vulnerability to TAA doesn't matter on CPUs > which don't advertise MDS_NO, because you're already doing VERW and > disabling hyperthreading, *and* can't turn TSX off if it actually available. >=20 > 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. --=20 Josh