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:17:56 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iNjYR-0000WQ-GN for speck@linutronix.de; Thu, 24 Oct 2019 22:17:55 +0200 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id AA1B8AE52 for ; Thu, 24 Oct 2019 20:17:49 +0000 (UTC) Date: Thu, 24 Oct 2019 22:17:48 +0200 From: Borislav Petkov Subject: [MODERATED] Re: [PATCH 3/9] TAA 3 Message-ID: <20191024201748.GL14115@zn.tnic> References: <580e02757c3e639bff00fcea830aa46eba46a92f.1571905227.git.bp@suse.de> <6f1ab744-622c-179b-276b-5506b2fd9ae1@citrix.com> <20191024194503.GH14115@zn.tnic> <38430127-3ece-dc06-2264-6b3bc347b523@citrix.com> MIME-Version: 1.0 In-Reply-To: <38430127-3ece-dc06-2264-6b3bc347b523@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: On Thu, Oct 24, 2019 at 09:07:27PM +0100, speck for Andrew Cooper wrote: > On Xen, I've juggled things such that we load microcode, then interpret > tsx=3D if the user has provided it (taking care to always write > MSR_TSX_CTRL if it is available, to discard whatever settings firmware > or kexec left), before querying CPUID. Yap, wanna try the same thing, in that exact order. > Later, the spec-ctrl=3D interpretation happens, which might choose to turn > off TSX due to TAA, which then has to modify MSR_TSX_CTRL and force > clear the bits in the policy. Well, the kernel doesn't reeval CPUID feature bits in that case because it has gone on booting and enabled all kinds of feature supporting code. This is the reason why the whole late microcode loading is such a bad thing to do. > Given that speculative mitigations rely heavily on CPUID, I can't reason > about a clean way to disentangle this, but the above seems to be the > least complicated algorithm. Right, considering our CPU feature supporting code doesn't do any reevaluation of features and it "reloads" support for newly appearing or disappearing features, the only ordering you can do is 1. load microcode and toggle MSRs or do whatever else, which modifies CPUID leafs. 2. Read and cache and act upon those feature leafs. That's it, feature bits are cast in stone. > On Haswell and Broadwell, the microcode which turned HLE/RTM off in the > pipeline left the LBR MSRs in a state where you can't context switch the > value, because they would yield a value via RDMSR which WRMSR faulted > on, because the two operations had an asymmetric view of how the top > bits of metadata should be interpreted, given some TSX-related metadata > and a sign extended linear address. >=20 > On Skylake where you can't actually turn RTM off, but we may hide > FEATURE_RTM/HLE, the above quirk is probably not true. Huh? How is that possible? TSX_CTRL has defined only bit 1 there, the CPUID enumeration bit, and bit 0 doesn't do any RTM disabling? Srsly?! > On Cascadelake, who knows?=C2=A0 RTM is being turned off in the pipeline, b= ut > maybe the HSX/BWX bug has been fixed, or maybe it is being turned off in > a different way, or ... Right, I guess we'll deal with any perfcounters fallout in public, when the stuff releases... --=20 Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imend=C3=B6rffer, HRB 36809, = AG N=C3=BCrnberg --=20