突破GKI限制：KernelSU非GKI设备集成实战指南

在Android设备的世界里，内核碎片化问题一直是开发者面临的重大挑战。特别是对于使用非GKI（Generic Kernel Image）设备的用户，想要体验KernelSU带来的强大root能力似乎遥不可及。本文将带你跨越这一障碍，通过三种实战方案实现非GKI设备的KernelSU完美集成，即使是零基础用户也能按图索骥，让老旧设备焕发新生。

核心价值：为什么非GKI集成如此重要

KernelSU作为基于内核的Android root解决方案，提供了比传统root方式更强大的权限管理和系统控制能力。然而，官方支持主要集中在GKI设备上，大量非GKI设备用户被挡在门外。通过本文介绍的方法，你将获得：

• 设备兼容性扩展：让不支持GKI的老旧设备也能使用KernelSU
• 系统级权限控制：实现更安全、更细粒度的root权限管理
• 模块化扩展能力：支持各类系统增强模块，提升设备功能

[!NOTE] 本文适用于所有非GKI架构的Android设备，特别推荐给那些官方未提供GKI支持但内核源码开放的设备用户。

准备工作：集成前的环境搭建

在开始集成之前，请确保你的开发环境满足以下条件：

1. 基础环境配置

   • 已安装Android NDK和SDK
   • 已配置交叉编译工具链
   • 设备内核源码已成功编译并可正常启动

2. 获取KernelSU源码

   # 克隆KernelSU仓库
   git clone https://gitcode.com/GitHub_Trending/ke/KernelSU
   cd KernelSU
   
   # 切换到支持非GKI的最后版本
   git checkout v0.9.5
   

⚠️ 风险提示：KernelSU 1.0及更高版本已不再支持非GKI内核，务必使用v0.9.5版本进行集成。

3. 内核源码准备 将KernelSU集成到你的内核源码树：

   # 在你的内核源码根目录执行
   curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5
   

💡 优化建议：建议在集成前对内核源码进行备份，以便出现问题时可以快速恢复。

📌 要点总结：

• 确保开发环境完整配置
• 必须使用v0.9.5版本的KernelSU
• 执行setup.sh脚本完成源码集成
• 提前备份内核源码

解决方案对比：三种集成路径的优劣势分析

方案	适用场景	复杂度	成功率	核心原理
kprobe自动集成	内核支持kprobe且工作正常	低	高	利用内核调试机制实现函数hook
手动源码修改	kprobe无法工作或内核版本过低	高	中	直接修改内核关键函数实现集成
混合集成方案	复杂内核环境或特殊设备	中	高	结合kprobe和部分手动修改

方案一：kprobe自动集成（推荐新手）

kprobe是Linux内核提供的调试机制，KernelSU可以利用它实现内核函数的hook，这是最简单的集成方法。

配置内核选项

编辑你的内核配置文件（通常位于arch/arm64/configs/目录），添加以下配置：

# KernelSU配置
CONFIG_KSU=y
CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_KPROBE_EVENTS=y

验证kprobe工作状态

编译并刷入内核后，通过以下步骤验证kprobe是否正常工作：

1. 启动设备并观察是否能正常进入系统
2. 若设备无法启动，尝试注释ksu.c中的以下函数调用：

   // 临时注释以测试kprobe问题
   // ksu_enable_sucompat();
   // ksu_enable_ksud();
   

3. 重新编译后若设备能正常启动，则说明kprobe存在问题

[!WARNING] 如果你的内核配置中启用了CONFIG_MODULES，可能会影响kprobe的工作，必要时可以尝试禁用该选项。

📌 要点总结：

• 开启kprobe相关内核配置是关键
• 通过注释测试可以快速定位kprobe问题
• 此方法适用于大多数支持kprobe的内核

方案二：手动源码修改（适用于复杂环境）

当kprobe无法正常工作时，需要采用手动修改内核源码的方式进行集成。这种方法需要修改四个关键函数。

修改内核配置

首先在配置文件中启用KernelSU：

# KernelSU配置
CONFIG_KSU=y

修改关键系统调用

1. 修改fs/exec.c（处理程序执行）

   diff --git a/fs/exec.c b/fs/exec.c
   index ac59664eaecf..bdd585e1d2cc 100644
   --- a/fs/exec.c
   +++ b/fs/exec.c
   @@ -1890,11 +1890,14 @@ static int __do_execve_file(int fd, struct filename *filename,
   	return retval;
   }
   
   +#ifdef CONFIG_KSU
   +extern bool ksu_execveat_hook __read_mostly;
   +extern int ksu_handle_execveat(int *fd, struct filename **filename_ptr, void *argv,
   +			void *envp, int *flags);
   +extern int ksu_handle_execveat_sucompat(int *fd, struct filename **filename_ptr,
   +				 void *argv, void *envp, int *flags);
   +#endif
   static int do_execveat_common(int fd, struct filename *filename,
   			      struct user_arg_ptr argv,
   			      struct user_arg_ptr envp,
   			      int flags)
   {
   +   #ifdef CONFIG_KSU
   +	if (unlikely(ksu_execveat_hook))
   +		ksu_handle_execveat(&fd, &filename, &argv, &envp, &flags);
   +	else
   +		ksu_handle_execveat_sucompat(&fd, &filename, &argv, &envp, &flags);
   +   #endif
   	return __do_execve_file(fd, filename, argv, envp, flags, NULL);
   }
   

2. 修改fs/open.c（处理文件访问控制）

   diff --git a/fs/open.c b/fs/open.c
   index 05036d819197..965b84d486b8 100644
   --- a/fs/open.c
   +++ b/fs/open.c
   @@ -348,6 +348,8 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
   	return ksys_fallocate(fd, mode, offset, len);
   }
   
   +#ifdef CONFIG_KSU
   +extern int ksu_handle_faccessat(int *dfd, const char __user **filename_user, int *mode,
   +			 int *flags);
   +#endif
   /*
    * access() needs to use the real uid/gid, not the effective uid/gid.
    * We do this by temporarily clearing all FS-related capabilities and
   @@ -355,6 +357,7 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
    */
   long do_faccessat(int dfd, const char __user *filename, int mode)
   {
   	const struct cred *old_cred;
   	struct cred *override_cred;
   	struct path path;
   	struct inode *inode;
   	struct vfsmount *mnt;
   	int res;
   	unsigned int lookup_flags = LOOKUP_FOLLOW;
   +   #ifdef CONFIG_KSU
   +	ksu_handle_faccessat(&dfd, &filename, &mode, NULL);
   +   #endif
   
   	if (mode & ~S_IRWXO)	/* where's F_OK, X_OK, W_OK, R_OK? */
   		return -EINVAL;
   

3. 修改fs/read_write.c（处理文件读写）和fs/stat.c（处理文件状态查询） 类似上述修改方式，添加KernelSU的处理函数调用。

💡 优化建议：对于4.17之前的内核，如果没有do_faccessat函数，可以直接修改faccessat系统调用的定义。

📌 要点总结：

• 手动集成需要修改四个关键系统调用
• 不同内核版本可能需要调整修改位置
• 确保修改后内核仍能正常编译通过

方案三：混合集成方案（平衡复杂度与兼容性）

对于一些特殊内核环境，可以采用混合集成方案：核心功能使用手动修改保证稳定性，非关键功能使用kprobe实现灵活性。

1. 按照方案二修改关键系统调用
2. 仅为非关键功能启用kprobe支持
3. 在内核配置中添加：

   # 混合模式配置
   CONFIG_KSU=y
   CONFIG_KPROBES=y
   CONFIG_HAVE_KPROBES=y
   # 仅启用必要的kprobe事件
   CONFIG_KPROBE_EVENTS=y
   

这种方案结合了前两种方法的优点，既保证了核心功能的稳定性，又保留了部分动态hook的灵活性。

进阶优化：提升系统稳定性与安全性

启用安全模式功能

为提高系统稳定性，建议启用KernelSU的安全模式功能。修改drivers/input/input.c文件：

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 45306f9ef247..815091ebfca4 100755
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -367,10 +367,13 @@ static int input_get_disposition(struct input_dev *dev,
 	return disposition;
 }

+#ifdef CONFIG_KSU
+extern bool ksu_input_hook __read_mostly;
+extern int ksu_handle_input_handle_event(unsigned int *type, unsigned int *code, int *value);
+#endif
+
 static void input_handle_event(struct input_dev *dev,
 			       unsigned int type, unsigned int code, int value)
 {
 	int disposition = input_get_disposition(dev, type, code, &value);
+   #ifdef CONFIG_KSU
+	if (unlikely(ksu_input_hook))
+		ksu_handle_input_handle_event(&type, &code, &value);
+   #endif
 
 	if (disposition != INPUT_IGNORE_EVENT && type != EV_SYN)
 		add_input_randomness(type, code, value);

[!NOTE] 如果采用手动集成方式，请确保关闭CONFIG_KPROBES选项，否则可能导致设备进入安全模式。

移植path_umount功能（适用于5.9之前内核）

为使"卸载模块"功能正常工作，需要手动移植path_umount函数到fs/namespace.c：

--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1739,6 +1739,39 @@ static inline bool may_mandlock(void)
 }
 #endif

+static int can_umount(const struct path *path, int flags)
+{
+	struct mount *mnt = real_mount(path->mnt);
+
+	if (flags & ~(MNT_FORCE | MNT_DETACH | MNT_EXPIRE | UMOUNT_NOFOLLOW))
+		return -EINVAL;
+	if (!may_mount())
+		return -EPERM;
+	if (path->dentry != path->mnt->mnt_root)
+		return -EINVAL;
+	if (!check_mnt(mnt))
+		return -EINVAL;
+	if (mnt->mnt.mnt_flags & MNT_LOCKED) /* Check optimistically */
+		return -EINVAL;
+	if (flags & MNT_FORCE && !capable(CAP_SYS_ADMIN))
+		return -EPERM;
+	return 0;
+}
+
+int path_umount(struct path *path, int flags)
+{
+	struct mount *mnt = real_mount(path->mnt);
+	int ret;
+
+	ret = can_umount(path, flags);
+	if (!ret)
+		ret = do_umount(mnt, flags);
+
+	/* we mustn't call path_put() as that would clear mnt_expiry_mark */
+	dput(path->dentry);
+	mntput_no_expire(mnt);
+	return ret;
+}
 /*
  * Now umount can handle mount points as well as block devices.
  * This is important for filesystems which use unnamed block devices.

📌 要点总结：

• 安全模式可提高系统稳定性
• 老旧内核需要移植path_umount功能
• 手动集成时需关闭KPROBES选项

实战验证：5步确认集成成功

完成集成后，按照以下步骤验证KernelSU是否正常工作：

步骤1：编译内核镜像

# 清理之前的编译产物
make clean && make mrproper

# 配置内核
make your_device_defconfig

# 开始编译（-j后面的数字根据CPU核心数调整）
make -j8 bootimage

预期效果：编译过程无错误，在out/target/product/your_device/目录下生成boot.img文件。

步骤2：刷入内核镜像

# 进入fastboot模式后执行
fastboot flash boot boot.img
fastboot reboot

预期效果：设备正常启动，无无限重启或卡在开机画面。

步骤3：验证KernelSU安装

安装KernelSU管理器应用后打开，观察应用是否能正常检测到KernelSU。

步骤4：功能测试

1. 尝试授予应用root权限
2. 安装一个简单的模块并启用
3. 验证模块功能是否正常工作

步骤5：稳定性测试

连续使用设备24小时，观察是否出现：

• 系统崩溃或重启
• 应用无响应
• 耗电异常增加

📌 要点总结：

• 编译过程无错误是基础
• 设备能正常启动是关键
• 功能测试需覆盖核心功能
• 稳定性测试至少持续24小时

常见失败场景诊断与解决方案

场景1：编译失败

症状：编译过程中出现大量错误，提示未定义的函数或变量。

解决方案：

• 检查KernelSU版本是否为v0.9.5
• 确认所有必要的补丁已正确应用
• 检查内核配置是否正确设置了CONFIG_KSU=y

场景2：设备无法启动

症状：刷入新内核后，设备卡在开机画面或无限重启。

解决方案：

• 尝试注释ksu_enable_sucompat()和ksu_enable_ksud()函数调用
• 检查是否同时启用了手动修改和kprobe
• 验证内核配置是否与设备匹配

场景3：pm命令执行失败

症状：在终端中执行pm命令时出现权限错误。

解决方案：修改fs/devpts/inode.c文件：

diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c
index 32f6f1c68..d69d8eca2 100644
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -602,6 +602,8 @@ struct dentry *devpts_pty_new(struct pts_fs_info *fsi, int index, void *priv)
         return dentry;
 }

+#ifdef CONFIG_KSU
+extern int ksu_handle_devpts(struct inode*);
+#endif
+
 /**
  * devpts_get_priv -- get private data for a slave
  * @pts_inode: inode of the slave
@@ -610,6 +612,7 @@ struct dentry *devpts_pty_new(struct pts_fs_info *fsi, int index, void *priv)
  */
 void *devpts_get_priv(struct dentry *dentry)
 {
+       #ifdef CONFIG_KSU
+       ksu_handle_devpts(dentry->d_inode);
+       #endif
         if (dentry->d_sb->s_magic != DEVPTS_SUPER_MAGIC)
                 return NULL;
         return dentry->d_fsdata;

社区解决方案集锦

KernelSU社区已经为许多非GKI设备提供了集成方案，以下是一些常见设备的解决方案：

华为设备系列

• P系列/Mate系列：需要禁用某些特定的华为内核保护机制
• 荣耀系列：需修改drivers/security/hw_key.c中的安全检查

小米设备系列

• Redmi系列：部分设备需要移植fs/namespace.c中的path_umount函数
• Mi系列：需要调整SELinux策略以允许KernelSU运行

三星设备系列

• Galaxy S系列：需修改init进程相关代码，解决权限问题
• Galaxy Note系列：需要禁用KNOX安全机制

[!TIP] 在尝试集成前，建议先在KernelSU社区搜索你的设备型号，可能已有现成的解决方案或补丁。

总结：非GKI设备的KernelSU集成之路

通过本文介绍的三种集成方案，即使是非GKI设备用户也能顺利体验KernelSU带来的强大功能。从简单的kprobe自动集成，到复杂的手动源码修改，再到平衡稳定性与灵活性的混合方案，总有一种方法适合你的设备和技术水平。

集成过程中遇到问题是正常的，关键是通过社区资源和本文提供的诊断方法，逐步排查解决。记住，每一次成功的集成不仅提升了你的设备功能，也是对Android内核知识的宝贵实践。

现在，是时候拿起工具，为你的非GKI设备开启KernelSU之旅了！