本站之前的两篇文章： 《基于 BusyBox 快速制作内核验证环境》 《基于完整发行版搭建内核验证环境》 分别总结了基于 QEMU 搭建内核验证环境的两种思路。经过这几年下来在日常工作中的实践和体会，总结下两者各自的优劣： 前者构建成本低，操作简单；用户态极简，启动时省去了大量用户态（如 systemd）的初始化工作，启动速度快。 后者有完整的 C 语言运行时环境，可执行动态链接的用户态程序；有完整的包管理，软件资源丰富，可拓展性强。 我个人的偏好是，优先考虑使用前者，毕竟简单高效，有利于反复试错和快速迭代；如果验证场景对 C 语言运行时或者其他用户态基础设施有依赖，再考虑使用后者。 那么，有没有一种方法，能够将两者的优点结合起来， …

前言 & 背景 CVE-2024-26816 1：/sys/kernel/notes 的内容是当前运行的 vmlinux 镜像的 .notes 节，里面存有内核函数 hypercall_page 的地址。此信息可用于绕过 KASLR 保护。 探究内容：x86 内核启动过程中，KASLR 对内核整体镜像做偏移时，是如何修改 .notes 节中的 hypercall_page 地址的？ 分析过程 初始链接阶段 对于 OLK-6.6 的 x86 内核，若编译时开启了 CONFIG_XEN 选项，则 arch/x86/xen/xen-head.S 会将汇编函数 hypercall_page 加入到 vmlinux …

0、前言 本文不介绍各个 Cap 集的含义，只列举它们各自发生变化的场景和方式。 只讨论 Linux 2.6.33 之后的场景，即：1、Bounding Set 为 per-thread 属性；2、支持文件 Cap。 1、线程自行调整 相较于 DAC 和 MAC，Capabilities 的一个特点是可在运行时动态增减。程序的代码中可带有调整 Cap 的相关系统调用和逻辑，在执行时根据需要主动调整线程的 Cap。例如，在执行某些需要特权的操作前将（Permitted Set 范围内）必要的 Cap 添加至 Effective Set 中，在执行完毕后再将这些 Cap 从 Effective Set 中去除。这种会主动调整 Cap 的 …

Canary 一词意为金丝雀，相传以前矿工们会携之下矿井，一旦金丝雀死亡则说明矿井中存在瓦斯泄露的情况。而 Stack Canary 的作用也类似：每开辟一个新栈帧时，先在毗邻上一栈帧处设置一个特定值，然后在每次函数返回时检查一下该值是否被改变；如被改变，则说明栈被越界写所破坏。 用户态程序 上面提到的关于 Canary 值的设置、校验，以及出错后的处理，这些动作的代码逻辑都是由编译器负责生成并嵌入到可执行文件中的。用户需要做，或者说可以做的事情只有： 需要添加 -fstack-protector/-fstack-protector-strong 编译参数。 可以在代码中定义 __stack_chk_guard 全局变量， …

代码所在地 功能代码 arch/arm64/kernel/pointer_auth.c arch/arm64/include/asm/pointer_auth.h arch/arm64/include/asm/asm_pointer_auth.h（这个容易漏掉！） 测试代码 tools/testing/selftests/arm64/pauth/*，用户态测试 TEST(corrupt_pac)：测试篡改带 PAC 的 LR 是否会导致验签失败从而令用户态进程收到信号 TEST(pac_instructions_not_nop{,_generic})：测试 pac* …