From b4cfc2f2980b5904d045b04931c67aa7d11a8c80 Mon Sep 17 00:00:00 2001 From: backslashxx <118538522+backslashxx@users.noreply.github.com> Date: Mon, 18 Mar 2024 10:27:31 +0800 Subject: [PATCH] Suggest non-gki kernel users to backport path_umount (#1464) Most kernel builders have to touch their kernel source code anyway, why not also tell them to backport path_umount so even non-gki users can benefit from this? I know this might be a bit controversial as this will raise the barrier of entry, but the benefits are just so high. Idea was from OnlyTomInSecond on KernelSU group chat way back, and it has been on the discussions for some time references: https://t.me/KernelSU_group/27237/176515 https://t.me/KernelSU_group/3249/184908 https://github.com/tiann/KernelSU/discussions/955#discussioncomment-7617166 https://github.com/OnlyTomInSecond/android_kernel_xiaomi_sdm845/commit/03d233db8bbe9fe101509430bfa09d1899168aa7 https://github.com/tiann/KernelSU/pull/1060 https://elixir.bootlin.com/linux/v5.9.1/source/fs/namespace.c#L1728 https://elixir.bootlin.com/linux/v5.10.9/source/fs/namespace.c#L1730 https://elixir.bootlin.com/linux/v6.5/source/fs/namespace.c#L1887 https://github.com/tiann/KernelSU/pull/1464#issuecomment-2002492107 Kernel side change examples 5.4 https://github.com/natsumerinchan/kernel_oneplus_sm8350/commit/961d9788624e88c3c58918b3781b9fbdd19ecbeb 4.19 https://github.com/backslashxx/android_karnol_ximi_fog/commit/164917f56d0e75ab51bb9f1bdf489acac7a6d3db 4.14 https://github.com/crdroidandroid/android_kernel_xiaomi_sm6150/commit/c07c70a0c59fb46ac0c1c812c3e993022e375cd5 4.9 https://github.com/backslashxx/msm8953-los21/commit/195f07593ae9769a992f3945bcdc43ff7fc99827 4.4 https://github.com/riarumoda/android_kernel_samsung_a9y18qlte/commit/21ea33fe41ce079ec1d663c0bd2201bc00a8084a https://github.com/tiann/KernelSU/pull/1464#issuecomment-2002424069 ofcourse having someone on 3.18 confirm this will be nice. **PROS**: umount modules for everyone **CONS**: barrier of entry +1 --------- Co-authored-by: Christoph Hellwig Co-authored-by: Fede2782 <78815152+Fede2782@users.noreply.github.com> Co-authored-by: Tom <31297720+onlytominsecond@users.noreply.github.com> --- kernel/Makefile | 7 +++ kernel/core_hook.c | 2 +- .../guide/how-to-integrate-for-non-gki.md | 54 +++++++++++++++++++ 3 files changed, 62 insertions(+), 1 deletion(-) diff --git a/kernel/Makefile b/kernel/Makefile index f8dff4d6..fcc58a5b 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -62,6 +62,13 @@ $(info -- KernelSU Manager signature hash: $(KSU_EXPECTED_HASH)) ccflags-y += -DEXPECTED_SIZE=$(KSU_EXPECTED_SIZE) ccflags-y += -DEXPECTED_HASH=\"$(KSU_EXPECTED_HASH)\" +ifeq ($(shell grep -q "int path_umount" $(srctree)/fs/namespace.c; echo $$?),0) +ccflags-y += -DKSU_UMOUNT +else +$(info -- Did you know you can backport path_umount to fs/namespace.c from 5.9?) +$(info -- Read: https://kernelsu.org/guide/how-to-integrate-for-non-gki.html#path_umount) +endif + ccflags-y += -Wno-implicit-function-declaration -Wno-strict-prototypes -Wno-int-conversion -Wno-gcc-compat ccflags-y += -Wno-declaration-after-statement -Wno-unused-function diff --git a/kernel/core_hook.c b/kernel/core_hook.c index dfb4d3f6..06fc75cf 100644 --- a/kernel/core_hook.c +++ b/kernel/core_hook.c @@ -513,7 +513,7 @@ static bool should_umount(struct path *path) static void ksu_umount_mnt(struct path *path, int flags) { -#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 9, 0) +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 9, 0) || KSU_UMOUNT int err = path_umount(path, flags); if (err) { pr_info("umount %s failed: %d\n", path->dentry->d_iname, err); diff --git a/website/docs/guide/how-to-integrate-for-non-gki.md b/website/docs/guide/how-to-integrate-for-non-gki.md index 131bd581..00abe526 100644 --- a/website/docs/guide/how-to-integrate-for-non-gki.md +++ b/website/docs/guide/how-to-integrate-for-non-gki.md @@ -40,6 +40,11 @@ But if you encounter a boot loop when integrated KernelSU, it is maybe *kprobe i comment out `ksu_enable_sucompat()` and `ksu_enable_ksud()` in `KernelSU/kernel/ksu.c`, if the device boots normally, then kprobe may be broken. ::: +:::info How to get module umount feature working on pre-GKI? + +If your kernel is older than 5.9, you should backport ```path_umount``` to ```fs/namespace.c```. This is required to get module umount feature working. If you don't backport ```path_umount```, module umount feature won't work. You can get more info on how to achieve this at the end of this page. +::: + ## Manually modify the kernel source If kprobe does not work in your kernel (may be an upstream or kernel bug below 4.8), then you can try this way: @@ -292,6 +297,55 @@ index 45306f9ef247..815091ebfca4 100755 add_input_randomness(type, code, value); ``` +## path_umount + +You can get module umount feature working on pre-GKI kernels by manually backporting ```path_umount``` from 5.9. You can use this patch as reference: + +```diff +--- 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. +``` + Finally, build your kernel again, KernelSU should work well. :::info Entering safe mode accidiently?