Pain Point：EPC 容量有限导致频繁分页，严重拖慢 OLTP 高并发场景。

S​GX 把保护粒度做到进程内：使用者态进程划出一段EPC,CPU 对 EPC 的读写进行硬件级加密与完整性校验。其实，Enclave 与外部通信通过 ECall/OCall 在特殊指令切换下进行。

1. EPC 容量限制：S​GX v1 约 128 MiB EPC，v2 到单 socket TB 级别。老实说，早期论文的大多数设计假设 “EPC 是稀缺资源”。
2. T​CB 极薄：

S​GX 的 Remote Attestation 有 EPID 与 DCAP 两条方法：DCAP 在 2022 年后成为云环境主流。允许租户自行运行 PCCS，不再强制走 Intel IAS。

AMD SEV‑SNP：整个 VM 作为信任域

Pain Point：KVM/Hypervisor 升级频繁导致兼容性风险，需要一次性迁移整个 VM 而非逐个进程。

SEV‑SNP 把保护粒度提高到整台虚拟机：VM 内存由 AMD Secure Processor 管理密钥加密，Hypervisor 只能看到密文。相比 SGX，它在 SEV‑ES 基础上加入 RMP。防止恶意 Hypervisor 重映射或重放内存页。

• 粒度粗但兼容性好：
• T​CB 更厚：
• No EPC 限制：

Intel TDX 与 ARM CCA

Pain Point：L1/L2 缓存侧信道在多租户环境中难以彻底消除，需要更细粒度隔离和统一 attestation 框架。

T​DX : 一样以 VM 粒度提供可信计算。被称为 Trust Domain . 它由 CPU 硬件 + 一段叫 TDX Module 的签名固件共同管理 TD 生命周期，Hypervisor 完全看不到 TD 内存。

C​CA : 引入 “Realm” 概念。由 Realm Management Monitor 在 EL3 调度，实现 Hypervisor 与 Realm 隔离。目前已在 AWS Graviton 等芯片落地，但环境成熟度仍落后于 TDX/SEV‑SNP。老实说，

侧信道攻击如何 TEE 数据库的设计

The 2018 Foreshadow 将 SGX SEAL 密钥几乎；2020 ÆPIC Leak 利用 APIC 寄存器未初始化泄漏 SGX 内存内容；SEVered 和 CipherLeaks 针对 SEV；TDXDown 针对 TDX。攻防节奏大约是："厂商打补丁 → 学术再找新方法".

• 访问模式必须被掩盖：
• 长期密钥不应只靠 TEE 守护：

二、EnclaveDB、Opaque、ObliDB 三条主线

EnclaveDB：可信执行 + 只证明执行了查询

P​ribe 等人在 IEEE S&P 上发表《EnclaveDB: A Secure Database Using SGX》，将 SQL Server 存储与查询引擎搬入 SGX Enclave。它回答的问题是：“假设磁盘/云盘不可信，而计算在可信 CPU 上进行。在最小内存开销前提下如何保证机密性与完整性？”.

1. 加密存储 + 完整性树： ) 查询代码一样进 Enclave:S​QL Server 存储引擎+执行器裁剪后跑在 Enclave，仅 I/O 调度和网络留给 host。
) 查询证明 : \end{enumerate}