Intel has officially sounded the death knell for Transactional Synchronisation Extensions (TSX) on a selection of processors from Skylake to Coffee Lake – a security-enhancing move which will have an oversized performance impact on certain workloads.
TSX was launched by Chipzilla in 2013 on selected Haswell processors. The technology, it promised, allowed for a dramatic boost in selected multi-threaded workloads – anything up to a 400 per cent boost in transactions per second (TPS) for databases, for example – by providing hardware support for transactional memory.
Sadly, those speed boosts weren't all they seemed. A year later, in 2014, Intel was forced to turn TSX off in Haswell and selected Broadwell chips after an erratum was disclosed allowing for "unpredictable system behaviour" – exactly the opposite of what you want in your database-centric server system.
For a while, things seemed well – until February 2019, when security researchers discovered that TSX could be used in an attack on Intel's Software Guard Extensions (SGX), breaking the secure enclave and allowing the tech to be used as an "egg hunter" for scanning memory for injected shell code.
If that wasn't bad enough, ZombieLoad followed later that year – a vulnerability which was updated post-disclosure following the discovery that the TSX Asynchronous Abort (TAA) function could be abused to infer the contents of protected memory locations, even in silicon thought to be immune to side-channel attacks like Spectre and Meltdown.
It would now appear that Intel plans to throw in the towel, as brought to our attention in a scan of the latest changes to the Linux kernel by Phoronix: Intel has released a microcode update which disables TSX on processors ranging from the Broadwell successor Skylake through to Coffee Lake parts released starting in 2017.
Dubbed a "memory ordering issue" by the company, the problems in the affected parts have been known for some time: Intel's public-facing documentation on the matter, here in PDF form, was first released in 2018. The company had previously been focused on workarounds, however, and it's only in an update released this month that it has admitted defeat and announced "client Intel TSX changes" which effectively turn the feature off for good.
- Intel data center boss Navin Shenoy exits as CEO takes sledgehammer to group
- Intel sponsors report on tech's role in decarbonisation and the irony isn't lost on us
- Intel to put SiFive's latest CPU cores into 7nm dev system to woo customers to RISC-V
- Google cosies up to AMD for high-performance scale-out Tau VMs – but makes eyes at Intel and Arm, too
"Note that for the affected Intel Xeon Processor E3 v5 and v6 Family (codename Skylake and Kaby Lake) and the 6th, 7th, and 8th Generation Intel Core i7 and i5 (code name Skylake, Kaby Lake, Coffee Lake, and Whiskey Lake), a newer microcode update will be released in 2021.1 IPU [Intel Platform Update] that will disable Intel TSX by default," Intel wrote by way of warning.
By default, the processor will force abort all RTM [Restricted Transactional Memory] transactions. CPUID bit CPUID.07H.0H.EDX (RTM_ALWAYS_ABORT) is set to indicate to updated software that the loaded microcode is forcing RTM abort. This bit can also be used to determine that the microcode update has been loaded with default settings that force aborts.
The change only affects parts up to the company's 8th-generation desktop-class and E3 V6 server-class families, with no change to the behaviour of its more recent processors – yet, at least.
These, however, already come with mitigations for security concerns in the TSX instructions which have a corresponding impact on performance – though not as severe as turning TSX off entirely – while the company's newest 10th-generation Comet Lake and Ice Lake and 11th generation Tiger Lake parts dropped TSX altogether.
With its latest parts launching with TSX missing in hardware, and the feature being turned off via microcode update in earlier parts, one thing seems clear: Intel is officially done with TSX in its current form.
Intel did not respond to a request for comment. ®