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

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.