投资使用消毒用品

  • 项目负责人：phosek@google.com、shayba@google.com
  • 领域：工具链

问题陈述

内存安全 bug 仍然是影响安全性的高严重程度 bug 的根本原因。排错程序的存在还可以快速暴露严重的 bug 并找出根本原因，从而提高工程效率。尽管 Fuchsia 在此领域具有相对优势，例如不同软件之间的隔离更强，以及对内存安全系统编程语言的投资日益增多，但与其他平台一样，Fuchsia 仍然需要关注内存安全。

目前，Fucsia 使用了多种排错程序来检测内存安全 bug：

  • AddressSanitizer (ASan) 可检测出界访问实例、在释放 / 返回 / 作用域之后使用，以及双重释放。相应地，kasan 也会将其扩展到内核代码。
  • LeakSanitizer (LSan) 会检测内存泄漏。
  • UndefineBehaviorSanitizer (UBSan) 可检测依赖于未定义程序行为的具体问题。
  • 与之相关的是，Fuchsia 支持 libFuzzer，用于运行以覆盖率为导向的模糊测试，并检测上述排错程序可检测到的崩溃或问题。我们正在进行相关工作，以将内核系统调用模糊测试设置为以覆盖率为导向来改进。
  • 最后，Fuchsia 支持 GWP-ASan（aan 的采样版本）。相关工作正在进行中，以证明其在生产环境中用于检测现场 bug。

这些排错程序涵盖不能保证内存安全的 C/C++ 代码。它们还会检测 Rust 不安全块中的内存 bug，并发现 Rust 代码中的内存泄漏。

这些工具被证明可以有效发现 bug。如果未检测到 bug，开发者无需进行任何操作。检测到 bug 时，问题排查相对容易，因为排错程序提供了堆栈轨迹，用于轻松分析根本原因，并且它们表现出可重现的行为。

我们在 2020 年至 2021 年期间广泛部署了这三种排错程序，并成功修复现有 bug。得益于之前的专门工作，我们在 Fuchsia 上实现了运行时插桩支持。他们临时由志愿者和 20%的员工组成，目前已经结束。

不过，我们仍有改进的空间。尤其是：

  • 排错程序未覆盖一些依赖于硬件的代码，主要是由于运行时性能问题和自动化数据缺口所致。
  • 内核代码的排错程序落后于用户空间代码的排错程序。
  • 还存在其他类别的严重 bug，这些 bug 在其他地方（但尚未在 Fuchsia 上提供）支持，尤其是对于未初始化的读取和各种线程安全 bug。
  • 排错程序在系统中检测到特定测试边界以外的 bug 不是自动导致问题的，需要手动分类才能将其分配给负责人。

当 Fuchsia 团队加大对设备驱动程序开发和树外开发以及这两者的投入时，前两个问题尤其令人担忧。其他问题则是持续降低工程生产力的不足之处。

解决方案声明

在之前对 LLVM 编译器运行时插桩支持的投资的基础上，增加对排错程序的投资。具体而言：

支持更多排错程序，例如：

修复现有排错程序长期存在的问题，例如：

  • 已知的 UBSan bug。
  • 长期的 lsan 问题，例如测试间隙和竞态。
  • 与工程团队互动，打造修复排错程序 bug 的文化。偿还原有排错程序 bug 的技术债务。

调查机会并制定未来工作的路线图，例如：

  • 在更多配置（除 qemu 之外）中启用排错程序，以便跟踪 Fuchsia 的优先级。
  • 确切地确定在插桩下不会执行哪些代码（例如驱动程序和其他依赖于硬件的代码），并按优先级顺序缩小这些差异。
  • 衡量和量化消毒剂对 Fuchsia 的影响 - 发现的问题的规模和分布、问题的严重程度、从检测到修复的时间、技术债务清单以及克服这些问题的计划。
  • 研究新的机会，例如利用对排错程序的硬件支持（已在其他平台得到采用），或进行其他优化（例如在插桩 build 中进行内嵌）。
  • 考虑增加对 Rust 排错程序的投资，例如，在检查内存安全问题时突破 FFI 边界，或为 Rust 引入 UBSan 等效项。

依赖项

  • Sanitizer 调出工作将依赖 Fuchsia 工具链团队中的 LLVM 专业知识，因此应扩展到更多人，以提升团队健康状况。
  • 顶层字节忽略 (TBI) 等硬件加速功能要求所有传递指针的系统调用中的内核支持。
  • 在硬件上运行排错程序需要配置实验室设备，并且需要对 EngProd 团队构建和测试自动化容量和配置进行更改。
  • Sanitizer 变体和各种切换开关需要由 Fuchsia build 团队提供支持。

请注意，上述所有团队均已致力于保证排错程序的原则性，并定期召开会议。

风险和缓解措施

  • 有些工作（尤其是调配工作）可能需要几年时间才能演示和验证。这需要长期的投入、全心投入和耐心。
  • 一些对硬件插桩可行性的预期是推测性的，假设积极的结果可以跟踪其他平台上的先验技术，并且取决于具体的和未披露的目标硬件选择。