Possibility of shipping KernelSU just as a kernel module

[arter97]

Hi.

Currently, it seems that KernelSU ships a GKI kernel image that integrates KernelSU, which means for people wanting to use it, they must use the GKI kernel.

Some OEMs are still not shipping Google's GKI kernel, which may lead to some compatibility or optimization issues when using Google's GKI for KernelSU.

Is there a technical reason why KernelSU wouldn't work as a separate kernel module?
KMI would allow the module to load under a customized GKI kernel like Samsung's.
Patching vendor_boot or vendor_dlkm would make it possible to inject the KernelSU module during early boot.

I'm about 99% certain that authors/contributers have tried this approach at some time, but I failed to find the relevant discussions on it.

Thanks,

[tiann]

It is theoretically possible, but in practice there will be some problems.

In fact, my first attempt to make it a kernel module also failed miserably. The main reason is that calling some kernel functions in the kernel module will be restricted, such as:

1. Some kernel functions have no export and cannot be called directly. Although the symbol address can be directly called through kallsyms_lookup_name or register_kprobe, but kallsyms_lookup_name has no export above 5.7, and the symbol register_kprobe will be clipped by GKI on some OEMs; it cannot be used directly. It is theoretically feasible to directly parse the kernel image to obtain the kallsyms_lookup_name symbol address, and then further obtain other addresses, but the following problems will still be encountered.
2. The GKI kernel has enabled KCFI. When using pointers to call certain symbols, it will be blocked by cfi and cause the kernel to crash; there are other ways to bypass it, but there is uncertainty in the future.
3. In addition, there are some symbols that cannot be called or are very troublesome to call, such as the operation of the selinux structure.

The above will cause the code to be very troublesome and painful to write, because it may take a lot of detours to call a function, which is far less convenient than directly integrating the kernel source code; however, running KernelSU in the kernel module does have many advantages, maybe we can further try.

In addition, in addition to the way in the kernel module, I have also tried the way of directly patching the kernel image. The principle is similar to this project: https://github.com/Battelle/patchwerk, but it needs to do a lot of hacks, which may not be stable enough; recently There is a similar project: https://github.com/bmax121/AndroidKernelPatch It uses another way to patch, taking over the startup phase of the kernel, just like Magisk took over the init procedure, but it is inevitable to use a lot of hack techniques .

All in all, the current implementation of KernelSU is an engineering compromise; I also hope there is a better way to implement it, and everyone is welcome to discuss it.

[tiann]

Currently, it seems that KernelSU ships a GKI kernel image that integrates KernelSU, which means for people wanting to use it, they must use the GKI kernel.

If you have the kernel source code, you can integrate the KernelSU source code into the kernel, and then compile the kernel yourself; this way, you don't need to use the pre-compiled image.

In fact, many non-GKI devices use this method to integrate KernelSU, and they work well.

[arter97]

Ah, didn't know that KernelSU heavily depends on unexported symbols. The Kconfig mentioning tristate have me guessing the other way.

Yeah, that'll be extremely tricky indeed. I guess we won't have a shot at having Google export those for a rooting solution lol

Do you have a list of important symbols that are unexported? I was guessing that kprobes would have solved a lot of problems but I guess not :(

[tiann]

Do you have a list of important symbols that are unexported? I was guessing that kprobes would have solved a lot of problems but I guess not :(

I don't have this list, but try to compile it as a module and see how many errors there are, we will probably know. (The current code is much more complicated and changed a lot than when I tried it at that time. There should not be more than 10 symbols when I tried that time)

[daiaji]

kmod确实感觉更优雅啊

[arter97]

Is there a documentation on how this new approach work?

I'm particularly curious on how it's hooking up to internal functions protected by CFI (if I'm not mistaken).

[tiann]

Is there a documentation on how this new approach work?

I'm particularly curious on how it's hooking up to internal functions protected by CFI (if I'm not mistaken).

Sorry, there is currently no documentation available. CFI protects against indirect calls, and we will try to avoid them as much as possible. In unavoidable situations, we will choose to directly modify the function pointer itself, such as: https://github.com/tiann/KernelSU/blob/main/kernel/ksud.c#L380