KernelSU 工作原理——内核态 su 与用户态管理器如何分工

三层结构

KernelSU 不是单个程序，而是三层组件的协作：

1. 内核侧：一段实现在 Linux 内核中的代码（GKI 模式编译进内核镜像，LKM 模式作为可加载内核模块 .ko 在开机时载入）。它负责 hook 关键系统调用、维护 su 授权判断、在内核中强制执行 App Profile。
2. 用户空间守护 ksud：跑在 root 环境下的命令行工具，负责修补 boot 镜像、管理模块的安装/启用/卸载、执行各阶段启动脚本、维护模块配置。它也能在 Recovery 环境下用来救砖。
3. 管理器 APK：手机上看得见的图形界面，用来查看安装状态、授权应用、安装模块、执行安装向导。管理器通过内核暴露的接口与内核侧通信。

开机时发生了什么

以 GKI 模式为例（LKM 模式多一步 insmod 载入内核模块）：

1. Bootloader 加载打补丁的 boot.img，内核启动；
2. 内核执行 init 进程，KernelSU 在此阶段注册钩子（LKM 模式先执行 ksuinit、载入 kernelsu.ko）；
3. 进入 post-fs-data 阶段：执行通用脚本与各模块的 post-fs-data 脚本，加载 sepolicy 规则与 system.prop；
4. 由元模块（如 meta-overlayfs）完成模块目录的挂载，随后跑 post-mount 阶段脚本；
5. late_start 服务阶段：与系统启动并行执行 service.sh 等非阻塞脚本；
6. 系统启动完毕后执行 boot-completed 阶段脚本。

理解这个执行链对排障很有用：模块脚本没跑，先看它放在哪个阶段；挂载没生效，先看元模块装没装。详见 模块机制与 systemless 修改。

为什么「在内核里」是卖点

• 授权不依赖用户态进程存活：即便守护进程出问题，内核侧规则仍然生效；
• 更难被检测：root 逻辑混入内核，用户态的检测点更难发现痕迹；
• 可以做到「临时 root」：LKM 模式下通过 fastboot boot 临时引导带 KernelSU 的内核，不刷写分区、重启即失效。