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 ; 16 Oct 2019 07:54:44 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iKe8o-0007sY-CH for speck@linutronix.de; Wed, 16 Oct 2019 09:54:43 +0200 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CDD22AC22 for ; Wed, 16 Oct 2019 07:54:34 +0000 (UTC) Date: Wed, 16 Oct 2019 09:54:34 +0200 From: Michal Hocko Subject: [MODERATED] Re: ***UNCHECKED*** Re: Re: [PATCH v5 08/11] TAAv5 8 Message-ID: <20191016075434.GL317@dhcp22.suse.cz> References: <20191009131251.GD6616@dhcp22.suse.cz> <20191014210458.GF4957@zn.tnic> <20191015103454.GW317@dhcp22.suse.cz> 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 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 > > 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