NoTamper：面向安全感知任务调度的审计任务协同调度原型

1. 项目简介

在面向终端、边缘设备和智能系统的运行环境中，操作系统往往要同时处理感知输入、业务计算、设备控制、网络通信和安全防护等任务。这些任务的目标并不一致：业务任务希望获得稳定的 CPU 时间和较低响应延迟，安全任务则更关心关键事件能否在风险扩大前被处理。调度器如果只按普通计算任务来分配资源，安全任务可能被延后；如果简单提高安全任务优先级，又可能打断业务执行，降低系统吞吐和实时性。

系统审计是安全感知任务调度的代表性场景。内核会记录系统调用、进程退出等关键事件，为攻击检测、溯源分析和安全取证提供依据。审计日志生成后会先停留在内核或共享缓冲区中，如果处理不及时，日志可能在安全持久化或远端传输前被篡改；如果每次产生日志都同步处理，业务线程又会被频繁打断。因此，审计系统的关键矛盾在于功能任务和安全任务之间的调度协同：安全审计任务需要在明确时限内运行，功能任务也需要维持可接受的执行效率。

现有软件审计方案通常只能满足其中一侧需求。独立进程式审计处理具备清晰的调度实体，便于及时唤醒安全任务，但频繁跨进程切换会带来较高开销；嵌入式或异步审计处理运行开销较低，但安全任务缺少独立调度实体，容易因为调度延迟导致日志在缓冲区中停留过久。通用调度器主要面向普通任务的公平性、优先级和吞吐量，缺少对安全时限、日志驻留时间和安全任务关联关系的表达能力。

NoTamper 从安全审计切入，将审计处理建模为与业务线程关联的安全任务。系统为每个被审计线程维护对应的用户态审计处理线程，并在系统调用返回、线程退出、缓冲区状态变化、业务线程让出 CPU 等关键时机触发处理。该模型使安全任务既具备可调度的实体和明确触发时机，又尽量靠近功能任务执行上下文，减少跨进程调度和数据搬运开销。通过这一原型，可以验证安全任务与功能任务协同调度在 OpenHarmony/Linux 内核环境中的可行性，并为“安全感知任务调度”这一参考案例提供具体落点。

1.1 核心思路

• 安全任务与功能任务关联：为被审计线程维护对应的审计处理线程，使安全处理与业务执行形成明确的一对一关系。
• 基于安全事件的调度触发：在系统调用、线程退出、缓冲区接近满、线程即将让出 CPU 等时机触发审计处理，减少无意义轮询。
• 降低安全任务响应延迟：通过及时调度审计任务，让日志尽快离开临时缓冲区，缩短安全风险窗口。
• 控制功能任务开销：审计处理尽量放在关联任务中完成，减少跨进程切换、额外拷贝和同步阻塞对业务程序的影响。
• 支持安全数据通路：结合共享映射、PKEY 内存保护和 RDMA 传输等机制，为安全任务提供低开销的数据搬运路径。

1.2 挑战

• 安全需求难以表达给调度器：传统调度通常关注公平性、优先级和吞吐量，缺少安全时限、完整性约束等调度语义。
• 审计任务不能过早或过晚运行：过早运行会增加无效调度，过晚运行会扩大日志驻留时间，需要根据业务线程活动动态决定触发时机。
• 功能任务与安全任务需要协同：审计线程既要跟随业务线程产生的事件，又不能长期抢占业务线程导致性能下降。
• 内核态和用户态需要一致配合：内核负责事件采集和调度触发，用户态负责日志转储和远端传输，两侧数据结构、缓冲区状态和异常路径必须保持一致。
• 安全处理过程应原子化：审计任务运行期间如果频繁阻塞、缺页或等待锁，会重新拉长风险窗口，因此需要减少不确定等待。

1.3 主要贡献

• 提出面向安全审计的任务调度抽象：将审计日志处理从普通后台逻辑提升为具有安全时限要求的安全任务，使日志驻留时间、业务开销和调度时机成为统一考虑的系统问题。
• 设计关联线程模型：为每个被审计业务线程绑定一个审计处理线程，使安全任务既靠近功能任务执行上下文，又具备独立调度实体，兼顾低开销和可调度性。
• 实现审计感知调度策略：结合定时触发、调度点触发和缓冲区满触发，在业务线程活跃、休眠、退出和缓冲区压力变化等状态下及时调度安全任务。
• 构建有界执行的数据通路：通过非抢占执行、预分配内存、无锁路径和 RDMA 传输减少审计任务运行中的阻塞和不确定等待，缩短安全风险窗口。
• 提供可验证原型与评估材料：仓库包含内核模块、用户态审计处理程序、控制工具、测试程序以及技术报告，可用于验证功能任务与安全任务协同调度的效果。

1.4 核心结果

NoTamper 在日志安全性和业务开销之间取得了较好的平衡：

• 日志驻留时间可控：在 100µs 到 2ms 的调度间隔下，NoTamper 的日志驻留时间基本跟随配置间隔变化；相比只能在缓冲区满时触发处理的函数级方案，日志驻留时间缩短约 95 倍到 505 倍。
• 真实应用开销较低：在 2ms 默认调度间隔下，NoTamper 在 I/O 密集型应用上的平均开销约为 2.80%，不同线程配置下约为 0.97% 到 5.33%；相比独立进程式审计，在 I/O 密集型负载上开销降低约 1.50 倍到 14.01 倍。
• 高频系统调用场景仍可运行：在 flooding 压力测试中，NoTamper 的开销为 21.98%，明显低于独立进程式和虚拟化路径审计方案，说明关联线程和轻量调度可以缓解高频安全事件带来的调度压力。
• 日志完整性保持稳定：在宏基准和 flooding 测试中，NoTamper 未观察到日志丢失；相比依赖丢弃日志降低开销的方案，更适合高吞吐安全审计场景。

1.5 作者介绍

本项目作者团队来自北京大学计算机学院，队长黄瑞哲，指导老师为北京大学计算机学院助理教授李锭老师。

2. 目录结构

本仓库交付一个可构建、可加载、可运行基础验证的安全感知任务调度原型以及相应的技术报告，主要内容包括：

• kmodule/：内核模块，实现系统调用 tracepoint 注册、进程/线程审计上下文管理、事件封装、缓冲区管理、调度触发和 ioctl 控制接口。
• consumer/：用户态审计处理程序和 RDMA 接收端，实现缓冲区映射、日志消费、远端写入以及 PKEY 相关内存保护逻辑。
• docs/：技术报告和实验图表，用于说明系统设计、调度机制、实验结果和与赛题方向的关系。
• 顶层 CMakeLists.txt 与 generate_cmake.sh：构建配置入口，用于生成内核模块、用户态程序、控制工具和测试程序。
• 技术报告: 详细阐述了 NoTamper 的设计思路、实现细节和性能评估。

具体来说，仓库目录如下所示

.
├── kmodule/          # 内核模块：事件采集、缓冲区管理、调度触发和控制接口
├── consumer/         # 用户态审计处理程序、RDMA 传输逻辑和内存保护支持
├── include/          # 内核态与用户态共享的数据结构、ioctl 定义和配置模板
├── scripts/
│   ├── ctrl/         # 控制工具，用于查看统计、导出日志和调整缓冲区参数
│   ├── tests/        # 基础测试程序，包括普通进程、多线程和压力场景
│   └── deps/         # 依赖准备脚本，用于获取 musl 和 RDMA verbs 相关依赖
├── docs/             # 技术报告和实验图表
├── CMakeLists.txt    # 顶层构建入口
└── generate_cmake.sh # 示例 CMake 配置脚本

3. 快速开始

NoTamper 包含两个主要组件：

• 内核模块：代码位于 kmodule/，可在未修改的 Linux 内核上构建和加载。
• 用户态审计处理程序：代码位于 consumer/，负责消费内核暴露的审计缓冲区，并支持本地写入或 RDMA 传输。

本项目主要在 openEuler 22.03 LTS、Linux 5.10 内核环境下测试。对于 OpenHarmony Linux 内核环境，需要保证内核具备对应 tracepoint 和模块构建能力。

3.1 环境要求

• make
• CMake
• 支持 --static-pie 的 GCC/G++ 8.0 以上版本
• pkg-config
• Linux 内核需要启用以下配置：
  • CONFIG_TRACEPOINTS
  • CONFIG_HAVE_SYSCALL_TRACEPOINTS

获取 musl libc：

./scripts/deps/getmusl.sh <NoTamper 项目绝对路径>

获取 RDMA Infiniband verbs 依赖：

./scripts/deps/getibverbs.sh <NoTamper 项目绝对路径>

3.2 构建与加载

mkdir build
cd build
cmake ..
make load

执行完成后，内核模块会被加载。生成的模块文件名为 notamper.ko。

3.3 配置说明

NoTamper 支持通过 CMake 配置以下参数：

• BUFFER_SIZE：每个线程审计缓冲区大小，默认值为 2*Kib。
• CONSUMER_PATH：用户态审计处理程序路径，默认值为 ${PROJECT_BINARY_DIR}/consumer/consumer。
• STORE_PATH：审计数据存储路径，默认值为 /tmp/notamper。
• STACK_SIZE：用户态审计处理线程栈大小，默认值为 1*Mib。

示例：

cmake .. -DBUFFER_SIZE=4*Mib -DCONSUMER_PATH=/my/path/to/consumer -DSTORE_PATH=/my/path/to/store

BUFFER_SIZE 可以使用整数，也可以使用 Kib、Mib 作为单位。例如，4*Mib 也可以写成 4096*1024。

NoTamper 还支持自定义日志路径格式。默认格式类似于 STORE_PATH/%u-%ld.buf，其中包含线程 ID 和纳秒级时间戳。可以通过 PATH_FORMAT 指定其他路径格式：

cmake .. -DPATH_FORMAT=/dev/pts/1

3.4 PKEY 支持

NoTamper 可以使用 Intel Protection Key（PKEY）保护用户态审计处理程序的内存区域，降低业务线程误写或恶意修改审计缓冲区的风险。如果运行环境不支持 PKEY，需要关闭该功能，否则可能因为执行不支持的指令而触发异常。

默认配置中 PKEY 支持关闭。如需开启，可在 CMake 中指定：

cmake .. -DPKEY_SUPPORT=on

如果需要显式关闭：

cmake .. -DPKEY_SUPPORT=off

4. 文档索引

文档	简介
README.md	项目入口文档，介绍项目背景、核心思路、贡献、目录结构和构建方式。
技术报告	系统性说明 NoTamper 的研究问题、系统设计、实现方案、实验结果。