内核级 Root 和用户空间 Root 到底差在哪
Android 的分层架构
要理解这个问题，先得清楚 Android（准确说 Linux）的进程隔离模型：
- 内核空间（Kernel Space）：最高优先级，直接操作硬件，运行在内核态（Ring 0）
- 用户空间（User Space）：普通进程运行的地方，受限的权限，运行在用户态（Ring 3）
两者通过系统调用（syscall）这个受控的"API 门"来交互——用户进程不能直接访问内核内存。
传统 root 是怎么工作的
以 Magisk 为例，它的 root 获取流程是这样的：
- 修补 boot 镜像里的 ramdisk，在 init 阶段注入自己的脚本
- 启动一个 root 权限的守护进程（magiskd / magisksu）
- App 请求 root 时，通过 socket 把请求发给守护进程
- 守护进程以 root 身份 fork 一个子进程来执行命令
这套方案的问题在于：su 进程是用户空间可见的。任何 App 都能检测 /sbin/su、/system/xbin/su、magisk 相关的属性值、以及执行 su 二进制后检查返回身份。SafetyNet 检测 root 也是基于这个原理——它检查的就是用户空间有没有这些"痕迹"。
APatch 的内核级 root 怎么做
APatch 绕过了整个用户空间的 su 守护进程方案：
- 直接 patch 内核，添加一个新的系统调用（SuperCall）
- SuperCall 在验证密钥正确后，直接在当前线程上修改凭证，使其获得 root 权限
- App 不需要启动新进程，不需要 IPC，甚至不需要知道自己"被 root 了"
关键点在于：root 权限的授予发生在内核态，对用户空间完全透明。没有 su 二进制、没有 su 守护进程、没有 socket——那些被 SafetyNet 用来检测 root 的"痕迹"全部不存在。
性能对比
| 维度 | 用户空间 root（Magisk） | 内核级 root（APatch） |
|---|---|---|
| root 进程可见 | 有 su 守护进程 | 无任何用户空间进程 |
| App 能否感知 root | 可以（检测 su 二进制） | 不能（权限在内核层面隐藏） |
| 获取 root 的开销 | fork + IPC + 调度 | 一次系统调用 + 内核内存修改 |
| SELinux 影响 | 需要 patch SELinux policy | 可选择 hook 绕过，不修改 policy |
| 对 SafetyNet 的可见性 | 容易被检测 | 难度大幅提升 |
为什么不是所有方案都走内核级
内核级 root 的一个硬伤是：内核补丁的兼容性取决于内核版本和编译选项。如果内核没有开启 CONFIG_KALLSYMS（符号表），KernelPatch 就无法工作。
Magisk 那条路虽然更容易被检测，但它的通用性极强——只要 Android 设备能启动 boot.img，就能用 Magisk root，不管内核怎么编译的。这也是为什么 Magisk 至今仍然是最主流的 root 方案。