[PATCH] x86/tsx: Set default TSX mode to auto

[PATCH] x86/tsx: Set default TSX mode to auto

[Nikolay Borisov]

The last known vulnerability concerning TSX was TAA (CVE-2019-11135) a
lot of time has passed since then and Intel has released a numerous
processor which do not have the TAA vulnerability (Cooper/Ice Lake,
Sapphire/Emerald/Granite Rappids) yet have TSX disable by default.

I believe having the default to AUTO rather than OFF strikes a good
balance between mitigation and reaping the benefits of the TSX feature.
So let's switch the default to AUTO.

Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 58d890fe2100..d1c4a8840d7c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1810,7 +1810,7 @@ config ARCH_PKEY_BITS
 choice
 	prompt "TSX enable mode"
 	depends on CPU_SUP_INTEL
-	default X86_INTEL_TSX_MODE_OFF
+	default X86_INTEL_TSX_MODE_AUTO
 	help
 	  Intel's TSX (Transactional Synchronization Extensions) feature
 	  allows to optimize locking protocols through lock elision which
-- 
2.34.1

Re: [PATCH] x86/tsx: Set default TSX mode to auto

[Dave Hansen]

On 8/20/25 06:21, Nikolay Borisov wrote:
> The last known vulnerability concerning TSX was TAA (CVE-2019-11135) a
> lot of time has passed since then and Intel has released a numerous
> processor which do not have the TAA vulnerability (Cooper/Ice Lake,
> Sapphire/Emerald/Granite Rappids) yet have TSX disable by default.
> 
> I believe having the default to AUTO rather than OFF strikes a good
> balance between mitigation and reaping the benefits of the TSX feature.
> So let's switch the default to AUTO.

At a bare minimum, the help text needs to get fixed up too. It still says:

	Therefore TSX is not enabled by default (aka tsx=off).

I'm also not highly motivated by the fact that CPUs have been released
without TAA. I think TAA is mostly irrelevant. CPUs had been released
with it mitigated even in the original commit that introduced this
Kconfig option: db616173d787 ("x86/tsx: Add config options to set
tsx=on|off|auto").

What has _changed_? Are there lots more folks who want to use TSX than
there were in 2019? Did it get faster? Has the chance of it being
exploited (separate from TAA) gone down?

Now would be the time for folks who are chomping at the bit to use TSX
in their big fancy apps to stand up and say why they want it and why
having their customers use the command-line to override this Kconfig
default is not workable.

Also, from distros, why not just set the Kconfig option to something
other than the default? I mean, we put Kconfig there for a *REASON*.
Let's not pretend that it's a massive engineering effort to change it.

Re: [PATCH] x86/tsx: Set default TSX mode to auto

[Nikolay Borisov]

On 8/20/25 19:46, Dave Hansen wrote:
> On 8/20/25 06:21, Nikolay Borisov wrote:
>> The last known vulnerability concerning TSX was TAA (CVE-2019-11135) a
>> lot of time has passed since then and Intel has released a numerous
>> processor which do not have the TAA vulnerability (Cooper/Ice Lake,
>> Sapphire/Emerald/Granite Rappids) yet have TSX disable by default.
>>
>> I believe having the default to AUTO rather than OFF strikes a good
>> balance between mitigation and reaping the benefits of the TSX feature.
>> So let's switch the default to AUTO.
> 
> At a bare minimum, the help text needs to get fixed up too. It still says:
> 
> 	Therefore TSX is not enabled by default (aka tsx=off).
> 
> I'm also not highly motivated by the fact that CPUs have been released
> without TAA. I think TAA is mostly irrelevant. CPUs had been released
> with it mitigated even in the original commit that introduced this
> Kconfig option: db616173d787 ("x86/tsx: Add config options to set
> tsx=on|off|auto").

To add a bit more context about the change, SUSE has been running with 
TSX enabled for the past 6 years and we haven't received any complaints 
from customers. Furthermore, there are customers which explicitly rely 
on TSX being enabled for sane performance.

It's our desire to be aligned with the upstream default option rather 
than ship a different options, hence the compromise we arrived at is 
switching the upstream kernel to auto so that TSX gets enabled by 
default unless there is an explicit reason not to.

> 
> What has _changed_? Are there lots more folks who want to use TSX than
> there were in 2019? Did it get faster? Has the chance of it being
> exploited (separate from TAA) gone down?
> 
> Now would be the time for folks who are chomping at the bit to use TSX
> in their big fancy apps to stand up and say why they want it and why
> having their customers use the command-line to override this Kconfig
> default is not workable.
> 
> Also, from distros, why not just set the Kconfig option to something
> other than the default? I mean, we put Kconfig there for a *REASON*.
> Let's not pretend that it's a massive engineering effort to change it.