KernelSU's kernel directory is GPL-2.0-only, and its x86_64 build can panic the kernel

The first warning in the README is about a kernel panic

The compatibility section ends with a CAUTION callout, and the text is blunt: recent kernel versions have implemented a breaking change causing KernelSU to fail and potentially trigger a kernel panic on `x86_64`, and readers are told to check the website for more info.

That is a different class of warning from anything else in this project. A manager app that misbehaves is an application problem. A kernel component that panics takes the device with it, and the architecture named in the warning is one of only two the project supports.

The compatibility statement around it is precise. KernelSU officially supports Android GKI 2.0 devices on kernel 5.10 and newer. Older kernels from 4.14 are also supported, but the kernel will need to be built manually. With this, WSA, ChromeOS and container-based Android are all supported. And currently the `arm64-v8a` and `x86_64` architectures are supported.

Put together, the two sentences describe an uneven support matrix: one of the two supported architectures carries a panic warning, and 32-bit ARM is not in the matrix at all.

Two of the three features are about containment

The features list has three entries, and reading them in order is instructive.

First, kernel-based `su` and root access management. Second, a module system based on metamodules, described as pluggable infrastructure for systemless modifications. Third, App Profile, described in the project's own words as lock up the root power in a cage.

So the headline capability is ordinary, the extension mechanism is metamodules rather than a modification of the system partition, and the third feature is a restriction. Two of the three are about what a root solution should not let an application do.

That is the positioning, and it is the reason a user would pick this over a general root tool. A metamodule is a unit of systemless modification, which means a module does not need a writable system image, and App Profile is a per-application grant rather than a device-wide one. The credits section names the inspiration, with the KernelSU idea credited to Kernel-Assisted Superuser and Magisk named as the powerful root tool.

The consequence for an adopter is that the interesting question is not whether it can root a device but what happens when an application that should not have root asks for it. That is the feature the project leads with in its third bullet.

The licence is split by directory, and one half is GPL-2.0-only

The license section has two bullets and the difference between them is the whole point:

Files under the `kernel` directory are GPL-2.0-only. All other parts except the `kernel` directory are GPL-3.0-or-later.

The repository metadata reports GPL-3.0, which is true of everything except one directory. So the tree is not under a single licence and a reader who checks the badge rather than the README will be wrong about the kernel part.

The distinction is not cosmetic. The or-later suffix on GPL-3.0 lets a recipient relicense the work under a later version of the licence, and the only suffix on GPL-2.0 means the kernel directory's terms cannot be relaxed that way. Code under the `kernel` directory is therefore the piece that has to be reconciled by hand if it is combined with anything, and the directory boundary is exactly where the difference is drawn.

For a device vendor or a ROM project this is the part to read first, because the boundary between the two terms is a build boundary as much as a legal one. The repository also ships a `LICENSE` file and a `SECURITY.md` at the root.

Fifteen translations, and every one of them is now machine generated

The link row at the top of the README carries fifteen languages: English, Español, 简体中文, 繁體中文, 日本語, 한국어, Polski, Português (Brasil), Türkçe, Русский, Tiếng Việt, Indonesia, עברית, हिंदी and Italiano.

The Translation section then says something that changes what those links mean. To help translate KernelSU, the project no longer accepts translation contributions via Weblate, and all translations are now handled using LLMs. If you would like to add support for a new language, feel free to open a PR. Modifications to existing English and Chinese translations are not accepted.

So the policy is a closed door with one window: new languages can be added by PR, and modifications to the existing English and Chinese translations are not accepted.

For a reader this is a concrete quality statement rather than a process detail. Someone needing Hindi or Hebrew or Italian documentation is reading generated text for a project that modifies a kernel, and the project has decided that machine output is the appropriate level of fidelity for that. There is a Weblate badge still in the header, which is a leftover from the previous arrangement.

libc is patched to a commit, not taken from a release

The workspace manifest has a patch block, and it is the only interesting thing in a very short file:

[patch.crates-io]
libc = { git = "https://github.com/rust-lang/libc", rev = "1a661633f11a261ff9c00b40875ef72f1cbec818" }

The C library bindings are redirected to a git repository at one specific commit. That is a reproducibility decision, and it has two consequences worth stating plainly.

First, `cargo update` will not move them. A patch entry pinned to a revision is outside the version resolution that a normal dependency participates in, so the commit is fixed until someone edits the manifest.

Second, a fix released in a version of `rust-lang/libc` will not arrive here on its own. If the pinned commit predates a correctness or security fix in the C bindings, the only path to it is a new revision in this file.

For a project whose userspace is a privileged daemon talking to the kernel, pinning the layer that wraps the system call interface is defensible. Doing it silently, in a two-line block under a workspace that otherwise has two dependencies, is the sort of thing a reader has to notice deliberately.

The userspace is two crates with two dependencies

The Cargo workspace is very small. The members are `userspace/ksud` and `userspace/ksuinit`, and they are also the default members, with resolver set to 3 and the package edition at 2024.

The shared dependency list is two entries: `anyhow` at 1 and `log` at 0.4. Those are the only dependencies declared at workspace level; each crate's own manifest can add more.

For a root daemon whose job is to answer requests from a manager app and act through kernel interfaces, that is a defensible shape, and it is a different shape from the Kotlin manager and the kernel module beside it. A narrow userspace is easier to audit for a component that runs with elevated privilege.

The release profile says the same thing. `strip = true`, `lto = true`, `opt-level = "z"` and `panic = "abort"`, with a per-package override giving `ksud` a single codegen unit. Sized for the smallest binary, with a panic that terminates rather than unwinding.

The build recipe covers one architecture and the README supports two

The task runner is a `justfile` rather than a Makefile, and it defines aliases and three targets. The build target for the userspace is one line:

cross build --target aarch64-linux-android --release

So cross-compilation tooling is required, and the only target named is the 64-bit ARM Android one. The README says both `arm64-v8a` and `x86_64` are supported, so producing the x86_64 artefact is not covered by the recipe in this repository.

The manager target depends on that build and then does two things. It copies the result into the Android app's native library directory:

cp target/aarch64-linux-android/release/ksud manager/app/src/main/jniLibs/arm64-v8a/libksud.so

and then changes into `manager` and runs `./gradlew aDebug`.

So the daemon ships inside the manager as a JNI library, and the manager is an ordinary Gradle Android project. That is the delivery mechanism, and it connects to the two other root-level files, `repack_apk.py` and `repack-config.example.json`. The `clippy` target runs `cargo fmt` before `cross clippy`, so linting reformats as it checks.

The credits name a rootkit, and the delivery is a repacked APK

The credits section is four lines, each naming a source and what it contributed. Kernel-Assisted Superuser gets the credit for the KernelSU idea. Magisk is named as the powerful root tool. `genuine` is credited for APK v2 signature validation. And Diamorphine, a rootkit project, is credited with some rootkit skills.

That last one is the interesting line. A project whose history includes learning from a rootkit, alongside a credit for APK signature validation, describes a lineage that includes both offensive and defensive work, and it does so in four lines without elaboration.

The tree also has `repack_apk.py` and a `repack-config.example.json` at the root, a `fastlane/` directory for release automation, a `js/` directory, a `website/` directory and a `docs/` directory. The README does not say what the repack script is for.

The other top level entries fit the same shape: `kernel/`, `userspace/`, `manager/` and `uapi/` for the four components, `scripts/`, a `Cargo.lock` with a `.cargo/` directory beside it, and an `AGENTS.md`.

Editorial conclusion

KernelSU fits a user on an arm64 device running a GKI 2.0 kernel who wants root scoped per app rather than granted to everything, and who is comfortable building a kernel for an older device. It does not fit an x86_64 deployment on a recent kernel, which the README itself warns can fail and potentially panic the kernel, nor a project that needs a permissive or single-version licence, because the tree is split across GPL-2.0-only and GPL-3.0-or-later. Before adopting, check three things: whether your device is arm64-v8a or x86_64, since those are the only two supported and the build recipe in this repository only covers the first, whether your kernel is 5.10 or newer, since below that the kernel has to be built manually, and the `libc` patch, which pins the C bindings to one commit of `rust-lang/libc` rather than a released version.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes