Confidentiality and Integrity
Last updated
Last updated
Intel TDX promises to secure the data of a Trust Domain against the hypervisor and other VMs running on the same Hardware. In order to successfully fulfil this promise Intel TDX needs an confidentiality and integrity protection mechanism. This mechanism needs to ensure that the content of the memory pages is secured so that other VMs or the hypervisor can not read or manipulate it.
Therefore Intel TDX uses Multi-Key-Total-Memory-Encryption which is a CPU enabled feature that encrypts the memory. The memory controller on an MKTME enabled CPU is extended with an encryption engine that provides the NIST approved AES-128-XTS and AES-256-XTS encryption algorithms. The encryption engine itself holds all encryption keys in the Key Encryption Table (KET). This table maps the encryption keys from a specific TD to its memory pages which are identified through the Host Key Identifier (HKID). With the help of this table the memory controller can encrypt and decrypt memory on the fly.
Intel TDX also offers integrity protection for the private memory pages of TDs in order to protect the TDs against further attacks. Intel TDX supports two modes of operation for its integrity protection, the Cryptographic Integrity (CI) and Logical Integrity (LI) mode. The Logical Integrity mode protects the encrypted memory through the usage of a TD Owner bit while the Cryptographic Integrity mode also adds a Message Authentication Code (MAC). The TD Owner bit is used to indicate that the data that was written is associated with a private HKID. The MAC in CI mode is computed for each cache line of 64 Bytes and also includes an encryption tweak which is the encrypted physical address for the current cache line. The MAC is also computed over the TD Owner bit. The MAC computation uses SHA-3-256 [1] as an underlying function and the MAC is shorted to 28 bit instead of 256 bit [2, p. 120].
The mentioned values TD Owner bit and MAC are used to identify poisoned memory upon reading it. Depending on the protection mode (CI vs LI) the CPU reacts differently. However once the CPU realizes that the memory it is trying to read has been poisoned, it writes an indication back that is associated with the memory address back into the memory. This allows the CPU on subsequent reads to detect that the memory has already been detected as poisoned and no further integrity checks will be performed. This indication can be cleared if a new write on that address is issued and the whole memory line is being written. In addition to reduce the attack vector any read on private TD data that comes from an operation outside of the SEAM mode returns all 0. This prevents the testing of MAC collisions with malicious ciphertext.
The following graphic shows what happens when a memory read occurs in CI Mode. We will decide between what happens when a page is meant to be private vs when a page is meant to be shared.
If a page is meant to be private, which is indicated through its HKID, a check of the TD Owner Bit is performed first. If the CPU concludes that the TD Owner Bit is set to zero a mismatch is recognized as the page was previously written using a shared HKID. Therefore the CPU returns zeroed data and indicates that the page has now to be treated as poisoned. If the TD Owner Bit however is set to zero and the MAC comparison is successful the decrypted data is returned. A failure with zeroed data and a poison marker for the page is returned, when the MAC comparison is not successful or the CPU notices that this page belongs to another TD.
A reverse logic is applied to shared memory pages. If the TD Owner Bit is set to one a TD bit mismatch failure is detected, as the page is marked private. The TD Owner Bit zero correctly indicates that a shared memory page is being used. If the MAC check is successful the page is being decrypted and no poison entry is being added. However if the Integrity check fails the CPU marks the page as poisoned and returns zeroed data.
If the TDX Module operates in LI Mode only a TD Owner Bit mismatch for private pages leads to a new poison. Otherwise when the TD Owner Bit mismatch happens for shared pages zeroed data is returned but no poison indication. Instead the the memory controller logs an error which can cause a shutdown or machine check on a subsequent read. If the TD Owner Bit matches the memory controller behaves the same way as in CI mode.