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 ; 22 Oct 2019 21:38:36 -0000 Received: from us-smtp-2.mimecast.com ([207.211.31.81] helo=us-smtp-delivery-1.mimecast.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iN1rP-0007Ts-8A for speck@linutronix.de; Tue, 22 Oct 2019 23:38:35 +0200 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0D3DA1800D6A for ; Tue, 22 Oct 2019 21:38:23 +0000 (UTC) Received: from treble (ovpn-124-213.rdu2.redhat.com [10.10.124.213]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9672D5DAAF for ; Tue, 22 Oct 2019 21:38:22 +0000 (UTC) Date: Tue, 22 Oct 2019 16:38:20 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH v7 04/10] TAAv7 4 Message-ID: <20191022213820.njr46drwwinzp7hu@treble> References: <20191022165112.GK31458@zn.tnic> <20191022170230.GM31458@zn.tnic> <20191022180032.GF29216@guptapadev.amr> <20191022181215.GP31458@zn.tnic> <20191022191614.GA26396@agluck-desk2.amr.corp.intel.com> <20191022192820.GU31458@zn.tnic> <20191022200235.GA26744@agluck-desk2.amr.corp.intel.com> <20191022205427.GW31458@zn.tnic> MIME-Version: 1.0 In-Reply-To: <20191022205427.GW31458@zn.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, Oct 22, 2019 at 10:54:27PM +0200, speck for Borislav Petkov wrote: > On Tue, Oct 22, 2019 at 01:02:35PM -0700, speck for Luck, Tony wrote: > > At first glance I find that more confusing that helpful. > > > > Perspective: TAA is an issue that affects ~3 CPU models. It will be > > a non-issue on future models. > > > > TSX control is a new CPU feature control that happens to begin > > with those three models, but will continue to be present on future > > CPU models. > > The ",async_abort..." piece is optional, of course. You should be able > to use > > tsx=on|off > > just fine, without the additional option flags. I.e., you get what you > ordered principle. Right, but then tsx=on exposes you to a bug, which might be surprising. > It is the same thing as when you don't specify tsx_async_abort= on the > command line now. I'm not sure what you mean, I think the patches mitigate TAA by default when TSX is on (ignoring SMT of course). Also, suspending disbelief for a moment and assuming TSX becomes a huge success story and you want to safely enable it 5 years down the road, you'd have to do tsx=on,tsx_async_abort=full,nosmt,tsx_bug2=full,nosmt .... etc when you just want to turn the darned thing on without having to worry about specifying all the mitigations for all currently known bugs. So while it is kind of nice to have everything specified on the same cmdline, I think I prefer the current approach of keeping the TSX enablement separate from the mitigation. -- Josh