此页面由 Cloud Translation API 翻译。

RFC-0117 - 组件模糊测试框架

RFC-0117：组件模糊测试框架
状态	已接受
领域	测试
说明	一个 Fuchsia 原生的跨进程模糊测试框架。
问题	24740
Gerrit 更改	529348
作者	aarongreen@google.com
审核人	abarth@google.com anmittal@google.com crjohns@google.com jsankey@google.com jeremymanson@google.com mvanotti@google.com” satsukiu@google.com shayba@google.com shrike@google.com
提交日期（年-月-日）	2021-05-24
审核日期（年-月-日）	2021-07-28

修改此 RFC

修改 RFC 元数据

摘要

引导式模糊测试可有效减少错误并增加对平台有信心，但目前还没有提供模糊测试框架可以跨多个进程边界进行模糊测试（如 Fuchsia 中）组件拓扑本文档针对此类框架，可跨流程共享覆盖率和测试输入以及在测试领域内进行，允许组件在其最主要的典型配置

设计初衷

程序测试可用于显示是否存在 bug，但绝不能显示他们的失踪！

--Edsger W.Dijkstra

引导式模糊测试是指在反馈环中测试软件的过程，生成的数据：

模糊测试工具生成一些测试输入数据，并使用这些数据来测试 target 软件进行比较。
如果测试结果失败，模糊测试工具会记录输入并退出。
目标软件会生成由模糊测试工具收集的反馈。
模糊测试工具根据反馈生成其他测试输入，并重复该输入。

引导式模糊测试对于查找与项目要求无关（因此通常未经测试）。通过自动测试覆盖率，还可以提高开发者的关键部分置信度系统的安全性、正确性和/或稳定性 注意事项。

可以使用以下分类来描述引导式模糊测试框架：
模糊测试分类

引擎：与目标无关的反馈环。
- 语料库管理：维护一系列模糊输入（ corpus）。记录新的输入并修改现有输入（例如合并）。
  - 种子语料库是一组精心设计的初始输入。
  - 实时语料库是一组持续更新的生成输入。
- Mutators：一组变更策略和确定性来源用于从语料库创建新输入的伪随机性。
- 反馈分析：根据反馈处理意见。
- 管理界面：与用户互动以协调工作流： <ph type="x-smartling-placeholder">
  - 使用特定输入来练习目标，即执行一次 模糊测试工具运行。
  - 对目标进行模糊测试，即执行一系列（可能是不确定的）模糊测试工具运行。
  - 分析或操纵给定语料库。
  - 响应检测到的错误和/或处理引发了该错误。
目标：进行模糊测试的具体目标领域。
- 输入处理：将单次运行的模糊测试工具输入映射到代码被测数据，例如例如通过特定函数、I/O 管道等
- 反馈收集：观察输入导致的行为。5 月收集硬件或软件跟踪记录、代码覆盖率数据、时间等。
- 错误检测：确定输入何时导致了错误。收集并记录测试工件，例如包括输入、日志、回溯等。

其中一些方面可能需要操作系统和/或其工具链，例如反馈收集和错误检测。目前已开启 Fuchsia，最完全受支持的模糊测试框架是 libFuzzer，通过预构建的 clang 工具链提供，作为编译器运行时。我们已向 sanitizer_common 运行时，用于收集代码覆盖率反馈，以及 libFuzzer 本身来检测异常。以及一组 GN 模板和托管工具，让开发者能够快速为 Fuchsia 上的库开发模糊测试工具。

但与 Linux 不同的是，在 Fuchsia 上，软件的基本可执行单元组件，而不是库。使用现有的引导式模糊测试框架进行模糊测试会很麻烦，因为其反馈的粒度过窄（例如单个进程中的 libFuzzer）或过于宽泛（例如在 qemu 实例上使用 TriforceAFL）。

在 Fuchsia 中，用于模糊测试组件的理想框架具有以下特性：

与现有持续模糊测试基础架构集成，例如 ClusterFuzz。
一种模块化方法，可利用其他平台中与平台无关的部分模糊测试框架，例如变更策略。
高性能的跨进程代码覆盖机制。
与现有 Fuchsia 工作流集成，例如 ffx。
可以隔离被测组件和/或为其依赖项提供模拟组件。
未修改的目标组件源。
一种可靠而灵活的方法来分析执行情况和检测错误。
一个类似于 Fuchsia 中其他测试类型的开发者故事。

设计

此设计试图：

遵循 Fuchsia 的习惯。
重复使用现有实现方案。

概括来讲，该设计利用了测试运行程序框架，并添加了：

用于驱动模糊测试的 fuzzer_engine。
ffx 插件和模糊测试管理器，用于与模糊测试工具进行交互和管理模糊测试工具。
一个 fuzz_test_runner，用于将 fuzzer_engine 连接到模糊测试管理器。

组件模糊测试框架设计

本文档的这一部分大致按照控制流进行组织：也就是说，它从想要执行模糊测试任务的人或机器人开始，对目标领域进行模糊测试。读者应该知道部分会参考后续部分将详细介绍的概念。

`ffx fuzz` 托管工具

用户（真人和机器人）通过 ffx 插件。此插件将能与通过以下方式提供 fuzz_manager 服务：

fuchsia.fuzzer.Manager 协议。
数据传输协议。

ffx fuzz 的子命令会镜像 fx fuzz 的子命令，例如：

analyze：报告给定语料库和/或字典的覆盖率信息。
check：检查一个或多个模糊测试工具的状态。
coverage：为测试生成覆盖率报告。
list：列出当前 build 中可用的模糊测试工具。
repro：通过重放测试单元来重现模糊测试工具的发现结果。
start：启动特定的模糊测试工具。
stop：停止特定的模糊测试工具。
update：更新模糊测试工具语料库的 BUILD.gn 文件。

模糊测试管理器

测试运行程序框架提供两个重要功能：

它可让您轻松创建复杂但封闭的测试领域并推动这些领域以及可自定义的测试运行程序。
它提供了收集重要诊断信息（例如日志和回溯。

此外，一次模糊测试运行可以用以下术语自然地表示：组件测试框架：使用指定的测试输入执行代码；根据错误类型、错误。

不过，模糊测试与其他形式的测试不同，比较连续模糊和连续模糊测试：

测试输入事先未知。
- 测试输入通过模糊测试生成。
- 持续模糊测试基础架构（如 ClusterFuzz）将具有并会“交叉花粉”他们的测试输入 在进行模糊测试时运行。
模糊测试执行是开放式的。模糊测试从来不会真正“通过”，失败或提前停止。
- 因此，需要提供包含详细信息的按需状态通常不会由其他测试提供，例如执行速度、总收集的反馈、使用的内存等
- 需要持续向真人或模糊测试工具提供此状态用于监控模糊测试工具执行的基础设施机器人。
模糊测试结果比简单的通过/失败更丰富。
- 失败时，输出需要包含触发输入以及任何关联的日志和回溯。
- 提前终止服务时，输出内容可能包括累计反馈和建议的参数（例如字典）。
模糊测试领域可用于模糊测试基础架构选择连续执行，例如“模糊一会儿。如果发现错误，对其进行清理，否则，合并并压缩语料库”。将每个步骤表示为测试套件可以提取大量工作一个步骤就能恢复状态，以便在下一步骤中恢复。

其中一些问题可以通过扩展测试运行程序框架来解决，例如它可以提供结构化输出。不过，如果使用该方法，模糊测试需求会为其他不需要测试的。因此，该设计添加了一个新的 fuzz_manager，它具有以下特点：

通过 ffx 为用户提供管理界面。
与 test_manager 交互，以在测试运行程序框架。
提供 fuchsia.fuzzer.manager.Harness，以便这些模糊测试工具重新连接并为用户请求提供服务。
提供数据传输协议，以方便将数据注入或如何从模糊测试工具中提取数据。

然后，对测试运行程序框架进行修改，如下所示：

添加了新的 fuzz_test_runner。此运行程序基于现有的 elf_test_runner 用于启动 fuzzer_engine 并向其传递模糊测试工具网址。
test_manager已修改为路由 fuzz_test_runner 的 fuchsia.fuzzer.manager.Harness 功能。此功能不会发送给测试，且非模糊测试工具的封闭性不受影响。
fuzz_test_runner 会为 fuchsia.fuzzer.Controller 协议。它会将一端安装为初创公司 fuzzer_engine 中的句柄，并使用 fuchsia.fuzzer.manager.Harness 将另一个传递给 fuzz_manager。

模糊测试引擎

fuzzer_engine 是模糊测试领域的一个组件。对于模糊测试工具分类，它能够：

实现 fuchsia.fuzzer.Controller 协议以提供 管理界面。
创建并使用存储空间功能来管理每个语料库。
对来自语料库的输入执行 Mutate 操作，以创建新的测试输入。（例如，链接针对 libMutagen）。
Uses 是 Adapter 的一项功能，用于发送要处理的新输入。
Exposes 一项用于对遥控器进行插桩的 fuchsia.fuzzer.ProcessProxy capability 模糊领域的进程可以用于提供收集的反馈，并 报告错误。
分析反馈。

如果将模糊测试视为具有不同输入的一系列测试，则让模糊测试引擎为每个项目实例化一个全新的测试领域输入，即让测试运行程序连续执行每个模糊测试运行。通过这种方法的主要问题在于和变更循环。模糊测试工具的质量与吞吐量直接相关，必须极快地完成“mutate”、“处理输入、反馈和分析反馈意见”应约为微秒级。

因此，模糊测试引擎包含在测试领域本身的方式与用于测试复杂拓扑的测试驱动程序类似。由事件对协调的共享 VMO 用于转移测试模糊测试目标适配器输入输出，以及来自对远程进程进行插桩，从而尽可能缩短延迟时间。

模糊测试工具引擎由 fuzz_test_runner 启动。这位跑步者非常类似于现有的 elf_test_runner，但添加了一项重要功能：它会为 fuchsia.fuzzer.Controller 协议创建一个通道对。它将此对的一端作为启动句柄安装在 fuzzer_engine 中。它使用 fuchsia.fuzz.manager.Harness 将另一个代码传递给 fuzz_manager 功能由 test_manager 传送给它。这样一来，test_manager 便可以仅向 fuzz_test_runner 和模糊测试工具提供 Harness 功能而不是所有测试。

目标适配器

模糊测试目标适配器在模糊测试工具分类。使用上述共享 VMO 和事件对，获取由模糊测试引擎生成的测试输入，与目标领域的插桩远程进程交互生成模糊测试。

这些特定的交互由模糊测试工具作者提供，这种贡献通常称为“编写模糊测试工具”。

模糊测试工具作者可以提供自己的模糊测试目标自定义实现或使用所提供的某个 Scaffold。

可能的适配器基架示例包括：

llvm_fuzzer_adapter：希望作者实现 LLVM 的模糊测试目标函数。
- 对于 C/C++，作者实现了：
```
extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size);
```
- 对于 Rust，作者使用 #[fuzz] proc_macro 属性实现了一个方法。
- 对于 Go，作者实现了：
```
func Fuzz(s []byte);
```
realm_builder_adapter：除了 LLVM 模糊测试目标函数之外，作者会实现一个方法来修改所提供的 RealmBuilder。通过适配器会为此函数提供默认构建器，并使用结果构建要进行模糊测试的组件领域。作者可以通过将其他路线、功能、模拟等：
```
pub trait FuzzedRealmBuilder {
  fn extend(builder : &mut RealmBuilder);
}
```
libfuzzer_adapter：与 llvm_fuzzer_adapter 的预期类似，但组件清单省略了模糊测试引擎，并提供 Controller 功能本身，并直接链接到 libFuzzer。这个明显不同的组件拓扑支持传统的库模糊测试 libFuzzer 进行了测试。
honggfuzz-persistent-adapter：要求模糊测试工具作者实现：
```
extern HF_ITER(uint8_t** buf, size_t* len);
```
honggfuzz 本身目前不受支持，但模糊测试目标为其编写的函数仍然可以与此框架集成。

请注意，目标适配器可以并且也应该链接到远程库并充当插桩远程进程与插桩测试中的进程一起运行目标。

插桩远程进程

为了收集反馈和检测错误，目标范围内的所有流程需要进行模糊测试的领域需要通过其他插桩（例如 SanitizerCoverage）。对于树内构建的模糊测试工具，可以通过工具链变体，用于将 flags 和 deps 传播到 GN 目标的依赖项必需的标志，例如-fsanitize-coverage=inline-8bit-counters, 也会进行记录，以便允许树外编译。

此外，进程还需要一个 fuchsia.fuzzer.ProcessProxy 客户端实施。上述工具链变体将树内模糊测试工具的进程与远程库相关联的依赖项。

远程库根据模糊分类法提供：

通过回调收集反馈，例如 __sanitizer_cov_inline_8bit_counters_init。
启动早期与 fuzzer_engine 的 ProcessProxy 的连接。
可以检测错误的后台线程，例如监控异常内存用量等

树外模糊测试工具可以提供自己的客户端实现。将 fuchsia.fuzzer.ProcessProxy FIDL 接口和远程库实现有助于更轻松地编写树外模糊测试工具。

最后，所需的编译时修改只是 LLVM 上的转换 IR。所有其他修改都仅在链接时生效。这样一来，服务提供商提供“模糊测试即服务”愿意提供 LLVM 字节码用于其组件，而无需源代码。

组件拓扑

综上所述，模糊测试工具组件拓扑包括：

core：系统根组件。
fuzz_manager：这是模糊测试工具与主机工具之间的根领域中的桥梁。
test_manager：与测试运行程序框架一样。
target_fuzzer：模糊领域入口点。
fuzzer_engine：与目标无关的模糊测试驱动程序。
target_adapter：包含用户提供输入的目标特定组件处理代码。
instrumented_target：对组件进行模糊测试。

adapter 和 target 组件可能有其他子组件，例如模拟和目标领域模糊不清。

上述各个部分的交互可如下所示：
模糊测试框架拓扑

FIDL 接口

该框架添加了两个 FIDL 库：一个用于 fuzz_manager，另一个用于与模糊测试工具本身进行交互。

`fuchsia.fuzzer.manager`

fuchsia.fuzzer.manager 定义的类型包括：

LaunchError：一个可扩展的 enum，列出与发现结果和启动模糊测试工具

fuchsia.fuzzer.manager 定义的协议包括：

fuchsia.fuzzer.manager.Coordinator：由 fuzz_manager 通过以下服务向用户投放： ffx。它包含启动模糊测试工具并将 fuchsia.fuzzer.Controller 以及停止模糊测试工具的方法。
fuchsia.fuzzer.manager.Harness：由 fuzz_manager 投放到 fuzz_test_runner（通过 core 和 test_manager 的静态路由）。通过运行程序使用此协议将通道的一端传递给可用于 fuchsia.fuzzer.Controller 协议。

`fuchsia.fuzzer`

fuchsia.fuzzer 定义的类型包括：

Options：带有用于配置执行的参数的可扩展 table，错误检测等
Feedback：一个灵活的 union，表示目标反馈，例如代码覆盖率、跟踪记录、时间等
Status：具有各种模糊指标的可扩展 table，例如总计例如：覆盖范围、速度等，
FuzzerError：一个可扩展的 enum，列出错误类别，例如这些 ClusterFuzz 可以识别的特征。

fuchsia.fuzzer 定义的协议包括：

fuchsia.fuzzer.Controller：由 fuzzer_engine 提供并传递给通过 fuzz_test_runner 与 fuzz_manager 通信。由 fuzz_manager 代理。包括将输入转移到/从以及使用模糊测试工具执行工作流，例如输入最小化、语料库合并和常规模糊测试
fuchsia.fuzzer.CorpusReader：已请求fuchsia.fuzzer.Controller付款。用于从特定种子或活动语料库获取输入。
fuchsia.fuzzer.CorpusWriter：已请求fuchsia.fuzzer.Controller付款。用于将输入添加到特定种子或活动语料库。
fuchsia.fuzzer.Adapter：由fuzzer_engine 开发者提供的 target_adapter。它包含用于注册协调事件对和用于发送测试输入的共享 VMO。
fuchsia.fuzzer.ProcessProxy：由 fuzzer_engine 向每个插桩处理流程。包括用于注册协调事件对，并注册用于提供反馈的共享 VMO。

构建实用程序

该框架为开发者提供了一个 fuchsia_fuzzer_package GN 模板。这使得他们可以：

自动包含 fuzzer_engine。
生成可供工具使用的元数据，例如种子的位置语料库。
使用非模糊测试工具链时，构建集成测试，而不是模糊测试工具选择变体，如测试部分中所述。
重复使用相关集成中被测组件的 build 规则测试。

该框架还包含一个组件清单分片，其中包含模糊测试工具所需的常见元素，例如fuzzer_engine 及其 fuzz_test_runner 等。模糊测试工具的组件清单包括：

默认模糊测试工具分片。
指向目标适配器组件的网址。
要进行模糊测试的组件清单的网址。这通常应为可在相关集成测试中重复使用。

结合使用这些构建实用程序，类似于集成测试开发。比较：
测试和模糊测试工具开发流程

实现

实施计划很简单：单独进行开发和单元测试类，然后组建从 libFuzzer，如测试部分所述。

语言

fuzzer_engine 和 remote_library 是用 C++ 实现的，各自的特点：

fuzzer_engine 和 remote_library 都必须与其他 C 集成 ABI，例如libMutagen、SanitizerCoverage 等
大多数 remote_library 功能都发生在“main 之前和 exit 之后”，即，在构建和/或加载 LLVM 模块时，如果 atexit 或发生严重异常时抛出该异常。因此，框架需要明确控制 ELF 可执行文件的细微细节生命周期

其他部分，例如realm_builder_adapter 是用 Rust 编写的。

数据传输协议

在某些情况下，用户需要提供或检索任意数量的数据，包括：

提供要执行、清理或最小化的特定测试输入。
将模糊测试工具语料库与开发者主机上的，或在多个 ClusterFuzz 实例。
提取触发了错误的测试输入。

为了尽量减少维护负担，最好使用 overnet。不过，任何单次传输都可能会超出一条 FIDL 消息。相反，Controller 协议包含多个方法，这些方法提供 zx_socket 对象，模糊测试工具引擎用于将数据流式传输到 VMO 和/或本地存储的文件或从其流式传输数据。

使用最小协议流式传输数据，以读取或写入命名序列字节。该协议不是 FIDL，因为发送的数据可能会超过 FIDL 消息的最大长度。命名的字节序列仍然是在概念上等同于以下 FIDL 结构：

struct NamedByteSequence {
  uint32 name_length;
  uint32 size;
  bytes:name_length name;
  bytes:size data;
};

堆栈展开

目前，libFuzzer 使用 LLVM 中的展开程序，该展开程序假定从在触发信号的线程上执行的 POSIX 信号处理程序。对于 Fuchsia，这就需要一种复杂的方法来处理包括修改崩溃线程的堆栈和注入回溯- 保留汇编 trampoline 以“复活”展开程序中的线程

如果 libFuzzer 未处理错误，则无需执行以上任何操作。相反，以最方便的方式处理不同类型的错误有效，例如：

异常由模糊测试引擎处理，该引擎会接收异常通道从其句柄测试作业。
超时也由模糊测试工具引擎管理。
Sanitizer 回调和 OOM 由远程库处理，该库会通知模糊测试引擎

性能

模糊测试不对生产系统执行，因此对以便了解任何配送代码的效果加入模糊测试工具链变体对构建 Fuchsia 的性能影响很小，框架会重复使用现有的变体，应该不会增加新的影响。

同样，在未插桩 build 上，通过模糊测试工具生成单元测试反映当前方法，预计不会增加任何当前方法的模糊测试工具测试成本。

对于模糊测试工具本身而言，决定模糊测试工具的最关键指标质量是指每单位时间的覆盖率，可通过衡量其他指标：

在固定时间段内运行的模糊测试工具的总覆盖率。
在固定时间段内执行的运行总次数。

ClusterFuzz 已针对每个模糊测试工具监控和发布这些指标。

工效学设计

人体工学是该设计的一个重要方面，因为其影响取决于提高 20%。

此框架尝试通过多种方式尽可能简化模糊测试。它可让开发者：

使用熟悉和灵活的方式编写模糊测试工具，如目标适配器部分。
使用现有的 GN 模糊测试模板系列构建模糊测试工具。
使用熟悉的工作流运行模糊测试工具。对 ffx fuzz 的使用是有意为之类似于 fx fuzz。
获取切实可行的结果。通过与 ClusterFuzz 集成，用户会提交错误自动添加符号化回溯和重现指令。

向后兼容性

基于 libFuzzer 的现有模糊测试工具会实现模糊测试目标函数。修改者提供了特定于 libFuzzer 的模糊测试目标适配器，这些模糊测试工具将无需修改源代码即可在此框架中运行。

安全注意事项

此框架不用于配送商品配置。对于设备内置模糊测试配置，与设备的通信将使用 Google 提供的现有身份验证和安全通信功能 overnet 和 ffx。

模糊测试工具输出可能需要考虑安全注意事项，例如，测试输入可能会导致以及利用可利用的内存损坏这些问题必须由模糊测试工具处理操作员（人工或模糊测试基础设施），可利用的 bug 报告（例如正确标记、防止未经授权的人员）披露声明等）。

隐私注意事项

在考虑隐私保护的影响时，对于模糊测试工具运算符处理模糊测试工具输出。这些输出包括日志、导致错误的输入、生成的字典和生成的语料库。我们假定这些日志已不含用户数据，因为这是一个单独的并密切监控隐私问题。其余输出则直接这些特征从测试输入中衍生而来。因此，使模糊测试工具输入不含用户数据确保模糊测试输出中不含用户数据。

您可以通过以下三种方式将输入添加到模糊测试工具的语料库中：

作为种子输入。种子语料库应签入源代码库。针对在源代码库中包含用户数据的常见限制。
作为对当前语料库的手动添加的内容。
- 这通常由模糊测试基础架构完成，例如 ClusterFuzz，因为它会“交叉授粉”将模型的输入其他实例。在这种情况下，其他实例不会包含用户而添加的输入则也不会。
- 人工操作员也可以通过 ffx 添加输入。在以下位置添加手动输入时，该工具会显示有关用户数据的警告。
作为实时语料库生成的新增内容。这些输入从现有输入。由于这些输入是无用户数据的，因此生成的。某些输入可能纯粹出于偶然因素而与某些用户数据匹配，例如模糊测试工具设法生成有效的用户名。不过，在此示例中，与用户数据之间没有明确关联。

语料库中不会包含任何其他数据，即使模糊测试工具是非封闭的（并且具有不确定性！），并使用由测试领域公开的来源提供的数据。通过框架不会将该数据视为测试输入的一部分，也不会保存。

最糟糕的情况是使用模糊测试工具，非封闭的，并且使用公开的功能将数据发送到测试领域验证个人身份信息的其他服务返回用户名是否有效。这需要付出大量的努力来规避模糊测试和测试框架尝试促进封闭性。而且，由于外部服务未进行插桩，这与随机猜测并无二致。

此外，在实践中，模糊测试工具将是完全封闭的。它们不会可以在包含用户数据的产品配置上运行，开发模糊测试工具以及 ClusterFuzz

测试

模糊测试工具引擎、目标适配器库和远程库是使用常规方法（例如 GoogleTest、#[cfg(test)]、等）。此外，集成测试使用默认的 ELF 测试运行程序来运行一组具有专门构建的示例目标的模糊测试工作流，基于 compile-rt 中的适用子集。

对于使用框架编写的模糊测试工具，框架将采用相同的方法：构建 未插桩 build 中使用模糊测试工具，则引擎将被测试所取代驱动程序，只执行种子语料库中的每个输入。这样可以缓解 “bit-rot”确保所有模糊测试工具都可以构建和运行。它还起着回归测试，尤其是在模糊测试工具作者通过在修复通过模糊测试发现的缺陷时添加输入。

文档

模糊测试文档树需要使用特定的新 GN 模板使用示例。计划的任何其他文档更改（例如 Codelab 等）也应反映此框架。

缺点和替代方案

所提方法的潜在缺点包括：

性能下降的风险，可通过实现密切降低模仿高度优化的模糊测试工具中对性能至关重要的部分。
维护负担，但因无需维护而节省了费用尴尬的集成，如POSIX 模拟。
耦合风险，例如测试运行程序框架可能会或由于该设计而无法这样做。如果这就会成为一个问题，可以加入将 test_manager 的更多功能直接导入 fuzz_manager，例如拥有后者会直接创建独立的测试领域。

这些缺点不像其他替代方案那样重要包括：

仅使用 libFuzzer 进行库模糊测试。

libFuzzer 中已添加了足够的 Fuchsia 支持，以便使用它来构建模糊测试工具在 Fuchsia 上。他们已经在。

同时，它们仅限于结构为库的单个进程。由于组件是 Fuchsia 上可执行软件的单元，而组件进行广泛沟通，这使得 Fuchsia 代码“unfuzzable”模型。

传统 libFuzzer

进程内 FIDL 模糊测试。

Chrome 等项目已尝试通过运行客户端和服务器线程。这需要修改客户端和以新的非标准配置运行。它可以在两个 Pod 之间但往往倾向于对组件生命周期做出不灵活的假设和/或按语言绑定重新实现。

从本质上讲，对交互组件。许多组件都有一个非常重要的拓扑。更改为或模拟整个封路的方式提高复杂性、开销和性能

此方法已在 Fuchsia 上推出，但尚未出现得到广泛采用，至少在一定程度上是由于这些限制。

进程内 FIDL 模糊测试

单服务 FIDL 模糊测试。

初步尝试设计跨进程 FIDL 模糊测试框架视为单个客户端和服务在此设计中，libFuzzer 并且客户端作为简单代理进行维护。修改者保留客户端和服务器之间的 FIDL 接口，就可以将目标，从而提供更灵活的服务因而需要重新实现的代码更少。

不过，这种方法并不能解决模糊组件闭包问题，并且因此与进程内 FIDL 模糊测试相比，优势非常有限。

单服务 FIDL 模糊测试

支持跨进程模糊测试的 LibFuzzer。

一般来说，与重新实现代码相比，重复使用代码具有多项优势，代码通常更“成熟”，性能更好，错误更少，而且维护费用较低出于这些原因，试图扩展 libFuzzer，而不是设计和实现新的模糊测试框架新的编译器运行时 clang_rt.fuzzer-remote.a 将执行如上面的远程库一样，而 libFuzzer 本身可以用作引擎。这两个编译器运行时都会使用一对特定于操作系统的 IPC 传输来代理对其他进程的方法调用。

与 libFuzzer 的维护人员协调，实施了一系列更改并发布它们以供审核。此外， IPC 传输库的实现是针对 Linux 和紫红色。维护人员明确请求获得 Linux 支持，持续测试，并会再次送交审核。

在 Linux 上，共享内存创建为匿名映射文件，即通过 memfd_create 发送，信号就是通过 Unix 传递的消息。域套接字。这些套接字还用于传输共享内存文件描述符，即通过 sendmsg 和 recvmsg。
在 Fuchsia 上，共享内存使用 VMO 实现，通过事件对，并通过 FIDL 消息进行交换，方式与此提案中的设计

遗憾的是，经过大量审核，这种方法不可行，但出于技术原因：随着时间的推移，libFuzzer 维护人员越来越多地担心必要的更改，使 libFuzzer 无法以其最初设计的方式运作。最终，团队决定无限期推迟提交所提议的更改。