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 ; 17 Apr 2020 12:34:47 -0000 Received: from [5.158.153.52] (helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jPQCk-000822-Cz for speck@linutronix.de; Fri, 17 Apr 2020 14:34:46 +0200 From: Thomas Gleixner Subject: Re: [PATCH 3/4] V8 more sampling fun 3 In-Reply-To: <20200416174452.GG21456@zn.tnic> References: <20200416171723.zk3lzznvslmtt4zf@treble> <20200416174452.GG21456@zn.tnic> Date: Fri, 17 Apr 2020 14:34:41 +0200 Message-ID: <874ktimgta.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: speck for Borislav Petkov writes: > On Thu, Apr 16, 2020 at 12:17:23PM -0500, speck for Josh Poimboeuf wrote: > > While it is present on all affected CPU models, the microcode mitigation > is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the > cases where TSX is not supported or has been disabled with TSX_CTRL. If the CPU has does not expose TSX_CTRL and has FEATURE_RTM disabled (BIOS or fused off) then we declare it as non vulnerable. If the CPU exposes TSX_CTRL then we declare it vulnerable and decide in the mitigation selection whether it is vulnerable or not depending on the RTM state. If RTM is off, we say: "Mitigation: TSX disabled". IMO the whole tsx_fused_off() logic is pointless. It does not matter whether TSX got fused off or disabled in BIOS or disabled via TSX_CTRL. The CPU model is affected but the problem is mitigated because TSX is disabled. Aside of that the tsx_fused_off() logic depends on the non-availability of TSX_CTRL. TSX_CTRL is available even on CPUs which enumerate TAA_NO, but I don't see any check for TAA_NO or BUG_TAA anywhere. Is SBRDS on MDS_NO parts independent of TAA, i.e. does it solely depend on the fact that RTM is on? Thanks, tglx