【论文】Building Verifiable Trusted Path on Commodity x86 Computers

论文思路整理

背景

已有工作缺陷

1. These systems employ only a small number of user-oriented I/O devices (e.g., a keyboard, mouse, or video display), and a small number of trusted programs (e.g., login commands and administrative commands).
2. These mechanisms use a smaller, more trustworthy kernel running with higher privilege than the OS, it does not provide a mechanism that enables isolated modules to communicate with devices without going through the OS
3. These work only demonstrates how to isolate device driver address spaces and Direct Memory Access (DMA). It does not fully isolate devices from compromised OS code in other administrative domains (e.g., system-wide configurations for I/O ports, Memory-Mapped I/O (MMIO), and interrupts remain unprotected).

挑战

OS 恶意将某个设备的 MMIO 区域和受害设备 MMIO 区域设置为重叠 => MMOIO Mapping Attack

OS 恶意设置设备的中断向量空间 => Interrupt Spoofing Attack

贡献

1. 建立可信路径
2. 很小的 TCB
3. 提出对于 x86 平台的建议
4. 验证

Threat Model

恶意 OS，可以访问任何系统资源，破坏任何隔离机制

The adversary can then leverage the compromised OS to actively reconfigure any device (e.g., modify a device’s MMIO region, or change the operating mode of a device) and induce it to perform arbitrary operations (e.g., trigger interrupts, issue DMA write requests) using any I/O commands.

OS 指恶意 OS，device 指恶意设备

可信路径的组成部分

Program Endpoint (PE) – Communication Path (CP) –> Device Endpoint (DE)

1. PE Isolation: OS 和 device 无法访问或破坏 PE 的任何有关可信路径的数据
2. Device Endpoint Isolation: PE 传输给 DE 的数据不能被 OS 修改或访问，同时 DE 产生的中断必须只能交给 PE
3. Communication Path Isolation: 确保可信路径上所有硬件设备都满足 Device Endpoint Isolation 的要求

论文假设 BIOS 等固件是可靠的，并且硬件都按照规格正常运作

系统架构

Trusted-Path Hypervisor

HyperVisor 是一个小型内核，将 OS 视为一个顶端的进程，该进程可以在大多时候管理多数设备。PE 在虚拟机中作为一个被隔离的进程，并将相关驱动放入 PE 中做隔离。

Program Endpoint

将 DE Driver 防止到 PE 内部的三大原因：

1. 论文目标是构建一个小型的 HyperVisor
2. 所有对于 PE code 的保护方式都可以运用到 DE 上
3. 需要保护的 DE Driver 一般很小，PE 可以只保留其中必须的部分来简化设计

将 DE Driver 放置于用户/内核空间的优点：

1. 允许驱动更新或修改，而无需调整用户代码
2. 省去了 OS 和 PE 中驱动版本同步的问题

将 DE Driver 放置于用户/内核空间带来的安全问题：

1. PE 和 DE Driver 之间的通信需要新增一条安全的信息通道
2. DE Driver 的隔离需要额外的机制来实现

Device-Isolation Challenges

单纯的驱动隔离和程序隔离不足以实现可信路径，因为系统中存在大量的 “共享设备配置状态”：

1. I/O 端口：所有设备共享相同的 I/O 端口空间，OS 可以恶意的重构 I/O 端口映射
2. MMIO region：所有设备共享 MMIO region 机制，OS 可以恶意的修改不同设备的 MMIO 映射
3. Interrupt Space：所有设备共享软件/硬件中断机制，OS 可以恶意向 MSI 寄存器或 LAPIC 寄存器中写入值发送假中断

Hypervisor Design

Protection of I/O-Port Access

Preventing Port-mapping Conflicts

攻击者手段：将 device I/O 端口恶意修改成覆盖 DE I/O 端口，所有发往 DE 的数据都会被 device 接收

方案：执行 PE 前，由 HyperVisor 扫描枚举所有设备，检测它们的 I/O 端口。保证所有 I/O 端口的映射不会被 OS 或 device 篡改

Confining I/O-port Access

方案：HyperVisor 通过配置 VMCS region 中的 I/O port-access-interception bitmap，防止 PE 访问非 DE 端口，防止 OS 访问 DE 端口

Protection of Device-Memory Access

Preventing MMIO Mapping Attacks

方案：扫描 PCIe 配置空间，检查不同设备的 MMIO 映射区域，防止 OS 篡改 MMIO 映射

Preventing Unauthorized Memory Access

攻击者手段：OS 直接访问 DMA/MMIO Buffer

方案：利用 HyperVisor 的 EPT，将这些区域设置 EPT trapping。同时设立 IOMMU，区分不同设备的 DMA Buffer 不会重叠（前提是，IOMMU 可以正确识别 DMA 请求）

Protection of Device Configuration Space

保护 MMIO 区域，DMA 区域，I/O 端口不被篡改和核心是保护设备配置空间。HyperVisor 保证只有 PE 可以访问 DE 的配置空间并且拒绝一切来自 OS 的访问 DE 配置空间的请求。

而设备配置空间的访问通过 MMIO 或 I/O 端口，看似出现了循环依赖：保护设备配置空间依赖于 MMIO/DMA/IO ports，保护 MMIO/DMA/IO ports 依赖于保护设备配置空间。

但实际上，即便 MMIO 和 I/O ports 被 OS 恶意攻击（DE 和 device 的 MMIO 重叠），PCIe 对于设备配置空间的访问也不会受到影响，因为 PCIe 转发事务包是根据设备在架构/总线上的地理位置决定的。

故 HyperVisor 只需要配置 I/O ports-access-interception bitmap，EPT，IOMMU 即可保护 MMIO/DMA/IO ports 配置。