KernelSU 内核级 Root 方案全解核心特性、兼容性约束与构建集成实践【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 是一个基于 Linux 内核的 Android Root 方案它以内核模块或编入内核的驱动的形式运行在内核态直接在 kernel space 中完成 root 权限的授予与管控。本篇以仓库中的俄文主文档 docs/README_RU.md 为骨架展开逐条解析其三大核心特性、官方兼容性与x86_64架构下的内核 panic 风险并结合 kernel/Kconfig、justfile、kernel/setup.sh 等仓库源码给出可操作的构建与集成步骤。读完本文你将能判断目标设备是否处于官方支持范围、理解 GKI/LKM 两种运行模式的选择依据并掌握从 GKI 内核树集成、Kconfig选项裁剪到ksud命令行修补boot.img的完整链路。一、项目定位为什么 Root 逻辑要放进内核KernelSU 的核心主张docs/README_RU.md 开篇即声明是Решение на основе ядра root для Android-устройств——一个基于内核的 Android root 方案。与运行在用户态、依赖setuid二进制或 Magisk 式分区修补的方案不同KernelSU 把权限决策点上移到内核态由此获得了文档中列出的三大特性。仓库 website/docs/guide/what-is-kernelsu.md 进一步说明了这一架构红利在内核态中可以拦截任意系统调用、为任意进程添加硬件断点、不可见地访问目标进程的物理内存等这些都是用户态方案不具备的内核接口能力。下面按俄文 README 的Особенности特性清单逐条展开。1. 基于内核的su与 Root 访问管理README 第一条特性是Управлениеsuи root-доступом на основе ядра基于内核的 su 和 root 访问管理。其实现入口可以从源码结构中直接验证kernel/supercall/supercall.c 实现了 KernelSU 独有的超级系统调用分发机制用户态通过uapi/supercall.h定义的接口进入内核态执行权限提升操作kernel/hook/setuid_hook.c 负责在经典setuid路径上拦截并改写身份提升行为kernel/policy/allowlist.c 维护哪些应用UID/包名有权获得 root 的允许名单权限授予完全由用户控制而非应用开发者——这一点与应用 Profile 文档website/docs/guide/app-profile.md中Granting su permissions is entirely controlled by the user, not the developer的描述一致。用户态侧管理器 APK 通过 JNImanager/app/src/main/cpp/jni.cc调用 Rust 编写的ksud工具完成修补与安装而su请求最终经由内核接口裁决。2. 基于 Metamodule 的模块化系统第二条特性是基于 metamodules 的模块系统面向无系统化systemless修改的可插拔基础设施。这里的关键设计是KernelSU 内核本体不内置/system挂载逻辑而是把挂载/overlay 这类系统分区修改能力委托给可插拔的 metamodule。仓库文档 website/docs/guide/metamodule.md 解释了为何这样设计安装文档 website/docs/guide/installation.md 的Post-Installation: Module Support一节也给出了明确提示如果你的模块需要修改/system文件安装 KernelSU 之后必须先安装一个metamodule如官方meta-overlayfs仅使用脚本、sepolicy 或 system.prop 的模块则不需要。这一核心瘦、能力插的架构使模块系统成为一等公民模块安装、卸载、按应用 unmount 等行为都由 metamodule 与内核策略kernel/feature/kernel_umount.c 等协作完成。3. 应用 Profile把 root 关进笼子第三条特性Профиль приложенийЗапри корневую силу в клетке应用 Profile把 root 力量关进笼子是 KernelSU 最具辨识度的安全设计。俄文 README 的表述直白——lock up the root power in a cage。其完整语义见 website/docs/guide/app-profile.md核心要点Root Profile已授权 root 的应用可定制su之后 root 进程的uid/gid/groups/capabilities/ SELinux 上下文。例如把某应用的 root 进程 UID 设为2000ADB shell 级别或剥离inet组使其无法通过su访问网络或为 root 进程自定义一个受限 SELinux 域如u:r:app1:s0并只授予必要规则。非 root 应用 Profile控制内核与模块系统对该应用的行为典型用途是Umount modules——对该应用隐藏所有 overlay 挂载用于对抗对系统分区修改敏感的应用配合管理器中的Umount modules by default全局开关可组成白名单/黑名单两种策略。Escalation 陷阱文档特别警告若把应用 root 进程设为 UID2000而2000本身也被授权 root应用可连续执行两次su逃逸到完整 root可用 Profile 中的NO_NEW_PRIVS标志阻止 KernelSU 层面的二次提权。内核侧的支撑实现位于 kernel/policy/app_profile.c 与 kernel/feature/feature.c用户接口定义在 uapi/app_profile.h 和 uapi/feature.h这些策略在内核内强制执行不依赖 root 应用的自觉行为这是它与su 里手动setuid切换用户的本质区别。二、兼容性状态官方支持边界与 x86_64 的 kernel panic 警告俄文 README 的Совместимость一节给出了四条兼容性事实逐条核对如下。官方支持矩阵维度官方状态说明内核版本GKI 2.0内核 5.10官方支持KernelSU 不为Unsupported设备提供任何 boot.img需自行编译内核旧内核4.14 可用但需自行构建属于兼容但非官方维护范围特殊环境WSA、容器化 Android 可运行需集成 KernelSU 内核英文 README 中还列出 ChromeOSCPU 架构arm64-v8a与x86_64与仓库中 kernel/hook/arm64 与 kernel/hook/x86_64 两套架构 hook 实现相对应如何判断我的设备是否被官方支持的实操方法见 website/docs/guide/installation.md安装 KernelSU 管理器后若显示Unsupported说明需要自己编译内核显示Not installed则说明设备在官方支持列表内。该文档同时强调 GKI 设备刷机前的三个关键概念——KMIKernel Module Interface决定跨内核镜像兼容性的w.x-androidXXX-k段、安全补丁级别防回滚机制可能拒绝低补丁级别的镜像以及内核版本号不等于 Android 版本号这些是选择正确 boot.img / AnyKernel3 包的前提。x86_64 架构的破坏性内核变更重要警告俄文 README 用醒目的CAUTION警告框指出最新内核版本中存在一项破坏性变更会导致 KernelSU 失效、并在x86_64上可能引发 kernel panic。该警告的完整技术背景记录在 website/docs/guide/x86_64-support.md根因上游内核为安全加固修改了系统调用路径把系统调用表中的间接分支改写成一系列直接条件分支syscall table hardening。KernelSU 的syscall_hook机制依赖改写 syscall 表项、把被拦截的调用路由到统一分发器加固后的内核会忽略这类表项修改若不做处理直接加载 hook初始化会失败甚至导致 kernel panic。修复方式二选一严禁同时使用启用 KernelSU 3.3.0 引入的构建选项KSU_X86_PATCH_SYSCALL_DISPATCHER——运行时动态修补加固后的 syscall 分发器无需再打内核源码补丁这是使用 3.3.0 的推荐方式对应源码为 kernel/hook/x86_64/patch_memory.c继续沿用原始内核源码补丁方案针对内核 6.6 / 6.12 / 6.18 各有对应补丁其原理是创建X86_FEATURE_INDIRECT_SAFE特性并可通过内核 cmdlinesyscall_hardeningoff激活。安全代价必须明示两种方案本质都是绕过/削弱针对推测执行漏洞的缓解措施会重新打开系统调用路径上的间接分支攻击面。官方文档明确建议生产服务器或对侧信道安全要求严格的系统不要使用上述任一方案它们仅面向root 优先于该项硬件缓解的测试/个人环境。这一警告在构建选项层面得到了直接印证见下文Kconfig解析。三、使用与构建从 GKI 树集成到 ksud 命令行俄文 README 的Использование一节指向安装、构建与官网三个入口。仓库内对应的实操材料如下。3.1 安装LKM 与 GKI 两种运行模式自 v0.9.0 起KernelSU 在 GKI 设备上支持两种模式详见 website/docs/guide/installation.mdLKM 模式不替换设备原内核向运行内核加载 loadable kernel module。优点是升级/OTA 便捷管理器内直接安装、支持安装到 inactive slot、LKM 可临时卸载且无需重启Android 13 设备上它修改的是init_boot分区的 ramdisk 而非boot。GKI 模式用 KernelSU 提供的通用内核镜像整体替换设备内核通用性强例如启用了 KNOX 的设备 LKM 不可用时且只依赖 KMI 一致即可刷机无需等待官方固件。选择建议实体手机优先 LKM模拟器、WSA、Waydroid 优先 GKI——这与俄文 README 中WSA 和容器化 Android 可用的兼容性描述呼应。命令行侧ksud boot-patch是最常用的 LKM 安装入口帮助输出完整参数如下引自安装文档实测oriole:/ # ksud boot-patch -h Patch boot or init_boot images to apply KernelSU Usage: ksud boot-patch [OPTIONS] Options: -b, --boot BOOT Boot image path. If not specified, it will try to find the boot image automatically -k, --kernel KERNEL Kernel image path to be replaced -m, --module MODULE LKM module path to be replaced. If not specified, the built-in module will be used -i, --init INIT init to be replaced -u, --ota Will use another slot if the boot image is not specified -f, --flash Flash it to boot partition after patch -o, --out OUT Output path. If not specified, the current directory will be used --magiskboot MAGISKBOOT magiskboot path. If not specified, the built-in version will be used --kmi KMI KMI version. If specified, the indicated KMI will be used -h, --help Print help最常见的用法ksud boot-patch -b boot.img --kmi android13-5.10其中--magiskboot可显式指定 magiskboot 路径缺省走内置版本--kmi用于设备内核名不符合 KMI 规范时手动指定 KMI 版本。ksud的 Rust 源码位于 userspace/ksud/srcmain.rs、boot_patch.rs等其 Android 端交叉构建命令由 justfile 提供# 构建 aarch64 的 ksud 静态产物对应 justfile 的 build_ksud 任务 cross build --target aarch64-linux-android --release # 构建管理器 APK先构建 ksud再复制为 jniLibs 中的 libksud.so最后 gradle 打包 cp target/aarch64-linux-android/release/ksud manager/app/src/main/jniLibs/arm64-v8a/libksud.so cd manager ./gradlew aDebug3.2 构建Kconfig 选项与 GKI 内核树集成KernelSU 内核侧的构建入口是 kernel/Kconfig其中声明了五个构建选项是理解其编译依赖与可裁剪面的关键选项类型/依赖默认值含义据 Kconfig help 文本KSUtristate依赖KPROBES EXT4_FSy总开关hook 能力依赖CONFIG_KPROBES/systemumount 能力依赖ext4_unregister_sysfs选M时编译为名为kernelsu的模块即 LKMKSU_DEBUGbool依赖KSUn开启 KernelSU 调试模式KSU_DISABLE_MANAGERbool依赖KSUn禁用管理器 APK 检测与管理器专属处理root 直接替代管理器相关功能KSU_DISABLE_POLICYbool依赖KSUn禁用按应用 root/non-root Profile 定制提权一律走默认全 root 配置non-root 处理仅跟随全局 umount 策略KSU_X86_PATCH_SYSCALL_DISPATCHERbool依赖KSU X86_64n运行时动态修补 x86_64 加固后的 syscall 分发器以支持 syscall hook作为内核源码补丁的替代方案对 x86_64 LKM 模式尤为有用注意最后一行它只在X86_64架构下出现默认关闭——这正是第二部分所述 x86_64 kernel panic 风险的官方缓解开关构建新内核尤其是 3.3.0 的 x86_64 目标时应当显式打开。对于 GKI 2.0 设备官方支持范围仓库提供了标准集成脚本 kernel/setup.sh其工作流见setup_kernelsu函数为在 GKI 内核源码树根目录执行自动探测common/drivers或drivers目录克隆 KernelSU 仓库或更新已有目录检出最新 tag 或指定commit-or-tag参数在drivers/下创建指向KernelSU/kernel的符号链接kernelsu向drivers/Makefile追加obj-$(CONFIG_KSU) kernelsu/向drivers/Kconfig注入source drivers/kernelsu/Kconfig。脚本支持--cleanup完整撤销上述修改。从源码结构看非 GKI 内核4.14 等旧内核没有这套标准集成路径正对应俄文 README 中旧内核需要自行构建的兼容性声明website/docs/guide/ 下的 how-to-integrate 系列文档给出了非 GKI 设备集成的补充说明。四、代码仓库结构速览结合俄文 README 的致谢与仓库实际布局各部分职责如下目录/文件职责kernel/内核模块主体hook/syscall、setuid、tp_marker 等 hook、supercall/超级系统调用、policy/allowlist 与应用 Profile、selinux/、manager/管理器身份识别、包观察、uapi/用户接口头文件userspace/ksudRust 编写的用户态工具boot 修补boot_patch.rs、模块管理module.rs、metamodulemetamodule.rs、sepolicy、sulog 等userspace/ksuinit早期 init 阶段的 Rust 初始化程序manager/app管理器 APKKotlin/Jetpack Compose UI、JNIcpp/、AIDL 接口、各语言res/values-*本地化资源uapi/与kernel/include/uapi/对应的用户接口头文件ksu.h、supercall.h等website/docs官方文档站源码含安装、metamodule、App Profile、x86_64 支持等完整指南scripts/开发辅助脚本如setup_cargo_config.py、prepare-ddk-x64.shjustfile中还定义了clippy任务cargo fmtcross clippy --target aarch64-linux-android --release可作为贡献前检查 Rust 侧代码规范的入口。五、许可证俄文 README 的Лицензия一节声明了双许可结构与仓库实际文件一致kernel/目录下的文件GPL-2.0-only见 kernel/LICENSE除kernel/目录外的所有部分userspace/、manager/、website/等GPL-3.0-or-later见仓库根目录 LICENSE。这一划分使内核侧保持与 Linux 内核一致的 GPLv2 约束而用户态工具链与文档可以采用 GPLv3。此外仓库根目录提供 SECURITY.md 用于说明安全漏洞的报告渠道涉及安全问题的读者应优先查阅该文件而非公开渠道。六、致谢上游依赖俄文 README 的Благодарности一节列出了四个上游项目它们也解释了代码库中的若干实现来源kernel-assisted-superuserKernelSU 整个内核辅助超级用户概念的原始出处Magisksepolicy 实现的重要参考KernelSU 的 kernel/selinux/sepolicy.c 一脉相承genuineAPK v2 签名校验机制用于管理器身份核验对应 kernel/manager/apk_sign.cDiamorphine部分 rootkit 技术内存修补等可对照 kernel/hook/patch_memory.h 及两套架构下的patch_memory.c实现。七、结语回顾 docs/README_RU.md 的完整脉络KernelSU 以内核态授权为立身之本通过 supercall allowlist 应用 Profile 三层机制实现细粒度 root 管控通过 metamodule 把系统分区修改能力做成可插拔组件官方支持边界锁定在 GKI 2.05.10与arm64-v8a/x86_64双架构并明确提示了 x86_64 新内核上 syscall 加固引发的兼容性风险及其两种解法。对于要在自有设备或容器化 Android 环境中落地 KernelSU 的开发者建议的路径是先按安装文档确认 KMI 与压缩格式选择 LKM 或 GKI 模式若目标是 x86_64 新内核则务必在Kconfig中打开KSU_X86_PATCH_SYSCALL_DISPATCHER或应用对应源码补丁再借助 kernel/setup.sh 与justfile完成集成与交叉构建。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KernelSU 内核级 Root 方案全解：核心特性、兼容性约束与构建集成实践
KernelSU 内核级 Root 方案全解核心特性、兼容性约束与构建集成实践【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSUKernelSU 是一个基于 Linux 内核的 Android Root 方案它以内核模块或编入内核的驱动的形式运行在内核态直接在 kernel space 中完成 root 权限的授予与管控。本篇以仓库中的俄文主文档 docs/README_RU.md 为骨架展开逐条解析其三大核心特性、官方兼容性与x86_64架构下的内核 panic 风险并结合 kernel/Kconfig、justfile、kernel/setup.sh 等仓库源码给出可操作的构建与集成步骤。读完本文你将能判断目标设备是否处于官方支持范围、理解 GKI/LKM 两种运行模式的选择依据并掌握从 GKI 内核树集成、Kconfig选项裁剪到ksud命令行修补boot.img的完整链路。一、项目定位为什么 Root 逻辑要放进内核KernelSU 的核心主张docs/README_RU.md 开篇即声明是Решение на основе ядра root для Android-устройств——一个基于内核的 Android root 方案。与运行在用户态、依赖setuid二进制或 Magisk 式分区修补的方案不同KernelSU 把权限决策点上移到内核态由此获得了文档中列出的三大特性。仓库 website/docs/guide/what-is-kernelsu.md 进一步说明了这一架构红利在内核态中可以拦截任意系统调用、为任意进程添加硬件断点、不可见地访问目标进程的物理内存等这些都是用户态方案不具备的内核接口能力。下面按俄文 README 的Особенности特性清单逐条展开。1. 基于内核的su与 Root 访问管理README 第一条特性是Управлениеsuи root-доступом на основе ядра基于内核的 su 和 root 访问管理。其实现入口可以从源码结构中直接验证kernel/supercall/supercall.c 实现了 KernelSU 独有的超级系统调用分发机制用户态通过uapi/supercall.h定义的接口进入内核态执行权限提升操作kernel/hook/setuid_hook.c 负责在经典setuid路径上拦截并改写身份提升行为kernel/policy/allowlist.c 维护哪些应用UID/包名有权获得 root 的允许名单权限授予完全由用户控制而非应用开发者——这一点与应用 Profile 文档website/docs/guide/app-profile.md中Granting su permissions is entirely controlled by the user, not the developer的描述一致。用户态侧管理器 APK 通过 JNImanager/app/src/main/cpp/jni.cc调用 Rust 编写的ksud工具完成修补与安装而su请求最终经由内核接口裁决。2. 基于 Metamodule 的模块化系统第二条特性是基于 metamodules 的模块系统面向无系统化systemless修改的可插拔基础设施。这里的关键设计是KernelSU 内核本体不内置/system挂载逻辑而是把挂载/overlay 这类系统分区修改能力委托给可插拔的 metamodule。仓库文档 website/docs/guide/metamodule.md 解释了为何这样设计安装文档 website/docs/guide/installation.md 的Post-Installation: Module Support一节也给出了明确提示如果你的模块需要修改/system文件安装 KernelSU 之后必须先安装一个metamodule如官方meta-overlayfs仅使用脚本、sepolicy 或 system.prop 的模块则不需要。这一核心瘦、能力插的架构使模块系统成为一等公民模块安装、卸载、按应用 unmount 等行为都由 metamodule 与内核策略kernel/feature/kernel_umount.c 等协作完成。3. 应用 Profile把 root 关进笼子第三条特性Профиль приложенийЗапри корневую силу в клетке应用 Profile把 root 力量关进笼子是 KernelSU 最具辨识度的安全设计。俄文 README 的表述直白——lock up the root power in a cage。其完整语义见 website/docs/guide/app-profile.md核心要点Root Profile已授权 root 的应用可定制su之后 root 进程的uid/gid/groups/capabilities/ SELinux 上下文。例如把某应用的 root 进程 UID 设为2000ADB shell 级别或剥离inet组使其无法通过su访问网络或为 root 进程自定义一个受限 SELinux 域如u:r:app1:s0并只授予必要规则。非 root 应用 Profile控制内核与模块系统对该应用的行为典型用途是Umount modules——对该应用隐藏所有 overlay 挂载用于对抗对系统分区修改敏感的应用配合管理器中的Umount modules by default全局开关可组成白名单/黑名单两种策略。Escalation 陷阱文档特别警告若把应用 root 进程设为 UID2000而2000本身也被授权 root应用可连续执行两次su逃逸到完整 root可用 Profile 中的NO_NEW_PRIVS标志阻止 KernelSU 层面的二次提权。内核侧的支撑实现位于 kernel/policy/app_profile.c 与 kernel/feature/feature.c用户接口定义在 uapi/app_profile.h 和 uapi/feature.h这些策略在内核内强制执行不依赖 root 应用的自觉行为这是它与su 里手动setuid切换用户的本质区别。二、兼容性状态官方支持边界与 x86_64 的 kernel panic 警告俄文 README 的Совместимость一节给出了四条兼容性事实逐条核对如下。官方支持矩阵维度官方状态说明内核版本GKI 2.0内核 5.10官方支持KernelSU 不为Unsupported设备提供任何 boot.img需自行编译内核旧内核4.14 可用但需自行构建属于兼容但非官方维护范围特殊环境WSA、容器化 Android 可运行需集成 KernelSU 内核英文 README 中还列出 ChromeOSCPU 架构arm64-v8a与x86_64与仓库中 kernel/hook/arm64 与 kernel/hook/x86_64 两套架构 hook 实现相对应如何判断我的设备是否被官方支持的实操方法见 website/docs/guide/installation.md安装 KernelSU 管理器后若显示Unsupported说明需要自己编译内核显示Not installed则说明设备在官方支持列表内。该文档同时强调 GKI 设备刷机前的三个关键概念——KMIKernel Module Interface决定跨内核镜像兼容性的w.x-androidXXX-k段、安全补丁级别防回滚机制可能拒绝低补丁级别的镜像以及内核版本号不等于 Android 版本号这些是选择正确 boot.img / AnyKernel3 包的前提。x86_64 架构的破坏性内核变更重要警告俄文 README 用醒目的CAUTION警告框指出最新内核版本中存在一项破坏性变更会导致 KernelSU 失效、并在x86_64上可能引发 kernel panic。该警告的完整技术背景记录在 website/docs/guide/x86_64-support.md根因上游内核为安全加固修改了系统调用路径把系统调用表中的间接分支改写成一系列直接条件分支syscall table hardening。KernelSU 的syscall_hook机制依赖改写 syscall 表项、把被拦截的调用路由到统一分发器加固后的内核会忽略这类表项修改若不做处理直接加载 hook初始化会失败甚至导致 kernel panic。修复方式二选一严禁同时使用启用 KernelSU 3.3.0 引入的构建选项KSU_X86_PATCH_SYSCALL_DISPATCHER——运行时动态修补加固后的 syscall 分发器无需再打内核源码补丁这是使用 3.3.0 的推荐方式对应源码为 kernel/hook/x86_64/patch_memory.c继续沿用原始内核源码补丁方案针对内核 6.6 / 6.12 / 6.18 各有对应补丁其原理是创建X86_FEATURE_INDIRECT_SAFE特性并可通过内核 cmdlinesyscall_hardeningoff激活。安全代价必须明示两种方案本质都是绕过/削弱针对推测执行漏洞的缓解措施会重新打开系统调用路径上的间接分支攻击面。官方文档明确建议生产服务器或对侧信道安全要求严格的系统不要使用上述任一方案它们仅面向root 优先于该项硬件缓解的测试/个人环境。这一警告在构建选项层面得到了直接印证见下文Kconfig解析。三、使用与构建从 GKI 树集成到 ksud 命令行俄文 README 的Использование一节指向安装、构建与官网三个入口。仓库内对应的实操材料如下。3.1 安装LKM 与 GKI 两种运行模式自 v0.9.0 起KernelSU 在 GKI 设备上支持两种模式详见 website/docs/guide/installation.mdLKM 模式不替换设备原内核向运行内核加载 loadable kernel module。优点是升级/OTA 便捷管理器内直接安装、支持安装到 inactive slot、LKM 可临时卸载且无需重启Android 13 设备上它修改的是init_boot分区的 ramdisk 而非boot。GKI 模式用 KernelSU 提供的通用内核镜像整体替换设备内核通用性强例如启用了 KNOX 的设备 LKM 不可用时且只依赖 KMI 一致即可刷机无需等待官方固件。选择建议实体手机优先 LKM模拟器、WSA、Waydroid 优先 GKI——这与俄文 README 中WSA 和容器化 Android 可用的兼容性描述呼应。命令行侧ksud boot-patch是最常用的 LKM 安装入口帮助输出完整参数如下引自安装文档实测oriole:/ # ksud boot-patch -h Patch boot or init_boot images to apply KernelSU Usage: ksud boot-patch [OPTIONS] Options: -b, --boot BOOT Boot image path. If not specified, it will try to find the boot image automatically -k, --kernel KERNEL Kernel image path to be replaced -m, --module MODULE LKM module path to be replaced. If not specified, the built-in module will be used -i, --init INIT init to be replaced -u, --ota Will use another slot if the boot image is not specified -f, --flash Flash it to boot partition after patch -o, --out OUT Output path. If not specified, the current directory will be used --magiskboot MAGISKBOOT magiskboot path. If not specified, the built-in version will be used --kmi KMI KMI version. If specified, the indicated KMI will be used -h, --help Print help最常见的用法ksud boot-patch -b boot.img --kmi android13-5.10其中--magiskboot可显式指定 magiskboot 路径缺省走内置版本--kmi用于设备内核名不符合 KMI 规范时手动指定 KMI 版本。ksud的 Rust 源码位于 userspace/ksud/srcmain.rs、boot_patch.rs等其 Android 端交叉构建命令由 justfile 提供# 构建 aarch64 的 ksud 静态产物对应 justfile 的 build_ksud 任务 cross build --target aarch64-linux-android --release # 构建管理器 APK先构建 ksud再复制为 jniLibs 中的 libksud.so最后 gradle 打包 cp target/aarch64-linux-android/release/ksud manager/app/src/main/jniLibs/arm64-v8a/libksud.so cd manager ./gradlew aDebug3.2 构建Kconfig 选项与 GKI 内核树集成KernelSU 内核侧的构建入口是 kernel/Kconfig其中声明了五个构建选项是理解其编译依赖与可裁剪面的关键选项类型/依赖默认值含义据 Kconfig help 文本KSUtristate依赖KPROBES EXT4_FSy总开关hook 能力依赖CONFIG_KPROBES/systemumount 能力依赖ext4_unregister_sysfs选M时编译为名为kernelsu的模块即 LKMKSU_DEBUGbool依赖KSUn开启 KernelSU 调试模式KSU_DISABLE_MANAGERbool依赖KSUn禁用管理器 APK 检测与管理器专属处理root 直接替代管理器相关功能KSU_DISABLE_POLICYbool依赖KSUn禁用按应用 root/non-root Profile 定制提权一律走默认全 root 配置non-root 处理仅跟随全局 umount 策略KSU_X86_PATCH_SYSCALL_DISPATCHERbool依赖KSU X86_64n运行时动态修补 x86_64 加固后的 syscall 分发器以支持 syscall hook作为内核源码补丁的替代方案对 x86_64 LKM 模式尤为有用注意最后一行它只在X86_64架构下出现默认关闭——这正是第二部分所述 x86_64 kernel panic 风险的官方缓解开关构建新内核尤其是 3.3.0 的 x86_64 目标时应当显式打开。对于 GKI 2.0 设备官方支持范围仓库提供了标准集成脚本 kernel/setup.sh其工作流见setup_kernelsu函数为在 GKI 内核源码树根目录执行自动探测common/drivers或drivers目录克隆 KernelSU 仓库或更新已有目录检出最新 tag 或指定commit-or-tag参数在drivers/下创建指向KernelSU/kernel的符号链接kernelsu向drivers/Makefile追加obj-$(CONFIG_KSU) kernelsu/向drivers/Kconfig注入source drivers/kernelsu/Kconfig。脚本支持--cleanup完整撤销上述修改。从源码结构看非 GKI 内核4.14 等旧内核没有这套标准集成路径正对应俄文 README 中旧内核需要自行构建的兼容性声明website/docs/guide/ 下的 how-to-integrate 系列文档给出了非 GKI 设备集成的补充说明。四、代码仓库结构速览结合俄文 README 的致谢与仓库实际布局各部分职责如下目录/文件职责kernel/内核模块主体hook/syscall、setuid、tp_marker 等 hook、supercall/超级系统调用、policy/allowlist 与应用 Profile、selinux/、manager/管理器身份识别、包观察、uapi/用户接口头文件userspace/ksudRust 编写的用户态工具boot 修补boot_patch.rs、模块管理module.rs、metamodulemetamodule.rs、sepolicy、sulog 等userspace/ksuinit早期 init 阶段的 Rust 初始化程序manager/app管理器 APKKotlin/Jetpack Compose UI、JNIcpp/、AIDL 接口、各语言res/values-*本地化资源uapi/与kernel/include/uapi/对应的用户接口头文件ksu.h、supercall.h等website/docs官方文档站源码含安装、metamodule、App Profile、x86_64 支持等完整指南scripts/开发辅助脚本如setup_cargo_config.py、prepare-ddk-x64.shjustfile中还定义了clippy任务cargo fmtcross clippy --target aarch64-linux-android --release可作为贡献前检查 Rust 侧代码规范的入口。五、许可证俄文 README 的Лицензия一节声明了双许可结构与仓库实际文件一致kernel/目录下的文件GPL-2.0-only见 kernel/LICENSE除kernel/目录外的所有部分userspace/、manager/、website/等GPL-3.0-or-later见仓库根目录 LICENSE。这一划分使内核侧保持与 Linux 内核一致的 GPLv2 约束而用户态工具链与文档可以采用 GPLv3。此外仓库根目录提供 SECURITY.md 用于说明安全漏洞的报告渠道涉及安全问题的读者应优先查阅该文件而非公开渠道。六、致谢上游依赖俄文 README 的Благодарности一节列出了四个上游项目它们也解释了代码库中的若干实现来源kernel-assisted-superuserKernelSU 整个内核辅助超级用户概念的原始出处Magisksepolicy 实现的重要参考KernelSU 的 kernel/selinux/sepolicy.c 一脉相承genuineAPK v2 签名校验机制用于管理器身份核验对应 kernel/manager/apk_sign.cDiamorphine部分 rootkit 技术内存修补等可对照 kernel/hook/patch_memory.h 及两套架构下的patch_memory.c实现。七、结语回顾 docs/README_RU.md 的完整脉络KernelSU 以内核态授权为立身之本通过 supercall allowlist 应用 Profile 三层机制实现细粒度 root 管控通过 metamodule 把系统分区修改能力做成可插拔组件官方支持边界锁定在 GKI 2.05.10与arm64-v8a/x86_64双架构并明确提示了 x86_64 新内核上 syscall 加固引发的兼容性风险及其两种解法。对于要在自有设备或容器化 Android 环境中落地 KernelSU 的开发者建议的路径是先按安装文档确认 KMI 与压缩格式选择 LKM 或 GKI 模式若目标是 x86_64 新内核则务必在Kconfig中打开KSU_X86_PATCH_SYSCALL_DISPATCHER或应用对应源码补丁再借助 kernel/setup.sh 与justfile完成集成与交叉构建。【免费下载链接】KernelSUA Kernel based root solution for Android项目地址: https://gitcode.com/GitHub_Trending/ke/KernelSU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考