【近期工作】MOAT: Towards Safe BPF Kernel Extension

作者：Hongyi Lu, Shuai Wang, Yechang Wu, Wanning He, Fengwei Zhang

会议：USENIX Security' 24

关键词：Kernel, eBPF, MPK

背景介绍

Linux 内核大量使用 BPF 来进行安全可靠的内核拓展。相较于常规的内核模块，BPF 程序在加载前都会经由 BPF Verifier 进行静态分析。Verifier 确保了 BPF 程序不包含可能危害到 Kernel 的代码，例如：

• 空指针访问
• 死循环
• 越界访问不属于 BPF 程序的内存

然而，静态分析不可能做到完美，Verifier 作为唯一确保 BPF 程序安全性质的工具，时常被安全人员发现漏洞。由于 BPF 程序的特殊性，这类漏洞通常都具有极高的危害性，往往能直接带来内核提权等严重安全后果。

为此，我们提出了 MOAT，利用 Intel MPK 这一安全特性，对 BPF 程序进行硬件隔离，从硬件层面上阻止了 BPF 程序对内核发起攻击。我们还利用了 PCID 来减少 MOAT 页表冲刷对内核性能的影响。

BPF 验证流程

在加载进内核之前，BPF 会经过一系列 Verifier 的安全验证流程，如下图所示。为了确保 BPF 程序不会进行越界访问，Verifier 会对 BPF 程序进行数据流分析，然而，完整且可靠的数据流分析是非常困难的，这也是 Verifier 最常见的漏洞来源之一。

BPF 程序结构

如下图所示，除开 BPF 程序本身，BPF 程序还会使用 BPF Map 与 BPF Helper。

• BPF Map 是 BPF 独有的数据结构，用于存储各种类型的数据以及和用户态进行通讯。
• BPF Helper 是内核提供给 BPF 的一套专属 API，使 BPF 程序能够对内核进行各种操作。

Intel MPK

Intel MPK 利用页表项中的 [62:59] 这四个比特来标志内存页所属的区域。并且允许开发者通过 PKR 寄存器来快速切换不同区域的权限，如下图所示。

隔离机制设计

下图为 MOAT 的总览。对于一个 BPF 程序，我们会将其所使用的内存区域（Stack, Map and Context）利用 MPK 标志出来，并且在 BPF 程序运行时，只允许 BPF 程序访问这些区域来阻止 BPF 程序对内核的攻击。为此，我们设计了一套双层隔离机制，MPK 负责阻止 BPF 程序恶意访问内核，MMU 负责阻止恶意 BPF 程序访问正常的 BPF 程序。

除此之外，我们还设计了一套 BPF Helper 的安全机制，通过验证 Helper 参数以及动态的在 BPF Helper 执行过程中保护内核对象来确保 Helper 不会被恶意 BPF 程序所利用。

第一层隔离：MPK

MPK 的一大缺陷即为其只支持 16 个隔离区域，无法支持大量的 BPF 程序的隔离。为了克服这一困难，MOAT 只利用 MPK 来进行 BPF 与内核之间的隔离。

如上图所示，我们只使用 MPK 分配三个区域，内核区域，BPF 区域以及共享区域。在 BPF 程序执行时，内核区域被设为不可访问，以确保 BPF 程序不会攻击内核。共享区域则负责存储 GDT 与 IDT 等中断等底层函数所必需的数据结构。

第二层隔离：独立的 BPF 地址空间

尽管第一层隔离确保了内核的安全性，但 BPF 程序之间仍存在相互破坏的可能。尽管我们并没有观察到已有的案例，然而 BPF 通常使用 BPF Map 来存储各类配置数据，一个恶意的 BPF 程序完全可以通过修改另一个 BPF 程序的 Map 来改变其行为，以此达成目的。

为此我们设计了基于页表的第二层隔离机制。如上图所示，BPF 程序只拥有其自身的页表映射，这阻止了恶意 BPF 程序对其他 BPF 程序进行破坏。然而，该机制带来了另一个问题，即频繁的页表冲刷会严重影响内核性能。为了解决这一问题，我们利用 PCID 来区分不同 BPF 程序的 TLB 表项，并且通过 BPF 共享内核映射以及将内核内存标记为全局，来阻止内核页表项被冲刷。

Helper 安全机制设计

隔离机制确保了 BPF 程序不会利用内存安全漏洞破坏内核，然而，BPF 程序仍可能通过将不合法的参数传递给 BPF Helper 函数来攻击内核。为此，我们设计了下面两种安全机制。

关键对象保护

我们观察到，BPF Helper 在运行时，并不会访问所有的与 BPF 相关的内核对象。于是我们通过分析以往的 CVE，来找出那些容易被攻击利用且 Helper 不应该访问的对象。通过人工分析的方式，我们一共确定了 44 个对象，这类对象大多是 BPF 用于实现动态派发的函数指针，只应该被来自用户态的系统调用访问。对于这类对象，一种常见的攻击方式是利用内存漏洞覆盖这些函数指针，来实现针对内核的任意代码执行。

如上图所示，我们将这类对象放置于一个额外的 MPK 区域中（MOAT 将使用总计 3+1 个区域），并且在 Helper 程序执行时禁止 Helper 访问这类区域。

Helper 参数验证

前面提到，BPF Verifier 实际上会检查 BPF 中变量的范围，我们将 Verifier 所期待的范围提取出来，并且对 BPF 程序进行插桩，来在运行时检查 BPF 所传入的参数是否合法，如上图所示。

“

为什么在 Verifier 可能存在漏洞的情况下该检查仍有作用？

因为目前 BPF Verifier 出现的问题并不是其期待的范围出错，而是其推导出的变量的值与实际运行时的值不一致，因此 MOAT 通过在运行时检查的方式，来直接检查实际运行时的值。

安全分析

我们分析了 MOAT 所面临的各类攻击面，以确保 MOAT 的安全性。

1. 直接攻击内核内存
2. 利用 Helper 攻击内核
3. 修改 PTE 以绕开 MPK
4. 修改 GDT/IDT 以攻击内核
5. 修改 PKR 寄存器以关闭 MPK
6. 跳转到 ROP Gadget
7. PKU Pitfall 中提到的攻击

除开理论分析之外，我们也分析了所有已知的 BPF 内存 CVE，对于有 PoC 的 CVE，我们直接进行复现以确保 MOAT 能够防御，对于没有 PoC 的 CVE，我们通过分析其原理确认 MOAT 能够防御。

性能测试

我们也对 MOAT 展开了一系列性能测试，包含如下内容。

• 在加载 685 个 BPF 程序的情况下运行 UnixBench
• 在同一挂载点加载 1，10，32，64，128 个 BPF 程序的情况下，进程创建的效率
• 加载各类包过滤器(XDP, SKB)时，BPF 的网络转发性能
• 加载各类追踪点时，BPF 的内核追踪性能
• 加载各类 SECCOMP-BPF 过滤器时，Nginx 的请求处理性能

（具体数据请见我们的原始论文，在大部分场景下，MOAT 的开销均低于 10% ）

我们也使用了之前工作 SandBPF 的测试用例测试了 MOAT，由于 SandBPF 的作者回复称不打算开源，因此下表中的数据只有相对性能开销有参考意义。

总结

MOAT 利用 MPK 等硬件特性，为 BPF 程序提供了完善的保护机制。

艰难困苦，玉汝于成 --- 张载