如果你还不知道，我们最近在博客上开发了一个模糊测试工具。我甚至不确定“模糊测试器”这个词是否合适来形容我们正在构建的东西，它几乎更像是一个暴露钩子的执行引擎？无论如何，如果你错过了第一集，你可以在这里（英文版）补上。我们正在创建一个模糊测试器，它将一个静态构建的Bochs模拟器加载到自身中，并在为Bochs维护一个沙盒的同时执行Bochs的逻辑。你可以这样理解：我们实在太懒了，不想从零开始实现自己的x86_64模拟器，所以我们就直接把一个完整的模拟器塞进了我们自己的进程中来使用。模糊测试器是用Rust编写的，而Bochs是一个C++代码库。Bochs是一个完整的系统模拟器，因此设备和其他所有东西都只是在软件中模拟的。对我们来说，这很棒，因为我们可以简单地对Bochs本身进行快照和恢复，从而对我们的目标进行快照模糊测试。因此，模糊测试器运行Bochs，而Bochs运行我们的目标。这使我们能够对任意复杂的目标进行快照模糊测试：网页浏览器、内核、网络堆栈等。在本集，我们将深入探讨将Bochs从系统调用中沙盒化的概念。我们不希望Bochs能够逃出其沙盒或从我们的环境外部获取任何数据。因此今天我们将研究我初次尝试的Bochs到模糊测试器的上下文切换实现，以处理系统调用。在未来，我们还需要实现从模糊测试器到Bochs的上下文切换，但目前让我们专注于系统调用。

这个模糊测试器最初由Brandon Falk构思并实现。

这篇文章不会涉及仓库的任何改动。

系统调用是用户态自愿切换上下文到内核态，以便利用某些内核提供的实用程序或功能的方式。上下文切换简单来说就是改变代码执行的上下文。当你在进行整数加法、读写内存时，你的进程是在用户态执行的，并且是在你进程的虚拟地址空间内执行的。但是如果你想要打开一个套接字或文件，你就需要内核的帮助。为此，你进行一次系统调用，这将告诉处理器将执行模式从用户态切换到内核态。为了离开用户态、进入内核态并返回用户态，必须非常小心地在每一步准确保存执行状态。一旦你尝试执行系统调用，操作系统首先要做的事情就是在开始执行你请求的内核代码之前保存你当前的执行状态，这样当内核完成你的请求时，它可以优雅地返回到执行你的用户态进程。

上下文切换可以被认为是从执行一个进程切换到执行另一个进程。在我们的例子中，我们是在Bochs的执行与Lucid的执行之间切换。Bochs在执行它的任务，读写内存、做算术运算等，但当它需要内核的帮助时，它会尝试进行一次系统调用。当这种情况发生时，我们需要：

通常，程序员不必担心直接进行系统调用。他们会使用C库中定义和实现的函数，而这些函数实际上会进行系统调用。你可以将这些函数视为系统调用的包装器。例如，如果你使用C库函数open，你并没有直接进行系统调用，而是调用了库中的open函数，而这个函数才是真正发出系统调用指令并执行上下文切换进入内核的。以这种方式编写代码可以大大减轻程序员的跨平台工作，因为库函数的内部实现会执行所有的环境变量检查并相应地执行。程序员只需调用open函数，而不必担心系统调用编号、错误处理等问题，因为这些都在提供给程序员的代码中保持了抽象和统一。

这为我们的需求提供了一个不错的切入点，因为Bochs的程序员也使用C库函数，而不是直接调用系统调用。当Bochs想要进行系统调用时，它会调用一个C库函数。这为我们拦截这些系统调用提供了机会。在这些函数中插入我们自己的逻辑，检查Bochs是否在Lucid下执行，如果是，我们可以插入逻辑将执行重定向到Lucid而不是内核。用伪代码表示，我们可以实现如下的功能：

Musl 是一个旨在“轻量化”的 C 库。与 Glibc 这种庞然大物相比，使用 Musl 使我们在处理时更为简单。重要的是，Musl 在静态链接方面的声誉非常好，而这正是我们在构建静态 PIE Bochs 时所需要的。因此，这里的想法是我们可以手动更改 Musl 代码，以改变调用系统调用的包装函数的工作方式，从而劫持执行，将上下文切换到 Lucid 而非内核。

在这篇文章中，我们将使用 Musl 1.2.4，这是截至今天的最新版本。

我们不会直接跳到 Bochs 上，而是先使用一个测试程序来开发我们的第一个上下文切换例程。这么做更为简单。测试程序如下：

该程序将告诉我们它的参数数量、每个参数的内容，运行约 5 秒钟，然后打印一个 Lucid 执行上下文数据结构的内存地址。如果程序在 Lucid 下运行，这个数据结构将由 Lucid 分配和初始化，否则将为 NULL。那么我们如何实现这一点呢？

我们的问题是，需要一种全局可访问的方式来让我们加载的程序（最终是 Bochs）判断它是运行在 Lucid 下还是正常运行。我们还需要提供许多数据结构和函数地址给 Bochs，因此我们需要一个工具来实现这一点。

我所做的是创建了一个自己的头文件，并将其放在 Musl 中，名为 lucid.h。该文件定义了我们在编译时需要 Bochs 访问的所有 Lucid 特定的数据结构。因此，在头文件中，我们目前定义了一个 lucid_ctx 数据结构，并创建了一个全局实例，名为 g_lucid_ctx。

因此，目前在 Lucid 的主函数中，我们执行以下操作：

当我们从 Lucid 跳转到 Bochs 的入口点时，最早调用的函数之一是在源文件 dlstart.c 中的 Musl 函数 _dlstart_c。目前，我们在堆上创建该全局执行上下文，然后将该地址传递给任意选择的 r15。这个函数最终会发生变化，因为我们将在未来想要从 Lucid 切换到 Bochs 来执行这一操作，但目前我们所做的只是：

因此，当我们从 Lucid 跳转到 Bochs 入口点时，r15 应该持有执行上下文的地址。在 _dlstart_c 中，我们可以检查 r15 并据此采取行动。这是我对 Musl 启动例程所做的那些添加：

当这个函数被调用时，最早的 Musl 逻辑并不会触及 r15。因此，我们使用内联汇编将值提取到一个名为 r15 的变量中，并检查它是否有数据。如果有数据，我们将全局上下文变量设置为 r15 中的地址；否则，我们将其显式设置为 NULL 并按正常方式运行。现在设置了全局变量，我们可以在运行时检查我们的环境，并选择性地调用真实的内核或 Lucid。

现在设置了全局变量，是时候编辑那些负责发出系统调用的函数了。Musl 组织得非常好，因此找到系统调用逻辑并不困难。对于我们的目标架构 x86_64，这些系统调用函数位于 arch/x86_64/syscall_arch.h 中。它们按照系统调用所需参数的数量进行组织：

系统调用有一个定义良好的调用约定。系统调用接收一个“系统调用号”，该号决定你想要的系统调用是什么，并放在eax中，然后接下来的n个参数按顺序通过寄存器传递：rdi、rsi、rdx、r10、r8和r9。

这很直观，但语法有点令人费解，比如在那些 __asm__ __volatile__ ("syscall") 行上，很难看出它在做什么。让我们以最复杂的函数 __syscall6 为例，详细解析一下所有的语法。我们可以将汇编语法看作是一个格式字符串，就像打印时使用格式字符串一样，但这是为了生成代码：

通过解释语法，我们可以看到发生了什么。这些函数的任务是将函数调用转换为系统调用。函数的调用约定，称为 System V ABI，与系统调用的约定不同，寄存器的使用也不同。因此，当我们调用 __syscall6 并传递其参数时，每个参数存储在以下寄存器中：

因此，编译器将从 System V ABI 中获取这些函数参数，并通过我们上面解释的汇编代码将它们转换为系统调用。所以现在这些就是我们需要编辑的函数，以便我们不发出那个系统调用指令，而是调用 Lucid。

因此，我们需要在这些函数体中找到一种方法来调用 Lucid，而不是发出系统调用指令。为此，我们需要定义自己的调用约定，目前我使用的是以下内容：

随着我们添加更多功能/功能，这些无疑会发生一些变化。我还应该指出，根据 ABI 的规定，函数有责任保留这些值，因此函数调用者期望这些值在函数调用期间不会改变，而我们正在改变它们。这没关系，因为在我们使用这些寄存器的函数中，我们将它们标记为“破坏寄存器”（clobbers），还记得吗？所以编译器知道它们会改变，编译器现在要做的是，在执行任何代码之前，它会将这些寄存器推送到堆栈中以保存它们，然后在退出之前，将它们从堆栈中弹出回寄存器中，以便调用者获得预期的值。所以我们可以自由使用它们。

为了更改这些函数，我首先更改了函数逻辑，以检查我们是否有全局 Lucid 执行上下文，如果没有，则执行正常的 Musl 函数，你可以在这里看到，我已经将正常的函数逻辑移到了一个名为 __syscall6_original 的单独函数中：

然而，如果我们在 Lucid 下运行，我会通过显式设置寄存器 r12 到 r15 来按照我们在上下文切换到 Lucid 时的预期设置调用约定。

现在设置好调用约定后，我们可以像之前一样使用内联汇编。注意，我们已经将 syscall 指令替换为 call r12，即像普通函数一样调用我们的退出处理程序：

现在我们调用的是退出处理程序，而不是进入内核的系统调用，并且所有寄存器都设置得好像我们在进行系统调用一样。我们还设置了调用约定的寄存器。让我们看看当我们进入退出处理程序时会发生什么，该函数是在 Lucid 中用 Rust 实现的。我们直接从 Bochs 代码跳转到 Lucid 代码！

我们首先需要做的是为退出处理程序创建一个函数体。在 Rust 中，我们可以通过将函数声明为 extern C 函数并在内联汇编中给它一个标签，使其对 Bochs 可见（通过我们修改过的 Musl）：

当 Bochs 在 Lucid 下尝试进行系统调用时，这个函数将被跳转到。我们首先需要考虑的是，我们需要像内核在进入上下文切换例程时那样跟踪 Bochs 的状态。我们首先要保存的是通用寄存器。通过这样做，我们可以保留寄存器的状态，同时也解锁它们供我们自己使用。因为我们首先保存了它们，所以我们可以自由使用它们。记住，我们的调用约定使用 r13 来存储执行上下文寄存器库的基地址：

我们可以通过以下方式保存寄存器值：

这将把寄存器值保存到内存中的寄存器库中以进行保留。接下来，我们需要保留 CPU 的标志（flags），幸运的是，有一条指令专门用于此目的，即将标志值推送到堆栈中的 pushfq。

我们现在使用的是一个纯汇编的存根代码，但我们希望能够在某个时候开始使用 Rust，而这个时候就是现在。我们已经保存了目前能保存的所有状态，现在是调用一个真正的 Rust 函数的时候了，这将使编程和实现变得更容易。不过，要调用一个函数，我们需要设置寄存器值以符合函数调用的 ABI 约定。我们希望访问的两个数据是执行上下文和退出的原因。记住，它们分别在 r15 和 r14 中。因此，我们可以简单地将它们放入用于传递函数参数的寄存器中，并立即调用一个名为 lucid_handler 的 Rust 函数。

现在，我们可以自由地执行真正的 Rust 代码了！以下是目前的 lucid_handler 函数：

这里有一些重要的部分需要讨论。

让我们从保存区域（save area）的概念开始。那是什么呢？我们已经保存了通用寄存器和 CPU 标志，但处理器还有一个被称为“扩展状态”的部分，我们还没有保存。这可能包括浮点寄存器、向量寄存器以及处理器用于支持高级执行功能（如 SIMD 指令、加密等）的其他状态信息。这重要吗？很难说，我们不知道 Bochs 会做什么，它可能依赖于这些状态在函数调用之间得到保留，所以我认为我们可以先保存它们。

要保存这个状态，你只需执行适用于你的 CPU 的相应保存指令。为了在运行时动态地执行此操作，我会查询处理器是否至少支持两条保存指令，如果不支持，那么现在我们不支持其他任何东西。因此，当我们最初创建执行上下文时，我们会确定需要使用哪条保存指令，并将该答案存储在执行上下文中。然后在上下文切换时，我们可以动态地使用适当的扩展状态保存函数。这之所以有效，是因为我们还没有在 lucid_handler 中使用任何扩展状态，所以它仍然被保留。你可以在这里看到我在上下文初始化期间是如何检查的：

其工作原理是处理器接受一个指向内存的指针，指示你希望保存的位置以及希望保存的内容，例如具体的状态。我只是最大化了我希望保存的状态量，并询问CPU这需要多少内存：

我对结果进行页对齐，然后在执行上下文初始化期间映射该内存，并将内存地址保存到执行状态中。现在在lucid_handler的运行时，我们可以保存扩展状态：

目前，我们处理的退出原因只是系统调用，因此我们调用我们的系统调用处理程序，然后在返回到exit_handler汇编存根之前恢复扩展状态：

让我们看看如何处理系统调用。

当我们正常运行测试程序时（不在 Lucid 下），我们会得到以下输出：

而当我们使用 strace 运行它时，我们可以看到进行了哪些系统调用：

我们看到前两个系统调用与进程创建有关，我们不需要担心这些，因为我们的进程已经创建并加载到内存中。其他的系统调用是我们需要处理的，比如 set_tid_address、ioctl 和 writev。我们暂时不担心 exit_group，因为如果我们正在进行快照模糊测试，Bochs 不应该退出，这将是一个致命的退出条件。

因此，我们可以使用保存的寄存器库信息从 eax 中提取系统调用号，并将其分派到相应的系统调用函数！你可以在这里看到该逻辑：

就这样！扮演内核的感觉有点有趣。现在我们的测试程序做的事情不多，但我敢打赌，当我们使用 Bochs 时，我们将不得不弄清楚如何处理文件之类的事情，但那是以后的事。现在我们要做的就是通过 rax 设置返回码，然后优雅地返回到 exit_handler 存根并返回到 Bochs。

我们恢复 CPU 标志，恢复通用寄存器，然后我们简单地执行 ret，就好像我们完成了函数调用一样。不要忘记我们在从 lucid_context 返回之前已经恢复了扩展状态。

就这样，我们拥有了一种能够处理从 Bochs 到模糊测试器的上下文切换的基础设施。它无疑会发生变化并需要重构，但理念将保持相似。我们可以看到下面的输出展示了测试程序在 Lucid 下运行，我们自己处理系统调用：

接下来，我们将针对 Musl 编译 Bochs，并着手让它运行。我们需要实现它的所有系统调用，并让它运行一个测试目标，我们将对其进行快照并反复运行。因此，下一篇博文应该是一个被系统调用沙盒化的 Bochs，同时对一个“Hello World”类型的目标进行快照并反复运行。敬请期待！

本文使用chatGPT-4o翻译而成，如有错误之处，请斧正
原文链接：https://h0mbre.github.io/Lucid_Context_Switching/

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！