【HUSTOJ 判题机源码解读系列04】判题机常见技术选择方案
从本文开始，我们就需要准备开始解读 HUSTOJ 中最核心的 judge_client.cc 文件的前置知识了。
作为真正判题的模块，我们需要理解其实现原理，使用了哪些技术，不过既然本文标题为“判题机常见技术选择方案”，应是不局限于 HUSTOJ 选择的技术方案，还应该介绍一些其他的技术方案，扩展一下知识的广度也是好的。
1. 判题机的职责
在了解常见的技术方案之前，我们在这里先明确一下判题机最核心的职责，我将其划分两个主要部分：
- 沙箱部分：提供一个受限的执行环境，负责编译和运行用户代码，并收集标准输出。沙箱的关键在于安全性，包括但不限于，防止恶意代码破坏服务器、限制 CPU 和内存占用、拦截危险的系统调用等等。
- 评测部分：判断用户代码的执行结果是否正确，包括检查算法是否符合预期、是否超出时间或内存限制，以及标准输出格式是否合规等。
此外，有些博客和教程会把判题任务调度也归入判题机的范畴，但我更倾向于把它作为上层服务，让判题机专注于代码执行和评测。这样不仅逻辑更清晰，也更利于系统扩展和维护。
评测部分实际上就是主要做了两件事，一是如果用户代码有执行有异常，需要确定异常是什么，并返回异常信息。二是如果没有异常，那就将用户标准输出文件和标准答案文件进行比对，查看输出是否一致。
这两件事实践起来都非常简单。判题机真正的难点是如何实现一个安全、高效的代码沙箱。
2. 沙箱部分实现技术方案
2.1 基于 ptrace + setrlimit + chroot 实现（HUSTOJ 的技术方案）
在 Linux 中，ptrace 和 setrlimit 分别用于进程控制和资源限制，而 chroot 则可以对文件系统进行隔离。
2.1.1 使用 ptrace 拦截危险的系统调用
利用 ptrace 允许父进程监视和控制子进程的机制，我们可以拦截危险的系统调用。在 Linux 下，每个系统调用都有一个唯一的编号（如 open、close 可能对应 2 和 3，具体编号取决于 CPU 架构）。当进程执行系统调用时，这个编号会存放在 rax 寄存器（对于 x86_64 架构）中。
现在我们就可以实现：
- 拦截系统调用：在子进程执行 syscall 时暂停它，并读取 rax 寄存器中的系统调用编号。
- 比对白名单：维护一个允许调用的系统调用列表，如果 rax 中的编号不在白名单内，我们就可以判定这个进程想要执行恶意代码，就直接终止该进程。
这样，我们就能有效拦截危险的系统调用，如 execve()（执行新进程）、fork()（创建子进程）等，避免代码逃逸或破坏服务器。然而，ptrace 的开销较大，因为它需要在每次系统调用发生时暂停进程，并在用户态与内核态之间频繁切换，十分影响运行效率。
2.1.2 使用 setrlimit 实现资源控制
使用 setrlimit 可以直接用于限制进程 CPU、内存、磁盘等，具体实现如下：
- 限制 CPU 运行时间（防止死循环）：
setrlimit(RLIMIT_CPU, time_limit); - 限制最大内存使用（防止 OOM）：
setrlimit(RLIMIT_AS, memory_limit); - 限制最大文件大小（防止恶意生成大文件）：
setrlimit(RLIMIT_FSIZE, max_file_size);
2.1.3 使用 chroot 隔离文件系统
chroot 允许改变进程的根目录视图，让进程只能访问特定的文件系统。例如，OJ 评测机可以使用 chroot("/sandbox")，让代码只能访问 /sandbox 目录，而无法访问 /etc/passwd 等系统文件，从而提供一定程度的文件隔离。
但是 chroot 其实是有进程逃逸的风险的。如果进程拥有 CAP_SYS_CHROOT 权限，或者能够执行某些系统调用（如 pivot_root），就可能绕过 chroot 限制。
2.2 基于 seccomp + cgroup + namespace + pivot_root 实现
2.2.1 实现 seccomp 实现拦截危险的系统调用
seccomp 允许进程以白名单模式运行，只允许执行特定的系统调用，其他所有系统调用都会被拒绝（SCMP_ACT_KILL）或者返回错误（SCMP_ACT_ERRNO）。
并且 seccomp 直接在内核级过滤 syscall，不会像 ptrace 那样需要执行进程暂停 & 用户态切换，手动判断系统调用是否合规，导致进程运行缓慢。
2.2.2 使用 cgroup 实现资源控制
cgroup 是 Linux 提供的基于文件系统的进程资源控制机制，可以对一组进程进行CPU、内存、I/O、进程数等资源的限制。
通过向对应的文件写入配置：
echo 50000 > /sys/fs/cgroup/cpu/oj/cpu.cfs_quota_us
可以有效的限制限制进程组使用的系统资源，并且相对于 setrlimit 只能限制单个进程来说，cgroup 能够限制一整个进程组，并且数据更准确。
2.2.3 使用 namespace + pivot_root 隔离进程运行环境
Linux 提供的 namespace 机制允许进程在隔离的环境中运行，使其看不到宿主机的其他进程和资源。在此基础上，通过 bind mount 和pivot_root隔离进程运行环境的文件系统，能够进一步的确保用户程序不会影响到服务器。
3. 使用 docker、podman 等容器软件（HUSTOJ 也支持）
除了自己实现一个代码沙箱，我们还可以使用 Docker、Podman 这样的容器软件来作为代码沙箱。实际上，Docker 和 Podman 的底层也是基于 Cgroup、Namespace 等 Linux 内核技术来实现进程隔离和资源控制的。
选择这种方式的最大优点就是 “简单”。这些开源容器软件已经封装好了底层逻辑，我们无需手动实现复杂的 进程管理、文件系统隔离、资源限制 等机制，直接使用现成的容器功能就行。而且，Docker 和 Podman 经过长期的社区维护，安全性、稳定性和兼容性都非常优秀。
但缺点在于灵活性较低。由于 Docker 和 Podman 并非专门为代码沙箱设计，而是通用的容器运行时，无法针对 OJ 评测机、在线编译环境等特殊需求进行深度优化。此外，通用容器的额外封装层会更消耗性能，性能可能比不上为 OJ 定制的沙箱。
4. 总结
本文我们介绍了实现代码沙箱的常见的几种方案，而 HUSTOJ 使用的 ptrace + setrlimit 的方案已经足够满足一个 OJ 判题机的所需，其优点是简单，缺点是效率有问题。
下期仍和本期一样，属于技术介绍类型，主要内容就是介绍 ptrace 如何使用，了解了 ptrace 怎么使用之后再开始分析 judge_client.cc 的具体实现。
