What does Transactional Synchronization Extensions (TSX) processor technology mean to vulnerability exploits (e.g. Brute Forcing)?

Intel Transactional Synchronization Extensions (TSX) was introduced since from Haswell processor with adding hardware transactional memory support. It was originally design to speed up execution of multi-threaded software through lock elision. Every new technology has both good side and evil side, then how about TSX extension? What can we use it to do for vulnerability exploits and its defenses?


According to Intel SDM, TSX provides two software interfaces for programmers:

• Hardware Lock Elision (HLE) is a legacy compatible instruction set extension (comprising the XACQUIRE and XRELEASE prefixes).
• Restricted Transactional Memory (RTM) is a new instruction set interface (comprising the XBEGIN, XABORT, and XEND instructions).

This post is focusing on the RTM interface, as the specification indicates below.

Software uses the XBEGIN instruction to specify the start of the transactional region and the XEND instruction to specify the end of the transactional region.

The XBEGIN instruction takes an operand that provides a relative offset
to the fallback instruction address if the transactional region could not be successfully executed transactionally.

A processor may abort transactional execution for many reasons. The hardware automatically detects transactional abort conditions and restarts execution from the fallback instruction address with the architectural state corresponding to that at the start of the XBEGIN instruction and the EAX register updated to describe the abort status.

The interesting things here are as follows:

1. What reasons can cause a transactional execution abort?
2. What does it look like when a transactional execution abort happens?

For the 2nd question above, the TSX specification says below, 

The architecture ensures that updates performed within a transactional region that subsequently aborts execution will never become visible. Only a committed transactional execution updates architectural state. Transactional aborts never cause functional failures and only affect performance.

which means after a TSX abort occurs, all the physical memory and processor register updates (after XBEGIN instruction) will be discarded, and from user's perspective, the memory and register states are "restored" to the states at the start of XBEGIN instruction. This seems to be the same with the behaviors of try/catch or setjmp/longjmp functionalities. 

However, there are some differences. For instance, any fault or trap in a transactional region that must be exposed to software will be suppressed, as if the fault or trap had never occurred. If any exception is not masked, that will result in a transactional abort and it will be as if the exception had never occurred. 

As matter of fact, all the synchronous exception events (like #GP, #PF) that occur during transactional execution are suppressed as if they had never occurred, and those events won't be delivered to processor for handling. 


Then regarding the 1st question above, there are a couple of reasons that might cause a TSX abort, like XABORT, CPUID, Software INT, VMX instructions, IO instructions, ring transitions (e.g. syscall), VMExit (ept violation), etc.


So, now let's think about something about Intel TSX!

Provided that a malicious software attempts to access (e.g. write or execute) a protected memory, normally it will trigger a #PF fault, then it could be detected and terminated subsequently by OS kernel. But if the malicious software attempts to do the same thing in TSX state after an XBEGIN instruction, as we pointed out above, such a #PF exception will be suppressed, which means the OS kernel cannot even detect this access violation. 

The similar case also applies to the access to protected memory by EPT (extended page table) in a VMM/Hypervisor. Because when guest software attempts to access the physical memory protected with EPT in a hypervisor, an EPT violation vmexit will be triggered, but in TSX state, such a vmexit won't be triggered, so the hypervisor won't detect it. 

So basically, it means that, To malicious software, before a successful attack, it can make more attempts (e.g. brute-forcing) to do bad things without being caught by OS kernel or even hypervisor. 

But now I don't have an idea on how to use it to do something "real bad". Maybe someone else does have ideas.... 



UPDATE:
Interesting!!! got this.... 
TSX improves timing attacks against KASLR
http://labs.bromium.com/2014/10/27/tsx-improves-timing-attacks-against-kaslr/