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 16:20:44 -0000 Received: from us-smtp-2.mimecast.com ([205.139.110.61] 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 1iNfqt-0002U0-1d for speck@linutronix.de; Thu, 24 Oct 2019 18:20:43 +0200 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0B56C80183D for ; Thu, 24 Oct 2019 16:10:19 +0000 (UTC) Received: from treble (ovpn-121-225.rdu2.redhat.com [10.10.121.225]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A85CE451F for ; Thu, 24 Oct 2019 16:10:18 +0000 (UTC) Date: Thu, 24 Oct 2019 11:10:16 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: [PATCH 9/9] TAA 9 Message-ID: <20191024161016.dnqexztns5xaiwh2@treble> References: <33b6f0fd589ba3ea35f05aacbcda0be19352a994.1571905227.git.bp@suse.de> MIME-Version: 1.0 In-Reply-To: <33b6f0fd589ba3ea35f05aacbcda0be19352a994.1571905227.git.bp@suse.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Oct 23, 2019 at 12:35:50PM +0200, speck for Michal Hocko wrote: > From: Michal Hocko > Subject: [PATCH 9/9] x86/tsx: Add config options to set tsx=on|off|auto > > There is a general consensus that TSX usage is not largely spread while > the history shows there is a non trivial space for side channel attacks > possible. Therefore the tsx is disabled by default even on platforms > that might have a safe implementation of TSX according to the current > knowledge. This is a fair trade off to make. > > There are, however, workloads that really do benefit from using TSX and > updating to a newer kernel with TSX disabled might introduce a > noticeable regressions. This would be especially a problem for Linux > distributions which will provide TAA mitigations. > > Introduce config options X86_INTEL_TSX_MODE_OFF, X86_INTEL_TSX_MODE_ON > and X86_INTEL_TSX_MODE_AUTO to control the TSX feature. The config > setting can be overridden by the tsx cmdline options. > > Suggested-by: Borislav Petkov > Signed-off-by: Michal Hocko > Signed-off-by: Pawan Gupta > Signed-off-by: Borislav Petkov > Cc: "H. Peter Anvin" > Cc: Ingo Molnar > Cc: Thomas Gleixner > Cc: Tony Luck > Cc: x86-ml > --- > arch/x86/Kconfig | 45 +++++++++++++++++++++++++++++++++++++++ > arch/x86/kernel/cpu/tsx.c | 22 +++++++++++++------ > 2 files changed, 61 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index d6e1faa28c58..eebae89726c4 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1940,6 +1940,51 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS > > If unsure, say y. > > +choice > + prompt "TSX enable mode" > + depends on CPU_SUP_INTEL > + default X86_INTEL_TSX_MODE_OFF > + help > + Intel's TSX (Transactional Synchronization Extensions) feature > + allows to optimize locking protocols through lock elision which > + can lead to a noticeable performance boost. > + > + On the other hand it has been shown that TSX can be exploited > + to form side channel attacks (e.g. TAA) and chances are there > + will be more of those attacks discovered in the future. > + > + Therefore TSX is not enabled by default (aka tsx=off). An admin > + might override this decision by tsx=on command line parameter. This > + has a risk that TSX will get enabled also on platforms which are > + known to be vulnerable to attacks like TAA and a safer option is to > + use tsx=auto command line parameter. I think this is misleading. tsx=on doesn't make you vulnerable to TAA, because we still the TAA mitigation. > + > + This options allows to set the default tsx mode between tsx=on, off > + and auto. See Documentation/admin-guide/kernel-parameters.txt for more > + details. > + > + Say off if not sure, auto if TSX is in use but it should be used on safe > + platforms or on if TSX is in use and the security aspect of tsx is not > + relevant. tsx=on vs tsx=auto is not a security consideration, but rather a performance one. With tsx=auto you disable TSX on some TAA-affected CPUs so you don't have to pay the performance penalty of the MDS mitigations. > + > +config X86_INTEL_TSX_MODE_OFF > + bool "off" > + help > + TSX is always disabled - equals tsx=off command line parameter. Define "always" :-) > + > +config X86_INTEL_TSX_MODE_ON > + bool "on" > + help > + TSX is always enabled on TSX capable HW - equals tsx=on command line > + parameter. > + > +config X86_INTEL_TSX_MODE_AUTO > + bool "auto" > + help > + TSX is enabled on TSX capable HW that is believed to be safe against > + side channel attacks- equals tsx=auto command line parameter. Not exactly :-) This also leaves TSX enabled on MDS vulnerable parts. -- Josh