Ylarod’s Blog

一加内核 panic 日志获取方法

Fri, 27 Feb 2026 00:00:00 GMT

做安卓内核开发时，kernel panic 是家常便饭。但如果 panic 后拿不到崩溃日志，排查问题就如同盲人摸象——你知道它崩了，却不知道崩在哪里。

在一加 ACE5 上，panic 后 /sys/fs/pstore 始终是空的，无法像常规 Linux 设备那样直接获取上次崩溃的 dmesg。本文记录了我为获取 panic 日志所做的全部尝试：从 ramoops 配置调整，到内核源码级的机制调研，再到最终发现高通 minidump 方案的完整探索过程。

万物的开始

一切从一个简单的建议开始。有朋友告诉我，通过对 ramoops 驱动执行一次 unbind/bind 操作，可以让 /sys/fs/pstore 下面出现文件：

试了一下，文件确实出现了：

但打开一看，内容完全和上一次的崩溃无关——更像是 unbind 那一刻转储的当前 dmesg，而不是 panic 时保存下来的日志。这说明 ramoops 驱动本身是能工作的，但上次 panic 时写入预留内存的数据已经不在了。

问题可能出在 ramoops 的配置上——也许预留的内存区域大小不对，或者缓冲区分配有问题。于是我决定尝试修改 ramoops 的配置参数。

对 ramoops 配置的尝试

先确认一下当前 pstore 使用的后端：

返回的是 ramoops，说明 pstore 确实在用 ramoops 作为后端。那问题大概率出在 ramoops 的缓冲区配置上。ramoops 有几个关键参数：record_size（单条 oops/panic 记录大小）、console_size（控制台日志大小）、pmsg_size（用户空间 pmsg 大小）。如果 record_size 为 0，panic 日志就不会被保存。

cmdline 修改

最直接的想法是通过内核命令行参数覆盖 ramoops 配置。安卓的 boot image header 中有 cmdline 字段，可以通过 magiskboot 修改。

注意：magiskboot 需要使用 30.7 及以上版本，老版本在解析 -h 参数时有 bug。

首先尝试修改 init_boot 分区：

在 header 文件中添加 ramoops 参数：

刷入重启后，检查 /proc/cmdline——没有任何变化。看来 init_boot 的 cmdline 没有被引导程序采用。

换一个思路，改 boot 分区：

这次刷入重启后，/proc/cmdline 里确实出现了我添加的参数。但检查 ramoops 的实际参数，发现它们完全没有变化。

阅读内核源码后找到了原因：安卓内核中 ramoops 的模块参数被标记为只读（module_param 使用 0444 权限），cmdline 中的参数只是被内核解析了，但 ramoops 驱动并不从 cmdline 读取配置——它的配置完全来自设备树（Device Tree）。

dtbo 修改

既然 cmdline 行不通，就得从设备树下手。

在安卓设备上，设备树通常分为两部分：DTB（基础设备树，编译进 boot image）和 DTBO（Device Tree Blob Overlay，设备树叠加层，位于独立的 dtbo 分区）。DTBO 的设计初衷是让厂商在不修改基础 DTB 的情况下，通过叠加层来定制硬件配置。ramoops 的内存区域配置通常就放在 DTBO 中。

首先从设备中提取 dtbo 分区镜像：

拉到本地：

DTBO 镜像是一个打包了多个 DTB overlay 的容器，需要专门的工具来解包。这里使用 mkdtimg：

解包 DTBO 镜像，将每个 overlay 反编译为可读的 DTS（Device Tree Source）格式，然后搜索 ramoops 相关的配置：

果然找到了。在其中一个 overlay 的 fragment@31 中，有 ramoops 预留内存区域的配置。原始配置如下：

可以看到问题所在：整个预留区域只有 0x240000（2.25MB），其中 pmsg 占了 0x200000（2MB），console 占了 0x40000（256KB），而 record-size 根本没有定义——这意味着 panic 时的 oops/panic 记录没有分配任何空间。

修改后的配置，压缩 pmsg 空间，为 console 和 record 各分配 1MB：

将修改后的 DTS 重新编译为 DTB，再打包回 DTBO 镜像：

检查新镜像的结构是否正确：

确认无误后刷入设备，重启验证参数是否生效：

参数确实变了！console_size 和 record_size 都变成了预期的值。看起来这次应该能行了。

然而，手动触发一次 panic 后重启，/sys/fs/pstore 下面依然空空如也。

ramoops 参数已经正确，驱动也正常加载，panic 也确实发生了——但日志就是不见了。具体原因尚不明确，可能的方向包括：硬件层面 DRAM 在掉电-上电周期中无法保持内容（mem-type = 0x02 表示使用的是普通 DRAM 而非 NVRAM）、bootloader 在启动早期主动清零了这片预留内存区域、或者 ramoops 驱动在该平台上存在其他未知的兼容性问题。

ramoops 这条路暂时走不通了，需要寻找其他方案。

自研？

既然 ramoops 靠不住，那不如自己动手——写一个内核模块，在 panic 时把日志直接写入 UFS 的某个分区。

以 mtdoops 为蓝本

内核中有一个现成的参考实现：mtdoops。它是一个独立的 kmsg dumper，在 panic 时将 printk ring buffer 中的日志写入 MTD 设备。我最初的想法很简单：参考 mtdoops 的源码架构，写一份类似的模块，把目标设备从 MTD 换成 /dev/block/by-name/logdump 分区。

不过在动手之前，有一个前提需要验证：logdump 分区的数据在重启后是否真的能保留？如果 bootloader 会在启动时清空这个分区，那不管怎么写都是白费。

分区持久化测试

挑两个看起来和 dump 相关的分区（logdump 和 rawdump）做个简单测试：

数据完好无损。logdump 和 rawdump 分区在重启后不会被清空，可以作为持久化目标。

顺手确认一下存储型号：

三星 UFS 4.0 闪存，存储介质可靠。前提条件满足了，接下来就是搞定 panic 时的写入逻辑。

从 MTD 到 block：撞上了墙

然而，当我真正深入 mtdoops 的源码时，才意识到事情没那么简单。

mtdoops 之所以能在 panic 时成功写入，是因为它走的是 MTD 子系统的专用接口 mtd_panic_write()。MTD（Memory Technology Device）面向的是 NOR/NAND Flash 这类原始闪存，驱动可以直接以轮询方式操作硬件寄存器完成擦写，不需要中断、不需要调度器，天然适合 panic 上下文。

但一加 ACE5 的存储是 UFS，它挂载在 SCSI/block 子系统下，和 MTD 完全是两个世界。我不能简单地把 mtdoops 的 mtd_panic_write() 替换成 kernel_write() 写 block 设备——panic 发生时中断已禁用、调度器已停止，整个 block I/O 路径根本不可用。

换句话说，mtdoops 的架构只能借鉴思路（注册 kmsg dumper → panic 时从 ring buffer 读日志 → 写入持久化存储），但写入这一步在 UFS 上完全行不通。

转向 pstore/blk

既然自己从头写不现实，那内核有没有现成的框架来解决”panic 时写 block 设备”这个问题？

答案是 pstore/blk——pstore 框架的块设备后端。它的设计目标正是把 panic 日志写入通用块设备分区。但深入源码后发现，它的可用性取决于一个关键条件：存储驱动是否实现了 panic_write 回调。

pstore/blk 的 best_effort 模式虽然可以挂载到任意块设备上，但看一下它的写函数实现：

这个函数只注册为普通 write，而不是 panic_write。panic 时 pstore/zone 框架的选择逻辑是：

所以 best_effort 模式在 panic 时只会标记”脏”，期望下次正常启动时回写——但 panic 后系统已经重启，RAM 中的脏标记自然也丢了。

要让 pstore/blk 真正在 panic 时落盘，需要存储驱动主动调用 register_pstore_device()，并提供一个能在中断禁用上下文中以轮询方式直接操作硬件的 panic_write 回调。

UFS 驱动有 panic_write 吗？

这成了关键问题。我让 Claude 帮忙阅读 AOSP android14-6.1 通用内核中 drivers/ufs/ 的全部源码，搜索任何与 panic_write、pstore、kmsg_dump 相关的实现。

结果：什么都没有。 AOSP 主线的 UFS 驱动完全没有实现 panic 路径下的持久化写入能力。

Claude 提了一个思路：AOSP 通用内核的 UFS 驱动比较精简，但高通的下游 vendor 内核（msm-kernel）中的 ufs-qcom.c 可能有类似的同步写入机制。毕竟高通对自家平台的 UFS 控制器最了解，很可能在 vendor 分支里加了 panic 写入的支持。

于是我让 Claude 转而分析一加 ACE5 的官方内核源码（android_kernel_oneplus_sm8650）中的 UFS 驱动。结果依然令人失望：

关键词	搜索结果
`panic_write`	未找到
`pstore_zone` / `register_pstore_device`	未找到
`kmsg_dump`	未找到

vendor 内核的 UFS 驱动里唯一和 panic 相关的代码是 ufs-qcom.c 中注册的 panic notifier：

这只是把 UFS 寄存器状态打印到 kernel log 用于调试，和把日志写入 UFS 存储是完全不同的两件事。

到这里，纯内核层面的方案基本全部走入了死胡同。问题的本质很清楚：panic 后 block 层不可用，而 UFS 驱动也没有实现绕过 block 层的轮询写机制。谁能在 panic 时直接操作 UFS 硬件？

深入 minidump

纯内核方案走不通，但一加自己肯定有办法拿到 panic 日志。查看设备上加载的内核模块，过滤 dump 相关的：

其中 minidump、qcom_va_minidump、memory_dump_v2 是高通平台特有的崩溃转储模块。让 Claude 对一加 ACE5 内核源码中这些模块的实现进行调研，得到以下分析结果。

机制概述

minidump 是高通平台私有的跨层协作方案，涉及 TrustZone（EL3）、ABL（Android Bootloader）、内核驱动三层，不是纯内核机制。

整体架构

内核侧：正常运行期间构建 minidump table

内核驱动在正常运行期间（非 panic 时）就通过 API 注册要 dump 的内存区域：

典型注册内容包括 KSTACK（内核栈）、KLOGBUF（printk ring buffer）、KPGTBL（内核页表）、各驱动关键结构体等。其中 KLOGBUF 即 printk ring buffer——panic 时所有的 pr_emerg()、dump_stack() 输出都在这里。

TrustZone 能直接写 UFS 的原因

TrustZone 运行在 EL3，有对所有硬件的直接访问权，自带精简 UFS 驱动，使用寄存器轮询等待命令完成，完全不依赖 Linux 内核的 UFS 驱动栈和中断机制。这恰好绕开了前面所有纯内核方案的致命瓶颈。

关键源文件

文件	功能
`drivers/soc/qcom/msm_minidump.c`	核心注册接口，`md_ops` dispatch
`drivers/soc/qcom/minidump_smem.c`	SMEM 后端实现，管理 SMEM ID 602 中的全局 TOC
`drivers/soc/qcom/minidump_log.c`	HLOS 侧 region 注册（kernel sections、IRQ stack、panic dump 等）
`drivers/soc/qcom/qcom_va_minidump.c`	VA minidump 框架，按需收集各子系统数据

完整实现需要的组件

高通下游内核（msm-kernel）中的 drivers/soc/qcom/minidump.c

TrustZone 固件（闭源，高通提供的 .mbn 文件）

ABL 中的 dump 处理代码（高通 UEFI ABL，部分开源）

三者缺一不可，纯内核层面无法单独实现。

与纯内核方案的对比

对比项	ramoops（内核方案）	minidump（高通方案）
谁来写存储	panic 核（内存保留）	TrustZone（EL3 固件）
依赖中断	否	否（TZ 自带轮询 UFS）
存储介质	预留 RAM	UFS rawdump 分区
数据量	受 ramoops 分区大小限制	可配置，通常更大
可选择性	全量 kmsg	精细化（按模块注册的关键内存）
开源程度	完全开源（内核主线）	高通私有（TZ 固件 + 下游内核驱动）

至此可以确定：一加实际使用的是高通 minidump 机制，由 TrustZone 在 panic 后直接将内存内容写入 UFS，而非依赖 ramoops。ramoops 在该设备上无法生效的具体原因仍未定论，但这已不影响日志的获取。

曙光与结论

理论到此为止，接下来只需要找到日志的具体存储位置。思路很简单：手动触发一次 panic，重启后从 dmesg 中搜索 minidump 相关的服务日志。

首先确认上次重启确实是因为 panic：

kernel crash Minidump——说明 minidump 机制确实被触发了。然后搜索 dmesg 中 minidump 相关的日志：

从日志中可以还原出一加的 minidump 用户空间处理链：

minidumpreader 读取 rawdump 分区中的 minidump 数据

olcpackupminidump 将日志打包

minidumpraise2olc 上报给 OLC（OnePlus Log Collection）服务

olc_get_minidump_log 提取日志文件

backup_minidumplog 备份到持久化路径

其中最关键的一行是那个 mount 命令——它暴露了日志的存储路径：

三次 panic 的日志都在。文件名格式为 SYSTEM_LAST_KMSG@@<版本号>@<时间戳>.dat.gz。备份路径也有一份：

把文件拉出来、解压、用 strings 提取可读内容——完整的 panic 日志赫然在目。

完整提取步骤

总结最终可用的 panic 日志提取流程：

触发或等待一次 kernel panic，设备会自动重启

重启后确认重启原因：

通过 adb shell 进入 root shell，将日志文件复制到 adb 可访问的路径并修改权限：

拉取到本地：

解压并提取可读的崩溃日志：

回顾

整个探索过程走了不少弯路，但也因此对 Linux 内核的 panic 日志转储体系有了系统性的理解：

ramoops：最通用的方案，将日志写入预留内存，但依赖这片内存跨重启不被清除。在一加 ACE5 上实测修改 dtbo 配置后仍无法生效，具体原因未明

mtdoops：架构简洁的 MTD 闪存 dumper，但它的写入接口绑定在 MTD 子系统上，无法用于 UFS 存储

pstore/blk：pstore 的块设备后端，设计上支持通用块设备，但 panic 时 block 层不可用，需要存储驱动实现 panic_write 回调——而 AOSP 主线和一加 vendor 内核的 UFS 驱动均未实现

minidump：高通私有方案，panic 后由 TrustZone 在 EL3 接管控制权，用自带的精简 UFS 驱动直接写入存储——这才是一加实际使用的机制

对于一加 ACE5（以及其他使用高通平台的一加设备），panic 日志最终存储在 /mnt/vendor/oplusreserve/media/log/minidump/ 目录下，以 SYSTEM_LAST_KMSG 为前缀的 gzip 压缩文件中。

深入分析 Seccomp BPF

Thu, 23 Oct 2025 00:00:00 GMT

概述

Seccomp (Secure Computing) 是 Linux 内核提供的一种安全机制，允许进程限制自己可以执行的系统调用。Seccomp Mode 2 (SECCOMP_MODE_FILTER) 使用 BPF (Berkeley Packet Filter) 程序实现灵活的系统调用过滤。但是不同于 eBPF，Seccomp BPF 使用 cBPF，对比 eBPF 仅保留了部分指令可以使用。

Seccomp BPF 的安装和验证的主要流程如下：

安装

用户空间通过 prctl 提交 BPF 程序

内核验证权限（no_new_privs 或 CAP_SYS_ADMIN）

从用户空间安全复制 BPF 指令

执行严格的 BPF 验证（基本检查 → 经典检查 → seccomp 特定检查）

转换为 eBPF 格式并尝试 JIT 编译

构建系统调用缓存以优化性能

附加到进程的过滤器链

设置 TIF_SECCOMP 标志启用检查

验证

系统调用入口检测 TIF_SECCOMP 标志

填充 seccomp_data 结构（系统调用号、参数、架构等）

首先检查缓存（快速路径）

遍历过滤器链，执行每个 BPF 程序

选择最严格的返回动作

根据动作类型处理（允许、拒绝、跟踪、杀死等）

记录审计日志（如果配置）

具体源码分析见下文

安装流程

1. 用户空间接口

用户通过 prctl 系统调用安装 seccomp 过滤器：

2. 内核调用链

2.1 入口函数

源码：kernel/seccomp.c:1962

该函数是 prctl(PR_SET_SECCOMP, ...) 的内核入口点，负责： - 根据 seccomp_mode 确定操作类型（STRICT 或 FILTER） - 将参数转换为内部格式 - 调用 do_seccomp() 执行实际操作

关键代码流程:

2.2 统一入口处理

源码：kernel/seccomp.c:1924

该函数是 prctl 和 seccomp 系统调用的统一处理入口： - SECCOMP_SET_MODE_STRICT: 调用 seccomp_set_mode_strict() - SECCOMP_SET_MODE_FILTER: 调用 seccomp_set_mode_filter() - SECCOMP_GET_ACTION_AVAIL: 查询动作是否可用 - SECCOMP_GET_NOTIF_SIZES: 获取通知结构大小

2.3 Filter 模式设置

源码：kernel/seccomp.c:1787

这是安装 BPF 过滤器的核心函数，执行以下步骤：

步骤 1：验证 flags

支持的 flags 包括： - SECCOMP_FILTER_FLAG_TSYNC: 同步所有线程 - SECCOMP_FILTER_FLAG_LOG: 记录所有非 ALLOW 动作 - SECCOMP_FILTER_FLAG_SPEC_ALLOW: 允许规避推测执行缓解 - SECCOMP_FILTER_FLAG_NEW_LISTENER: 创建用户态通知监听器

步骤 2：准备过滤器

步骤 3：获取锁

步骤 4：检查并附加过滤器

步骤 5：设置 seccomp 模式

3. 过滤器准备

3.1 从用户空间复制过滤器

源码：kernel/seccomp.c:681

该函数处理用户空间到内核空间的过滤器转换：

处理兼容模式:

调用核心准备函数:

3.2 核心过滤器准备

源码：kernel/seccomp.c:629

权限检查:

必须满足以下条件之一： - 进程设置了 no_new_privs 标志 - 进程具有 CAP_SYS_ADMIN 能力

分配 seccomp_filter 结构:

创建 BPF 程序:

这里调用了 net/core/filter.c 中的函数，seccomp_check_filter 作为转换函数传递。

初始化引用计数:

4. BPF 程序创建与验证

4.1 从用户空间创建 BPF 程序

源码：net/core/filter.c:1414

验证基本参数:

分配 BPF 程序结构:

从用户空间复制指令:

保存原始程序（用于检查点恢复）:

准备并验证过滤器:

4.2 准备 BPF 过滤器

源码：net/core/filter.c:1320

检查经典 BPF 指令:

这一步验证： - 指令长度不超过 BPF_MAXINSNS - 没有越界跳转 - 内存访问合法 - 不使用除零操作

执行 seccomp 特定转换:

4.3 Seccomp 特定检查

源码：kernel/seccomp.c:268

该函数对 seccomp BPF 程序进行特殊处理：

重定向数据加载指令:

将 BPF_LD 改为 BPF_LDX 以确保从 seccomp_data 结构加载数据，而不是网络包数据。

替换长度加载:

允许的指令白名单: 只允许安全的 ALU、跳转、内存操作和返回指令，拒绝其他所有指令。

JIT 编译:

如果架构支持，将 BPF 程序编译为原生机器码以提高性能。

解释器迁移:

如果无法 JIT 编译，将经典 BPF (cBPF) 转换为扩展 BPF (eBPF) 供解释器使用。

5. 附加过滤器

源码：kernel/seccomp.c:857

验证过滤器总长度:

限制：MAX_INSNS_PER_PATH = (1 << 18) / sizeof(struct sock_filter) = 256KB

链接过滤器:

过滤器以链表形式组织，新过滤器总是添加到链表头部。

线程同步（如果需要）:

6. 设置 Seccomp 模式

源码：kernel/seccomp.c:437

设置模式:

内存屏障:

启用推测执行缓解:

设置 TIF_SECCOMP 标志:

此标志导致内核在每次系统调用时检查 seccomp 过滤器。

验证执行流程

1. 系统调用拦截

当进程执行系统调用时，如果设置了 TIF_SECCOMP 标志，内核会在系统调用处理前调用 seccomp 检查。

架构相关入口:

2. Seccomp 检查入口

源码：kernel/seccomp.c:1296

检查暂停标志:

获取系统调用号:

根据模式分发:

获取过滤器链:

检查缓存:

系统调用缓存优化：如果某个系统调用对所有过滤器都返回 ALLOW，将其缓存以避免重复执行 BPF 程序。

遍历过滤器链:

优先级规则： - 数值越小，优先级越高（更严格） - SECCOMP_RET_KILL_PROCESS < SECCOMP_RET_KILL_THREAD < SECCOMP_RET_TRAP < … < SECCOMP_RET_ALLOW

3.3 BPF 程序执行

BPF 程序通过以下方式之一执行：

JIT 编译的原生代码（如果 fp->jited == true）

eBPF 解释器（如果未 JIT 编译）

BPF 程序接收 seccomp_data 结构作为输入，返回一个 32 位动作值。

4. 动作处理

源码：kernel/seccomp.c:1181

根据过滤器返回值执行相应动作：

4.1 SECCOMP_RET_ERRNO

4.2 SECCOMP_RET_TRAP

发送的信号信息：

4.3 SECCOMP_RET_TRACE

4.4 SECCOMP_RET_USER_NOTIF

用户态通知机制： 1. 将系统调用信息发送给用户态监督进程 2. 阻塞当前进程等待响应 3. 根据用户态响应决定如何处理系统调用

4.5 SECCOMP_RET_LOG

4.6 SECCOMP_RET_ALLOW

4.7 SECCOMP_RET_KILL_THREAD / SECCOMP_RET_KILL_PROCESS

5. 日志记录

源码：kernel/seccomp.c:964

根据 /proc/sys/kernel/seccomp/actions_logged 配置决定是否记录：

审计日志包含： - 系统调用号 - 信号（如果有） - Seccomp 动作 - 进程 PID、UID 等

关键数据结构

1. seccomp_filter

源码：kernel/seccomp.c:215

生命周期: - refs: 包括直接任务、依赖过滤器、用户通知监听器 - users: 只包括直接关联的任务 - 当 users 到达 0 时，不能再有新任务关联 - 当 refs 到达 0 时，释放过滤器

2. seccomp_data

源码：include/uapi/linux/seccomp.h

这是传递给 BPF 程序的数据结构，大小为 64 字节。

3. task_struct.seccomp

源码：include/linux/sched.h

4. action_cache

源码：kernel/seccomp.c:161

缓存构建（源码：kernel/seccomp.c:825）:

对每个系统调用号： 1. 用固定的 nr 和 arch 模拟执行 BPF 程序 2. 如果返回 SECCOMP_RET_ALLOW，在位图中设置对应位 3. 继承前一个过滤器的缓存（新过滤器只能更严格）

缓存使用:

BPF 程序处理

1. cBPF 到 eBPF 转换

源码：net/core/filter.c:565

转换过程： 1. 第一遍：计算转换后长度 2. 第二遍：实际转换指令并计算跳转偏移 3. 第三遍（如需要）：调整跳转偏移

指令映射示例:

2. JIT 编译

启用条件: - 内核配置 CONFIG_BPF_JIT=y - 架构支持（x86_64, ARM64, etc.） - /proc/sys/net/core/bpf_jit_enable 设置

优势: - 原生机器码执行，性能提升 2-4 倍 - 减少指令分发开销

缺点: - 增加内核攻击面 - 消耗更多内存

3. 解释器执行

如果无法 JIT 编译，使用 eBPF 解释器：

安全机制

1. 验证器检查

基本检查 (bpf_check_basics_ok): - 程序不为空 - 最后一条指令是 RET - 没有无效指令

经典 BPF 检查 (bpf_check_classic): - 没有越界跳转 - 没有后向跳转（防止循环） - 内存访问合法 - 除数不为零检查

Seccomp 特定检查 (seccomp_check_filter): - 只允许白名单中的指令 - 数据访问限制为 seccomp_data 结构 - 强制 4 字节对齐访问

2. 长度限制

限制总指令数为 256KB，防止： - DoS 攻击（过长的执行时间） - 内存耗尽

3. 权限要求

安装 seccomp 过滤器需要：

no_new_privs 标志: - 通过 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) 设置 - 禁止进程及其子进程获得新权限 - 防止特权提升攻击

4. 单向门机制

一旦设置 seccomp 模式，无法更改或移除，只能添加更严格的过滤器。

5. 内存屏障

确保多核系统中的内存一致性。

6. 推测执行缓解

默认启用推测执行缓解（如 SSBD），防止 Spectre 类攻击。

深入 Seccomp User Notification 机制

Seccomp 用户态通知 (User Notification) 允许用户空间进程拦截和处理被 seccomp 过滤的系统调用。与传统的 SECCOMP_RET_ERRNO 或 SECCOMP_RET_KILL 不同，SECCOMP_RET_USER_NOTIF 可以将系统调用决策权委托给用户空间的监督进程。被过滤的系统调用会阻塞，等待用户空间监督进程的决策，并将系统调用号、参数、架构等信息传递给用户空间。监督进程可以返回错误码、返回值，或允许系统调用继续执行，也支持通过 SECCOMP_IOCTL_NOTIF_ADDFD 向被监督进程注入文件描述符。

整体架构

关键数据结构：

核心数据结构

1. 内核通知对象 (seccomp_knotif)

源码：kernel/seccomp.c:64

状态机转换：

INIT: 通知已创建，等待监督进程读取

SENT: 监督进程已读取，等待响应

REPLIED: 监督进程已响应，可以唤醒被监督进程

2. 通知容器 (struct notification)

源码：kernel/seccomp.c:143

设计要点：

大多数 seccomp 过滤器不使用通知，因此单独分配此结构以节省内存

request 信号量：初始值为 0，每个新通知 up()，读取时 down()

next_id：随机初始化防止 ID 预测攻击

3. FD 注入对象 (seccomp_kaddfd)

源码：kernel/seccomp.c:120

4. 用户空间接口结构

源码：include/uapi/linux/seccomp.h

seccomp_notif (通知请求)

seccomp_notif_resp (通知响应)

标志位：

SECCOMP_USER_NOTIF_FLAG_CONTINUE (0x1)：允许系统调用继续执行（有 TOCTOU 风险）

seccomp_notif_addfd (FD 注入请求)

完整工作流程

阶段 1：Listener FD 创建

1.1 安装带 NEW_LISTENER 标志的过滤器

用户空间代码：

1.2 内核处理流程

源码：kernel/seccomp.c:1787

1.3 init_listener 函数

源码：kernel/seccomp.c:1721

seccomp_notify_ops 文件操作：

源码：kernel/seccomp.c:1714

阶段 2：系统调用拦截与通知

2.1 触发 SECCOMP_RET_USER_NOTIF

被监督进程执行系统调用 → 匹配 BPF 过滤器 → 返回 SECCOMP_RET_USER_NOTIF：

源码：kernel/seccomp.c:1158

2.2 seccomp_do_user_notification 详解

源码：kernel/seccomp.c:1077

这是用户态通知的核心函数，被监督进程的系统调用会在此阻塞。

关键点：

通知对象在栈上：seccomp_knotif n 在被监督进程的内核栈上分配，生命周期与系统调用相同

数据指针有效性：n.data 指向 __seccomp_filter 的 sd，在整个通知期间有效

多次唤醒：do-while 循环处理 addfd 请求，每次注入 FD 都会唤醒一次

信号中断：如果被监督进程收到信号，wait_for_completion_interruptible 返回错误

阶段 3：监督进程读取通知

3.1 等待通知 (poll/epoll)

监督进程使用 poll 或 epoll 监听 listener fd：

源码：kernel/seccomp.c:1685

3.2 读取通知 (ioctl NOTIF_RECV)

源码：kernel/seccomp.c:1425

状态转换：INIT → SENT

阶段 4：监督进程发送响应

4.1 发送响应 (ioctl NOTIF_SEND)

源码：kernel/seccomp.c:1494

状态转换：SENT → REPLIED

4.2 验证通知有效性 (ioctl NOTIF_ID_VALID)

源码：kernel/seccomp.c:1538

监督进程在处理通知前可以验证通知是否仍然有效（被监督进程可能已收到信号退出）：

阶段 5：FD 注入机制

5.1 使用场景

FD 注入允许监督进程将自己的文件描述符"传递"给被监督进程，典型场景：

容器运行时代理设备访问：容器进程 open("/dev/fuse") → 监督进程打开真实设备 → 注入 fd

网络代理：容器进程 socket() → 监督进程创建 socket 并配置 → 注入 fd

5.2 注入流程 (ioctl NOTIF_ADDFD)

源码：kernel/seccomp.c:1562

5.3 被监督进程处理 addfd

源码：kernel/seccomp.c:1066

在 seccomp_do_user_notification 的循环中调用：

双向等待机制：

监督进程在 seccomp_notify_addfd 中等待 kaddfd.completion

被监督进程在 seccomp_do_user_notification 中被唤醒，调用 seccomp_handle_addfd 安装 fd 并 complete()

阶段 6：清理与关闭

6.1 Listener 关闭

源码：kernel/seccomp.c:1352

当监督进程关闭 listener fd 时：

源码：kernel/seccomp.c:1366

Android 平台的 Seccomp 使用

在 Android 中，Seccomp 是多层安全机制的一部分，搭配 SELinux、命名空间隔离、UID/GID 沙箱、权限模型 等共同构建应用安全边界。

Android 从 Android 8.0 开始引入了对 App 进程的 Seccomp 过滤器。

设计目标是：

减少应用可访问的系统调用数量；

阻止利用内核漏洞的攻击面；

对特权进程（如 zygote 或 system_server）使用更严格的策略。

参考 bionic/libc/seccom/seccomp_policy.cpp Android 的 Seccomp 机制分为4个类型：

进程类型	过滤器类型	主要作用
普通 App 进程	App filter	限定 App 允许的 syscall 集合
App Zygote 进程	App Zygote filter	更严格，只允许必要的 syscall
System 进程	System filter	系统进程的特定白名单
UID/GID 改变辅助过滤器	SetUid/Gid filter	限制 setresuid/setresgid 参数范围

在 android 系统中，最终可用的 SYSCALL 是由 SYSCALL - BLOCKLIST + ALLOWLIST 组成的，同时会参考 SECCOMP_PRIORITY.TXT，把高频 syscall 放在 BPF 判断的“快路径”前面，以减少匹配开销。

具体的这些文件也可以在 bionic 源码中找到：bionic/libc/

具体的计算逻辑可以参考 genseccomp.py

解决爱思助手导致的 Mac 锁屏不熄屏问题

Tue, 01 Apr 2025 00:00:00 GMT

最近发现公司 mac 电脑锁屏之后屏幕又不熄屏了，回想起之前排查过是爱思助手导致的问题，而且之前配置的 Shortery 只退出爱思助手没有生效，于是重新修改了一下脚本：

新建一个快捷指令，按照图中的内容操作

打开 Shortery 配置触发器：

另一个 AOSPXRef - aosp.app

Thu, 05 Oct 2023 00:00:00 GMT

国内入口：http://aosp.xtuly.cn/

国外入口：https://aosp.app/

通知频道：https://t.me/aospapp

源码同步

校园网联合镜像站：https://mirrors.cernet.edu.cn/list/AOSP

安装工具

下载初始化包

首先检查md5是否一样，如果不一样不能使用那个源

使用每月更新的初始化包

使用 aria2 多来源下载初始化包

校验文件

MD5不一样也别着急，只要能解压就行，使用repo sync 同步之后，报错的删除掉再重新同步即可！

md5校验

压缩包测试

同步源码

先解压缩

然后同步每个版本的源码

精简源码

部署

先 clone 仓库

编辑 versions.txt，修改为你拉取下来的源码和对应的api level

然后执行 python3 gen.py 生成 openresty 配置和 docker compose 配置

修改 init.sh 里面的 for 条件，睡眠时间

第一次启动容器的时候需要执行 init.sh 逐个启动各个版本的 opengrok 实例，索引比较耗费系统资源。

使用 IDA Python 修改基本块的背景颜色

Fri, 22 Sep 2023 00:00:00 GMT

bb 为基本块的地址

WireShark+OpenWrt 抓包

Mon, 28 Nov 2022 00:00:00 GMT

路由器

配置免密登陆

将公钥写入 /etc/dropbear/authorized_keys 文件

文件权限644

安装tcpdump

开始抓包

先安装wireshark，然后执行下面的指令即可

Ylarod’s Blog

一加内核 panic 日志获取方法

万物的开始

对 ramoops 配置的尝试

cmdline 修改

dtbo 修改

自研？

以 mtdoops 为蓝本

分区持久化测试

从 MTD 到 block：撞上了墙

转向 pstore/blk

UFS 驱动有 panic_write 吗？

深入 minidump

机制概述

整体架构

内核侧：正常运行期间构建 minidump table

TrustZone 能直接写 UFS 的原因

关键源文件

完整实现需要的组件

与纯内核方案的对比

曙光与结论

完整提取步骤

回顾

深入分析 Seccomp BPF

概述

安装流程

1. 用户空间接口

2. 内核调用链

2.1 入口函数

2.2 统一入口处理

2.3 Filter 模式设置

3. 过滤器准备

3.1 从用户空间复制过滤器

3.2 核心过滤器准备

4. BPF 程序创建与验证

4.1 从用户空间创建 BPF 程序

4.2 准备 BPF 过滤器

4.3 Seccomp 特定检查

5. 附加过滤器

6. 设置 Seccomp 模式

验证执行流程

1. 系统调用拦截

2. Seccomp 检查入口

3. 过滤器执行

3.1 填充 seccomp_data

3.2 运行过滤器链

3.3 BPF 程序执行

4. 动作处理

4.1 SECCOMP_RET_ERRNO

4.2 SECCOMP_RET_TRAP

4.3 SECCOMP_RET_TRACE

4.4 SECCOMP_RET_USER_NOTIF

4.5 SECCOMP_RET_LOG

4.6 SECCOMP_RET_ALLOW

4.7 SECCOMP_RET_KILL_THREAD / SECCOMP_RET_KILL_PROCESS

5. 日志记录

关键数据结构

1. seccomp_filter

2. seccomp_data

3. task_struct.seccomp

4. action_cache

BPF 程序处理

1. cBPF 到 eBPF 转换

2. JIT 编译

3. 解释器执行

安全机制

1. 验证器检查

2. 长度限制

3. 权限要求

4. 单向门机制

5. 内存屏障

6. 推测执行缓解

深入 Seccomp User Notification 机制

整体架构

核心数据结构

1. 内核通知对象 (seccomp_knotif)

2. 通知容器 (struct notification)

3. FD 注入对象 (seccomp_kaddfd)

4. 用户空间接口结构

seccomp_notif (通知请求)