Overview
Software that performs secret-based memory access is vulnerable to well-known cache-based side channel attacks, which can be used to extract secrets based on memory access patterns. These attacks are generally applicable to all software that handles secrets, including software within a Trust Domain (TD) that runs using Intel® Trust Domain Extensions (Intel® TDX) with Multi-Key Total Memory Encryption (MKTME).
Intel TDX helps mitigate a variety of potential attacks in virtualized systems with an untrusted, even potentially malicious, Virtual Machine Monitor (VMM). This is achieved in part by preventing the VMM from using KeyIDs that are reserved for use by TDs, helping ensure the VMM cannot directly generate requests to TD private memory with TD private KeyIDs. The VMM can still try to access TD private memory using an incorrect KeyID, resulting in potential caching of KeyID aliases, which are copies of the same physical address decrypted using different KeyIDs.
Since Intel processors will force evictions of older aliased data in certain configurations and circumstances, they are affected by some new variants of cache-based side channel attacks from the untrusted VMM when Intel TDX is enabled. These new variants enable a malicious or untrusted VMM to learn memory access patterns of victim TDs. Such attacks can be mitigated through careful coding practices that avoid secret-dependent memory access. Finally, Intel processors may implement new or modified memory coherence flows in the future; therefore, software must not rely on the presence or absence of these KeyID alias handling flows for correct operation.
Background
Cache Based Timing Side Channel Attacks
This class of attacks often affects software that exhibits secret-dependent memory access patterns and can potentially result in leakage of a secret. Currently, there are many types of cache-based side channels (Prime + Probe, Flush + Reload), which vary in their precision and efficiency. For example, Prime and Probe attacks are relatively less precise and inefficient, because they depend on cache set collisions, while Flush and Reload attacks allow targeting a specific cacheline and are more efficient.
Intel® Trust Domain Extensions (Intel® TDX)
Intel TDX provides a Trusted Execution Environment (TEE) for executing Virtual Machines (VMs) even when managed by an untrusted or even potentially malicious VMM. More specifically, TDX enforces CPU, memory, and I/O isolation for TDX-protected VMs or TDs and helps protect TD resources against unauthorized access and modification by the VMM.
MKTME is a key building block of TDX. It enables the CPU to encrypt each TD’s memory with a unique Advanced Encryption Standard (AES) key. Each memory request includes a KeyID that is used to specify the key that should be used to encrypt/decrypt memory associated with that request. This KeyID flows from the CPU through the caches to the memory controller, and every cache tag at all levels of the memory hierarchy in the system includes a KeyID.
The Intel TDX architecture partitions KeyIDs between Shared (VMM) and Private (TDX) usage in order to prevent the VMM from directly accessing TD private memory. Specifically, a VMM is prohibited from generating requests with Intel TDX KeyIDs and therefore can’t read/write TD private memory successfully. However, it can still access TD private memory using an incorrect KeyID, resulting in potential caching of ‘KeyID aliases,’ which are copies of the same physical address decrypted using different KeyIDs.
Since KeyID aliases complicate cache coherence, Intel processors will force evictions of older aliased data in certain configurations and circumstances. For example, an aliased access (say with KeyID K2) to an existing cacheline (say with KeyID K1), may evict the currently cached (K1) copy prior to re-fetching the same line with the new KeyID (K2). A similar modification to the address monitoring hardware utilized by the MONITOR instruction, which detects writes to a ‘target’ physical address, may also ignore the KeyID portion of incoming physical address snoop requests.
The known security implications of the above cache coherence and MONITOR hardware modifications are discussed below.
Impact
Intel TDX architecture assumes the VMM is untrusted and could potentially launch attacks against TDs on the same platform. Such an untrusted VMM could use the previously described cache coherence implementation in certain configurations to launch cache-based side-channel attacks with cacheline precision (for example, Flush + Reload, Flush + Flush); these new variants would not be possible without the KeyID-related cache coherence flows because the VMM cannot directly generate memory requests (and hence, cause flushes) with Intel TDX KeyIDs. These flush-based attacks typically have higher precision than other types of cache side-channel attacks that rely on cache set congruence such as Prime + Probe or Evict + Reload.
Similarly, the modification to the MONITOR hardware to ignore the KeyID allows an untrusted VMM in the context of Intel TDX to observe a TD’s memory access patterns. Meaning it can reveal the sequence of memory addresses that a TD accesses at cacheline granularity.
Note: The attacks described above reveal only memory access patterns/addresses accessed by a TD; they do not directly reveal the data held in those addresses.
Use Cases
The above attacks require VMM privileges and are hence, relevant only in the context of a platform that uses Intel TDX to protect TDs against an untrusted/malicious VMM. They are not applicable to scenarios where the VMM is a trusted software component.
Mitigation
Since all the above attacks only reveal memory access patterns (but not the data at those addresses) to an attacker, they can be mitigated by adhering to Intel’s recommended secure coding practices and avoiding coding styles that make secret-based (for example, cryptographic key based) memory access. Please refer to the secure coding guidelines. Note that future Intel processors may implement new or modified memory coherence protocols, so software must not rely on the presence or absence of these KeyID-related coherence flows for correct operation.
Affected Processors
KeyID-based cache aliases might occur in various configurations of Intel processors that support MKTME. The KeyID alias flushing behavior may be enabled in a subset of these configurations, but it is only a potential security concern in systems using Intel TDX. This issue affects Intel processors that support Intel TDX (for example, processors formerly code named Sapphire Rapids) in certain configurations.