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 ; 08 Oct 2019 02:46:52 -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 1iHfWV-0008MT-49 for speck@linutronix.de; Tue, 08 Oct 2019 04:46:51 +0200 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C26B0309174E for ; Tue, 8 Oct 2019 02:46:44 +0000 (UTC) Received: from treble (ovpn-121-70.rdu2.redhat.com [10.10.121.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7AF5A5C1D4 for ; Tue, 8 Oct 2019 02:46:44 +0000 (UTC) Date: Mon, 7 Oct 2019 21:46:42 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH v5 05/11] TAAv5 5 Message-ID: <20191008024642.rydvop7ug2luc6zg@treble> References: =?utf-8?q?=3Cc5adf983a4becc2c63c510e108833d56a6d0b282=2E1570255065=2Egi?= =?utf-8?q?t=2Epawan=2Ekumar=2Egupta=40linux=2Eintel=2Ecom=3E?= MIME-Version: 1.0 In-Reply-To: =?utf-8?q?=3Cc5adf983a4becc2c63c510e108833d56a6d0b282=2E15702?= =?utf-8?q?55065=2Egit=2Epawan=2Ekumar=2Egupta=40linux=2Eintel=2Ecom=3E?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Oct 04, 2019 at 11:30:31PM -0700, speck for Pawan Gupta wrote: > TSX Async Abort (TAA) is a side channel vulnerability to the internal > buffers in some Intel processors similar to Microachitectural Data > Sampling (MDS). In this case certain loads may speculatively pass > invalid data to dependent operations when an asynchronous abort > condition is pending in a TSX transaction. This includes loads with no > fault or assist condition. Such loads may speculatively expose stale > data from the uarch data structures as in MDS. Scope of exposure is > within the same-thread and cross-thread. This issue affects all current > processors that support TSX, but do not have ARCH_CAP_TAA_NO (bit 8) set > in MSR_IA32_ARCH_CAPABILITIES. All the patches are missing "Subject:" lines, so when applied, they have subjects like "TAAv5 1". > -/* Update the static key controlling the MDS CPU buffer clear in idle */ > +/* Update the static key controlling the MDS and TAA CPU buffer clear in idle */ > static void update_mds_branch_idle(void) > { > /* > @@ -775,8 +881,11 @@ static void update_mds_branch_idle(void) > * The other variants cannot be mitigated when SMT is enabled, so > * clearing the buffers on idle just to prevent the Store Buffer > * repartitioning leak would be a window dressing exercise. > + * > + * Apply idle buffer clearing to TAA affected CPUs also. > */ > - if (!boot_cpu_has_bug(X86_BUG_MSBDS_ONLY)) > + if (!boot_cpu_has_bug(X86_BUG_MSBDS_ONLY) && > + !boot_cpu_has_bug(X86_BUG_TAA)) > return; I'm not sure this belongs here. The existing check was for X86_BUG_MSBDS_ONLY, which is the only MDS variant which can be mitigated in idle with SMT enabled. If the other MDS variants are present (which is true for most CPUs) then this function doesn't enable the MDS idle mitigation, because it wouldn't be sufficient. So does this fully mitigate TAA on idle threads with SMT enabled? If not then this change is probably pointless. -- Josh