Everything in protection and isolation models assumed the kernel was the trustworthy referee: it enforces the access matrix, and if you trust it, you are safe. But turn the question around. What if you don't trust the operating system? You are a bank running your key-signing code on a cloud VM you don't own; the hypervisor, the host kernel, the datacentre technician with physical access — all of them can, in the classical model, read every byte of your memory. The most privileged code is precisely the code best placed to steal your secrets.

A Trusted Execution Environment (TEE) flips the trust model on its head. Instead of the OS protecting apps from each other, hardware protects a small piece of an app from the OS itself — from the kernel, the hypervisor, even someone with a probe on the memory bus. The trusted computing base shrinks from "the whole kernel" to "the CPU and a few thousand lines inside it." This lesson is about how that inversion is built — enclaves, secure worlds, confidential VMs — and the chain of trust that has to reach all the way back to the moment you press the power button.

Intel SGX — an enclave inside a hostile process

Intel's SGX (Software Guard Extensions) carves out an enclave: a region of a process's address space that even the kernel and hypervisor cannot read. The CPU's memory-encryption engine encrypts enclave pages in DRAM with a key that never leaves the silicon, so a bus probe or a cold memory dump yields only ciphertext. Code outside the enclave — including ring-0 code — that tries to read enclave memory gets aborts or garbage. The threat model is startling: the enclave trusts only the CPU.

Two mechanisms make an enclave useful rather than merely private:

• Measurement: as the enclave is built, the CPU cryptographically hashes its initial code and data into a register (\texttt{MRENCLAVE}). This identity fixes exactly what was loaded — change one byte and the measurement changes.
• Attestation: the CPU can sign a statement — "this exact measurement is running inside a genuine SGX enclave on genuine Intel hardware" — with a hardware key a remote party can verify. Only after that proof does the remote party provision its secrets into the enclave. You never send your key to a machine until the machine has proved what it is running.

And yet SGX has been side-channel-plagued. It deliberately does not defend against microarchitectural leakage, and a parade of attacks — Foreshadow (L1TF), Plundervolt (undervolting to induce faults), SGAxe, ÆPIC — have repeatedly extracted enclave secrets or forged attestations. The enclave's memory is encrypted, but its access patterns, timing, and speculative behaviour leak through the same side channels you met with Spectre. Intel has since deprecated client SGX. The lesson is sobering: encrypting memory is the easy part; closing every side channel is the part nobody has finished.

ARM TrustZone — two worlds, one CPU

ARM took a coarser, whole-system approach with TrustZone. The processor is split into two worlds: a Normal World that runs your ordinary OS (Android, Linux) and a Secure World that runs a tiny trusted OS (OP-TEE, Qualcomm's QSEE, Trusty). A single hardware bit — the \texttt{NS} ("non-secure") bit — propagates through the CPU, the bus, the caches, and even the memory controller, so Secure-World memory and peripherals are physically invisible to the Normal World. Crossing between them goes through one controlled gate, the Secure Monitor Call (\texttt{SMC}) — structurally the same idea as the syscall trap, one rung higher.

This is why your phone's fingerprint template, DRM keys, and mobile-payment secrets survive even a fully rooted Android: they live in the Secure World, and the compromised Normal-World kernel simply has no path to them. TrustZone protects a whole subsystem (a trusted OS plus its apps), where SGX protects a single enclave inside one process — different granularities of the same trust inversion.

AMD SEV and confidential VMs — encrypt the whole guest

Enclaves ask you to rewrite your app to split out a tiny trusted core — painful. The cloud wanted something coarser: run an entire, unmodified virtual machine such that the hypervisor cannot read it. That is confidential computing, and AMD's SEV (Secure Encrypted Virtualization), Intel's TDX, and ARM's CCA all deliver it: the VM's memory is transparently encrypted with a per-guest key managed by a dedicated security processor, so the host hypervisor sees only ciphertext. SEV-SNP adds integrity protection against a malicious hypervisor remapping or replaying the guest's pages, and the whole VM can be attested as a unit.

The trade-off is the size of the trusted base. An SGX enclave trusts only the CPU and a few thousand lines of your code — tiny, but you must re-architect. A confidential VM trusts the entire guest OS and your unmodified app — huge, but you change nothing. The industry has largely voted for the latter: lifting a whole VM out of the host's reach fits how clouds already work, even if the TCB is a whole Linux.

The chain of trust — where does trust start?

Attestation and enclaves all rest on one hard question: if the OS can lie, and the firmware can lie, whom do you believe first? The answer is a hardware root of trust — a small piece of immutable code (a mask-ROM burned into the chip) and fused keys the attacker physically cannot alter. From that anchor, secure boot builds a chain: each stage verifies the signature of the next stage before executing it. The root ROM checks the firmware; UEFI Secure Boot checks the bootloader (the \texttt{shim}/GRUB signatures); the bootloader checks the kernel; and so on up to your apps. Break any link and the chain refuses to proceed.

There are two distinct flavours, and they are often confused. Secure Boot is enforcing: it refuses to run anything whose signature does not verify — a gate. Measured Boot is recording: each stage computes a hash of the next and extends it into a TPM (Trusted Platform Module) register called a PCR — it does not block anything, but it leaves an unforgeable record of exactly what ran, which a remote verifier can later demand (remote attestation). One stops bad boots; the other proves what booted.

The TPM's clever trick: extend, don't overwrite

A PCR is never written, only extended:

Because each new value folds in the old one, the final PCR is a hash of the entire ordered sequence of everything that ran. You cannot forge it: to hit a target PCR you would have to have loaded exactly the right components in exactly the right order — and malware that loads after a stage can never retroactively change what that earlier stage already extended. This one-way, append-only accumulation is what makes "prove to me what you booted" possible. Run the extend chain and watch a single tampered stage cascade into a completely different final measurement.