kernel: expose umount list to ioctl interface

[backslashxx]

This idea is borrowed from simonpunk's susfs4ksu.
What we see here is that, yeah well, lets just have userspace send us what it
wants unmounted, this is better than hardcoding everything.

This also solves that issue where MNT_DETACH fails, as long as we send
unmountables in proper order.

A small anti-duplicate mechanism is also added.

While in-kernel umount is a bit worse than zygisk-provider-based ones, this can still
serve as a healthy alternative.

[backslashxx]

one command for each? or add another struct member?
a u8 to denote add/delete/wipe everything?

in response to ee42d6f#comments

[tiann]

I prefer to add another member in struct

[tiann]

Maybe we can pass the flags to umount too.

[backslashxx]

how about something like this?

https://godbolt.org/z/xPe6WKscM

come to think of it, we can use smaller width for mount flags and then just cast it.
do I go u8?

[tiann]

First, use ksud kernel notify-module-mounted to inform the kernel to begin handling the unmount process. Then, call ksud kernel umount add/del/wipe.

[aviraxp]

Haven't check the code, does kernel do umount in reversed order of mount is informed?

[backslashxx]

First, use ksud kernel notify-module-mounted to inform the kernel to begin handling the unmount process. Then, call ksud kernel umount add/del/wipe.

reference for others: backslashxx/mountify@483ddc6

Haven't check the code, does kernel do umount in reversed order of mount is informed?

order is kept, last in is first to unmount.

I also recommend a way for users maybe to control iso service umount, maybe thats for you @aviraxp

[aviraxp]

As kernel uses path_umount, it only takes path as argument. Take following scernio into consideration:

1. system overlays something on product/app/someapk
2. meta module mounts something on /product/app/someapk again
3. When app starts, Zygisk umounts 2
4. As kernel only knows path, it umounts 1

This way system is broken.

I have thought of managing mounts and force disable kernel umount if zygisk is enabled, but that may not fit everyone's need.

Ideal way is to use fs type and source to identify mounts.

[backslashxx]

As kernel uses path_umount, it only takes path as argument. Take following scernio into consideration:

1. system overlays something on product/app/someapk
2. meta module mounts something on path A (eg /product/app/someapk) again
3. When app starts, Zygisk umounts 2
4. As kernel only knows path, it umounts 1

This way system is broken.

I have thought of managing mounts and force disable kernel umount if zygisk is enabled, but that may not fit everyone's need.

disable kernel umount and flag that you provide the feature via managedFeature.
as described on PR, this is a second choice.

without this yeah double umount can happen, but this decision is left to metamodule and zygisk providers
something like this
PerformanC/ReZygisk#254

otherwise we can include another flag and restore check_mnt for overlayfs but its just more stuff to track.
this one by default just unmounts mount point as is.

the list by default is also empty. this becomes a userspace problem if somebody really added something on the list.

proper priorities are also kept

KernelSU/kernel/kernel_umount.c

Lines 103 to 111 in 88fe949

	// this hook is used for umounting overlayfs for some uid, if there isn't any module mounted, just ignore it!
	if (!ksu_module_mounted) {
	return 0;
	}
	if (!ksu_kernel_umount_enabled) {
	return 0;
	}

[aviraxp]

What if user want to use kernel umount and not zygisk's umount? I think managedFeatures should be dynamic.

[backslashxx]

yeah, I guess this is an issue.
atleast we need something there on settings to tell which module is managing it.

so for example on ZN
if user uses DE/UM, it has to be flagged there that ZN is managing umount and disables it.
and once user disables DE/UM, it has to enable back kernel umount

the real reason on why I removed that check_mnt there is to free it up of overlayfs, so other mountypes/filesystems can also be unmounted (magic mount metamodule, customized overlayfs etc etc)

so yeah 🤔

[tiann]

the real reason on why I removed that check_mnt there is to free it up of overlayfs, so other mountypes/filesystems can also be unmounted (magic mount metamodule, customized overlayfs etc etc)

What if the umount command specifies the source and type, and requests the kernel to unmount the corresponding mount point?

[backslashxx]

we can strcmp path->mnt->mnt_sb->s_type and path->mnt->mnt_devname

so two more char * ?

if user sends 0 on both we don't check, keeping old behavior

but if user sends overlayfs and KSU, it will have to be strcmp'd.

migth be easier to just use devname.

--
actually, we can just add another mode so we leave the struct untouched.
mode 4 for 'KSU' devname

if arg3 == 4 on try_umount, check for devname

this might be easier

#define KSU_UMOUNT_WIPE 0  // ignore everything and wipe list
#define KSU_UMOUNT_ADD 1   // add entry (path + flags)
#define KSU_UMOUNT_DEL 2   // delete entry, strcmp
#define KSU_UMOUNT_ADD_CHECKED 3   // add entry (path + flags), and checked for KSU devname

then

static void try_umount(const char *mnt, int flags, int mode)
{
    struct path path;
    int err = kern_path(mnt, 0, &path);
    if (err) {
        return;
    }

    if (path.dentry != path.mnt->mnt_root) {
        // it is not root mountpoint, maybe umounted by others already.
        path_put(&path);
        return;
    }

    if (mode == 3 && !!strcmp(path.mnt->mnt_devname, "KSU") {
         path_put(&path);
         return;
    } 

    ksu_umount_mnt(&path, flags);
}

a bit hacky but atleast we avoid re-struct

[backslashxx]

@tiann @aviraxp

EDIT: cleaned up a little
backslashxx@b338f19

but I'm not sure if this is usable on LKM

but when adding as "mode 3" it will check for KSU devname first

I'm also not sure on real_mount

[aviraxp]

This will likely break build for ddk

[backslashxx]

it does build, but you have to confirm if it works
theres no way we can just traverse struct vfsmount, layout is randomized

[aviraxp]

Actually that should be fine. Gki devices doesn't really enable randomized layout.

[backslashxx]

Actually that should be fine. Gki devices doesn't really enable randomized layout.

so for bind mounts, a metamodule has to use cmd.mode 1.
for overlay/tmpfs mounts, it has to use mode 3 and with devname KSU.

on magic mount folders where you create new files for should be devname'd KSU and added via mode 3

[backslashxx]

@aviraxp so is everything working ok?
you can test with this
https://godbolt.org/z/xPe6WKscM