【机密计算顶会解读】01：BlackBox——用于保护不受信任操作系统上的容器安全监视器

导读：本文介绍BlackBox系统架构，其核心组件CSM，提供轻量化安全监控，使容器在不可信操作系统上安全运行。

原文链接：BlackBox: A Container Security Monitor for Protecting Containers on Untrusted Operating Systems | USENIX

BlackBox: A Container Security Monitor for Protecting Containers on Untrusted Operating Systems （OSDI‘22）

一、研究背景

容器作为共享计算基础设施的核心，广泛应用于应用程序的部署、打包和隔离。

1. 相比于虚拟机技术：容器具有资源占用更少、启动速度更快、IO性能更优的特点。
2. 相比于基于硬件Enclave的技术：容器更便于开发，而往往Enclave要求开发者对应用进行代码改写，并带来显著的CPU计算开销。

从上表可知，容器相比于虚拟机和硬件Enclave有更好的性能表现。然而，容器的安全依赖于底层特权操作系统，例如Linux，这类商用操作系统因代码量庞大且复杂，存在较多漏洞，攻击者可以通过利用这些漏洞，对容器中的数据和内容发起攻击。所以当前仍缺乏一种能够兼顾轻量化和安全性的容器解决方案。

二、BlackBox：安全轻量的容器设计方案

2.1 系统架构

如图一，系统整体依赖一个核心组件container security monitor (CSM)。CSM作为一个轻量化的安全监视器，专注于保障容器的数据机密性和完整性。与传统的虚拟化技术不同，CSM 不负责硬件资源的虚拟化管理，而是引入了一种受保护的物理地址空间（PPAS），通过内存隔离保护每个容器的运行环境。

CSM 的核心功能：

1. 内存访问控制
   • 每个容器分配一个独立的 PPAS，CSM 通过限制内存的访问范围，实现物理内存隔离。
   • 容器只能访问自身的 PPAS，OS 无法访问容器内的内存数据。
2. 系统调用和上下文切换保护
   • CSM 拦截所有容器与 OS 的交互（如系统调用、中断和异常），确保容器的 CPU 寄存器和内存状态在切换到 OS 时被保存和清理，避免 OS 未授权访问容器数据。
   • 在从 OS 返回容器时，CSM 恢复容器上下文，并验证 CPU 和内存状态的完整性。
3. 提供应用程序二进制接口（ABI）
   • 为 OS 提供接口（如创建和销毁 enclave 的 API），允许操作系统请求服务，但所有这些请求都需经过 CSM 的安全验证。
4. 内存管理辅助
   • OS 可以分配内存，但无法直接操作容器的页表，所有修改需由 CSM 检查，防止 Iago 攻击等基于内存的攻击。
5. 简化可信计算基（TCB）
   • CSM 不涉及 CPU 调度、虚拟设备管理或中断处理等复杂功能，降低了 TCB 的规模和复杂性。
   • CSM 依赖 OS 提供传统功能，如文件系统、中断管理和设备驱动，但通过严格的检查避免信任 OS。

2.2 BlackBox系统的启动和初始化

BlackBox的启动依赖硬件信任链和操作系统的引导流程，通过 UEFI 和签名验证，确保只有经过认证的 CSM 和操作系统内核能加载运行。CSM 的引导过程借助操作系统现有的启动代码，这不仅简化了 CSM 的设计，还提升了兼容性。在操作系统完成硬件初始化后安装 CSM，此时网络和存储等服务尚未启用，能有效避免远程攻击的风险。安装完成后，CSM 以比操作系统更高的权限级别运行，隔离和保护容器的内存。通过控制 IOMMU，CSM 还能防止设备通过 DMA 攻击访问容器或自身内存，从而为容器提供一个安全的运行环境。

2.3 BlackBox初始化一个安全容器

BlackBox使用 build_bb_image工具将普通镜像转化为BlackBox镜像，镜像中的代码和数据会被加密，并通过哈希值和签名确保其完整性。容器启动时，容器调用 CSM 的 create_enclave 接口创建一个隔离的容器环境，并将容器的内存转移到一个受保护的地址空间（PPAS）。在此过程中，操作系统无法直接执行加密的容器代码，必须通过 CSM 解密。容器销毁时，CSM 会清除容器的内存和 CPU 状态，确保信息不会泄露。整个流程确保容器的完整性和机密性，防止操作系统的干扰和篡改。

2.3 BlackBox中安全容器执行任务

每当操作系统通过 fork、clone、exec 或 exit 系统调用创建或管理任务时，它必须调用相应的 CSM 接口（如 task_clone、task_exec 和 task_exit），否则任务将无法在容器中执行。对于任务创建，CSM 会验证任务的 CPU 状态和内存，确保其地址空间不被操作系统直接修改。如果任务是通过 fork 或 clone 创建的，CSM 会为子任务分配新的页表，并确保子任务的内存与父任务隔离。执行时，CSM 会验证新的地址空间并解密相应的二进制文件，确保任务能够在容器内正确运行。任务退出时，CSM 会清理相关资源并移除任务条目，确保容器内的内存和状态不被操作系统访问。整个过程确保任务在容器中的执行受到保护，不受操作系统干扰。

2.4 BlackBox中的内存隔离

BlackBox通过要求操作系统调用 CSM 来更新进程的页表，防止操作系统直接修改页表，从而确保内存管理的安全性。对于内存映射的管理，CSM 会验证内存映射是否符合预定义的规则，例如检查是否存在重复映射、是否允许写操作等。在内存页分配时，操作系统必须通过 CSM 来请求分配，并且 CSM 会验证这些请求是否符合容器的内存保护规则。 BlackBox还支持写时复制（CoW）内存优化，当多个进程共享同一内存页并尝试写入时，操作系统通过 CSM 调用来处理复制操作，确保容器内存的完整性。对于释放内存，BlackBox通过拦截相关系统调用来确保容器的内存不会被误释放，维持容器内存的隐私性和完整性。 总体来说，BlackBox通过将内存管理的部分任务交给 CSM 来防止恶意操作系统对容器内存的直接访问，同时确保容器内存的隐私和安全性。

2.5 BlackBox中容器内任务之间的进程间通信

在 BlackBox中，当类似于 pipe 和 Unix 域套接字的系统调用用于进程间通信时，容器会将需要传递的数据加密并拷贝到系统调用的共享内存中（这种机制同样适用于 read 和 recvmsg 等调用）。为了实现同步，BlackBox使用 futex，并通过 CSM 提供一个新的接口，允许操作系统通过该接口读取容器中已经存储的 futex。 此外，BlackBox还实现了信号通知机制。由于操作系统需要创建信号处理的堆栈，且该堆栈不能直接位于容器的内存空间中，操作系统会将信号栈放置在 PPAS 之外。在信号处理过程中，CSM 会将栈移到 PPAS 中，处理完信号后再将其移回 PPAS 之外。

三、实验设置及结果

3.1 实验设计

实验使用了两种硬件平台：

1. Raspberry Pi 4 (Arm 架构)：4 核 Cortex-A72 1.5 GHz，8 GB RAM，250 GB SSD，Gigabit 以太网，运行 Raspberry Pi OS Buster。
2. AMD Seattle Rev.B0 服务器：8 核 Cortex-A57 2 GHz，16 GB RAM，512 GB HDD，10 GbE NIC，运行 Ubuntu 16.04。

客户端运行在 Lenovo ThinkPad P52，配备 Intel i7-8750H 处理器和 32 GB RAM。

实验在以下五种配置下运行：

1. Basline配置：原生运行于主机，没有容器。
2. Docker配置：使用未经修改的 Linux 容器。
3. BlackBox NS配置：BlackBox 在 Docker 上运行传统 Linux 容器，但不启用安全隔离（用于量化无安全隔离时的开销）。
4. BlackBox NE 配置：BlackBox 在 Docker 上运行 enclaved Linux 容器，但不启用 IPC 加密（用于量化没有加密时的开销）。
5. BlackBox Enclaved 配置：BlackBox 在 Docker 上运行 enclaved Linux 容器，并启用 IPC 加密。

3.2 实验结果

性能测量：

1. 系统调用开销：对于 read、write、open、close、select 等系统调用，BlackBox Enclaved 的开销大约是 Docker 的两倍，但仍显著低于基准配置（原生执行）。开销主要来源于系统调用参数在容器的 PPAS 和 OS 之间的复制。
2. fork 和 exec：这些操作的开销相较于 Docker 高，特别是在验证新进程的地址空间时，需要进行额外的检查，但这部分开销可以通过解密机制的优化来减少。
3. 页面错误：BlackBox NS 配置下，使用 NPT（Nested Page Tables）导致的开销比 Docker 大，启用容器隔离（enclaved）后，由于需要验证地址映射和防范潜在的攻击，开销更大。
4. IPC 加密：在 pipe 和 UNIX domain socket 测试中，启用 IPC 加密时，性能会受到较大影响，因为加密数据会增加额外的填充和认证数据，影响读写延迟。
5. 网络性能：BlackBox 在网络性能上表现良好，尤其是在没有虚拟化 I/O 的情况下，网络吞吐量表现与原生配置相当。

应用性能：

1. 在现实应用工作负载下，BlackBox Enclaved 相对于原生执行的开销较小，通常不到 15%。这表明 BlackBox 在 Arm 嵌入式和服务器硬件上的性能开销非常适中。
2. Apache、HAProxy、Nginx 的延迟和吞吐量表现显示，BlackBox 具有很好的吞吐能力，并且延迟增加较小。
3. MySQL 和 Memcached 的性能也显示了类似的结果，BlackBox 的开销低于 15%。

CPU 使用率：

1. 对比原生执行，BlackBox 在 Raspberry Pi 上的 CPU 使用率增加不到 15%，在 AMD 服务器上也保持在 15%以内，除了 Apache 工作负载的 CPU 使用率有所增加。这是因为在高吞吐量下，复制到系统调用缓冲区的额外开销会导致 CPU 使用率增加。

3.3 总结

结果表明 BlackBox 在容器安全保护方面提供了显著的安全性，且在性能上与传统 Docker 容器相差无几。虽然 BlackBox 在某些系统调用和 IPC 加密操作上会引入额外的开销，但在应用级别的负载下，这种开销相对较小，且 BlackBox 对容器机密性和完整性的保护表现出色。

本账号发布内容均为原创，欢迎转载，转载请注明出处。更多资讯请移步【机密计算前沿技术】服务号，欢迎交流！