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 ; 15 Oct 2019 20:54:36 -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 1iKTpy-0008HL-NH for speck@linutronix.de; Tue, 15 Oct 2019 22:54:35 +0200 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9ADBC2CE90A for ; Tue, 15 Oct 2019 20:54:27 +0000 (UTC) Received: from treble (ovpn-123-150.rdu2.redhat.com [10.10.123.150]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 41CB35D70D for ; Tue, 15 Oct 2019 20:54:27 +0000 (UTC) Date: Tue, 15 Oct 2019 15:54:25 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: ***UNCHECKED*** Re: [PATCH v5 08/11] TAAv5 8 Message-ID: <20191015205425.sncjqueunt7tx653@treble> References: <20191015103454.GW317@dhcp22.suse.cz> <20191015130627.7jkhqy2zrtm35ool@treble> <20191015152649.yim4krwuttrh6xgi@treble> <20191015200024.hxs4brxi7gbvmcdy@treble> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, Oct 15, 2019 at 10:35:04PM +0200, speck for Jiri Kosina wrote: > On Tue, 15 Oct 2019, speck for Jiri Kosina wrote: > > > > Maybe I'm missing something. Isn't there going to be a ucode update for > > > MDS_NO parts, which does the verw buffer clearing? In that case there's > > > no need to disable TSX, and instead the verw mitigation could be used, > > > if desired. > > > > My understanding was that MDS_NO CPUs will only get ucode update that > > exposes TSX control MSR, and nothing else. I'm looking at a Cinco slide deck from Intel, where page 11 says that CPUs with MDS_NO=1 will get a microcode update to provide both VERW buffer clearing support and the new MSR interface to disable TSX. > > > AFAICT, the patch allows to set the default to tsx=auto, which disables > > > TSX on *all* vulnerable parts, not just the MDS_NO ones. I don't see > > > how that would prevent user regressions. > > > > > > It sounds like maybe you're suggesting something else, that TSX should > > > only be disabled on vulnerable MDS_NO parts? > > > > OK, let me take a look at the code again. I definitely thought that's what > > 'auto' indeed does. > > OK, so you are right and I misunderstood the logic in the code, sorry. > > Then the only purpose of 'auto' really is getting TSX enabled on future > CPUs which would eventually have ARCH_CAP_TAA_NO=1; so pretty useless for > preventing regressions. > > So yeah, I agree, 'auto' is actually useless to prevent regressions, and I > believe we want some other 'auto' (*), which would actually disable TSX > only if (X86_BUG_TAA && !MD_CLEAR), agreed? Based on the above-mentioned slide, I don't see how X86_BUG_TAA && !MD_CLEAR is a realistic scenario, if the user has updated their microcode. > (*) I'd actually prefer to convert the current 'auto' to this new > semantics; it'll keep TSX enabled on future CPUs without X86_BUG_TAA, > and it'll prevent regressions in unnecessary cases. I'm also not sure I see the point of the existing tsx=auto option, unless we can identify who's actually going to use it. -- Josh