Linux v5.6 安全特性深度解析：WireGuard、新系统调用与内核加固

Linux v5.6 于2020年3月发布。以下是我注意到的一些值得关注的功能的简要概述：

WireGuard 广泛使用的 WireGuard VPN 已经脱离内核树很长时间了。自其首次上游 RFC 以来，经过三年半的时间，Ard Biesheuvel 和 Jason Donenfeld 在 v5.5 内核中完成了所有加密先决条件的整理工作。在这个版本中，Jason 成功将 WireGuard 本身纳入内核。这是一条曲折的道路，我感谢所有参与其中的人坚持下来，并找到了妥协和替代方案。

openat2() 系统调用和 RESOLVE_ 标志* Aleksa Sarai 在内核的 open() 处理中添加了一些重要的路径解析“作用域”选项，包括不在路径层次结构中的特定点之上遍历（RESOLVE_BENEATH）、禁用 procfs（例如 /proc/$pid/exe）和其他伪文件系统中的各种“魔法链接”解析（RESOLVE_NO_MAGICLINKS），以及将给定的查找视为相对于不同根目录进行（如同在 chroot 中，RESOLVE_IN_ROOT）。作为其中的一部分，很明显无法正确扩展现有的 openat() 系统调用，因此他添加了 openat2()（这是一个很好的例子，展示了为“可扩展系统调用”参数进行规范化的努力）。RESOLVE_* 标志集还涵盖了之前的行为，如 RESOLVE_NO_XDEV 和 RESOLVE_NO_SYMLINKS。

pidfd_getfd() 系统调用 在急需的 pidfd API 的持续增长中，Sargun Dhillon 添加了 pidfd_getfd() 系统调用，这是一种以无竞争方式（或当 /proc 未挂载时）获取进程文件描述符的方法。在此之前，无法确保通过 /proc/$pid/fd/$N 打开文件描述符实际上会与正确的 PID 关联。关于此的更多细节已在 LWN 上撰写。

通过 io_uring 的 openat() 从我“减少攻击面”的角度来看，我个人对 io_uring() 系列 API 持怀疑态度，但我不能否认它们对某些工作负载的实用性。能够在不实际进行系统调用的开销的情况下管道化读取和写入，对性能来说非常棒。Jens Axboe 添加了 IORING_OP_OPENAT 命令，以便现有的 io_uring 可以打开文件，动态添加到给定 io_uring 的可用读取/写入目标映射中。虽然 LSM 仍然能够愉快地拦截这些操作，但我对 io_uring 日益成为“系统调用多路复用器”保持警惕。当然，我很高兴看到它有一个全面的（虽然是“树外”）测试套件作为 liburing 的一部分。

移除阻塞随机池 在对随机数算法进行更改以消除单独的熵池后，Andy Lutomirski 移除了阻塞随机池。这显著简化了内核 pRNG 代码，同时不损害设计用于获取“加密安全”随机数的用户空间接口。引用 Andy 的话：“这个系列不应该破坏任何现有程序。/dev/urandom 没有变化。/dev/random 在启动后仍然会阻塞，但阻塞的次数会比以前少。” 关于该系列的历史和讨论的更多细节，请参见 LWN。

arm64 对片上 RNG 的支持 Mark Brown 添加了对未来 ARMv8.5 的 RNG（SYS_RNDR_EL0）的支持，从内核的角度来看，这类似于 x86 的 RDRAND 指令。这将提供一种独立于引导加载程序的方法，为内核的 pRNG 添加熵，用于早期启动随机性（例如栈金丝雀值、内存 ASLR 偏移等）。在人们运行在 ARMv8.5 系统上之前，他们可以继续依赖引导加载程序在 arm64 上提供随机性（通过 UEFI RNG 接口）。

arm64 E0PD Mark Brown 添加了对未来 ARMv8.5 的 E0PD 功能（TCR_E0PD1）的支持，这会导致从用户空间到内核空间的所有内存访问在恒定时间内发生故障。这是一种尝试，以消除在从用户空间探测内核内存布局时任何可能的时间侧信道信号，作为针对 Meltdown 式攻击的替代保护方法。期望是 E0PD 将用于替代 arm64 上更昂贵的内核页表隔离（KPTI）功能。

powerpc32 VMAP_STACK Christophe Leroy 向 powerpc32 添加了 VMAP_STACK 支持，加入了 x86、arm64 和 s390 的行列。这有助于防御各类依赖于耗尽内核栈以与相邻内核栈冲突的攻击。（另一个常见目标，敏感的 thread_info，已在 Linux v5.1 中由 Christophe Leroy 从栈底部移开。）

通用页表转储 与 RISCV 添加页表转储（通过 /sys/fs/debug/kernel_page_tables）的工作相关，Steven Price 从多个架构中提取了现有实现，并创建了一个通用的页表转储框架（然后重构了所有其他架构以使用它）。我很高兴有这个功能，因为我仍然记得当 ARM 没有可用的页表转储器时，我在尝试实现上游内核内存保护时延迟了一段时间。任何使架构更容易正确实现内核内存保护的事情都让我高兴。

以上就是目前的内容；如果您认为我遗漏了什么，请告诉我。接下来：Linux v5.7。

评论 (1)

1 条评论

随着 arm64 架构扩展，我们可能会在早期架构修订版上看到一些实现——一个实现可以提供新架构修订版的一些功能，而无需实现该修订版的所有强制功能。相反，v8.5-RNG 可能不会出现在 v8.5 系统上，因为它是可选的。评论者：Mark Brown — 2020年9月5日 @ 5:07 am