All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: ***UNCHECKED*** Re: Re: [PATCH v5 08/11] TAAv5 8
Date: Wed, 16 Oct 2019 09:54:34 +0200	[thread overview]
Message-ID: <20191016075434.GL317@dhcp22.suse.cz> (raw)
In-Reply-To: <nycvar.YFH.7.76.1910160924330.13160@cbobk.fhfr.pm>

On Wed 16-10-19 09:26:14, speck for Jiri Kosina wrote:
> On Tue, 15 Oct 2019, speck for Michal Hocko wrote:
> 
> > From 9666e91b63cd6213d362d04289e1bcbbe2050bc3 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mhocko@suse.com>
> > Date: Tue, 15 Oct 2019 11:21:01 +0200
> > Subject: [PATCH] x86, tsx: allow to set tsx=auto by a config option
> > 
> > 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 X86_INTEL_ENABLE_SAFE_TSX config option to override the
> > default tsx=off semantic and make tsx=auto a default which is more
> > update friendly.
> 
> So given the recent clarifications, especially around older MDS_NO=0 CPUs, 
> I think it'd actually make more sense to turn this into a config option 
> that would simply allow to chose what the default behavior should be, 
> chosing from tristate off/on/auto.

This on top of the commit?
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9823e34b81ce..f7f79f189359 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1940,11 +1940,11 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
 
 	  If unsure, say y.
 
-config X86_INTEL_ENABLE_SAFE_TSX
-	prompt ""
-	def_bool n
+choice
+	prompt "TSX enable mode"
 	depends on CPU_SUP_INTEL
-	---help---
+	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.
@@ -1953,14 +1953,37 @@ config X86_INTEL_ENABLE_SAFE_TSX
 	  to form side channel attacks (e.g. TAA) and chances are there
 	  will be more of those attacks discovered in the future.
 
-	  Therefore the TSX is not enabled by default. 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. Enabling this config option will make tsx=auto the default.
-	  See Documentation/admin-guide/kernel-parameters.txt for more details.
+	  Therefore the 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.
 
-	  If you really benefit from TSX then enable this option, otherwise say n.
+	  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 in not
+	  relevant.
+
+config X86_INTEL_TSX_MODE_OFF
+	bool "off"
+	help
+	  TSX is always disabled - equals tsx=off command line parameter.
+
+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.
+endchoice
 
 config EFI
 	bool "EFI runtime service support"
diff --git a/arch/x86/kernel/cpu/tsx.c b/arch/x86/kernel/cpu/tsx.c
index d3dc1ce5cd4b..a2df0d5ffb15 100644
--- a/arch/x86/kernel/cpu/tsx.c
+++ b/arch/x86/kernel/cpu/tsx.c
@@ -99,10 +99,12 @@ void __init tsx_init(void)
 		}
 	} else {
 		/* tsx= not provided */
-		if (IS_ENABLED(X86_INTEL_ENABLE_SAFE_TSX))
+		if (IS_ENABLED(X86_INTEL_TSX_MODE_AUTO))
 			tsx_ctrl_state = x86_safe_tsx_mode();
-		else
+		else if (IS_ENABLED(X86_INTEL_TSX_MODE_OFF))
 			tsx_ctrl_state = TSX_CTRL_DISABLE;
+		else
+			tsx_ctrl_state = TSX_CTRL_ENABLE;
 	}
 
 	if (tsx_ctrl_state == TSX_CTRL_DISABLE) {
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2019-10-16  7:54 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-05  6:17 [MODERATED] [PATCH v5 00/11] TAAv5 0 Pawan Gupta
2019-10-05  6:26 ` [MODERATED] [PATCH v5 01/11] TAAv5 1 Pawan Gupta
2019-10-05  6:27 ` [MODERATED] [PATCH v5 02/11] TAAv5 2 Pawan Gupta
2019-10-05  6:28 ` [MODERATED] [PATCH v5 03/11] TAAv5 3 Pawan Gupta
2019-10-05  6:29 ` [MODERATED] [PATCH v5 04/11] TAAv5 4 Pawan Gupta
2019-10-05  6:30 ` [MODERATED] [PATCH v5 05/11] TAAv5 5 Pawan Gupta
2019-10-05  6:31 ` [MODERATED] [PATCH v5 06/11] TAAv5 6 Pawan Gupta
2019-10-05  6:32 ` [MODERATED] [PATCH v5 07/11] TAAv5 7 Pawan Gupta
2019-10-05  6:33 ` [MODERATED] [PATCH v5 08/11] TAAv5 8 Pawan Gupta
2019-10-05  6:34 ` [MODERATED] [PATCH v5 09/11] TAAv5 9 Pawan Gupta
2019-10-05  6:35 ` [MODERATED] [PATCH v5 10/11] TAAv5 10 Pawan Gupta
2019-10-05  6:36 ` [MODERATED] [PATCH v5 11/11] TAAv5 11 Pawan Gupta
2019-10-05 10:54 ` [MODERATED] Re: [PATCH v5 02/11] TAAv5 2 Borislav Petkov
2019-10-07 17:48   ` Pawan Gupta
     [not found] ` <5d98396a.1c69fb81.6c7a8.23b1SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-05 21:43   ` [MODERATED] Re: [PATCH v5 03/11] TAAv5 3 Andy Lutomirski
2019-10-07 17:50     ` Pawan Gupta
     [not found] ` <5d9839a4.1c69fb81.238e9.8312SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-05 21:45   ` [MODERATED] Re: [PATCH v5 04/11] TAAv5 4 Andy Lutomirski
     [not found] ` <5d983ad2.1c69fb81.63edd.6575SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-05 21:49   ` [MODERATED] Re: [PATCH v5 09/11] TAAv5 9 Andy Lutomirski
2019-10-07 18:35     ` Pawan Gupta
     [not found] ` <5d9838f1.1c69fb81.f1bab.d886SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-05 21:49   ` [MODERATED] Re: [PATCH v5 01/11] TAAv5 1 Andy Lutomirski
2019-10-06 17:40     ` Andrew Cooper
     [not found] ` <5d983ad2.1c69fb81.e6640.8f51SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-06 17:06   ` [MODERATED] Re: [PATCH v5 09/11] TAAv5 9 Greg KH
2019-10-08  6:01     ` Pawan Gupta
2019-10-10 21:31       ` Pawan Gupta
2019-10-11  8:45         ` Greg KH
2019-10-21  8:00           ` Thomas Gleixner
2019-10-08  2:46 ` [MODERATED] Re: [PATCH v5 05/11] TAAv5 5 Josh Poimboeuf
2019-10-09  1:45   ` Pawan Gupta
2019-10-08  2:57 ` [MODERATED] Re: [PATCH v5 09/11] TAAv5 9 Josh Poimboeuf
2019-10-08  6:10   ` Pawan Gupta
2019-10-08 10:49     ` Jiri Kosina
2019-10-09 13:12 ` [MODERATED] Re: ***UNCHECKED*** [PATCH v5 08/11] TAAv5 8 Michal Hocko
2019-10-14 19:41   ` Thomas Gleixner
2019-10-14 19:51     ` [MODERATED] " Jiri Kosina
2019-10-14 21:04       ` [MODERATED] " Borislav Petkov
2019-10-14 21:31         ` Jiri Kosina
2019-10-15  8:01           ` Thomas Gleixner
2019-10-15 10:34             ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-15 13:06               ` Josh Poimboeuf
2019-10-15 13:10                 ` Jiri Kosina
2019-10-15 15:26                   ` Josh Poimboeuf
2019-10-15 15:32                     ` Jiri Kosina
2019-10-15 19:34                       ` Tyler Hicks
2019-10-15 20:00                       ` Josh Poimboeuf
2019-10-15 20:15                         ` Jiri Kosina
2019-10-15 20:35                           ` Jiri Kosina
2019-10-15 20:54                             ` Josh Poimboeuf
2019-10-15 20:56                             ` [MODERATED] " Pawan Gupta
2019-10-15 21:14                               ` Jiri Kosina
2019-10-15 23:12                                 ` Josh Poimboeuf
2019-10-15 23:13                                   ` [MODERATED] [AUTOREPLY] [MODERATED] [AUTOREPLY] Automatic reply: " James, Hengameh M
2019-10-16  4:52                                   ` [MODERATED] " Jiri Kosina
2019-10-16  5:05                                     ` Jiri Kosina
2019-10-21 21:15                                       ` Luck, Tony
2019-10-16  7:14                                     ` Josh Poimboeuf
2019-10-16  7:20                                       ` Jiri Kosina
2019-10-18  1:17                                   ` Ben Hutchings
2019-10-18  4:04                                     ` Pawan Gupta
2019-10-15 17:47               ` Borislav Petkov
2019-10-16  7:26               ` [MODERATED] Re: ***UNCHECKED*** " Jiri Kosina
2019-10-16  7:54                 ` Michal Hocko [this message]
2019-10-16  9:23                   ` [MODERATED] Re: ***UNCHECKED*** Re: " Michal Hocko
2019-10-16 12:15                     ` Thomas Gleixner
2019-10-16 18:34                       ` [MODERATED] " Pawan Gupta
2019-10-18  0:14                       ` Pawan Gupta
2019-10-21  8:09                         ` Thomas Gleixner
2019-10-21 12:54                         ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko
2019-10-21 20:01                           ` [MODERATED] " Pawan Gupta
2019-10-21 20:33                             ` Josh Poimboeuf
2019-10-21 20:34                               ` Josh Poimboeuf
2019-10-21 20:33                                 ` Pawan Gupta
2019-10-21 23:01                                   ` Andrew Cooper
2019-10-21 23:37                                     ` Luck, Tony
2019-10-21 23:39                                       ` Andrew Cooper
2019-10-14 21:05       ` [MODERATED] Re: ***UNCHECKED*** " Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191016075434.GL317@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=speck@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.