Latest Posts

• Intel TDX vs AMD SEV-SNP: A Systems Engineer's Field Guide

  A layer-by-layer comparison for engineers who know one side and want to understand the other.

  ---

  Introduction

  Modern cloud VMs run on hypervisors their tenants don’t control. A traditional hypervisor can read guest memory, inspect registers, and inject arbitrary interrupts — it’s an implicit member of the trust boundary.

  Confidential computing hardware removes the hypervisor from that boundary. Intel TDX and AMD SEV-SNP are the two production implementations. They share the same threat model — an actively malicious hypervisor — but make different architectural choices at every layer. This post maps those layers side by side.

  ---

  The Trust Architecture

  The core question: who enforces isolation, and where do they live?

  	Intel TDX	AMD SEV-SNP
  Security enforcer	TDX Module (SEAM mode, VMX root)	AMD Secure Processor (PSP) — ARM Cortex-A5 on-die
  Firmware TCB	ACMs + SEAM loader (x86 microcode path)	PSP firmware (signed by AMD)
  Guest name	Trust Domain (TD)	SNP VM
  Host control structure	VMCS (hardware-cached, SEAM-protected)	VMCB (memory-resident, 4KB page)

  Intel’s enforcer runs on the main CPU in a new processor mode (SEAM). AMD’s enforcer is a separate ARM processor (the PSP) embedded on the same die. Different attack surfaces: the TDX Module shares cache/memory bus with the host; the PSP is isolated silicon with its own firmware TCB.

  ---

  Memory Encryption

  Both architectures use hardware AES engines in the memory controller. The divergence is in how they tag which key to use.

  	Intel TDX	AMD SEV-SNP
  Per-VM key selector	HKID — encoded in physical address bits	ASID — tagged TLB/cache entries
  Shared memory indicator	Bit 51 of GPA = 1 (shared → HKID=0)	C-bit in guest PTE = 0 (unencrypted)

  Intel puts the private/shared split in the address: set bit 51 of a GPA and the memory controller routes it through HKID 0 (no encryption). AMD puts it in the page table entry: the C-bit in each PTE selects encrypted or plaintext. AMD’s vTOM feature simplifies this with a single watermark GPA — all addresses below it are private — closer to Intel’s model.

  ---

  Page Ownership and Integrity

  Encryption alone isn’t enough. A malicious hypervisor can remap, replay, or alias pages. Both architectures solve this with a hardware-enforced ownership table checked on every memory access.

  	Intel TDX	AMD SEV-SNP
  Ownership table	PAMT (Physical Address Metadata Table)	RMP (Reverse Map Table)
  Hypervisor assigns page	TDH.MEM.PAGE.ADD (SEAMCALL)	RMPUPDATE instruction
  Guest validates page	TDG.MEM.PAGE.ACCEPT (TDCALL)	PVALIDATE instruction

  The guest validation step is the key anti-replay mechanism: the hypervisor assigns a page with Validated=0; the guest must validate it before use. If the hypervisor swaps in a different physical page at the same GPA, the replacement’s Validated bit is 0 and the guest gets a fault instead of silently using compromised memory. The RMP also enforces a reverse-map check (each physical page can be mapped to only one GPA), preventing aliasing attacks.

  AMD’s own framing of the guarantee: “If a VM is able to read a private page of memory, it must always read the value it last wrote.”

  ---

  Guest–Hypervisor Communication

  Even with a malicious hypervisor, guests need device emulation and configuration. Both architectures define a structured interface and protect guest register state in transit.

  	Intel TDX	AMD SEV-ES/SNP
  Register state protection	TDVPS (encrypted, TDX Module only)	VMSA (encrypted with guest’s ASID key)
  Communication interface	TDG.VP.VMCALL / shared GPA	VMGEXIT / GHCB page
  Hardware-triggered exception	#VE (vector 20)	#VC (vector 29)

  When hardware intercepts a guest event the VMM must handle, both architectures turn it into a guest-handled exception rather than an invisible VM exit — keeping register state inside the guest. The guest’s exception handler then explicitly communicates outward: AMD’s #VC handler writes to the GHCB (a shared 4KB page) and calls VMGEXIT; Intel’s #VE handler calls TDG.VP.VMCALL. Structurally: #VC → VMGEXIT ≈ #VE → TDG.VP.VMCALL.

  ---

  Privilege Levels Within the Guest

  Both architectures support privileged services inside the confidential VM (vTPM, attestation proxy, unenlightened guest support) without pushing them to the untrusted hypervisor.

  	Intel TDX	AMD SEV-SNP
  Mechanism	TD Partitioning: L1 VMM + nested L2 TDs	VMPLs 0–3: per-page R/W/X permissions per level
  Privileged service layer	L1 VMM inside TD	SVSM (Secure VM Service Module) at VMPL 0
  Open-source reference	Linux KVM inside a TD	Coconut-SVSM (Rust)

  AMD’s VMPL model is compact — it adds only per-page permission bits to existing RMP entries. VMPL 0 (SVSM) gets full permissions on each page and grants subsets to VMPL 1–3 via RMPADJUST. When the guest OS at VMPL 3 triggers a #VC, the ReflectVC feature reflects it to VMPL 0 for handling, keeping all hypervisor interaction mediated by the SVSM.

  ---

  Closing

  Both architectures converge on the same high-level answers: hardware memory encryption, a page ownership table to block remapping attacks, a protected guest–hypervisor communication channel, and intra-guest privilege separation. The differences are in philosophy — mediation vs delegation, on-CPU firmware vs off-CPU co-processor, address-based shared bit vs PTE-based C-bit.

  The naming maps cleanly once you know it: PAMT → RMP, HKID → ASID, VAPIC → AVIC, TDVMCALL → GHCB/VMGEXIT, #VE → #VC. The challenge is in the details — different field layouts, different instruction names, and different assumptions about what the guest must actively participate in vs what the hardware handles transparently.

• Determining the PID of a FUSE Daemon based on the /proc/mounts

  I am toying with a trivial Passthrough FUSE file system [1] mounted at /some-path/fusey-files, the PID of the FUSE daemon is 1234. and I wanted to programmatically find out (using /proc or /sys or some other kernel interface such as ioctl) that this mount is backed by the FUSE daemon running at PID 1234? What I have found so far is hacky and imprecise, and I feel like the FUSE module in the kernel must have this information, and I am just missing something.

• Understanding the various mounts setup by a Docker container

  Why does a docker container have so many mounts?

• Experience of running hybrid CHERI userspace on seL4

  In this article, I share the experience of getting to a point where we could run userspace applications in seL4, which had CHERI capabilities enabled(Hybrid mode). CHERI [6] is an architectural extension that adds HW capabilities to modern processors. Morello [7] is the ARM implementation of CHERI. SeL4 [8] is a formally verified microkernel widely deployed in security-critical applications. Since seL4 is formally verified, it might not benefit from CHERI capabilities, but the user application running on seL4 will still benefit.

• Linux Docker Build

  Steps to build the linux kernel in a docker container and install it on the host. This is done so that it does not mess up the packages installed on the host.

• Virtual Machine Core Idea

  While trying to find tutorials on how to implement a simple hypervisor, most of the articles I found online were about using Intel’s VT-X extensions – called Hardware extensions for virtualization to implement a Virtual machine [1]. However, the idea of a virtual machine is so much older than the hardware extensions meant to make virtualization more accessible. So, I wanted to get to the crux of what we are virtualizing and how. Then later, see how hardware extensions for virtualization make it either easier or speed things up.

• Genode: Running out of capabilities on 64-bit platforms

  I am using Genode(with seL4) as the OS platform for demonstrating my research ideas. As with starting with a new platform I have run into some hurdles.

• seL4: Page count mismatch in sel4utlils vspace library

  Updated Feb 2, 2022
  Root cause at the bottom
  

  I was looking at the sel4utils/vspace library and noticed a mismatch in the number of pages allocated as per the two data structures which keep track of the address space. Below I have laid out my test setup, steps to reproduce and finally the exact questions.

• First Post

  This is my first blog post. Hopefully, I will be able to soon replace this with a real post.