By performing computations within hardware-based Trusted Execution Environments (TEEs), Confidential Computing protects data in use, which has been a longstanding challenge in data security. This paper provides an overview on Confidential Computing technologies, with a focus on security implications and recent developments. We begin with an introduction to Confidential Computing, its principles, and its relevance to data security. We outline the threat model for Confidential Computing, considering in-scope and out-of-scope attack vectors. We analyze published attacks, their complexities, and mitigation approaches in the context of Confidential Computing. We analyze data security within TEEs, including encryption, access control, and memory protection mechanisms across diferent technologies (e.g., Intel TDX, AMD SEV, Arm CCA). Finally, we explore future research directions, including the challenges related with the integration of TEEs and emerging technologies like Compute Express Link (CXL) to further enhance data-in-use security and the use of Confidential Computing in Machine Learning applications.
Data may exist in three diferent states: datian transit, dataat rest, and datain use. Data is in transit when it is traversing the network, it is at rest when it is on a storage or memory device, and it is in use while it is being processed. Protecting sensitive data in all of these states is of critical importance, and while cryptography has been successfully applied for the protection of data in transit and data at rest, the protection of data in use is still an open problem, with a few proposals that aim at solving it.
Confidential Computing
[
The definition specifies hardware-based for a valid reason: security in any layer of the computing stack could be circumvented by exploiting a vulnerability at a lower level. By providing security at the lowest possible level, it is possible to reduce the required trusted parties.
Confidential Computing is particularly relevant in the context of third-party cloud services. Confidential Computing-enabled hardware allows Cloud Service ProviCdeSrPss)( to give users the possibility to create, deploy, and manage Virtual MachiVnMess(), with guarantees on the confidentiality and integrity of the data on which they perform their computations.
In a traditional settingC,SPs give their users the possibility to creaVteMs that share the same hardware and are managed byhaypervisor. The data transferred to thVeM by the users is then managed by theCSP, which is trusted with the confidentiality and integrity of this data. This setting requires trust at multiple levels: the user needs to trust both the provider of the hypervisor and the CSP not to share their data or tamper with them. In a Confidential Computing-enabled setting, the only point of trust is the hardware manufacturer, i.e., the one that provides the authenticated firmware which guarantees the confidentiality and integrity of the data in use insidesetchuere VM.
CEUR
ceur-ws.org
Virtual Machine
Virtual Machine
Gradually, all the main players in the processor industry are designing new chips with hardware
extensions to support Confidential Computing in their server CPUs. At the moment, there are mainly
four technologies that can be used to provide Confidential Computing capabilities to users: Intel Trust
Domain ExtensionsT(DX) [
In this paper, we analyze the current status of existing Confidential Computing technologies and provide insights about the future research directions in the field. In particular, the contributions of this work are the following: • A security-oriented survey on Confidential Computing technologies, which focuses existing attacks and mitigations. • A comparison of the threat models of commercially available Confidential Computing solutions. • Future research directions on Confidential Computing, the integration of TEEs with the CXL protocol and Machine Learning applications.
As defined by the Confidential Computing Consortium (CCC), the goal of Confidential Computing is to reduce the ability for the owner, operator, or exploiter of a platform to access the private data and code inside TEEs so that it is not economically or logically viable to attack the platform during execution.
There are various threat vectors that can be used to exploit the vulnerabilities in a system: not all of them are addressed by Confidential Computing, in fact, some are explicitly considered in scope while others are considered out of scope. In particular, the following threat vectors are considered to be in scope for Confidential Computing: 1 software attacks, i.e., attacks on software and firmware installed on the host, including the OS, the hypervisor, BIOS, and so o2n;protocol attacks, i.e., attacks on protocols associated with attestation as well as workload and data tran3spcorrytp;tographic attacks; 4 basic physical attacks: cold DRAM extraction, bus and cache monitoring, plugging of attack devices into an existing port;5 basic upstream supply-chain attack, i.e., attacks that compromTEisEes such as adding debugging ports.
There is a set of threat vectors for which the mitigations vary significantly based on the silicon implementation, and there are some grey areas (such as integrity, rollback, and replay attacks) that may be considered in scope by some vendors, and out of scope by others. Sophisticated physical attacks are out of scope, as well as availability attacks oTnEtEhse. A key assumption behind the guarantees provided by Confidential Computing is that there are no exploitable side-channels that the owner (or other entities with access to the system) could use to infer information about the data or execution. Any existing side-channel could allow attackers to infer information about data or operations inside a TEE by exploiting the knowledge of the architecture ofTtEhEeitself. TheCCC states that preventing side-channel attacks depends not only on the TEE manufacturers but also on third-party vendors and application developers, thus considering this class of attacks out of scope.
Diferences among the threat models of commercial Confidential Computing solutions are summarized in Table1.
The main memory, i.e., where data in use resides, is the main asset that Confidential Computing aims to protect. Diferent Confidential Computing solutions make diferent assumptions about the threats that the main memory is subject to and this, as explained in the previous section, leads to slightly diferent threat models between them.
There are three security requirements that all Confidential Computing technologies must meet: • Data confidentiality : unauthorized entities cannot view data while it is in use withinTtEhEe. • Data integrity: unauthorized entities cannot add, remove, or alter data while it is in use within the TEE.
• Code integrity: unauthorized entities cannot add, remove, or alter code executing in the TEE.
Among the diferent technologies, the most used solution to provide confidentiality and integrity to the data residing in the main memory is a combination of encryption and access control. Every technology implements this in a diferent way, with diferent results on the guarantees.
In the past years, researchers from both industry and academia have found vulnerabilities in Confidential Computing platforms and published attacks that exploit them. Mitigations for the previously mentioned attacks have been proposed in research papers or distributed from the manufacturers in the form of microcode updates. In this section, we describe existing attacks and mitigation proposals foTrDIXntel and AMDSEV-SNP. To the best of our knowledge, no attacks have been published regarding Arm CCA.
The main vulnerabilities that have been disclosed for TInDtXelcome from a report published by Google Project Zero and Google Cloud Security in 2092].3T[o the best of our knowledge, no academic work has been published regarding attacks on Intel TDX.
Exit Path Interrupt Hijacking The attack described in this section exploits vulnerabilities in one of the Attested Code ModulesA( CMs) provided by Intel, which are thTeDX module, the Non-Persistent SEAM Loader N(P-SEAMLDR), and the Persistent SEAM LoaderP-(SEAMLDR). These two are code modules whose function is to ultimately load the TDX module in secure memory.
Since the startup BIOS code is outside the Trusted Computing BasTeC(B) for IntelTDX, Intel designed theNP-SEAMLDR to dynamically establish a root of trust on which the rest oTfDtXhe infrastructure is loaded. ThNeP-SEAMLDR performs two main tasks before returning control to the hypervisor: it validates the system configuration and installsPt-hSeEAMLDR into theSEAMRR memory region. The hypervisor can then interact with the truPs-tSeEdAMLDR to install the signed TDX module into theSEAMRR memory region.
All the code outside thesAeCMs is outside theTCB, and can thus attackNP-SEAMLDR. For this reason, theACM protects itself from exploitation in diferent ways. First of all, all external interrupts are masked and hardware breakpoints are disabled. Then, software exceptions are inhibited by setting the Interrupt Descriptor Table RegisteIDr T(R) limit to zero, which leads to any exception causing a triple fault and system shutdown. Finally, the binary is loaded at a known virtual address and no ASLR is applied, unlike P-SEAMLDR and the TDX module.
From an attacker perspective, there are two interesting windows during the execution of the NP-SEAMLDR: shortly after ACM entry the host’s Interrupt Descriptor TabIlDeT() is still configured beforeIDTR is set to zero, and shortly befoArCeM exit theIDT is restored to host’s. If an exception can be forced to occur within these windows, the attacker can gain control over the instruction pointer while in privileged mode. Intel fixed this vulnerability in the 1.0 releaTseDoXfby checking that every return address in the exit path is canonical and non-malicious.
ECC Disablement Vulnerability This vulnerability depends on the ability of the attacker to misconfigure the system. If a privileged attacker can successfully disable Error-CorrectinEgCCCo)d,e ( Rowhammer 1[0] bit flips could be more likely.
This is not an issue iTfDX cryptographic integrity is enabled: the HMAC provides a protection that is similar to ECC, with respect to memory integrity attacks. However, ifToDnXlylogical integrity is enabled, there is a single bit per cache line: if the attacker is able to EdCisCa,btlheen they would only need to flip a single bit in order to bypass the TDX logical integrity checks. This leaTdDsXto being vulnerable to Rowhammer-style attacks, where a malicious VMM tries to flip bits in memory owned by the TDX module or by Trust Domains (TDs).
Intel resolved this issue in fourth-generation Intel Xeon Scalable CPUs so that the control registers that contain configuration values foErCC are locked beforMeCHECK runs. Then,MCHECK validates that their values are configured properly before enabling TDX. 3.2. AMD SEV, SEV-ES, SEV-SNP Since the introduction of AMSDEV in 2016, several attacks against this new architectural extension have been published. Some of these attacks have been mitigated with the introduction of Secure Encrypted Virtualization with Encrypted StatSeE V(-ES) and SEV-SNP, while others may still be applicable under the right conditions. Google Project Zero and Google Cloud Security published a security report on AMD SEV-SNP as wel1l1[].
Crossline When a secureVM is created, it is assigned an Address Space IdentifierAS(ID) by the hypervisor, which then notifies the AMD Secure Processor (SP) that a new secVuMrehas been created. The AMD SP creates the ephemeral encryption key associated with the newly assAigSnIeDd, which is used to look up the key whenever a private memory page belonging toVtMheneeds to be decrypted. TheASIDs are not authenticated: this is the logic flaw behinCdrossline [12], a class of attacks that rely on the ability of a maliciouVsM to change itsASID into the one of the victimVM, thus being able to decrypt its memory. There are no assumptions of the adversary’s knowledge about the contentsVoMf:ththee only assumption is that they control the hypervisor. This assumption is in line with the threat mSoEdVel. of
Two versions ofCrossline attacks have been proposedC. rosslinev1 explores the use of nested page table walks to decrypt the victim’s memory, whCilreosslinev2 is a more powerful variant that allows the attacker VM to execute an instruction inside the encrypted memory of the victim VM. The huge advantage of these attacks is that they’re stealthy: they rely on modifying the state of the attacker VM alone, and these changes are not propagated to the victim VM’s state, so there is no way for it to notice the ongoing attack. Moreover, it is even possible for the attacker to rewind the state of their VM to eliminate any trace of the attack.
The introduction oSfEV-ES, which also encrypts the control structures ofVtMhes, increased the dificulty of successfully executing these attacks. In fact, while version 1 is still applicable with some further steps, the impossibility of manipulating the values in specific registers makes version 2 unfeasible. With the introductionSoEfV-SNP, specifically aimed at preventing attacks against memory integrity, both versions of this attack have been rendered unfeasible due to the new Reverse Map Table (RMP) table walk mechanism.
Ciphertext Side-Channel Attacks As explained in AppendixA.2, the RMP is used to perform diferent checks depending on who is requesting access to a memory page. Specifically, if the hypervisor is requesting read access to a memory page, there will be no RMP table walk, even if the requested page belongs to a secure VM.
This behavior opens the door tCoipherleaks [13]: this attack, called “ciphertext side-channel attack”, allows the privileged hypervisor to monitor the changes of the ciphertext blocks on the guest VMs memory pages and exfiltrate secrets from the guest. This is also possible thanks to the mode of operation used bySEV’s memory encryption: XOR-Encrypt-XOR (XEX) encrypts each 16-byte memory block independently and preserves the one-to-one mapping between the plaintext and ciphertext pairs for each physical address.
In particular, thCeipherleaks attack monitors the ciphertext of tVhMe Save Area V(MSA) area duringVMEXITs, then by comparing the ciphertext blocks with the ones collected during previous VMEXITs the adversary can learn that the corresponding register values have changed, and infer the execution state of the guesVtM. Moreover, by looking up a dictionary of plaintext-ciphertext pairs collected during thVeM startup, the adversary is able to recover some selected values of the registers. Due to the severity of this attack, AMD released a microcode patch to mitigate it. This patch enables the third-generation AMD EPYC processors to include a nonce into the encryption of the VMSA area, thus breaking the link between the plaintext and the ciphertext. However, even if this patch is enough to makeCipherleaks unfeasible, it is not enough to prevent other ciphertext side channel attacks that exploit memory leakage from any other memory page thanV MthSeA. In fact, it was demonstrated that ciphertext side-channel attacks can be successfully performed by targeting any memory1r4e]g.ion [
As a defense against generalized ciphertext side-channel attackCs,iptherfix framework1[
The RMP contains self-protecting entries, i.e., entries that contain the address wheRrMe Pthreesides, marked as belonging to the trusted firmware so that the hypervisor cannot modify them. An unchecked write could be leveraged modify these entries to be marked as belonging to the hypervisor. In this state, a malicious hypervisor can transition any page to any state simply by writingRtoMtPh:eallSEV-SNP security features are lost. This bug has been fixed by modifying the size of the memory region initialized by the firmware from 1 MiB to 2 MiB. However, any possible bug that allows to perform unchecked writes could, under the right conditions, be leveraged to perform an RMP degradation attack. Microarchitectural Side Channel Attacks A common technique when attackinTgEEs, especially Intel Software Guard ExtensionsS(GX), is calledsingle-stepping. This technique involves using the system’s APIC timer to interrupt the enclave after the execution of each instruction, to increase the temporal resolution of microarchitectural attacks. The same technique has been successfully appliedStEoVAVMMDs, with SEV-Step [16]. This is a framework that allows to perform single-stepping iSnEsVidVeMs, and gives access to common attack primitives like page fault tracking and cache attacks SaEgVai.nSsitnce side-channel attacks are out of scope, with respecStEtVo, so there is no specific countermeasure in place.
Confidential Computing technologies are rapidly evolving, with revisions and new iterations being developed year after year. The proliferation of Confidential Computing technologies has introduced a demand for interoperability across a wide variety of devices spanning CPUs, GPUs, accelerators, and memory, which requires the introduction of standards to allow these devices to be compatible with all Confidential Computing solutions. In this section, we propose and analyze two research directions related with Confidential Computing: the integration of TEEs with the Compute eXpress Link standard and the use of Confidential Computing in Machine Learning applications.
Compute eXpress Link (CXL) is a multi-protocol technology designed to support accelerators and memory devices over the PCIe protoco1l7[]. The purpose of CXL is sharing computing or memory resources in datacenters. Since its introduction in 2019, several revisions of the standard have been released: the CXL 3.1 specification, released in 2023, introduced the support of Confidential Computing technologies in CXL.
TEE Security Protocol The TEE Security Protocol defines the architecture to support workload confidentiality in a CXL system. Its scope is limited to directly connected CXL Type 3 (memory expansion device) Single Logical Devices (SLDs) or Multi-Headed SLDs (MH-SLDs) that might support dynamic capacity features for memory pooling architectures.
VMM/OS
VVTMMVM TSM
DSM
TSM RoT
TEE Capable Target
The diagram in Figur2e outlines the components of a confidential computing architecture in a CXL system. The TEE Security Manager (TSM) and the TEE Security Manager Root-of-Trust (TSM RoT) are responsible for the authentication and attestation of the device and for the exchange of security protocol transactions in order to discover security properties or to configure and securely lock the device. These operations are performed via the SPDM protocol that guarantees the confidentiality of the messages exchanged. The transactions on the device are processed by the Device Security Manager (DSM). TSM and TSM RoT are the agents that can assign security properties (such as memory encryption and access control) on a VM-basis distinguishing between secure VMs and legacy VMs. Memory Encryption The memory encryption feature is introduced to support data-in-use confidentiality. Two modes are defined: 1 initiator-based encryption, where data are encrypted through the CXL host and exchanged encrypted with the target, a2ndtarget-based encryption, where data are exchanged in clear text and encrypted/decrypted by the device. The recommended encryption algorithm is AES-XTS 256 but the standard is open to other types or future vendor-specific solutions. The main requirement of the encryption engine is to minimize the impact on the memory access latency, power, and costs.
TEE Exclusive State (TE State) is used to indicate whether the content of the memory is for TEE or non-TEE data. Initiators that generate memory accesses shall determine the TEE status of each memory transaction (TE Intent). TEEs are permitted to access both exclusive and non-exclusive memory, while non-TEE entities are permitted to access only non-TEE memory.
Threats to mitigate are related to integrity attacks: changing data of a VM in memory (even with encryption) and replay attacks. Integrity violations impact software running on trusted VMs in an unpredictable way. The basic principle of integrity protection is that if a trusted VM can read a private (encrypted) page of memory, it must always read the last value it wrote.
Access control is the verification of TE Intent against TE State in the memory being accessed and the resulting behavior if the verification fails. Access control can be on read and/or write. The device can advertise the supported access control types. The host can enumerate and enable access control types. TE State can be changed with diferent methods. One method called Implicit TE State Change, uses memory write operations to change the TE State at the host cache line level (64 bytes). A second method is based on specific commands that can have larger granularities (typically 4 kilobytes). The main architectural challenges on the CXL Type 3 device related to TE State Tracking and Access control are the impact on the memory space to store TE state on a 64 bytes basis and the performance degradation due to the storage of the TE state and to the checks to be performed when the device is accessed.
Encrypted
Transfers GPU No R/W Access (b) NVIDIA CC On.
NVIDIA
Driver
Hypervisor Complete access Unencrypted Transfers
GPU (a)NVIDIA CC Of.
Machine learning and data-driven technologies have been subject to rapid and pervasive development in the last few years. Machine learning models may be trained using sensitive information and, as the use of cloud-based machine learning platforms has increased, robust privacy and security guarantees have become a necessity.
The security of training and inference processes of machine learning models in cloud environments
is a relevant topic1[
Confidential Computing has emerged as a promising approach to achieve secure and trustworthy machine learning, mainly because of its high performance coming from hardwaTreE-Ebsa.sMedost of the computation in the context of machine learning models’ training is performed on external devices, like Graphics Processing UnitGsP(Us) or other accelerators. For this reason, in the last few years, there have been eforts to provide solutions for the integration of external devices in Confidential Computingenabled environments both in academia and in industry. Even if the research interest on this topic converges on machine learning applications because of their difusion, any application that ofloads its computation toGPUs or other external devices could also benefit from the application of these solutions. NVIDIA Confidential Computing NVIDIA has recently announced its new H1G00PU, based on the Hopper architecture, which is the first commercGiaPlU solution introducing hardware-based confidential computing capabilities. In July 2023, they released a whitepaper explaining what are the goals of NVIDIA Confidential Computing, which features are enabled on the HG1P0U0, and how it integrates into theTEEs created by Confidential Computing-enabled CPUs. NVIDIA specifically requires that the CPU used together with their H100 needs to be from Intel, AMD, or Arm, and must support TDX, SEV-SNP orCCA, respectively. With NVIDIA Confidential Computing enabled, all the data transferred between the secuVrMe and theGPU will be fully encrypted, with no possibility from the hypervisor to read or write the data. This behavior is represented in F3i.gure
The main goals set by NVIDIA for the H10G0PU are to provide data and code confidentiality, data and code integrity, and to provide protection against basic physical attacks so that interposers on buses such as PCIe and DDR memory cannot leak data or code.
NVIDIA outlines three main modes of deliveriGnPgUs to aVM: assigning an entire confidential GPU to a single trustedVM (mainly used for inference, HPC or lightweight training), assigning multiple confidential GPUs to a single trustedVM (with NVLink support and multiple possible topologies, typically used for training) and, finally, assigning each confidenGtiPaUl to multiple tenants. The threat model of NVIDIA Confidential Computing is essentially the same asTfDorX, CCA andSEV-SNP. Also in this scenario, sophisticated hardware attacks are out of scope, as well as denial of service attacks. Other Solutions The NVIDIA H100 GPU is the only available commercial solution that provides Confidential Computing capabilities onGPUs. However, researchers from both academia and industry published several proposals for the extension of confidential computinGgP Utos or, more generally, accelerators.
Graviton 1[
Acai [20] is a CCA-based solution that allows confidentiValMs to use accelerators while relying on hardware-based memory protection to preserve security. There are three modes inVwMhsich can access accelerators Aocnai. If the SoC has integrated accelerators, tAhecnai uses existingCCA primitives to enable VM access. For PCIe devicAesc,ai supports encrypted access. This mode creates redundant data copies (at least three). For this reason, the third mode pisrottheceted mode, which reduces the number of copies to one by allowing accelerators to directly access the VM memory.s This requires careful consideration, as in the oriCgiCnAalspecification external accelerators connected over PCIe cannot access realm memorAyc.ai addresses this by modifying the granule protection mechanism to disallow any other software from accessing the normal world shared memoVryM: tahned accelerator can communicate over a shared memory area in normal world meAmcoari ya.lso establishes mutual attestation between accelerators and VMs leveraging existing attestation mechanisms from PCIe5.
IPU Trusted Extensions (ITX)2[
All these models have diferent approaches in including external devices inside the CPU TEE’s trust boundary. However, devices implementing these approaches are not commercially available at the time of writing, and, while they are surely promising, it’s impossible for us to say whether these approaches are taken into account in the development of the new generation of Confidential Computing-enabled AI accelerators.
Confidential Computing technologies are rapidly evolving. New use cases and scenarios, like the integration with the CXL standard and the use of Confidential Computing with Machine Learning applications, need careful threat modeling and security analyses to avoid that the introduction of external devices into the Trust Boundary of Confidential Computing systems cause their security guarantees to be weakened. In this paper we have provided a comparison of the threat models of commercially available Confidential Computing technologies, as well as a detailed analysis of their inner workings. We have provided an overview on the attacks and mitigations for these systems, and an analysis on future research directions in this field, identifying the integration with the CXL standard and Machine Learning applications as the most interesting and promising.
This work was initially accepted to be published in the proceedings of the 8th Italian Conference on Cybersecurity (ITASEC 2024). Alessandro Bertani’s research grant was partially funded by Micron Technology and Project FARE (PNRR M4.C2.1.1 PRIN 2022, Cod. 202225BZJC, CUP D53D23008380006, Avviso D.D 104 02.02.2022), which is under the Italian NRRP MUR program funded by the European Union - NextGenerationEU.
During the preparation of this work, the authors used ChatGPT, Google Gemini and Grammarly to perform spelling and grammar checks. After using these tools, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content.
Even if commercially available Confidential Computing solutions are similar to one another, in this appendix we highlight their diferences. We also add details with respect to other works, as well as a description of RISC-V AP-TEE, which was not included in the work of Guanciale2e2t]a.l. [
IntelTDX is a set of architectural extensions that enable the creation and management of hardwareisolated, secureVMs calledTDs. TDX is designed to isolateVMs from every nonT-D component, including the hypervisor.
IntelTDX uses a CPU-attested software module (theTDX module), Intel Virtual Machine Extensions (VMX) and Intel Multi-Key Total Memory Encryption (MK-TME), which is used to create and manage a diferent private key for eachTD, that is then used to encrypt the memory pages of eaTcDh and their control structures.
IntelTDX introduces a new CPU mode that helps enforce the security policies foTrDtsh,ecalled Secure Arbitration ModeSE(AM), that is the CPU mode in which the privileged and trustTeDdX module is executed. Control transfers between the hypervisor anTdDthXemodule happen when a SEAMCALL instruction is executed. This instruction causes the CPU mode to switchSEtAoM, transferring the control to the TDX module.
To guarantee memory isolation betweeTnDs and from the hypervisor, a Guest Physical Address (GPA) can beprivate orshared, depending on theSHARED bit of theGPA. The CPU translates sharedGPAs using theshared Extended Page TableE(PT), which resides unencrypted in host VMM memory and is directly managed by the VMM. The CPU translates priGvaPAtes using thesecure EPT, which is unique perTD and is encrypted with the private key of its associaTteDd. The secure EPT is designed not to be directly accessible by any other software thanTthDeX module, nor by any devices.
During TD launch, its initial contents and configuration are recorded byTtDhXe module. At runtime, the IntelTDX architecture reuses the IntSeGlX attestation infrastructure to support attesting to these measurements. Software running insideTaD can request theTDX module to generate an integrity-protectedTDREPORT structure that includeTsD’s measurements and an asymmetric key that is used to establish a secure channel with the software running insideT Dth. eAn SGX Quoting Enclave can be used to check the integrity of the report produced in the previous step. If integrity is successfully verified, the Quoting Enclave can insert the guTeDst’s measurements in a quote, which is crucial in establishing trust between the user and the platform.
Memory Confidentiality and Integrity TDX uses MK-TME to enable cache-line-level memory encryption. The TDX module assigns eacThD a unique, privateKeyID which corresponds to an AES-128 bit cryptographic key managed by the memory controller. The keys saved into the memory controller are not accessible by software or by using external interfaces to an SoC.
TDX also provides two memory integrity modecsr:yptographic integrity andlogical integrity. When cryptographic integrity is enabled, each cache line is protected with a 28-bit MAC (obtained by truncating the output of a SHA-3-256-based MAC generation function), in addition to AES-XTS-128 encryption. Moreover, a 1-bTitD ownership tag is maintained with each cache line to identify if the line is associated with a memory page assigned to a TD. When cryptographic integrity is enabled, the ownership tag is included in the computation of the MAC. When only logical integrity is enabled, the TD ownership tag is maintained but there is no MAC computation.
AMD SEV aims at isolatingVMs and the hypervisor from one another. It uses one key per virtual machine to isolate guests and the hypervisor from one another. The keys are managed by the AMD (a)TDX Architecture.
(b) SEV-SNP Architecture.
(c) CCA Architecture.
Secure Processor (SP) and are used to encrypt the memory pages owned by each gSuEeVst-.ES is an improvement overSEV: it encrypts all CPU register contents when a VM stops running, thus preventing the leakage of information in CPU registers to untrusted components, and can detect malicious modifications to a CPU register state.SEV-SNP is the last iteration of this technology and the focus of this section. It adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more. The architectuSrEeVo-SfNP is depicted in Figure4b. The basic principle oSfEV-SNP integrity is that if a VM is able to read a private (i.e., encrypted) page of memory, it must always read the last value it wrote: if this is not possible, it should get an exception indicating that the value could not be read. This principle is enforced by a component called RMP.
As happens for InteTlDX, the guarantees of memory confidentiality and integrity are enforced by a trusted firmware component, provided by AMD, that runs on the AMD SP. The AMD SP, the SoC hardware, and the secure VM itself are the only trusted components in this technology’s threat model.
WhileSEV and SEV-ES only supported attestation during the launch of a guVeMst, SEV-SNP is more flexible: a guest VM can request an attestation report from the AMD AP at any time. Attestation reports contain system information and a block of arbitrary data supplied by thVeMguaesstpart of the request and are signed by the AMD SP. Attestation reports enable third parties, e.g., the guest owner, to validate that specific data came from a specific VM Memory Confidentiality and Integrity SEV-SNP uses Multi Key Secure Memory Encryption to provide memory confidentiality to secure VMs. At boot, the keys fVoMrs are randomly generated and stored in the AMD SP. SEV-SNP also uses AES-128 with XEX as mode of operation.
Many of the integrity guaranteesSoEfV-SNP are enforced through thReMP, a single data structure, shared across the system, which contains one entry for every page of DRAM that may be uVseMdsb.y The purpose of theRMP is to track the owner of each page of memory: the hypervisor, a spVecMific, or the AMD SP. Memory accesses are controlled in a way that only the owner of the page can write it. The RMP is only checked when the hypervisor is performing write accesses to memory pages: since SEV-SNP encrypts all the memory pages belonging to secVuMres, the hypervisor being able to read the encrypted content of a memory page is not considered as a threat. Both read and write accesses inside anSEV-SNP VM requireRMP checks. Figure5 shows the diferences inRMP table-walks when the hypervisor and an SEV-SNP VM request write access to a memory page.
Arm CCA allows to deployVMs while preventing access by other software components, like the hypervisor.CCA allows the hypervisor to control VthMe but removes any right to access code, register states, or data used by theVM. This separation is enabled by protectVedM execution spaces called Realms. A Realm is completely isolated from a “normal” execution environment in terms of code execution and data access. The separation is achieved through a combination of hardware extensions and trusted firmware. The architecture of Arm CCA is depicted in Fig4ucr.e
Armv8-A already introduced the concept woofrld, i.e., a combination of a security state of a processing element and physical address space. The security state a processing element is executing in determines which physical address it can access. The Arm CCA introduceRseathlme Management Extension (RME) [23], which adds two new worlds1: the Root world is the world with the highest privilege (the Monitor runs in Root worl2d),the Realm world is composed of the Realm security state and the Realm Physical Address range.
The RME is composed of a set of hardware extensions that are required by the architecture to allow isolated Realm VM execution, while the software component that is used to manage the RVeaMlsm is calledRealm Management Monitor (RMM), which is part of the TCB of Arm CCA, is the trusted component that executes in the Root world and is in charge of ensuring the isolation among Realm, Normal, and Secure worlds.
CCA remote attestation allows the user of a service provided by a Realm to determine the trustworthiness of the Realm and of the implementation of the CCA platform. The protocols that should be used for attestation are implementation-specific and are not discussed in the guidelines provided by Arm. However, the desired outcome of successful attestation is a secure point-to-point connection between an attested endpoint in the Realm, and the reliant party (the user). Memory Confidentiality and Integrity In the case of Arm CCA, the guarantees on the security of the data is implementation-dependent. Arm provides some rules that must be strictly followed, and some suggestions. Arm only suggests using encryption algorithms waditdhress tweaking, leaving the choice of the algorithm and mode of operation to the hardware manufacturer. This allows the selection of an algorithm depending on the specific power and area requirements. Memory integrity should also be provided as a guarantee to the Realm owner, but the details are implementation-dependent.
There are other Confidential Computing architectures that have been proposed, both in academia and in industry. IBMPEF and RISC-V Application PlatformT-EE (AP-TEE) are two examples of these proposals. The former doesn’t have publicly available information, apart from the paper published by IBM in which they describe the architectural extension at a high level. The latter is the result of the efort of several contributors, whose aim is to provide Confidential Computing capabilities to the RISC-V open-source platform.
IBM Protected Execution Facility In 2021, IBM published the description of its own implementation of a Confidential Computing extension to the OpenPOWER architectur4]e a[nd, to the best of our knowledge, this paper is the only documentation available on this TEE.
The goal ofPEF is to enable users to create and manage secVurMes, guaranteeing the confidentiality and integrity of their memory. To do sPoE,F utilizes a Trusted Platform Module (TPM), and a new trusted firmware called theProtected Execution Ultravisor (or justultravisor).
PEF achieves isolation between secuVrMes and the outside through hardware-enforced access control policies, and memory confidentiality and integrity with the use of cryptography. It also introduces a new CPU state, called thseecure state, which is managed by the Ultravisor: this firmware component manages all security-related hardware features in the processor, and is the only component that can do so.
The access control mechanismPiEnF is based on the assignment oVfMs to security domains: each secureVM has its own security domain in secure memory, while the hypervisor is in another security domain in normal memory. This approach ensures that the seVcMurseare protected from the hypervisor and one another and that the hypervisor’s security domain is protected from all the secure VMs.
The Ultravisor protects the confidentiality of the secVurMe when the hypervisor is paging or dumping it. When data from secure memory are made available to software that is not running in secure memory, the Ultravisor performs encryption with integrity using Galois Counter Mode as the mode of operation, prior to allowing a page to be moved to normal memory. When a page is accessible to the hypervisor, it is not accessible to the securVeM: when the latter wants to access the page, the Ultravisor performs an integrity check and, if it is successful, decrypts the page and allows access from the secure VM. RISC-V Application Platform - TEE This section describes the first proposal of a Confidential Computing extension to the RISC-V architecture, calCleodnfidential Virtual Machine Extension orCoVE [24].
As for previous architectures, CoVE relies on the presence of a trusted software module called the TEE Security Manager, or TSM, which manages security properties for workload assets to protect against access from the OS or the hypervisor. The isolation of the TSM from the host is supported by Instruction Set Architecture (ISA) extensions.
The CoVETCB consists of the TSM that acts as the TCB intermediary between TEE and non-TEE components, and of hardware elements that enforce confidentiality and integrity properties for workload data-in-use. As for all other technologies, the hypervisor is untrusted and manages the resources for all workloads, both confidential and non-confidential.