Threat Model & Security Boundaries

This threat model is the main driver behind Lunal's architecture. We designed our platform around the principle that even our own infrastructure shouldn't be able to see customer data.

This document explains what confidential computing protects against and what it doesn't. After reading it, you'll understand where the trust boundaries lie, what an attacker with hypervisor control can and cannot do, and which guarantees you actually get from the hardware. This assumes you're comfortable with basic virtualization concepts (VMs, hypervisors, memory) but doesn't require any prior knowledge of confidential computing.

The Security Guarantees

SEV-SNP provides three guarantees. Understanding what each means, and what it doesn't mean, is essential for reasoning about what the technology actually gives you.

Confidentiality. Guest memory is encrypted with a per-VM key that the hypervisor cannot access. Register state is encrypted when the VM exits to the hypervisor. The hypervisor sees ciphertext, not plaintext. This is a cryptographic guarantee: breaking it requires breaking AES-128 or compromising AMD's key management.

Integrity. The hardware detects if the hypervisor tampers with guest memory. Substituting pages, replaying old data, or remapping addresses all trigger faults the guest can catch. The hypervisor cannot silently corrupt guest state. This is also a cryptographic guarantee, enforced by hardware checks on every memory access.

Attestation. The guest can prove to a remote party what code it's running. AMD's security processor measures the initial guest image and signs a report with a key rooted in the silicon. A verifier can check this signature against AMD's certificate chain to confirm the report came from real hardware, not from software pretending to be a confidential VM.

SEV-SNP does not provide availability. The hypervisor controls whether your VM runs, and can terminate it at any time. This is architectural: you can't enforce availability against someone who controls the power switch.

Who You Trust

SEV-SNP narrows the set of entities you must trust. Here's the explicit list.

You trust AMD. You trust that AMD's manufacturing process didn't embed backdoors in the silicon. You trust that AMD's key management practices keep root keys secure. You trust that the Platform Security Processor (PSP) firmware doesn't have exploitable vulnerabilities. You trust that AMD's key distribution service serves authentic certificates.

You trust the cryptographic primitives. AES-128 for memory encryption, ECDSA P-384 for attestation signatures, SHA-384 for measurements. If these break, the guarantees break.

You trust the physical host of the hardware. There is a class of non-trivial physical attacks, requiring specialized hardware and knowledge, that can break TEE security. Who ever physically hosts the hardware can implement these attacks.

You trust your own software. SEV-SNP protects the execution environment, not the code running in it. If your kernel has a vulnerability, an attacker can exploit it. Attestation proves what code loaded, not that the code is correct.

Who You Don't Trust

The value of SEV-SNP comes from what you no longer need to trust.

You don't trust the cloud provider's software stack. The hypervisor, host OS, management plane, orchestration systems, and monitoring agents are all outside the trust boundary. They can be compromised, malicious, or buggy without affecting the confidentiality or integrity of your guest.

You don't trust the cloud provider's employees. Administrators with root access to the hypervisor, datacenter technicians with physical access to servers, and anyone in the operational chain cannot read your guest's memory or tamper with it undetected.

You don't trust other tenants. Even if another VM on the same physical host is compromised and escalates to hypervisor level, it cannot access your guest's data.

You don't trust the network or storage infrastructure. Data leaving the encrypted memory boundary (to disk, to network) passes through untrusted channels. You use software encryption (TLS, LUKS) to protect it there. SEV-SNP protects data while it's being processed in memory.

The Traditional Trust Model

In conventional virtualization, a guest virtual machine trusts everything below it. The guest trusts the hypervisor to correctly isolate it from other guests. The hypervisor trusts the host operating system to manage hardware resources fairly. The entire stack trusts the hardware to execute instructions correctly. This forms a hierarchy where each layer assumes the layers beneath it are honest.

This model works fine when you control the infrastructure. If you own the physical server, you trust it because you trust yourself. But cloud computing inverts this: you're running on someone else's hardware, managed by someone else's software, operated by someone else's employees. The traditional trust model asks you to trust all of them.

Cloud providers implement extensive security controls: employee background checks, access audits, network segmentation, encrypted storage. These are meaningful and reduce risk. But they don't change the fundamental architecture: the hypervisor has complete visibility into and control over your VM's memory, registers, and execution.

The Adversarial Hypervisor

SEV-SNP treats the hypervisor as adversarial. This isn't a statement about cloud provider intentions. It's a design principle: assume the worst-case attacker has full control of the hypervisor and host OS, then design hardware that protects the guest anyway.

What does "full hypervisor control" mean in practice? The attacker can read and write any region of host memory. They can inspect and modify the nested page tables that translate guest physical addresses to system physical addresses. They can control which physical pages back the guest's memory. They can intercept and inject interrupts. They can pause, resume, snapshot, and migrate the VM at will. They control the I/O devices the guest thinks it's talking to.

In traditional virtualization, this level of access means total compromise. The attacker can dump the guest's memory, extract encryption keys, modify code in flight, and observe every piece of data the guest processes. SEV-SNP's goal is to make most of these attacks impossible despite the attacker having this level of access.

What SEV-SNP Protects Against

SEV-SNP provides hardware-enforced protections against a specific set of attacks. The protections fall into two categories: memory confidentiality and memory integrity.

Memory Confidentiality

Reading guest memory. The memory controller encrypts all guest memory with a per-VM key (the VEK, VM Encryption Key) that only the AMD security processor knows. When the hypervisor reads a guest's memory region, it gets ciphertext. The encryption is AES-128 with a physical-address-based tweak, meaning the same plaintext encrypts differently at different addresses. The hypervisor cannot derive the key: it's generated by hardware, stored in hardware, and never exposed to any x86 software.

Inspecting register state. When a VM exits to the hypervisor (for interrupt handling, I/O, etc.), traditional virtualization stores the guest's register state in a memory structure the hypervisor reads. SEV-SNP encrypts this save area (called the VMSA) with the guest's VEK. The hypervisor can trigger VM exits but cannot read the register values.

Memory Integrity

Modifying guest memory. Encryption alone doesn't prevent modification attacks. An attacker who can't read your data might still corrupt it strategically. SEV-SNP adds the Reverse Map Table (RMP): a hardware structure that tracks which VM owns each physical page and what guest address it should map to. Every memory access by a guest triggers an RMP check. If the hypervisor modifies the page contents, the guest gets cryptographic garbage (wrong key). If the hypervisor tries to substitute a different physical page, the RMP check fails because the expected guest address won't match.

Replaying old memory contents. Without integrity protection, an attacker could snapshot a guest's memory, let it run for a while, then restore the old snapshot. This could revert security-critical state (nonces, sequence numbers, key material). The RMP validation mechanism prevents this: each page has a "validated" bit that the guest sets after verifying the page. If the hypervisor swaps in a page from an old snapshot, it won't have the validated bit set, and the hardware rejects the access.

Remapping guest addresses. The hypervisor controls the nested page tables that translate guest physical addresses (GPAs) to system physical addresses (SPAs). Without protection, it could silently remap GPA 0x1000 from pointing at physical page A to pointing at physical page B. SEV-SNP prevents this by storing the expected GPA in each RMP entry. The hardware checks that the GPA from the page table walk matches the GPA recorded in the RMP. A mismatch causes a fault.

What SEV-SNP Does NOT Protect Against

The security boundary has clear limits. These aren't weaknesses to be fixed in a future version. They're architectural constraints that follow from what confidential computing is trying to achieve.

Availability and Resource Control

Denial of service. The hypervisor can always refuse to schedule your VM. It can terminate your VM at any time. It controls the power and the physical resources. SEV-SNP protects confidentiality and integrity, not availability. If you need guaranteed uptime, you need operational controls (SLAs, redundancy, multi-cloud), not hardware encryption.

Resource starvation. The hypervisor controls CPU scheduling, memory allocation, and I/O bandwidth. It can slow your VM to a crawl without technically killing it. Timing-sensitive workloads remain vulnerable to performance interference.

Information Leakage Channels

Side-channel attacks. The CPU still shares microarchitectural state between the guest and the hypervisor. Cache timing, branch prediction, power analysis, and electromagnetic emissions can leak information. AMD has added mitigations for some attacks (separate branch prediction state, cache partitioning options), but side channels remain an active research area. SEV-SNP significantly raises the bar compared to unprotected VMs, but it doesn't eliminate all side-channel risk.

I/O visibility. I/O devices sit outside the encrypted memory boundary. When the guest reads from disk or sends network traffic, that data passes through shared memory regions the hypervisor can observe. Guests typically use software encryption (TLS, LUKS) to protect data in transit and at rest. SEV-SNP protects data while it's being processed in memory, not while it's moving through I/O channels.

Interrupt timing. The hypervisor controls when interrupts are delivered. Even with restricted injection mode, a malicious hypervisor can observe timing patterns: when the guest handles interrupts, how long operations take, what the guest is doing when it's interruptible. This is a form of side channel.

Software Vulnerabilities

Bugs in guest code. SEV-SNP protects the execution environment, not the software running in it. If your application has a buffer overflow, an attacker who can send it malicious input can exploit it. The attacker might be the cloud operator sending data through a network interface, or it might be a legitimate user whose requests happen to trigger the bug. The hardware can't tell the difference between intended and malicious computation.

Compromised guest images. Attestation proves that a specific set of code was loaded at boot. It doesn't prove that code is correct, secure, or does what you want. If you deploy a backdoored kernel, attestation faithfully reports the backdoored kernel's measurement. The verifier needs to know what measurements to expect and trust that those measurements correspond to trustworthy software.

Physical Attacks

Memory Interposer attacks. If an attacker can physically freeze the DRAM and move it to another system, they might recover data. SEV-SNP's encryption happens in the memory controller on the CPU die; once data leaves the CPU package and sits in DRAM, it's encrypted. However, sophisticated physical attacks against DRAM (voltage glitching, probing) are an active research area. SEV-SNP raises the bar significantly compared to unencrypted memory, but it's not designed to resist nation-state-level hardware attacks.

Hardware tampering. If an attacker can modify the CPU itself, replace the memory controller, or intercept signals on the CPU package, all bets are off. SEV-SNP assumes the CPU die is intact. Protecting against supply chain attacks on the silicon is outside its scope.

Trust Anchor Compromise

Compromised AMD hardware or firmware. The trust anchor is AMD's security processor and the keys fused into the silicon at manufacturing. If AMD's manufacturing process is compromised, or if the security processor firmware has vulnerabilities, the guarantees break. This is a much smaller attack surface than "trust the entire cloud stack," but it's not zero. You're trading trust in your cloud provider for trust in AMD.

The Trust Anchor

Every security system has a root of trust: something you assume is correct because you can't verify it further down. In SEV-SNP, the trust anchor is AMD's Platform Security Processor (PSP) and the cryptographic keys fused into the CPU during manufacturing.

The PSP is an ARM core embedded in the AMD processor die. It runs its own firmware, independent of the x86 cores running your hypervisor and guests. It generates the per-VM encryption keys, manages attestation, and enforces security policies. The PSP has access to hardware key material that no x86 software, at any privilege level, can read.

Attestation reports are signed by a key derived from fuses in the silicon: the VCEK (Versioned Chip Endorsement Key). AMD's key distribution service provides certificates that chain back to AMD's root certificate. A verifier checks this chain to confirm that the attestation report really came from an AMD processor, not from software pretending to be one.

This design means you're trusting: (1) AMD's manufacturing process didn't embed backdoors in the silicon, (2) AMD's key management practices keep the root keys secure, (3) the PSP firmware doesn't have vulnerabilities that allow bypass, and (4) the cryptographic primitives (AES, ECDSA, SHA) remain secure. These are meaningful assumptions, but they're substantially narrower than trusting every layer of a cloud provider's software stack.

Summary

SEV-SNP shifts the trust boundary from "trust the cloud provider's entire stack" to "trust AMD's silicon." The hypervisor is treated as adversarial: it can observe and manipulate the VM's external interfaces but cannot read memory, registers, or corrupt pages without detection. The protection is enforced by hardware (the memory controller's encryption engine and the RMP) using keys the hypervisor never sees.

The boundaries are precise. You get strong confidentiality and integrity for data in memory during processing. You don't get availability guarantees, side-channel immunity, or protection against bugs in your own code. The trust anchor is AMD's manufacturing and key management; if those fail, the guarantees fail.

Understanding these boundaries is essential for reasoning about what confidential computing actually gives you. The following documents explain how the hardware enforces these boundaries: how encryption works, how the RMP provides integrity, how guests communicate with the hypervisor safely, and how attestation lets you verify the whole thing.

Lunal's platform is built on this threat model. Our infrastructure services—firewalls, load balancers, routing—run in TEEs themselves. We can't see your data, and you don't have to trust that we won't look. The hardware enforces it.