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 22:38:35 -0000 Received: from esa2.hc3370-68.iphmx.com ([216.71.145.153]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iNlkW-0002Xp-EF for speck@linutronix.de; Fri, 25 Oct 2019 00:38:33 +0200 Subject: [MODERATED] Re: [PATCH 3/9] TAA 3 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> <20191024201748.GL14115@zn.tnic> From: Andrew Cooper Message-ID: <832cb284-9852-5cfe-b71c-c3a23b85adc5@citrix.com> Date: Thu, 24 Oct 2019 23:38:21 +0100 MIME-Version: 1.0 In-Reply-To: <20191024201748.GL14115@zn.tnic> Content-Type: multipart/mixed; boundary="89nw9feHGcooDZecdlKO0SWbfW4gWCUy5"; protected-headers="v1" To: speck@linutronix.de List-ID: --89nw9feHGcooDZecdlKO0SWbfW4gWCUy5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 24/10/2019 21:17, speck for Borislav Petkov wrote: > 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 interpre= t >> 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= =2E > This is the reason why the whole late microcode loading is such a bad > thing to do. :) I don't necessarily disagree, but the customers (who ultimately pay my salary) want late microcode loading and livepatching, so we've delivered.= > >> On Haswell and Broadwell, the microcode which turned HLE/RTM off in th= e >> pipeline left the LBR MSRs in a state where you can't context switch t= he >> 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 metadat= a >> and a sign extended linear address. >> >> 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 C= PUID > enumeration bit, and bit 0 doesn't do any RTM disabling? Srsly?! Skylake CPUs aren't getting TSX_CTRL, but force setting/clearing bits at boot will affect later logic.=C2=A0 (Unless I'm being blind while reading= the patches, which is a distinct possibility). > >> On Cascadelake, who knows?=C2=A0 RTM is being turned off in the pipeli= ne, but >> 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... So, I remembered that I had already written a test case for this bug. Initial experimentation shows that using TSX_CTRL to secure Cascade Lake doesn't result in Haswell/Broadwell style GP faults, which is good news.=C2=A0 I will be adjusting Xen's logic not to invoke the quirk on mo= re modern parts. ~Andrew --89nw9feHGcooDZecdlKO0SWbfW4gWCUy5--