Computing in a Sealed Room: Confidential Computing and the Limits of Not Trusting

The Hook: The Gap That All Encryption Leaves Open

There is a routine that has become second nature in any reasonably mature IT operation. Data on disk? Encrypted — BitLocker, LUKS, server-side encryption in object storage. Data on the wire? Encrypted — TLS everywhere, ideally with certificate rotation and perfect forward secrecy. Two of the three classic data states are thereby covered: data at rest and data in transit.

And then comes the third state, which is rarely discussed because for so long there was no answer to it: data in use. The moment an application actually processes data, that data must sit in plaintext in main memory. Disk encryption has decrypted it, TLS has unwrapped it, and now it lies as naked bytes in the RAM pages of a virtual server. Who can reach it there?

The uncomfortable answer is: the hypervisor. And therefore anything and anyone who controls the hypervisor. In classical virtualization, the hypervisor is the omnipotent master of the guest machine — it manages the guest's memory pages, can read them at any time, rewrite them, swap them out, take a snapshot. That is not a bug; that is its job. Except: in the public cloud, the hypervisor does not belong to you. It belongs to the provider. And so, technically speaking, neither does the confidentiality of your data during processing — it hangs on the trustworthiness and uncompromised state of a software stack you neither see nor control, operated by staff you have never met, in a data center you will never enter.

For years the answer to this was organizational: contracts, certifications, data processing agreements, audits. That is not nothing — but it is paper. Confidential computing is the attempt to answer the same question with silicon. The idea: if the CPU itself ensures that the hypervisor cannot read the guest's memory in plaintext, then you no longer have to trust the operator, only the chip vendor and the mathematics.

This article takes that promise apart. It shows what exactly is guaranteed and what is not, how the two dominant technologies AMD SEV-SNP and Intel TDX work under the hood, why remote attestation — not encryption — is the actual core of the matter, what the whole thing costs in performance (there are hard measurements), and where research has knocked cracks into the wall over the past two years. What remains at the end is a sober assessment: confidential computing relocates trust; it does not abolish it.

Part 1: What Exactly Is Being Claimed

The definition

The Confidential Computing Consortium — a Linux Foundation project in which AMD, Intel, ARM, Google, Microsoft and Red Hat, among others, collaborate — has settled on a terse definition: Confidential computing is the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment.

Every word in that sentence carries weight. Hardware-based: the guarantee comes not from an operating system or a library but from mechanisms in the processor. Attested: there is a cryptographic proof that the environment really is what it claims to be — without that proof, the encryption is worthless, which we come to in Part 3. Trusted Execution Environment (TEE): the shielded region itself.

The three mandatory properties of a TEE

According to the Consortium, an environment may only call itself a TEE if it assures three properties:

Data confidentiality: Unauthorized parties cannot view the data while it is being processed inside the TEE.

Data integrity: Unauthorized parties cannot add, remove or alter the data while it is in use.

Code integrity: Unauthorized parties cannot add, remove or alter the code running inside the TEE.

That is more precise than it first appears. Confidentiality alone would be worth little. An attacker who cannot read memory but can arbitrarily modify it can bend the computation until it reveals the result on its own. This is precisely why the relevant AMD technology is called SEV-SNP — Secure Nested Paging — and no longer merely SEV: the first generation of AMD's Secure Encrypted Virtualization encrypted guest memory but did not protect it against manipulation by the hypervisor. AMD's own white paper from January 2020 is titled Strengthening VM Isolation with Integrity Protection and More — that appended word "Integrity" is the whole story.

Optional, but not guaranteed, further properties may be added: code confidentiality (the algorithm itself also stays secret), authenticated launch, attestability, and recoverability.

What is explicitly not protected

Here things get interesting for practice, and here the Consortium is remarkably honest. In scope of the threat model are: software attacks on the host operating system, hypervisor and firmware; protocol attacks on attestation; cryptographic attacks; basic physical attacks such as cold DRAM extraction, bus or cache monitoring, and attack devices plugged into ports; and gross supply-chain manipulations such as added debug ports.

Out of scope are: sophisticated physical attacks requiring invasive hardware access over longer periods; supply-chain attacks further upstream, for instance at chip manufacturing or key injection time; and availability attacks. That last point matters and is often overlooked: a TEE protects your data from being read or falsified — it does not protect your VM from simply being switched off by the operator. The hypervisor remains master over compute time, memory allocation and lifetime.

And then there is one further assumption, which the document itself flags as challenged by research: the model assumes there are no exploitable side channels. Part 5 of this article is about exactly that.

Part 2: How the Hardware Does It

There are roughly two generations of TEEs, and the shift between them explains why confidential computing is only now arriving at scale.

The first generation: enclaves within a process

Intel's SGX (Software Guard Extensions, from 2015) was the most prominent representative of the enclave model: an application creates a small, specially protected memory region in which only a carefully minimized portion of its code runs. That yields a very small trusted computing base — the amount of code you must trust is tiny, which is ideal in security theory.

In practice it was an imposition. Existing applications did not simply run in an enclave; you had to split them, marshal system calls across a boundary, live with tight memory limits. For the overwhelming majority of real workloads — a database, an application server, an ML training run — the rework cost was prohibitive.

The second generation: the whole VM as the protected room

Today's relevant answer is the confidential VM (CVM): not a piece of code is shielded but an entire virtual machine including its own operating system kernel. The deal is exactly the inverse of SGX: the trusted computing base becomes large (the whole guest OS is inside it, with all its holes), but the rework cost falls to nearly zero — an unmodified Linux server runs inside.

The two market-dominating implementations are AMD SEV-SNP and Intel TDX (Trust Domain Extensions). A thorough survey of both platforms published by Masanori Misono, Dimitrios Stavrakakis, Nuno Santos and Pramod Bhatotia (TU Munich and INESC-ID Lisbon, published in 2024 in the Proceedings of the ACM on Measurement and Analysis of Computing Systems) compared the architectures and their costs systematically for the first time. Their findings form the backbone of the next two sections.

Memory encryption: who holds the key?

The basic mechanism is the same in both cases: a memory controller in the processor transparently encrypts and decrypts memory pages on the way between CPU cache and DRAM, with a key that is unique per VM and that software never gets to see. If the hypervisor reads a page of the guest, it obtains ciphertext.

The paths differ in detail:

• SEV-SNP marks via a special bit in the guest physical address (the C-bit) whether a page is encrypted or deliberately shared. Key management is handled by the AMD Secure Processor, an ARM-based coprocessor on the CPU die.
• TDX uses a shared bit and two nested page tables — one for shared, one for private memory (the secure EPT) — with different key IDs per trust domain. On top of that comes a new CPU mode called SEAM, in which a trusted software component runs: the TDX module.

That is a philosophical difference that matters in practice: AMD moves the trust anchor into a separate hardware coprocessor, Intel into signed firmware shipped by Intel that runs in a privileged CPU mode. Both variants have their friends; the TDX module is updatable (good against vulnerabilities, but one more component you must trust), the Secure Processor is more rigid.

Integrity protection: bookkeeping over page ownership

Encryption alone prevents no rewriting. A hypervisor could swap encrypted pages, duplicate them, or replay an old version. Against that you need tamper-proof bookkeeping over which physical page belongs to which guest at which guest physical address.

• SEV-SNP introduces the Reverse Map Table (RMP) for this — a table the hypervisor cannot write, mapping each host physical page to its owner and the expected guest physical address. Every memory access is checked against the RMP. If a page is re-pointed behind the guest's back, the check fails.
• TDX uses a Physical Address Metadata Table (PAMT) plus a TD-Owner bit and message authentication codes per cache line.

Both architectures add a rule you learn early when debugging CVMs: the guest must explicitly accept memory (memory acceptance) before it may use it. This prevents the hypervisor from slipping foreign pages to the guest after the fact — and is, as we shall see, one of the main reasons for long startup times.

Part 3: Attestation — the Actual Core

Here comes the point at which confidential computing is usually misunderstood in practice. The encryption is not the interesting part. The interesting part is the question: how do I know my data ended up in a TEE at all?

Imagine you send your secrets into a VM the provider sells you as "confidential." If you demand no proof, it may just as well be an entirely ordinary VM with someone reading along. The entire security property hangs on a cryptographic proof that the hardware produces about itself and about the loaded code — and on your willingness to check that proof before transmitting the secrets. Confidential computing without verified attestation is theater.

The roles: RFC 9334

In 2023 the IETF created, with RFC 9334 (Remote ATtestation procedureS (RATS) Architecture, by Birkholz, Thaler, Richardson, Smith and Pan, informational), a vocabulary that is now used across vendors. It separates cleanly between:

Crucial is the separation of Evidence (raw measurements) from Attestation Result (an appraised verdict). Only this allows the difficult appraisal logic to be delegated to a specialized service, so that not every application must itself understand chip vendor certificate chains.

RFC 9334 describes two topological patterns whose names have stuck:

Passport model: The Attester itself obtains an Attestation Result from a Verifier and presents it to Relying Parties — like a passport issued by a trusted authority. The Relying Party treats it as opaque data.

Background-check model: The Attester sends its Evidence to the Relying Party, which forwards it unprocessed to the Verifier and receives the verdict back — like an employer verifying credentials with the issuing institution.

Freshness: the underrated problem

An attestation proof without a time reference is useless, because an attacker could replay an old, legitimate one. RFC 9334 names three mechanisms: explicit timekeeping with synchronized clocks and signed timestamps (delicate in TEEs, because the clock typically sits outside the trust boundary), implicit timekeeping with a nonce (the appraiser sends an unpredictable random value that must be covered by the signature), and epoch IDs (a distributor periodically sends epoch identifiers to all parties, which avoids per-Attester state). In practice, the nonce dominates.

What it looks like concretely

On SEV-SNP, the Secure Processor signs the attestation report with a chip-specific key, the VCEK (Versioned Chip Endorsement Key); it is verified through AMD's certificate chain. On TDX, the report is initially only MAC-protected and is converted by an SGX-based Quoting Enclave into a signed quote verifiable through Intel's certification services — a nice detail: Intel's new VM technology inherits its trust anchor from the older enclave technology.

In both cases the report contains measurements of the loaded guest boot state (firmware, kernel, initrd, command line) as well as configuration flags — for instance whether debugging is permitted. Checking exactly those flags is in practice the most common failure mode: a report that is cleanly signed but says "debug allowed" is not a security proof.

Part 4: What It Costs — the Measurements

This is where people usually guess. Misono and colleagues measured, on Linux 6.8 and the then-current vendor stacks. The numbers are clear and instructive — and above all they show where the costs arise.

Three patterns can be derived from this.

First: the memory encryption itself is cheap. Roughly 16 nanoseconds of additional latency and single-digit percentages in memory benchmarks — that is the price of AES in the memory path, and it is remarkably low. Anyone who believes confidential computing is expensive "because everything gets encrypted" is looking at the wrong cause.

Second: the transitions are expensive. Every switch between guest and hypervisor — a VM exit — costs several times as much in CVMs, because registers must be saved, states switched and checks run. That hits precisely the workloads which generate many such transitions: network I/O above all. In combination with the second cost driver — copying through bounce buffers, because DMA devices may not write directly into encrypted guest memory — the authors measure, for UDP traffic at low CPU utilization, roughly 75% overhead on SEV-SNP and 81% on TDX, and for TCP under high CPU load throughput drops of up to about 60%.

Third: the startup costs are one-time but severe. Explicit memory acceptance and host-side bookkeeping make the first-time allocation of large memory amounts considerably more expensive; afterwards, behavior normalizes to roughly 5% off a normal VM. For long-lived servers that is irrelevant. For a model of "start a fresh confidential VM per request" — an obvious design for confidential inference — it is a serious problem. For compute workloads, the authors measure with NPB and passive OpenMP waiting an average of +41% (SEV-SNP) and +73% (TDX), with an extreme case of +431% on TDX; active polling in the guest reduces these costs considerably because it avoids transitions.

An important caveat from the authors themselves: these numbers hold for specific hardware, specific kernel and firmware versions, and a then still very young software ecosystem. The orders of magnitude remain instructive; the exact percentages age quickly.

Part 5: The Cracks in the Wall

Confidential computing has a property rarely seen so clearly in security technologies: the threat model is extremely aggressive. It assumes the hypervisor is malicious — not merely buggy, but an active, privileged attacker with full access to hardware management. That is an enormous claim, and security research has systematically probed it in recent years. Two works by the same group at ETH Zurich show particularly well where the fracture points lie.

Heckler: attacking through the doorbell

Benedict Schlüter, Supraja Sridhara, Mark Kuhne, Andrin Bertschi and Shweta Shinde presented an attack named Heckler at the 33rd USENIX Security Symposium in 2024. The observation behind it is strikingly simple: the hypervisor is still allowed to deliver interrupts to the guest — this is necessary for the guest to work with the outside world at all. But the guest kernel cannot distinguish an injected interrupt from a genuine one. It runs the corresponding handler. And handlers have side effects on registers and program state.

The attack: the hypervisor waits (precisely timed via page-fault tracing) for a specific point in the victim program's execution and injects a deliberately chosen interrupt there.

The showcase example is int 0x80, Linux's legacy system-call entry. This handler reads eax as the call number and writes the result back to eax. If the attacker injects it exactly when eax contains 0, the result becomes a non-zero value. And now the punchline: inject this right after auth_password returns in OpenSSH, and the return value "wrong password" becomes "correct password" — authentication with an arbitrary password, equally on SEV-SNP and TDX. The same principle applied to sudo, against the return value of PAM's blank-password check, elevates an unprivileged user to root. Both attacks chained — first a shell via SSH, then root via sudo — amount to a complete takeover of the supposedly protected VM.

On SEV-SNP the authors additionally found that floating-point exceptions (int 0x0, 9, 16) propagate into user space as SIGFPE, where application-owned signal handlers can be abused as gadgets; they demonstrated falsified results in a Java statistics tool, a Julia text-analysis package and a C neural network — a pure integrity breach, without ever having read memory.

The mitigation for int 0x80 (CVE-2024-25744) is a kernel patch that disables IA32 emulation by default in SEV and TDX guests. For the remaining interrupts (CVE-2024-25743) the authors argue that software cannot in principle make the distinction and that hardware filtering is required — as TDX already partly implements for interrupts below 31. That TDX fared better here was less luck than design.

Heracles: when determinism becomes an oracle

Even more fundamental is Heracles, presented at ACM CCS in 2025 by Benedict Schlüter, Christoph Wech and Shweta Shinde. It targets a property of the memory encryption itself.

SEV-SNP encrypts with AES-XEX and a tweak derived from the physical DRAM address. That is a good idea: it means the same plaintext at different addresses yields different ciphertexts, so you cannot simply compare blocks across memory. But the tweaks are static over the guest's lifetime — and therefore the encryption at a given address is deterministic: the same plaintext at the same address always yields the same ciphertext.

The hypervisor can read ciphertext (that is permitted) and move encrypted guest pages within DRAM through management APIs (that is necessary). When a page is moved, it is re-encrypted with the tweak of its new location. From this the authors build a plaintext oracle: the attacker places a guessed value in a page it controls, moves that page to the victim's former address, and compares the resulting ciphertext with a previously stored snapshot. If it matches, the guess was right.

A full 16-byte block cannot be brute-forced this way. Using four primitives that exploit byte-by-byte copy operations, chosen data offsets, and repeated or incrementing values, the authors shrink the search to roughly one byte at a time. They demonstrated the extraction of kernel memcpy data, bash and sudo passwords, mbedtls exponents (and thus keys) and Mongoose session cookies — at roughly 0.5 to 2.5 seconds per byte. AMD's response came as a feature change in SEV-SNP ABI 1.58, not as a CVE.

What one should learn from this

I am of the opinion that the right reading of these works is not "confidential computing is broken" but something more specific: the interfaces are the problem, not the cryptography. In neither case was AES too weak. In one attack it was the interrupt channel, in the other the memory management API — that is, precisely those places where the TEE must still necessarily talk to the untrusted hypervisor.

This is a recurring pattern in computer architecture: the confidentiality guarantee holds for the data path, but computers do not consist only of data paths. They have control paths, microarchitecture, timing behavior, state management. Anyone familiar with When the Processor Guesses Too Much: Spectre, Meltdown, and the Sin of Speculative Execution recognizes the kinship immediately: there it was speculative execution that undercut a formally correct isolation through its observable timing behavior. Bits That Flip on Their Own: Rowhammer and the Physical Weakness of Computer Memory belongs in the same family — memory does not keep its abstraction if you provoke it physically enough. The Consortium's threat model explicitly assumes there are no exploitable side channels; that assumption is not satisfied but merely a state renegotiated with every patch.

Part 6: Why It Is Still Worth It

If the promise is cracked — why the effort? The answer lies in a sober look at what confidential computing actually works well against.

The three scenarios that genuinely hold up

First: reducing liability and access, not attack resistance. The most common real benefit is not fending off a state-funded adversary but eliminating whole classes of access opportunities: the curious administrator, the misconfigured monitoring tool, the memory dump that accidentally lands in a support ticket, the snapshot in a backup. Against opportunistic and negligent access the technology works very well — and statistically that is what actually happens.

Second: multi-party computation under mutual distrust. Two hospitals want to analyze their patient cohorts jointly without handing each other the raw data. Two banks want to correlate fraud patterns. Here the TEE is a neutral third party made of silicon: both parties attest which code runs there and send their data only once the proof checks out. It is notable that this is exactly the same problem that Proving Without Revealing: Zero-Knowledge Proofs from Ali Baba's Cave to zk-SNARKs solves by purely mathematical means — and likewise the one that The Noise That Protects Privacy: Differential Privacy and the Art of Revealing Nothing About the Individual approaches statistically. Three technologies, three trust anchors: hardware, mathematics, statistics. The hardware variant is by far the most performant and by far the most assumption-laden.

Third: confidential inference and model protection. Anyone wanting to run a language model on someone else's infrastructure has two secrets to protect: the user inputs and the model weights. Confidential computing is currently the only way to address both at once without making the computation orders of magnitude more expensive — which is why extension to GPUs (a confidential mode with encrypted host-to-GPU transfer) is the most closely watched line of development right now.

Operational reality

Three things decide in practice whether a CVM project succeeds or fails, and none of them is the encryption:

Attestation must be enforced, not merely available. If your secret management hands out keys before it has seen a valid, fresh report checked against reference values, you have a nice checkmark on the compliance list and no security property. The correct sequence is always: VM starts → attests → only then receives its keys from a key management service that verifies the attestation.

The reference values must be reproducible. A report delivers measurements of firmware, kernel and initrd. You must know which values are correct — that is, have reproducible builds or at least a reliable supply chain for the reference values. Here, interestingly, the circle closes to The Tree That Condenses Truth: Merkle Trees and the Art of Efficient Integrity Verification: transparency logs over published reference measurements are the obvious way to solve this problem vendor-independently, and that is exactly the path current architectures for confidential AI services take.

The trusted computing base stays large. In a CVM the entire guest kernel is inside the trust boundary. A hole in the guest kernel is a hole in the TEE. Confidential computing protects you from the operator — not from yourself. Anyone serious about shrinking the attack surface combines CVMs with minimal guest images of the kind that have become established around Betting on a Stranger's Code: Firecracker microVMs and the End of the Container-versus-VM Dilemma.

A comparison table for orientation

Part 7: The Overarching Design Principle

Step back, and confidential computing is less an encryption technology than a relocation of the trust anchor. Before, you had to trust the operator: its staff, its processes, its hypervisor, its data center access. Afterwards you must trust the chip vendor: its silicon design, its firmware, its certificate chain, its key injection during manufacturing — and your own guest image.

That is indisputably progress, because the new trust base is smaller, more uniform and more verifiable. A certificate chain can be verified; the integrity of a data center operation can only be attested to by witness. But it is precisely not "zero trust" in the literal sense, and the marketing phrase "no longer having to trust anyone" is false. Trust in distributed systems is not a quantity you eliminate — it is a quantity you relocate, shrink and make checkable.

The same pattern appears wherever security is taken seriously: The Key That Dies After Every Message: The Signal Protocol, the Double Ratchet, and the Art of End-to-End Encryption moves trust from the server operator to the conversation partners' devices without abolishing it. Harvest Now, Decrypt Later: Post-Quantum Cryptography and the Race Against the Quantum Computer moves it from one mathematical hardness problem to another that one hopes will hold up longer. The honest question is never "do I trust?" but always: "whom exactly, for what, and how would I notice that the trust had been broken?"

The Central Takeaway

The practical lesson fits in one sentence: confidential computing is only as strong as the attestation you actually enforce — and only as strong as the smallest guest image you run inside it.

Concretely, for any assessment of such an architecture, this means asking three questions, in this order:

1. Is attestation performed, and before key release? If secrets flow before a fresh report checked against known reference values exists, the technology is decoration. Check the configuration flags explicitly, not just the signature.
2. Who is the verifier, and whose reference values apply? If the same provider you want protection from is also the verifier and sets the reference values, you have not relocated the trust, only renamed it.
3. How large is the trusted computing base inside the guest? Every package in the guest image is part of your TEE. A full general-purpose Linux in a confidential VM is an improvement over a normal VM, but not a hermetic room.

And as expectation management: count on single-digit percentage costs for memory-heavy and high double-digit costs for network-heavy workloads, on considerably longer startup times, and on attack research continuing. Confidential computing raises the cost of an attack by the operator from "a configuration change" to "a publishable research paper." That is a great deal. It is not infinite.

A Question to Reflect On

Confidential computing solves the problem of not wanting to trust the operator by shifting trust to the chip vendor — to a company whose silicon design you cannot inspect, whose fabrication you cannot audit and whose key injection you cannot verify. At the same time, Heckler and Heracles show that this trust base, too, has gaps that only became visible through external research.

So if trust in distributed systems never disappears but merely changes address: by what criterion do you actually decide which address is better? Is it the size of the component to be trusted, the number of independent auditors, the speed at which vulnerabilities become public — or simply the question of whose interests align best with your own? And where in your own architecture have you placed a trust whose breach you would not even notice?

Cross-References in the Vault

• When the Processor Guesses Too Much: Spectre, Meltdown, and the Sin of Speculative Execution – the microarchitectural prototype of the same problem: formally correct isolation undercut by side channels.
• Bits That Flip on Their Own: Rowhammer and the Physical Weakness of Computer Memory – what happens when memory does not keep its own abstraction; relevant to the physical threat model of TEEs.
• Proving Without Revealing: Zero-Knowledge Proofs from Ali Baba's Cave to zk-SNARKs – the same goal (computing without revealing) with mathematics rather than hardware as the trust anchor.
• The Noise That Protects Privacy: Differential Privacy and the Art of Revealing Nothing About the Individual – the statistical approach to the same tension between utility and confidentiality.
• The Tree That Condenses Truth: Merkle Trees and the Art of Efficient Integrity Verification – the data structure behind transparency logs for attestation reference values.
• Betting on a Stranger's Code: Firecracker microVMs and the End of the Container-versus-VM Dilemma – isolating foreign code on shared infrastructure, the complementary question.
• The Key That Dies After Every Message: The Signal Protocol, the Double Ratchet, and the Art of End-to-End Encryption – relocating trust from the operator to the endpoints.
• Harvest Now, Decrypt Later: Post-Quantum Cryptography and the Race Against the Quantum Computer – how durable the cryptographic assumptions are on which attestation chains also rest.

Sources

• Confidential Computing Consortium (2021): A Technical Analysis of Confidential Computing, Version 1.2, October 2021 (errata release dated 2021-09-28). Linux Foundation. https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf
• Birkholz, H., Thaler, D., Richardson, M., Smith, N., Pan, W. (2023): Remote ATtestation procedureS (RATS) Architecture. RFC 9334, IETF, January 2023 (Informational). https://www.rfc-editor.org/rfc/rfc9334.html
• Misono, M., Stavrakakis, D., Santos, N., Bhatotia, P. (2024): Confidential VMs Explained: An Empirical Analysis of AMD SEV-SNP and Intel TDX. Proceedings of the ACM on Measurement and Analysis of Computing Systems 8(3), Article 36. DOI: 10.1145/3700418. https://dl.acm.org/doi/10.1145/3700418
• Schlüter, B., Sridhara, S., Kuhne, M., Bertschi, A., Shinde, S. (2024): Heckler: Breaking Confidential VMs with Malicious Interrupts. Proc. 33rd USENIX Security Symposium, Philadelphia. https://www.usenix.org/system/files/usenixsecurity24-schluter.pdf
• Schlüter, B., Wech, C., Shinde, S. (2025): Heracles: Chosen Plaintext Attack on AMD SEV-SNP. Proc. ACM Conference on Computer and Communications Security (CCS '25), Taipei. https://heracles-attack.github.io/Heracles-CCS2025.pdf
• AMD (2020): AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More. White Paper, January 2020 (document 70366). https://docs.amd.com/v/u/en-US/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more

← All articles