Skip to content

Commit

Permalink
Suggest non-gki kernel users to backport path_umount (#1464)
Browse files Browse the repository at this point in the history
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

#955 (comment)

OnlyTomInSecond/android_kernel_xiaomi_sdm845@03d233d
#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
#1464 (comment)


Kernel side change examples
5.4
natsumerinchan/kernel_oneplus_sm8350@961d978
4.19
backslashxx/android_karnol_ximi_fog@164917f
4.14
crdroidandroid/android_kernel_xiaomi_sm6150@c07c70a
4.9
backslashxx/msm8953-kernel@195f075
4.4
https://github.com/riarumoda/android_kernel_samsung_a9y18qlte/commit/21ea33fe41ce079ec1d663c0bd2201bc00a8084a
#1464 (comment)
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 <[email protected]>
Co-authored-by: Fede2782 <[email protected]>
Co-authored-by: Tom <[email protected]>
  • Loading branch information
4 people authored Mar 18, 2024
1 parent 6016937 commit b4cfc2f
Show file tree
Hide file tree
Showing 3 changed files with 62 additions and 1 deletion.
7 changes: 7 additions & 0 deletions kernel/Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion kernel/core_hook.c
Original file line number Diff line number Diff line change
Expand Up @@ -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);
Expand Down
54 changes: 54 additions & 0 deletions website/docs/guide/how-to-integrate-for-non-gki.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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?
Expand Down

0 comments on commit b4cfc2f

Please sign in to comment.