突破GKI限制：KernelSU非GKI内核集成创新方案全解析

在Android设备的root解决方案领域，非GKI内核与KernelSU集成一直是开发者面临的主要挑战。由于Android设备内核碎片化严重，特别是非GKI（Generic Kernel Image）设备缺乏统一的内核镜像支持，导致许多老旧设备无法享受到KernelSU带来的强大root能力。本文将通过创新的技术框架，帮助开发者突破这一限制，实现KernelSU在非GKI设备上的完美集成。

1. 技术原理对比：kprobe vs 手动修改

在开始集成操作前，我们首先需要了解两种主流集成方案的底层工作原理，以便根据实际设备情况做出最佳选择。

kprobe自动集成原理

kprobe机制就像内核中的监控摄像头，能够在不修改内核源码的情况下，动态地在指定函数入口/出口插入钩子程序。KernelSU利用这一特性实现对关键内核函数的拦截，从而实现root权限管理功能。

适用场景：内核版本较新（通常4.14+）且kprobe功能正常的设备，追求最小侵入式集成的场景。

手动修改集成原理

手动修改方式则像是直接对内核进行"外科手术"，通过直接修改核心函数的代码逻辑，将KernelSU的功能直接嵌入到内核流程中。这种方式虽然侵入性强，但兼容性更好，适用于kprobe无法工作的老旧内核。

适用场景：内核版本较旧（4.14以下）、kprobe功能异常或被禁用的设备，需要最大兼容性保障的场景。

📌 核心要点：kprobe方案具有维护成本低、升级方便的优势，但依赖内核特性支持；手动修改方案兼容性更强，但需要应对内核版本差异带来的适配挑战。选择时需综合考虑内核版本、设备特性和长期维护需求。

2. 设备兼容性矩阵：不同内核版本适配建议

不同的Android内核版本对KernelSU的支持程度不同，以下是针对不同内核版本的适配建议：

内核版本	推荐集成方案	主要挑战	额外配置
5.4+	kprobe自动集成	需确保kprobe依赖项完整	CONFIG_KPROBES=y
4.14-5.4	kprobe优先，手动备选	部分内核kprobe实现不稳定	可能需要禁用某些kprobe特性
4.9-4.14	手动修改集成	函数名和参数差异	需适配vfs_statx/vfs_fstatat差异
4.4及以下	手动修改集成	大量API不兼容	需要移植多个现代内核函数

⚠️ 注意：KernelSU 1.0及更高版本已不再支持非GKI内核，最后支持版本为v0.9.5，集成时务必使用此版本。

📌 核心要点：内核版本是选择集成方案的首要依据，5.4以上版本优先考虑kprobe方案，4.9以下版本则必须使用手动修改方案。同时需注意KernelSU的版本兼容性。

3. 3步实现kprobe自动集成

3.1 准备条件

• 已获取设备内核源码并能成功编译
• 内核版本4.14及以上
• 具备基本的内核配置和编译知识

3.2 操作命令

首先，将KernelSU源码集成到内核源码树：

# 进入内核源码根目录
cd /path/to/your/kernel/source

# 下载并执行KernelSU安装脚本，指定v0.9.5版本
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5

然后，配置内核选项：

# 打开内核配置界面
make menuconfig

在配置界面中启用以下选项：

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

3.3 验证方法

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

1. 启动设备，观察是否能正常开机
2. 执行以下命令检查KernelSU模块是否加载：

   dmesg | grep "KernelSU"
   

3. 若输出类似"KernelSU initialized"的日志，则表示kprobe集成成功

适用场景：内核版本较新且kprobe功能完整的设备，适合希望快速集成且尽量减少源码修改的场景。

🔧 故障排除：如果设备无法启动，可能是kprobe依赖项未完全启用。可以尝试启用CONFIG_MODULES选项，或通过make menuconfig检查并启用KPROBES的所有依赖项。

📌 核心要点：kprobe方案的关键在于确保内核配置中启用了所有必要的kprobe相关选项，安装脚本会自动处理大部分集成工作，大大降低了集成难度。

4. 4步实现手动修改集成

当kprobe方案不可行时，手动修改内核源码成为必要选择。这种方式虽然复杂，但兼容性更好。

4.1 准备条件

• 已获取设备内核完整源码
• 熟悉内核代码结构和编译流程
• 具备C语言编程和内核补丁制作能力

4.2 操作步骤

步骤1：集成KernelSU源码

同kprobe方案，首先将KernelSU源码集成到内核：

cd /path/to/your/kernel/source
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5

步骤2：修改内核配置

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

# KernelSU
CONFIG_KSU=y
# 禁用kprobe以避免冲突
# CONFIG_KPROBES is not set

步骤3：修改关键内核函数

需要修改四个核心文件，以下是关键修改内容：

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); // TODO: KernelSU execveat hook
+	else
+		ksu_handle_execveat_sucompat(&fd, &filename, &argv, &envp, &flags); // TODO: KernelSU sucompat handling
+   #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); // TODO: KernelSU faccessat hook
+   #endif
 
 	if (mode & ~S_IRWXO)	/* where's F_OK, X_OK, W_OK, R_OK? */
 		return -EINVAL;

3. 修改fs/read_write.c

diff --git a/fs/read_write.c b/fs/read_write.c
index 650fc7e0f3a6..55be193913b6 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -434,10 +434,14 @@ ssize_t kernel_read(struct file *file, void *buf, size_t count, loff_t *pos)
 }
 EXPORT_SYMBOL(kernel_read);

+#ifdef CONFIG_KSU
+extern bool ksu_vfs_read_hook __read_mostly;
+extern int ksu_handle_vfs_read(struct file **file_ptr, char __user **buf_ptr,
+			size_t *count_ptr, loff_t **pos);
+#endif
 ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
 {
 	ssize_t ret;
+   #ifdef CONFIG_KSU 
+	if (unlikely(ksu_vfs_read_hook))
+		ksu_handle_vfs_read(&file, &buf, &count, &pos); // TODO: KernelSU vfs_read hook
+   #endif
+
 	if (!(file->f_mode & FMODE_READ))
 		return -EBADF;
 	if (!(file->f_mode & FMODE_CAN_READ))

4. 修改fs/stat.c

diff --git a/fs/stat.c b/fs/stat.c
index 376543199b5a..82adcef03ecc 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -148,6 +148,8 @@ int vfs_statx_fd(unsigned int fd, struct kstat *stat,
 }
 EXPORT_SYMBOL(vfs_statx_fd);

+#ifdef CONFIG_KSU
+extern int ksu_handle_stat(int *dfd, const char __user **filename_user, int *flags);
+#endif
+
 /**
  * vfs_statx - Get basic and extra attributes by filename
  * @dfd: A file descriptor representing the base dir for a relative filename
@@ -170,6 +172,7 @@ int vfs_statx(int dfd, const char __user *filename, int flags,
 	int error = -EINVAL;
 	unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;

+   #ifdef CONFIG_KSU
+	ksu_handle_stat(&dfd, &filename, &flags); // TODO: KernelSU stat hook
+   #endif
 	if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
 		       AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
 		return -EINVAL;

步骤4：适配不同内核版本

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

diff --git a/fs/open.c b/fs/open.c
index 05036d819197..12345678abcd 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1234,6 +1234,10 @@ SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode)
 	return do_faccessat(dfd, filename, mode);
 }

+#ifdef CONFIG_KSU
+extern int ksu_handle_faccessat_syscall(int *dfd, const char __user **filename, int *mode);
+#endif
+
 SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode)
 {
+   #ifdef CONFIG_KSU
+	ksu_handle_faccessat_syscall(&dfd, &filename, &mode); // TODO: KernelSU faccessat syscall hook
+   #endif
 	return do_faccessat(dfd, filename, mode);
 }

4.3 验证方法

1. 编译内核并刷入设备
2. 启动设备，检查是否正常开机
3. 安装KernelSU管理器应用
4. 验证root功能是否正常工作：

   su -
   id
   

   若输出包含uid=0(root)，则表示集成成功

适用场景：kprobe无法正常工作的老旧内核设备，或需要最大兼容性保障的场景。

📌 核心要点：手动修改方案的关键在于准确找到并修改内核中的关键函数，不同内核版本可能需要调整函数名和参数。禁用kprobe选项是避免冲突的重要步骤。

5. 安全模式配置与实现

为提高系统稳定性，建议启用KernelSU的安全模式功能，当系统出现异常时可通过特定按键组合进入安全模式。

5.1 实现步骤

修改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); // TODO: KernelSU input hook for safe mode
+   #endif
 
 	if (disposition != INPUT_IGNORE_EVENT && type != EV_SYN)
 		add_input_randomness(type, code, value);

5.2 验证安全模式

1. 编译并刷入修改后的内核
2. 重启设备，在启动过程中按住音量键
3. 若设备进入安全模式（通常会有相应提示），则表示配置成功

⚠️ 注意：如果采用手动集成方式，请确保关闭CONFIG_KPROBES选项，否则可能导致设备莫名其妙进入安全模式。

适用场景：所有非GKI设备，特别是对系统稳定性要求较高的场景。

📌 核心要点：安全模式功能为系统提供了故障恢复机制，通过监控输入事件实现，是提升系统可靠性的重要保障。

6. 常见问题解决与排错流程

6.1 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); // TODO: KernelSU devpts handling for pm command
+       #endif
         if (dentry->d_sb->s_magic != DEVPTS_SUPER_MAGIC)
                 return NULL;
         return dentry->d_fsdata;

6.2 移植path_umount功能（5.9之前内核）

对于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.

6.3 排错流程图

设备无法启动
  |
  v
+----------------+    是    +----------------+    是    +----------------+
| 尝试注释ksu_*函数 |----->| 能启动         |----->| kprobe问题     |
+----------------+         |                |         | 切换手动方案   |
        |                  +----------------+         +----------------+
        | 否
        v
+----------------+    是    +----------------+
| 检查编译日志   |----->| 有错误信息      |-----> 修复编译错误
+----------------+         |                |
        |                  +----------------+
        | 否
        v
+----------------+    是    +----------------+
| 内核配置正确?  |----->| 重新配置内核    |-----> 启用必要选项
+----------------+         |                |
        |                  +----------------+
        | 否
        v
+----------------+
| 硬件兼容性问题 |-----> 参考设备兼容性矩阵
+----------------+

适用场景：集成过程中遇到设备无法启动、功能异常等问题时的系统排查。

📌 核心要点：排错过程应遵循先软件后硬件、先简单后复杂的原则，通过注释关键代码、检查编译日志和内核配置等步骤逐步定位问题。

7. 进阶优化：性能与安全性增强

7.1 功能裁剪

根据设备硬件性能，可以对KernelSU功能进行适当裁剪：

diff --git a/kernel/Kconfig b/kernel/Kconfig
index abcdef123..4567890ab 100644
--- a/kernel/Kconfig
+++ b/kernel/Kconfig
@@ -123,10 +123,10 @@ config KSU
 	bool "KernelSU support"
 	default n
 	select KSU_CORE
-	select KSU_MODULE
-	select KSU_PROFILE
+	# select KSU_MODULE  # 禁用模块支持以节省内存
+	# select KSU_PROFILE  # 禁用配置文件功能以提高性能
 	select KSU_SECURITY
-	select KSU_DEBUG
+	# select KSU_DEBUG  # 禁用调试功能以提高性能
 	help
 	  KernelSU is a kernel-based root solution for Android.

7.2 安全加固

为增强安全性，可以添加额外的权限检查：

diff --git a/kernel/ksu.c b/kernel/ksu.c
index 123456789..abcdef123 100644
--- a/kernel/ksu.c
+++ b/kernel/ksu.c
@@ -456,6 +456,12 @@ int ksu_handle_su_request(struct ksu_su_request *req)
 	if (!req)
 		return -EINVAL;

+	// TODO: 额外的安全检查
+	if (req->uid == AID_ROOT && !is_allowed_root_access()) {
+		ksu_log("Root access denied for uid %d", req->uid);
+		return -EPERM;
+	}
+
 	// 检查是否在允许列表中
 	if (is_in_allowlist(req->uid)) {
 		return ksu_allow_su_request(req);

适用场景：对性能要求较高的低端设备，或对安全性有特殊需求的场景。

📌 核心要点：进阶优化应根据实际设备情况和需求进行，功能裁剪可以提升性能，而安全加固则能增强系统安全性，需在两者间找到平衡。

通过本文介绍的创新方案，开发者可以突破GKI限制，在非GKI设备上成功集成KernelSU。无论是选择kprobe自动集成还是手动修改集成，都需要根据设备内核版本和特性做出合适选择，并遵循本文提供的最佳实践。希望本文能够帮助开发者顺利实现KernelSU在非GKI设备上的集成，为老旧设备带来新的生命力。