在机密计算领域，Gramine 与 Occlum 都是基于 Intel SGX 的可信执行环境框架，但设计哲学差异明显。Gramine 通过兼容层把原生 Linux 二进制直接载入 enclave，Occlum 则实现了一套轻量 LibOS 让用户态程序运行在自身构建的文件系统与系统调用子集上。将二者以容器化方式封装，可以在不改变现有 DevOps 流程的前提下，灵活切换或并存不同的可信应用形态。
Gramine 与 Occlum 的核心架构差异
Gramine 的前身是 Graphene，它的核心是一个负责拦截系统调用的 PAL（Platform Adaptation Layer）。当我们在 SGX 环境中启动一个未经修改的 Nginx 或 Python 解释器时，Gramine 会把这些程序的系统调用翻译成 enclave 内可安全处理的形式，并将多数逻辑留在原生二进制中。这种做法的优势是迁移成本极低，只要提供签名配置文件就能把现成应用关进飞地。但缺点是系统调用转发会带来一定性能损耗，并且应用依然依赖外部宿主的部分资源视图。
Occlum 走的是另一条路：它不追求直接运行任意 Linux 二进制，而是提供一个类似操作系统的运行时，包含自己的根文件系统、内存分配器和网络栈。开发者需要把程序交叉编译或适配到 Occlum 的 LibOS 上，之后整个应用连同依赖都被打包为一个不可分的 enclave 镜像。由于系统调用在内部闭环处理，Occlum 对宿主的攻击面更小，也更容易做形式化验证。其代价是初期适配工作量偏高，尤其是涉及复杂动态链接或特定内核特性的软件。
从容器化视角看，这两种框架对镜像的要求不同。Gramine 容器通常包含一个极薄的运行时加上原始二进制与 manifest，Occlum 容器则内置了 LibOS 和打包后的 fs.img。在 Kubernetes 里，它们都能以相同 Pod 规范调度，只是 init 流程和 device-plugin 对 SGX 设备的暴露方式略有区别。理解这些差异是后续混合部署的基础。
容器化封装时的构建与签名流程
要把 Gramine 应用容器化，一般先在 Dockerfile 里安装 gramine-sgx 工具链，再把编译好的二进制和手写 manifest 复制进去。manifest 中必须声明 permitted 文件、加密密钥以及 enclave 大小。构建镜像后，由于 SGX 要求对 enclave 签名，通常会在节点侧挂载注入私钥，或在构建阶段使用测试签名。下面给出一个简化的 Gramine 容器构建片段：
FROM ubuntu:22.04 RUN apt-get update && apt-get install -y gramine-sgx COPY myapp /app/myapp COPY myapp.manifest /app/myapp.manifest WORKDIR /app CMD ["gramine-sgx", "myapp"]
Occlum 的容器化更强调 occlum build 这一步。开发者先写 Occlum.json 描述内存布局和挂载点，然后运行工具把用户程序与 LibOS 揉成单一镜像。容器启动时只需执行 occlum run。因为 Occlum 把文件系统虚拟化了，所以容器内看不到传统 Linux 目录树，这要求日志和配置必须通过 Occlum 的 mount 机制预先安排。示例构建指令如下：
occlum init cp ./server /opt/occlum/instance/image/bin/ occlum build occlum run /bin/server
签名方面，Occlum 同样依赖 SGX 签名私钥，但它把签名嵌在构建出的镜像头里。生产环境务必使用合规的证书链，并在 CI 流水线中用保密仓库管理密钥。容器化并没有消除 SGX 的信任根要求，只是把繁琐的本地环境配置转移到了镜像层和编排层。
混合部署场景与性能权衡
实际业务中，我们可能用 Gramine 快速包裹一个遗留的 Java 服务，同时用 Occlum 承载新写的 Rust 数据处理模块，两者通过容器网络互相调用。这种混合部署让团队不必一次性重构所有代码，却能逐步收获 enclave 保护。在节点上，SGX 驱动通过 /dev/sgx_enclave 暴露设备，容器运行时需配置 privileged 或 device 白名单。由于每个 enclave 占用 EPC 内存，调度器应限制单节点上机密容器的密度。
性能上，Gramine 的 syscall 拦截在文件密集场景下延迟较高，Occlum 的内部 LibOS 调用更快但启动时要做镜像校验和加载。我们曾用对照测试跑相同加解密任务：Gramine 启动快约 0.4 秒，但每秒事务少一成；Occlum 启动慢 1.2 秒，稳态吞吐更稳。容器化引入的层叠加和 cgroup 限制会轻微放大这些差距，因此资源请求要按实测留余量。
另一个常被忽略的点是调试。Gramine 支持 gramine-sgx-debug 模式输出飞地内日志，Occlum 则有 occlum console 命令。在容器里使用这些工具时，需要把对应字符设备挂入并关闭生产签名校验。建议为排障单独准备 debug 标签的镜像，避免把调试通道留在线上机密容器里，防止信息泄露。
运维监控与合规落地建议
容器化 Gramine 与 Occlum 之后，传统 Prometheus 导出器若跑在 enclave 外，只能看到代理指标。更稳妥的做法是在 LibOS 或 PAL 侧集成轻量 metric 接口，通过本地 Unix 套接字由 sidecar 容器拉取。这样既能监控 enclave 内 CPU 真实占用，又不破坏隔离边界。对于 Occlum，可在 Occlum.json 中开放特定端口映射给监控容器。
合规层面，金融与医疗场景常要求证明代码未经篡改。SGX 的远程证明（DCAP 或 EPID）应与容器启动钩子绑定：只有拿到有效 quote 才允许流量进入。我们可以将 Gramine 的 verify 步骤和 Occlum 的 report 获取写成 Init 容器，主容器等待证明通过后再起服务。下表列出两者证明集成要点：
| 框架 | 证明产物 | 容器集成方式 |
|---|---|---|
| Gramine | 基于 manifest 的 SGX quote | Init 容器调用 gramine-sgx-verify |
| Occlum | LibOS 生成 report 经 PCA 签名 | sidecar 拉取 occlum report 并上报 |
最后，镜像仓库需启用签名与扫描，防止恶意层替换 enclave 配置。由于 Gramine 和 Occlum 都依赖宿主内核的 SGX 驱动版本，集群升级前要确认驱动兼容，否则容器可能起不来或降级到模拟模式。把以上环节写成 GitOps 清单，就能在常规发布中无缝带上机密计算能力。