可信执行环境（TEE）如 Intel SGX 通过硬件级隔离保护 enclave 代码和数据免受主机操作系统和特权软件的攻击。然而，现有 TEE 设计通常将整个 enclave 视为一个安全域，缺乏内部隔离机制。这意味着同一 enclave 内的不同模块（例如库操作系统、应用程序逻辑）共享相同的权限域，一旦其中一个模块被攻陷，攻击者便能访问整个 enclave 的内存，导致租户间的安全屏障失效。为解决该问题，该论文提出一种硬件-软件协同设计方法，用于实现高效的 enclave 内隔离（intra-enclave isolation）。其核心思想是在硬件层面引入更细粒度的内存访问控制和地址转换支持，同时在软件层面设计轻量级的隔离执行环境。具体而言，论文扩展了现有 TEE 的内存保护机制，将 enclave 的逻辑内存划分为多个安全域，每个域具有独立的访问权限和资源；系统软件（如库操作系统）负责管理域的创建和上下文切换，而硬件则确保域间隔离的强制执行。实验基于 QEMU 模拟器和 Linux 内核原型实现，评估了典型微基准和宏基准（如 Web 服务器、数据库查询）。结果表明，相比全软件方案（如基于软件防护模块（SFI）的隔离），该协同设计方案将性能开销从 20%-50% 降低至 3%-8%，且代码改动量小，易于集成到现有 TEE 栈中。该工作为构建多层次、细粒度的可信执行环境提供了新思路，特别适用于多租户云场景中不同敏感度的应用模块共存于同一 TEE 的情况，或需要动态加载第三方库的机密计算框架。

该论文针对云推理服务（CIS）中用户请求包含大量个人敏感或企业机密信息，而现有保护方案（如苹果的PCC、谷歌的Private AI Compute）依赖专有硬件和封闭生态系统，难以被其他厂商采纳的问题，提出了OpenPCC：一个基于商用可信执行环境（TEE）的开放且机密的LLM服务框架。论文首先分析了构建安全、开放CIS的基本需求，然后设计了OpenPCC架构，该架构利用商用的Intel SGX或AMD SEV等TEE硬件，在不依赖专有硬件的前提下实现机密性保护。作者实现了开源原型，并在Llama-3 8B vLLM负载上进行了端到端评估，分离了OpenPCC自身开销与底层TEE硬件开销。分析和评估证明了系统的可行性和安全性。论文适合云安全研究人员、LLM服务提供商和隐私工程师阅读。

本文针对跨组织协作计算中，参与方需要处理敏感数据和专有代码但不愿将其暴露给不可信基础设施或其他参与者的难题，提出了一种名为双向机密虚拟机（2cVM）的双层架构。该架构将硬件可信执行环境（TEE）与工作负载内隔离层相结合。与普通机密虚拟机（CVM）不同，2cVM 强制执行共存工作负载之间的相互隔离，确保各参与方对自己的数据和代码保持控制。2cVM 中所有计算受一份“承诺清单”约束，该清单枚举了参与方、组件组成、允许的数据通道以及授权输出；清单被锁定在虚拟机中并纳入远程证明证据，使得策略在虚拟机整个生命周期内不可变且可独立验证。概念验证实现结合了 AMD SEV-SNP 提供的硬件保护与 WebAssembly 组件模型提供的细粒度沙箱隔离。在商用硬件上针对四类基准测试的评估表明，两层隔离的开销并非线性叠加：一旦工作负载在 WebAssembly 沙箱内执行，启用硬件内存保护的边际成本很小。开销取决于工作负载，主要由内存访问模式决定，从顺序访问的几乎可忽略到不规则指针追逐访问的大约 2 倍。这些结果表明，2cVM 为隐私保护的协作计算提供了实用且可验证的基础。

本文针对可信执行环境（TEE）复制中的故障模型问题展开研究。TEE 通过硬件保证计算机密性和完整性，在 TEE 威胁模型下，硬件可以防护大多数外部注入的故障行为（如内存篡改），仅允许崩溃故障。因此，理论上在 TEE 内复制受信代码时，使用崩溃容错（CFT）复制协议即可。然而，TEE 缺乏高效且通用的手段来确保外部持久状态的新鲜性（freshness）。当 TEE 重启时，外部状态可能被回滚到旧版本，导致 CFT 复制不足以应对。另一方面，直接采用拜占庭容错（BFT）协议则过于保守，因为 BFT 旨在容忍任意恶意行为，而 TEE 的故障仅限于重启时的状态回滚。为此，作者提出了一种针对 TEE 复制的重启-回滚（RR）故障模型，精确刻画了 TEE 在外部状态下的可能故障行为。然后展示了如何将现有复制协议少量修改即可适配该故障模型，并保持原有性能。具体地，作者将两种广泛使用的崩溃容错协议——ABD 读写寄存器协议和 Paxos 共识协议——适配到 RR 模型。基于这些协议，构建了一个名为 TEEMS 的复制元数据服务，该服务能够为不可信的云存储服务提供 TEE 级别的机密性、完整性和新鲜性保证。评估表明，所提协议性能显著优于对应的 BFT 协议（吞吐量提升 1.25 至 55 倍），且与不防护回滚攻击的 CFT 版本性能相同。

论文提出 GDPRuler，一种用于不可信云环境中的键值存储（KVS）的可验证 GDPR 合规中间件系统。背景：GDPR等隐私法规对个人数据的存储、处理和审计提出严格要求，而KVS简单数据模型和不可信云部署使合规极具挑战。现有方案需侵入式代码修改、性能开销高或忽略合规机制本身的完整性。核心方法：GDPRuler 在机密虚拟机（CVM）内运行可信 GDPR 监视器，无需修改KVS代码。监视器强制执行GDPR策略、管理合规元数据、维护防篡改审计日志。声明式策略语言将核心GDPR义务转化为可执行的运行时规则。为提升效率，GDPRuler 将元数据紧凑编码到KV记录中，为GDPR特定查询建立专用元数据索引，仅以空间高效格式记录合规相关事件。实现：作为透明代理支持未修改的Redis和RocksDB。评估：使用YCSB和GDPR启发的工作负载，GDPRuler 开销低：吞吐量约为原生KVS的61%，其中CVM环境贡献28%-32%；元数据存储开销低于20%；GDPR查询通过元数据索引获得13-182倍加速。贡献：通过将可验证策略嵌入可信中间件层，为不可信云基础设施上的KVS提供了实现GDPR合规的实用路径。

随着LLM即服务等机密云工作负载的兴起，用户数据必须在可信且未被篡改的环境中处理，这需要密码学证明。现有的解决方案，特别是Confidential Containers (CoCo)，强制采用严格的“每个Pod一个虚拟机”模型，仅证明客户操作系统栈，而忽略了容器级别的身份验证，并且每个虚拟机带来巨大的资源开销。本文提出了dstack-capsule，一个基于Kubernetes的平台，在Intel TDX上实现了Pod级别的远程证明。其核心思想是两层证明架构：静态平台测量通过不可逆的特权熔断机制冻结在RTMR[3]中，而动态Pod身份（pod_uid、pod_spec_hash、workload_id）嵌入在TDX Quote的report_data字段中，每次请求由硬件签名。dstack-capsule引入了以下主要贡献：(1) Pod级别证明协议，将Pod规范摘要绑定到硬件签名的Quote上；(2) 特权熔断机制，将节点从设置模式原子性地转换到安全模式；(3) 多层沙箱，涵盖存储、运行时、准入、API和网络隔离层；(4) 基于Kubernetes 1.32、Intel TDX和Sysbox的完整开源实现。实验评估了安全属性、证明正确性和性能特征，表明dstack-capsule实现了Pod粒度的验证，而无需每个虚拟机隔离的资源开销。该工作适合对机密计算、Kubernetes安全以及硬件辅助信任执行环境感兴趣的安全工程师和研究人员。

该论文针对AMD SEV（安全加密虚拟化）技术缺乏形式化安全保证的问题，提出了一套形式化验证框架。AMD SEV是机密计算中的关键技术，通过硬件内存加密保护虚拟机内敏感数据。然而，现有实现缺乏对安全性属性的严格证明。研究首先对AMD SEV规范进行设计级和属性级抽象，建立精确的模型，然后通过属性检查（property checking）验证机密性、完整性和可用性（CIA三元组）。该方法为定义和验证执行环境的关键安全属性提供了严谨的数学基础。实验表明，该框架能够有效捕获规范中的安全约束，并发现潜在的安全缺口。该工作适用于安全架构师、云服务提供商和形式化方法研究人员，有助于提升对AMD SEV安全性的信任度。

随着云原生技术的快速普及，多租户环境中的机密容器部署需求日益迫切。然而，现有基于微虚拟机（microVM）架构的机密容器设计，虽然增强了容器间隔离，但其复杂的软件栈导致较高的启动延迟和资源开销，不适合短期容器工作负载。本文提出 Fasco，一种基于 ARM 机密计算架构（CCA）的轻量级机密容器运行时。Fasco 将每个容器直接实例化为独立的容器域（Container Realm），利用 CCA 的硬件强制隔离机制，确保容器内应用数据的机密性和完整性。此外，Fasco 引入专门系统域（System Realm）为容器域提供系统服务和资源管理。通过异常转发和共享缓冲区，Fasco 保证不同容器域之间的隔离。作者在 ARMv8 硬件上实现了 Fasco 原型并进行了性能评估，实验结果表明，Fasco 相比现有机密容器架构，显著降低了启动延迟和性能开销，同时保持了较小的可信计算基（TCB）。该工作为机密容器提供了一种更轻量、高效的实现方案，特别适用于函数计算、微服务等短期容器场景。

本文实证研究了在Intel SGX2安全区内运行Arrow-native DataFrame引擎Polars的性能特性。作者使用Gramine作为LibOS，在TPC-H SF30基准测试集（约22-73 GB）和Azure Blob Storage环境下，测量了端到端、仅查询和表加载三种性能开销。实验发现，端到端开销相对稳定在1.49-1.56倍，但分解后显示：仅查询开销从1.51-1.52倍下降至1.43-1.44倍，而表加载开销则从2.27倍上升至4.07倍，说明数据摄入是主要瓶颈。查询级分析显示，中位数SGX减速为1.45倍，最大2.57倍，部分查询因状态性EPC压力出现运行时间剧烈波动。此外，比较了Polars的惰性（lazy）与急切（eager）两种API，惰性执行整体快2.25-2.27倍，而急切执行在41 GB及以上时因内存不足失败。与近期DuckDB-SGX2研究对比，结果表明SGX2支持Arrow-native分析处理的额外开销与SQL引擎相当，但加载路径放大和API级优化是影响端到端性能的主要因素。该研究为机密分析工作负载在TEE中的部署提供了定量参考。

本文提出EBCC（Enclave-Backed Confidential Containers），一种兼容OCI（Open Container Initiative）的运行时架构，旨在将机密计算工作负载无缝集成到标准容器生命周期管理中。现有机密容器系统通常依赖虚拟机后端或特定TEE的执行基板，导致机密执行与常规OCI运行时生命周期分离，增加了部署和管理的复杂性。EBCC将REE（富执行环境）侧的锚点和TEE（可信执行环境）侧的机密阶段视为一个单一的容器化机密计算复合体，保留标准OCI生命周期操作（如创建、启动、停止、删除），并将TEE特定执行逻辑封装在后端适配器之后。它维护每个实例的持久状态和每个阶段的工件，用于请求处理、响应生成、日志记录和证据绑定。作者在Keystone TEE后端上实现了EBCC原型，并评估了其正确性、性能、内存占用和并发行为。结果显示，EBCC相比原生Keystone执行引入了额外延迟，主要来自生命周期中介、请求验证、EID分配、后端分发和工件持久化，但额外开销集中在主机端管理状态。跨TEE案例研究（SGX、TDX、OP-TEE）表明，相同的生命周期和阶段抽象可以映射到enclave风格、VM风格和嵌入式风格的TEE。这些结果表明EBCC能够使基于TEE的执行通过OCI风格的生命周期进行管理，而不会显著扩大受保护侧的TCB（可信计算基）。

近期的研究工作反复证明了侧信道攻击能够破坏可信执行环境（如Intel SGX）的机密性保证。与此同时，云环境中的可信执行正朝着机密虚拟机（CVM）方向发展。不幸的是，一些侧信道攻击在CVM上依然可行，并且新发现了针对CVM架构的攻击。以往工作探索了保护用户空间飞地（如Intel SGX）免受侧信道攻击的防御措施，但基于CVM的混淆执行引擎的设计空间在很大程度上尚未被探索。本文提出了一种名为INCOGNITOS的unikernel设计，为基于CVM的云工作负载提供全系统混淆。INCOGNITOS完全拥抱unikernel原则，如最小化可信计算基（TCB）和直接硬件访问，使得全系统混淆成为可能。INCOGNITOS改造了两个关键操作系统组件——调度器和内存管理，以实现一种新颖的自适应混淆方案。INCOGNITOS的调度器设计为通过同步滴答传递，从不可信hypervisor的定时器中断中实现自主权。这使得INCOGNITOS能够可靠地监控hypervisor执行控制权（即VMExit）的频率，并调整由分页子系统执行的内存重随机化频率，该子系统通过直接MMU访问透明地执行内存重随机化。最终的INCOGNITOS设计为自混淆unikernel作为安全的CVM部署策略提供了依据，同时与以往工作相比进一步推进了混淆技术。评估结果表明，INCOGNITOS对CVM攻击具有弹性，并且其自适应混淆方案为实际程序提供了可接受的性能。

本文是一篇关于机密计算（Confidential Computing, CC）如何保障自主AI代理系统安全的综述。随着LLM驱动的代理系统（如基于MCP和A2A协议进行规划、调用工具、维持持久内存以及委托任务的系统）的兴起，其暴露的攻击面显著不同于独立的模型推理。这类代理积累敏感上下文、持有凭证，并在多方不完全控制的流水线上运行，从而面临提示注入、上下文窃取、凭证盗取以及代理间消息投毒等威胁。当前防御完全在软件栈内实现，容易被具有足够特权的攻击者（如被攻陷的云运营商）静默绕过。机密计算提供了一种基于硬件的替代方案：可信执行环境（TEE）将代理代码和数据与特权系统软件隔离，远程证明则能在分布式部署中建立可验证的信任。本综述从四个部分综合设计空间：（i）对六种TEE平台（Intel SGX、Intel TDX、AMD SEV-SNP、ARM TrustZone、ARM CCA和NVIDIA H100 CC）的统一分类，涵盖部署角色和性能权衡；（ii）一个以代理为中心的威胁模型，涵盖感知、规划、记忆、行动和协调层，映射到九个安全目标；（iii）对基于CC的防御的对比调查，区分了从单次调用推理中迁移的发现与需要全新代理设计的发现；（iv）六个开放挑战，包括多跳代理链的复合证明以及LLM规模的GPU-TEE性能。尽管多个硬件信任基元在针对性部署中已足够成熟，但尚未有广泛建立的端到端框架将它们绑定为生产级代理AI的连贯安全基座。本文适合AI安全研究人员、系统架构师和云基础设施开发者阅读。