Confidential computing for microVMs: SEV-SNP, TDX, and arm CCA explained

I build PandaStack, where every sandbox, database, and hosted app is a Firecracker microVM, so I spend a lot of time explaining isolation boundaries. The question security reviewers ask most — usually phrased as "is the memory encrypted?" — is actually about a completely different technology than the one they think they're asking about. Firecracker, KVM, jailer, seccomp: that entire stack exists to protect the host from the guest. Confidential computing — AMD SEV-SNP, Intel TDX, arm CCA — exists to protect the guest from the host. Same silicon, adjacent acronyms, opposite arrows. This is the explanation I end up giving, written down: what these features do at the hardware level, what they emphatically do not do, what they cost you, and the honest answer to "do I need this?" (usually: no).

The inversion: who is protected from whom

Standard hardware virtualization gives you a wall, and the wall has a direction. The guest runs its own kernel under the CPU's virtualization extensions, with a second layer of address translation it cannot touch, so guest code can't form a pointer into host memory — it can only trap out on a narrow, defined path. Every layer Firecracker adds on top hardens the same direction: the tiny virtio device model, the memory-safe Rust VMM, the jailer's chroot and dropped privileges, seccomp on the VMM's own syscalls. The guest is assumed hostile. The host is assumed trustworthy, because the host is you.

Now flip the assumption. What if the host isn't you? The hypervisor sets up the guest's memory, so it can read it. It can dump RAM to a file, pause the guest mid-instruction and read its registers, remap a page under its feet, or snapshot the whole machine and study it at leisure on a workbench. None of that is a vulnerability — it's the hypervisor's job description. Which means that on infrastructure you don't own, "my data is in a VM" says nothing about whether the operator can read your data. Historically the answer was: of course they can, and your only controls were a contract, an audit log, and someone's word.

Confidential computing replaces that word with a hardware guarantee. The goal is to shrink a running VM's trusted computing base down to roughly "the CPU vendor's silicon and firmware, plus my own guest image" — deliberately excluding the hypervisor, the host kernel, the cloud's management plane, and every human with a badge that opens the cage door.

What the hardware actually does

All three major implementations do two things, in different ways with different names: they encrypt guest memory with a key the host cannot access, and they let the guest prove to a remote party what it is. Everything else is detail — but the detail matters, so treat the sketches below as shape rather than spec, and verify against the vendor's current documentation. This area moves fast and the errata are load-bearing.

AMD SEV-SNP

AMD's line evolved in stages. SEV encrypted guest memory with a per-VM key held by a separate on-chip security processor, so a host reading the guest's DRAM got ciphertext. SEV-ES extended that to the guest's register state at VM exit, closing off the trick of reading secrets out of the CPU registers the moment the guest trapped. SEV-SNP — Secure Nested Paging — added the piece that made the whole thing defensible: memory integrity. Encryption stops the host reading pages, but not from moving them around, aliasing two guest-physical addresses onto one page, or replaying an old ciphertext into a location the guest later reads. SNP adds a hardware-tracked structure, the Reverse Map Table, recording for each page which guest owns it and at which guest-physical address — so a host-controlled remap, alias, or replay is detected rather than silently succeeding. It also provides hardware-rooted attestation reports signed by a chain leading back to AMD.

Intel TDX

Intel's Trust Domain Extensions wrap the guest in what Intel calls a Trust Domain. The architectural difference worth understanding is that TDX interposes an Intel-signed, hardware-loaded software component — the TDX module — between the untrusted hypervisor and the trust domain. The hypervisor still schedules and resources the VM, but it does so by calling into that module rather than touching the guest directly, and the module enforces the confidentiality and integrity rules. Memory is encrypted with per-domain keys via the platform's multi-key encryption engine, with integrity protection, and attestation arrives as a signed quote a relying party verifies against Intel's certification services. The upshot matches AMD's: the host operates the VM without being able to read inside it.

arm CCA and Realms

arm's Confidential Compute Architecture, introduced with Armv9-A's Realm Management Extension, adds a new world — the Realm world — alongside the existing normal and secure worlds. A Realm's memory is protected from the normal-world hypervisor by hardware granule protection, and a small trusted Realm Management Monitor mediates the hypervisor's requests, playing a role broadly analogous to Intel's TDX module. Conceptually it lands in the same place as the other two. Practically it's the newest of the three, and the gap between "the architecture specifies it" and "you can rent it by the hour" is real — so the first question about arm CCA today is silicon and platform availability, not API design.

# Smoke-test a host for confidential-VM support. EXACT paths, parameter
# names, and output strings vary by kernel version and vendor — this is a
# starting point, not an authoritative check.

# AMD: SEV / SEV-ES / SEV-SNP surface as CPU flags.
grep -o -E 'sev_snp|sev_es|\bsev\b' /proc/cpuinfo | sort -u

# ...but flags only say the silicon can. Ask whether KVM actually will:
cat /sys/module/kvm_amd/parameters/sev 2>/dev/null       # Y / N
cat /sys/module/kvm_amd/parameters/sev_es 2>/dev/null    # Y / N
cat /sys/module/kvm_amd/parameters/sev_snp 2>/dev/null   # Y / N

# Intel: TDX host enablement is typically visible as a kvm_intel param
# and/or a /sys/firmware entry, depending on kernel version.
cat /sys/module/kvm_intel/parameters/tdx 2>/dev/null

# The kernel log is the most honest source: firmware init either came up
# or told you exactly why it didn't.
sudo dmesg | grep -i -e sev -e snp -e tdx
# e.g. "SEV-SNP: RMP table physical range ..."          -> initialised
#      "ccp: SEV-SNP support indicated by CPU but ..."  -> not enabled in BIOS

# Inside a guest, the attestation device is the thing that matters:
ls -l /dev/sev-guest /dev/tdx_guest 2>/dev/null

# If any of the above is empty, stop and read your vendor's and your
# cloud's current docs before concluding anything about your fleet.

Attestation is the product; encryption is the plumbing

Here's the part people skip, and it's the part that does the work. Encrypted memory alone is nearly useless to you as a relying party. Suppose a service tells you "your data is processed in an encrypted VM." How do you know? The operator could have booted a normal VM, or a confidential VM running a modified image with a debug hook, and the API response would look identical. You're trusting a promise again.

Attestation converts that promise into something checkable. The guest asks the hardware for a report; the hardware signs it with a key rooted in the CPU vendor's certificate chain; the report carries measurements of what was loaded — firmware, kernel, initrd, boot configuration, policy bits like whether debug is permitted — plus a nonce the relying party supplied so an old report can't be replayed. A verifier outside the machine, explicitly not the host operator, checks the chain and the measurements against a policy, and only then releases a secret encrypted to a key bound to that attested guest.

The key is released to a measurement, not to a machine, an IAM role, or a person's assurance. That substitution — a fingerprint of running code in the place where a promise used to be — is the entire product.

# SHAPE ONLY. Every vendor's report format, verification library, and
# certificate chain differs, and the details change. Do not hand-roll
# this against real secrets — use the vendor's or your KMS's path.

def release_secret(nonce: bytes) -> bytes:
    # 1. The GUEST asks its hardware for a signed report. The nonce comes
    #    from the relying party, so a captured report can't be replayed.
    report = hardware_attestation_report(nonce)  # /dev/sev-guest, TDX quote, ...

    # 2. The RELYING PARTY -- outside this machine, and NOT the host
    #    operator -- checks the signature chains up to the silicon vendor.
    verify_signature_chain(report, vendor_root=VENDOR_ROOT_CERT)

    # 3. ...and that the MEASUREMENTS describe a boot chain it is willing
    #    to trust. This is the actual policy decision. Everything else is
    #    ceremony around this line.
    assert report.nonce == nonce
    assert report.measurement == EXPECTED_MEASUREMENT
    assert report.policy.debug_disabled          # a debuggable guest is readable
    assert report.policy.migration_allowed is False

    # 4. Only now does the secret move, wrapped to a key bound to the
    #    attested guest. The host operator never handles plaintext.
    return wrap_for_guest(SECRET, report.guest_public_key)

# Fails closed: change one byte of the measured boot chain and step 3
# rejects. That is the good news AND the operational bill -- see below.
#
# What this does NOT assert: that the code inside the measurement is
# correct. The hardware will faithfully attest to your bugs.

What it does not protect against

This is where I want to be blunt, because "confidential" is a marketing-shaped word and it invites people to hear guarantees that were never on offer. Memory encryption does not encrypt your `SELECT * FROM users` bug. Attestation will happily sign a report proving, with cryptographic rigour, that you are running exactly the vulnerable build you deployed.

• Bugs in your own guest code. SQL injection, a deserialization flaw, a token leaked into a log line, an exposed admin endpoint — all untouched. The trust boundary is drawn around your guest, so everything inside it is trusted by definition, including your mistakes.
• A compromised guest OS. If an attacker gets code execution inside the confidential VM, they are inside the protected boundary. The hardware is now diligently hiding the intruder from the host operator, which is not the outcome you were hoping for.
• Side channels — partially, and this is genuinely evolving. Cache and transient-execution effects, memory access patterns, timing, and in some designs observable properties of the ciphertext itself have all been the subject of a steady stream of academic results, with vendors responding through microcode, firmware, and architectural changes. Some classes are explicitly out of scope in the vendors' own threat models. Read current vendor security documentation rather than assuming any class is closed.
• Physical attacks, in varying degrees. Vendors document what is and isn't in scope, and DRAM interposers, cold-boot style attacks, and voltage glitching are treated differently across designs and generations. "The operator can't read RAM off the memory bus" is a claim to check per-platform, not a universal property.
• Availability. The host still schedules you, still allocates your memory, and can still refuse to run you or pull the plug. Confidentiality and integrity are on the menu; being allowed to exist is not.
• I/O, unless you handle it. Disk and network traffic still passes through the untrusted host, typically via explicitly shared, unencrypted bounce buffers, because the host has to move the bytes. Everything sensitive crossing that line must be encrypted and authenticated by the guest. A confidential VM writing plaintext to a virtual disk has protected its RAM and published its data.

Standard microVM vs confidential VM, side by side

Lined up on the dimensions that drive the decision. Confidential-VM entries are qualitative on purpose — specifics are vendor and version dependent.

• Who is protected from whom — Standard microVM (KVM/Firecracker): the host and other tenants are protected from the guest; the operator is trusted and has full visibility. Confidential VM (SEV-SNP/TDX/CCA): the guest is additionally protected from the host, hypervisor, and operator, all moved outside the trust boundary.
• Memory — Standard microVM: plaintext in host RAM; the hypervisor can read and dump it by design, which is how snapshots work at all. Confidential VM: encrypted with a key the host cannot access, plus integrity protection against host-controlled remapping, aliasing, and replay.
• Attestation — Standard microVM: none, and none would be coherent when the host can already read everything. Confidential VM: hardware-rooted signed reports carrying measurements of the boot chain, usable as a precondition for releasing a secret.
• Snapshot, restore, and fork — Standard microVM: first-class. Freeze RAM and device state to a file, restore mid-instruction, copy-on-write fork it, stream it from object storage. Confidential VM: not the naive path — memory is encrypted under a platform-bound key, so save/restore and live migration need explicit vendor support and extra protocol, and are often restricted or unavailable.
• Performance and operations — Standard microVM: minimal overhead; a snapshot restore lands in tens of milliseconds. Confidential VM: expect measurable, workload-dependent overhead (encryption, extra exits, bounce buffers for I/O, longer launch and attestation flows), plus a fleet where CPU generation, firmware, and kernel versions become correctness requirements rather than preferences.
• Ecosystem maturity — Standard microVM: extremely mature; Firecracker underpins large public serverless fleets. Confidential VM: real and shipping in major clouds, but younger — a moving target of firmware revisions, errata, guest-kernel requirements, and published research.
• What you give up — Standard microVM: nothing unusual; you keep full debuggability. Confidential VM: some or all of your snapshot and migration story, easy debugging (a debuggable guest is a readable guest, and the attestation policy will say so), and the ability to shrug at a firmware update.

Where Firecracker sits in this

Firecracker is a VMM, and its documented security model is the outward-facing one: minimal device model, jailer, seccomp, a memory-safe implementation — all aimed at containing an untrusted guest. A confidential VM is not something a VMM can grant by itself. Launching one is a coordinated dance across the CPU and its security processor, platform firmware, the host kernel's KVM support, the VMM's launch and measurement flow, and a guest kernel that knows it's confidential and handles shared memory correctly. Every layer has to opt in.

So be careful with any sentence — including one you might be tempted to extract from this post — asserting that a specific VMM "supports SEV-SNP today." Support status, which CPU generations, which host kernels, and what happens to snapshotting under it are exactly the facts that change between releases. If it matters to your design, read the current Firecracker documentation and release notes plus your cloud provider's confidential-computing docs, and confirm against a machine you can actually boot. Don't take my word for it, and don't take a two-year-old GitHub issue's word for it either.

One structural tension is worth flagging regardless of who supports what: the fast-boot techniques microVM platforms are built on assume readable guest memory. Snapshot-restore on every create, copy-on-write forking a running VM, streaming memory pages on demand from object storage — all of them work because the memory is plaintext to the host. Encrypt it under a platform-bound key and those techniques don't merely slow down; they need a fundamentally different mechanism or they stop existing. That's the honest cost of moving the host outside the trust boundary.

You probably don't need this — and here's who does

The test is one question, answered with a specific adversary rather than a feeling: is there a party with administrative access to the machine your workload runs on, whom you don't trust with your plaintext and can't address with contracts, access controls, and audit logging? If you can't name them, confidential computing is expensive theatre. If you can, it's the only thing that addresses them.

Cases where the answer is genuinely yes:

• Regulated data on infrastructure you don't own. PHI, financial records, or data under a residency regime where "the provider's staff could technically read it" is a finding rather than a footnote — especially when a regulator or a counterparty's security team is asking.
• Model weights you're shipping to someone else's hardware. Deploying a proprietary model on-premises at a customer's site or onto a partner's GPUs makes that customer your adversary for exactly one asset, and attestation lets you release the weights only to a measured runtime. Verify the accelerator story separately from the CPU story — it's a distinct and faster-moving area.
• Clean rooms where nobody trusts the referee. Two parties want a joint computation over data neither will show the other, and neither fully trusts you to hold the middle. "Here is the measurement of the code that will touch both datasets" survives an adversarial reviewer; "we promise" does not.
• Key and signing operations you want to be unable to perform. If holding a key means you can be compelled or compromised into using it, a measured environment that uses it only under policy is a real reduction in your own power — sometimes exactly the goal.
• Buyers whose procurement requires it. Less noble but entirely real: if a checkbox stands between you and a contract, the feature is the feature. Just be honest internally that this is why.
• The inverse case is not on this list: untrusted code, multi-tenant workloads, agent tool calls, CI jobs, customer app hosting. There the operator is you, you need visibility to debug, and the boundary you want is the ordinary one.

And if you do need it, my advice mirrors what works with enclaves: make the confidential part small, boring, and stable. One narrow operation, few dependencies, a measurement that changes twice a year. That measurement is now a release artifact you review — every dependency bump changes the fingerprint, and a changed fingerprint means a key-release policy update in lockstep or a service that stops working with a spectacularly unhelpful error. Putting your whole application inside the boundary means putting your whole dependency graph inside your attestation policy.

Where PandaStack sits, stated plainly

PandaStack's isolation model is standard hardware virtualization: KVM plus Firecracker, with the jailer, seccomp, per-sandbox network namespaces, and a fresh microVM per workload. That protects your host and your tenants from the code you're running, with a hardware boundary between tenants rather than a shared kernel. It's the model AWS Lambda and Fargate stake their multi-tenancy on, and it's the right tool when the code is the adversary.

It is not a confidential-computing product, and I won't fuzz that line to make a sale. PandaStack does not encrypt guest memory against the host and does not attest to anything: as the operator of a host, I can read a sandbox's memory and disk — which is exactly what makes 179ms snapshot-restore creates and copy-on-write forks possible. If your requirement is "the operator must not be able to see this," you want a confidential VM or an enclave for that specific step, and this for everything around it — usually most of the system.

The bottom line

SEV-SNP, TDX, and CCA are one idea implemented three ways: encrypt guest memory with a key the host can't reach, protect its integrity against a host that controls the page tables, and let the guest prove what it is to someone who isn't the host. That's a genuinely new capability, and for a small set of problems it's the only thing that works. It is not a general security upgrade. It doesn't fix your code, doesn't help once someone is inside your guest, offers partial and evolving mitigation of side channels, and will complicate or remove the snapshot, fork, and migration mechanics that make microVM platforms fast.

Pick the boundary that points at your actual adversary. If it's the code you're running, you want a microVM and its full operator visibility. If it's the operator, you want attestation, and you'll pay for it in performance, portability, debuggability, and a permanent subscription to your vendor's errata. Either way, verify every specific claim — mine included — against current vendor and cloud documentation, because down here the details change faster than the blog posts do.