Linux 7.0 Prepares to Enable Intel TSX by Default for Performance Gains on Safe CPUs

A significant configuration change is brewing for the Linux kernel's handling of Intel's Transactional Synchronization Extensions (TSX). A patch authored by SUSE Linux engineer Nikolay Borisov has been queued into the tip/tip.git repository's x86/cpu branch, proposing to change the default TSX mode from "off" to "auto" for the upcoming Linux 6.20~7.0 kernel cycle. This move, if accepted without last-minute objections, represents a long-awaited shift in the kernel's stance on a feature that has been sidelined for years due to security concerns.

The Security Backstory: Why TSX Was Disabled

Intel TSX is a hardware feature designed to improve performance in multi-threaded applications by allowing a transactional memory model. It enables "lock elision," where a thread can execute a critical section without acquiring a traditional lock, assuming no conflicts occur. If a conflict is detected, the hardware rolls back the transaction and falls back to a standard lock. This can significantly reduce lock contention in workloads like databases, high-performance computing (HPC), and financial trading systems.

However, TSX's journey in the Linux kernel has been rocky. In 2019, Intel and the kernel community discovered side-channel vulnerabilities associated with TSX, specifically the TSX Async Abort (TAA) vulnerability (CVE-2019-11135). TAA could allow an attacker to infer data from memory, similar to other speculative execution attacks like Meltdown and Spectre. In response, the kernel community disabled TSX by default for all CPUs, and Intel released microcode updates to mitigate the issue. For a time, even CPUs not vulnerable to TAA had TSX disabled as a precautionary measure.

The Case for Re-enabling TSX

The new patch argues that the security landscape has evolved. Borisov notes that the last known major vulnerability concerning TSX was TAA, and "a significant amount of time has passed since then without anyone reporting any issues." Furthermore, Intel has since released new processor architectures that are not vulnerable to TAA, including:

• Cooper Lake (3rd Gen Xeon Scalable)
• Ice Lake (10th Gen Core, Xeon Scalable)
• Sapphire Rapids (4th Gen Xeon Scalable)
• Emerald Rapids (5th Gen Xeon Scalable)
• Granite Rapids (6th Gen Xeon Scalable)

Despite these safe processors being available, TSX has remained disabled by default in the upstream kernel, creating a divergence from enterprise distributions. SUSE, for example, has been shipping kernels with TSX enabled for the past six years, and its customers have come to rely on the performance benefits. Borisov's patch aims to reduce this divergence by adopting the "auto" mode, which enables TSX on processors believed to be safe while keeping it disabled on vulnerable ones.

How the "Auto" Mode Works

The "auto" mode is the key to this change. When TSX mode is set to "auto," the kernel will automatically enable TSX for CPUs that are not affected by TAA and similar vulnerabilities. For processors that are vulnerable, TSX will remain disabled. This provides a balanced approach: it unlocks performance where it's safe to do so while maintaining security for older hardware.

If you're running on a vulnerable CPU and want to force TSX enabled (at your own risk), you can still boot the kernel with the tsx=on parameter. This overrides the default "auto" behavior and enables TSX unconditionally.

Checking TSX Status

To verify if TSX is present and enabled on your system, you can check the /proc/cpuinfo file. Look for the hle (Hardware Lock Elision) and rtm (Restricted Transactional Memory) flags. If both are present, your CPU supports TSX, and if the kernel is configured correctly, it should be enabled.