Self-Hosted Confidential Computing: Building Trusted Execution Environments with Intel SGX and AMD SEV

Quick Summary (TL;DR) Confidential computing protects data in use by isolating workloads inside hardware-enforced Trusted Execution Environments (TEEs). Intel SGX gives you fine-grained, per-application enclaves that require code adaptation. AMD SEV transparently encrypts entire VMs with near-zero code changes. This guide walks you through hardware selection, BIOS/firmware setup, attestation, development tooling, Kubernetes integration, and performance tuning so you can run confidential workloads on your own hardware—not someone else’s cloud.

Data at rest is encrypted. Data in transit is encrypted. Data in use—sitting in RAM, exposed to the hypervisor, the kernel, and anyone with physical access—has historically been wide open. Confidential computing closes that gap. And thanks to mainstream support in AMD EPYC and Intel Xeon platforms, you can now build it yourself.

Introduction to Confidential Computing

Confidential computing uses CPU-level mechanisms to create an isolated, encrypted execution context. The host operating system, hypervisor, and even a malicious administrator are locked out of the memory region where your workload runs. The CPU holds the only keys.

Why self-host it? Three reasons dominate:

• Data sovereignty — regulated workloads (healthcare, finance, government) may not leave your premises.
• Threat model control — you decide who is trusted, rather than inheriting a cloud provider’s assumptions.
• Cost — confidential cloud instances carry a premium; owned hardware amortizes over time.

The two dominant technologies are Intel SGX and AMD SEV. They solve the same problem from opposite directions.

Understanding Trusted Execution Environments (TEEs)

A TEE is a hardware-isolated region of execution whose contents are protected from everything outside it. The CPU enforces this via memory encryption engines, access-control hardware, and cryptographic measurement of the code loaded into the TEE.

flowchart TD
    A[Application / VM] --> B{TEE Boundary}
    B --> C[Encrypted Memory Region]
    B --> D[CPU-Enforced Isolation]
    D --> E[Memory Encryption Engine]
    E --> F[Sealing / Attestation Keys in CPU]
    G[Hypervisor / Host OS] -.->|Denied Access| C
    H[Physical Attacker] -.->|Encrypted RAM Bus| C

Two properties make a TEE trustworthy:

1. Confidentiality & integrity — memory is encrypted and tamper-evident.
2. Attestation — the CPU can cryptographically prove what is running to a remote party.

Intel SGX vs. AMD SEV: Key Differences

Feature	Intel SGX	AMD SEV (SEV-SNP)
Isolation granularity	Per-application enclave	Per-virtual-machine
Code changes required	Yes (SDK / partitioning)	No (transparent to guest)
Protected from hypervisor	Yes	Yes
Memory encryption	Enclave pages only	Entire VM memory
Attestation	Intel DCAP / IAS	AMD KDS (VCEK/VLEK)
Typical overhead	Higher (enclave transitions)	Low (<5% CPU-bound)
Best for	Secrets processing, key management	Lift-and-shift legacy VMs
Minimum hardware	Xeon E-2200 / Scalable 2nd Gen+	EPYC 7002 (Rome)+

The practical rule: choose SGX when you need to protect a small, sensitive code path; choose SEV when you want to protect a whole workload without rewriting it.

Hardware Requirements and Compatibility

Before anything else, verify your platform. Confidential computing fails silently on unsupported silicon.

Intel SGX checklist:

• CPU: Intel Xeon E-2200 series or Scalable 2nd Gen+ (check ark.intel.com for “Intel SGX”).
• BIOS: Enable SGX and set SGX memory size (e.g., 128 MB–256 MB).
• Motherboard: Must expose SGX in firmware — many consumer boards do not.

AMD SEV checklist:

• CPU: AMD EPYC 7002 (Rome) or newer; SEV-SNP requires EPYC 7003 (Milan)+.
• BIOS: Enable SME, SEV, SEV-ES, and SEV-SNP.
• Host kernel: Linux 5.19+ for SNP; kvm_amd module with sev=1.

Verify on a running Linux host:

# Intel SGX
grep -o sgx /proc/cpuinfo | head -1        # should output: sgx

# AMD SEV
sudo dmesg | grep -i sev
# Look for: "SEV: SEV-SNP API:1.51 ... SNP enabled"

If these come back empty, stop and fix firmware first—no software workaround exists.

Setting Up Intel SGX on Self-Hosted Hardware

Step 1 — Install the SGX driver and DCAP stack:

# Ubuntu 22.04+
sudo apt install linux-image-generic
# Install Intel SGX DCAP packages from Intel's repo
sudo apt install libsgx-dcap-ql libsgx-dcap-default-qpl \
                 libsgx-enclave-common sgx-aesm-service
sudo systemctl enable --now aesmd

Step 2 — Confirm the AESM daemon and driver:

ls /dev/sgx_enclave /dev/sgx_provision
systemctl status aesmd

Step 3 — Write and run a minimal enclave. Using the Intel SGX SDK, an enclave is a shared object (.so) with a trusted/untrusted boundary. A trivial “seal a secret” flow:

// Inside the enclave (trusted)
sgx_status_t seal_secret(const uint8_t *secret, size_t len) {
    sgx_key_128bit_t key;
    sgx_seal_data(...);  // derives sealing key from CPU
}

Step 4 — Run with the runtime and verify the enclave launches. If you need to run unmodified binaries, use Gramine, Occlum, or SCONE, which emulate Linux syscalls inside the enclave.

Setting Up AMD SEV on Self-Hosted Hardware

SEV’s advantage is that the guest is a normal VM. The work is on the host.

Step 1 — Enable SEV in the KVM host:

# Check module parameters
cat /sys/module/kvm_amd/parameters/sev        # should be: 1 (or Y)

# If not enabled, add to /etc/modprobe.d/kvm.conf
options kvm_amd sev=1 sev_es=1 sev_snp=1
sudo update-initramfs -u && sudo reboot

Step 2 — Launch an SEV-encrypted VM with QEMU:

qemu-system-x86_64 \
  -enable-kvm \
  -machine q35,confidential-guest-support=sev0 \
  -object sev-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 \
  -cpu EPYC \
  -m 4G \
  -drive file=guest.qcow2,if=virtio \
  -nographic

Step 3 — Verify encryption inside the guest:

sudo dmesg | grep -i sev
# Expect: "AMD Memory Encryption Features active: SEV"

That’s it. The guest OS and applications run unmodified—their memory is transparently encrypted by the CPU’s memory controller.

Remote Attestation: Verifying Enclave Integrity

Attestation is the trust anchor. Without it, a remote service has no reason to release secrets to your TEE.

sequenceDiagram
    participant App as Workload (TEE)
    participant CPU as CPU (SGX/SEV)
    participant Verifier as Relying Party
    participant KDS as Intel IAS / AMD KDS
    App->>CPU: Request report (measurements)
    CPU-->>App: Signed hardware report
    App->>Verifier: Send report + quote
    Verifier->>KDS: Validate signature & cert chain
    KDS-->>Verifier: Attestation result
    Verifier-->>App: Release secrets (if valid)

Intel SGX produces a quote signed by an attestation key, validated via Intel’s DCAP or IAS. AMD SEV-SNP produces a report signed by the Versioned Chip Endorsement Key (VCEK), validated against AMD’s Key Distribution Service (KDS).

A minimal verification flow with the DCAP library:

sgx_ql_qv_result_t result;
sgx_qv_verify_quote(quote, quote_size, NULL, &result, ...);
if (result == SGX_QL_QV_RESULT_OK) {
    // Safe to release secrets
}

Always pin the expected measurement (MRENCLAVE for SGX, launch digest for SEV-SNP) on the verifier side. Attestation without measurement pinning is theater.

Developing Secure Enclaves: Tools and Frameworks

Framework	Target	Unmodified binaries?	Notes
Intel SGX SDK	SGX	No	Native enclave development
Open Enclave SDK	SGX	No	Cross-vendor abstraction
Gramine	SGX	Yes	Library OS, minimal changes
Occlum	SGX	Yes	Memory-safe libOS
SCONE	SGX	Yes	Container-native
Kata + SEV	SEV	Yes	Pod-level isolation

For most teams, Gramine or Occlum on SGX—or Kata Containers with SEV-SNP—strike the best balance between security and engineering effort.

Integrating Confidential Computing with Existing Infrastructure

Containers & Kubernetes:

• SGX: Use the Intel SGX device plugin to expose /dev/sgx_enclave to pods. Run enclaves inside Gramine-enabled containers.
• SEV: Run SEV-encrypted VMs as Kubernetes nodes, or use Kata Containers with sev-snp runtime class for pod-level memory encryption.

# Pod requesting SGX device
spec:
  containers:
    - name: enclave-app
      image: myrepo/gramine-app:latest
      resources:
        limits:
          sgx.intel.com/epc: 64Mi

Key management: Seal secrets to the TEE using CPU-derived sealing keys (SGX) or inject them via encrypted disks at VM launch (SEV). Never store long-lived secrets in plaintext on the host—release them only after successful attestation.

Performance Considerations and Optimization

• SGX: Enclave entry/exit (EENTER/EEXIT) is expensive. Batch operations, minimize syscalls, and keep hot data inside the enclave. EPC (enclave page cache) is limited—profile memory pressure.
• SEV: Overhead is dominated by memory encryption on the bus. CPU-bound workloads see <5% loss; memory-bandwidth-heavy workloads can lose more. Enable SEV-ES for register-state protection at a small cost.

Always benchmark with your actual workload. Synthetic numbers mislead.

Security Best Practices and Common Pitfalls

• Pin measurements during attestation—otherwise you trust any enclave.
• Keep firmware updated. SGX and SEV have had microarchitectural side-channel CVEs (e.g., Foreshadow, SGAxe). Patch relentlessly.
• Don’t trust the host for secrets. Use sealing or attestation-gated release.
• Watch side channels. Shared caches and memory buses leak information; isolate co-tenants where possible.
• Verify your BIOS settings survived reboots—some boards silently reset SGX/SEV flags.

Conclusion: The Future of Self-Hosted Confidential Computing

Confidential computing has crossed from research curiosity to production reality. With EPYC and Xeon silicon now shipping in commodity servers, you can build a TEE-based trust boundary on hardware you own. Choose SGX for surgical protection of sensitive code; choose SEV for transparent, whole-VM encryption. In both cases, remote attestation is the linchpin—get it right, and you gain a level of assurance that no amount of software-only encryption can match.

FAQ

What is the difference between Intel SGX and AMD SEV? Intel SGX isolates individual application code in secure enclaves, protecting data in use at the application level. AMD SEV encrypts entire virtual machines, providing memory encryption at the VM level. SGX offers finer-grained control but requires code adaptation, while SEV is more transparent to existing applications.

Do I need special hardware for confidential computing? Yes—you need a CPU supporting Intel SGX (Xeon E-2200 series or newer) or AMD SEV (EPYC 7002 series or newer). Your motherboard and BIOS must also support these features, and you may need to enable them in firmware settings.

How does remote attestation work? Remote attestation lets a remote party verify that a TEE is genuine and running the expected code. The CPU generates a signed report containing measurements of the enclave or VM, which is sent to a verification service (Intel IAS/DCAP or AMD’s KDS) to validate the signature and measurements.

Can I run existing applications in a TEE without modification? With AMD SEV, yes—existing VMs run unmodified because SEV encrypts memory transparently. With Intel SGX, applications must be partitioned into trusted and untrusted parts, though frameworks like Gramine or Occlum allow running unmodified Linux binaries with minimal changes.

What are the performance overheads? SGX typically incurs higher overhead due to enclave entry/exit and memory restrictions, especially for I/O-heavy workloads. SEV has lower overhead (often <5% for CPU-bound tasks) but can impact memory-intensive workloads. Benchmark your specific workload before committing.