Magisk memodifikasi file system melalui ratusan userspace bind mount individual via magiskd, memicu overhead dentry cache dan kebocoran jejak pada /proc/self/mountinfo. Sebaliknya, KernelSU memadukan subsystem OverlayFS langsung di kernel-space, mereduksi latensi syscall openat() secara signifikan, serta mencegah deteksi root berbasis mount namespace berkat isolasi proses Zygote yang bersih.
Dua Pendekatan VFS: Userspace Bind Mount vs In-Kernel OverlayFS
Perbedaan mendasar antara Magisk dan KernelSU bertumpu pada layer tempat abstraksi Virtual File System (VFS) dimanipulasi: userspace bind mount versus in-kernel OverlayFS. Magisk membanjiri VFS dengan ratusan syscall bind mount individual melalui daemon userspace magiskd, sedangkan KernelSU memindahkan seluruh orkestrasi penyajian modifikasi partisi langsung ke subsystem OverlayFS di dalam kernel-space. Keputusan arsitektur ini secara langsung menentukan seberapa besar overhead dentry cache yang membebani kernel dan seberapa tebal jejak forensik yang terekspos pada /proc/self/mountinfo.
Kenyataan di lapangannya begini: saat kamu mengaktifkan beberapa modul Magisk yang memodifikasi puluhan binary, font sistem, atau XML konfigurasi di partisi /system, magiskd tidak menyentuh blok partisi riil. Daemon ini membangun skeleton directory bayangan di /debug_ramdisk atau tmpfs, lalu mengeksekusi syscall mount(..., MS_BIND) secara granular per file atau per direktori. Dampaknya instan pada struktur internal VFS. Setiap kali sebuah proses melakukan path traversal, kernel dipaksa memecahkan rantai mount point yang bertumpuk-tumpuk, memicu penalti cache miss pada dentry lookup dan memanjangkan waktu eksekusi syscall I/O dasar seperti stat() atau openat().
Masalahnya kian runyam saat kita membedah fase Zygote fork process. Demi mengelabui sistem deteksi, Magisk mengandalkan hook Zygisk untuk mencegat pemanggilan forkAndSpecialize, lalu terburu-buru melepaskan mount namespace yang terinfeksi sebelum sandbox App Zygote mengunci hak aksesnya. Di sinilah letak friksi empirisnya. Jika terjadi delay timing atau race condition mikroskopis saat eksekusi unmount namespace tersebut, mount leaking tak terhindarkan. Proses aplikasi yang masuk ke dalam isolated sandbox masih sempat mewarisi snapshot mount table yang bocor, sehingga aplikasi perbankan cukup membaca string pada /proc/self/mountinfo untuk menemukan bukti otentik adanya bind mount milik Magisk.
KernelSU memutus rantai masalah userspace tersebut dengan memanfaatkan modul native OverlayFS yang hidup berdampingan dengan VFS core. Ketimbang membombardir kernel dengan ratusan bind mount granular, KernelSU memperlakukan partisi sistem asli sebagai lowerdir (read-only) dan memetakan direktori modul ke dalam satu upperdir terpadu. Seluruh resolusi tumpang tindih file ditangani langsung oleh logika internal driver OverlayFS (seperti pemanggilan ovl_lookup dan manipulasi dentry internal kernel). Bagi userspace, pohon direktori gabungan ini tampak sebagai satu kesatuan yang homogen tanpa ada pembengkakan mount table.
Hasilnya bersih. VFS traversal berjalan mulus karena kernel mengelola struktur inode secara terpusat tanpa melompati daftar mount point yang terfragmentasi. Keuntungan paling krusial dari pendekatan kernel-space ini terlihat pada kontrol visibilitas: KernelSU dapat menentukan namespace mana yang berhak melihat layer modifikasi secara atomik sebelum instruksi userspace pertama milik Zygote fork dieksekusi, meniadakan celah mount leak yang selama ini menjadi momok pada ekosistem Magisk.
- Magisk mengandalkan userspace bind mount granular yang membebani dentry cache dan meninggalkan jejak masif pada mountinfo, sedangkan KernelSU menyatukan modifikasi filesystem via unified upperdir OverlayFS langsung di VFS layer.
- Race condition unmount namespace pada Zygote fork process di Magisk kerap memicu mount leaking ke isolated sandbox App Zygote, celah yang secara inheren dieliminasi oleh isolasi kernel KernelSU.
- Performa openat() syscall pada KernelSU jauh lebih efisien untuk modifikasi file sistem skala besar, tetapi adopsi pada perangkat non-GKI menuntut patching manual yang rentan memicu kernel panic.
Adu Performa VFS: Dentry Lookup, Inode, dan Latensi openat()
KernelSU memangkas latensi syscall openat() dan beban dentry lookup secara drastis dibanding Magisk begitu sistem memuat puluhan hingga ratusan file modul. Di atas kertas maupun pengujian kernel tracing, Magisk menjejali kernel dengan tumpukan struct vfsmount individual yang mencekik VFS path lookup, sedangkan KernelSU menggabungkan seluruh injeksi file ke dalam satu layer unified OverlayFS in-kernel.
Mari bedah mekanismenya di level Virtual File System. Magisk Magic Mount bekerja dengan mengkloning pohon direktori dan mengeksekusi bind mount individual per file atau direktori target. Saat kamu memasang modul font besar, patch audio system-wide, atau debloater yang menyentuh ribuan file, tabel mount kernel membengkak seketika. Setiap kali aplikasi memanggil openat(), kernel mengeksekusi path walk via path_lookupat(), memeriksa mount_lock seqlock, dan melintasi batas vfsmount berulang kali. Dentry cache (dcache) terfragmentasi parah karena kernel dipaksa mengalokasikan struct dentry terpisah untuk setiap titik bind mount tiruan, lengkap dengan duplikasi struct inode pada slab allocator (khususnya dentry_cache dan f2fs_inode_cache atau ext4_inode_cache).
Kenyataan di lapangannya jauh lebih runyam saat proses Zygote mem-fork aplikasi baru. Magisk mengandalkan Zygisk untuk membersihkan titik-titik mount ini pada child process aplikasi target melalui unmount namespace di userspace. Di sinilah friksi fatal kerap terjadi: jika hook Zygisk terlambat beberapa mikrodetik saja mengeksekusi unmount sebelum seccomp filter terpasang atau App Zygote terisolasi sempurna, terjadi mount leaking. Proses sandbox aplikasi mewarisi salinan tabel mount yang kotor, memberi karpet merah bagi mekanisme deteksi anti-root untuk membaca kejanggalan via /proc/self/mountinfo. Beban traversing pada tree mount yang kusut ini juga langsung mendongkrak latensi cold launch aplikasi secara nyata.
KernelSU memotong seluruh inefisiensi tersebut langsung dari kernel driver. Alih-alih membuat ratusan rantai bind mount granular, KernelSU menyatukan modul ke dalam topologi OverlayFS: partisi fisik read-only (seperti /system berbasis EROFS atau EXT4) diposisikan murni sebagai lowerdir, sementara file modul ditempatkan di upperdir. VFS hanya melihat satu struct vfsmount tunggal. Resolusi dentry ditangani langsung oleh ovl_lookup(), di mana kernel menyatukan representasi dentry upper dan lower layer ke dalam memori tanpa perlu menduplikasi alokasi inode untuk file yang tidak tersentuh modifikasi. Jalur resolusi path tetap bersih, mengonsumsi siklus CPU yang konstan setara partisi native.
Friksi teknis beralih ke sisi kompatibilitas saat kita menguji skenario ini di luar kernel modern GKI (Generic Kernel Image). Pada custom ROM berbasis kernel legacy, mengimplementasikan OverlayFS untuk memanipulasi partisi Android sering membentur limitasi xattr dan SELinux context, terutama jika filesystem dasar vendor belum mendukung fitur overlayfs metacopy atau redirect_dir secara stabil. Pengujian di partisi EROFS bawaan perangkat Pixel menunjukkan latensi openat() tetap stabil di angka sub-mikrodetik pada KernelSU, berbanding terbalik dengan variansi latensi Magisk yang melonjak tajam saat puluhan proses meminta path resolution bersamaan. Perbedaan struktural penanganan VFS dan konsumsi memori kedua mekanisme ini terangkum jelas pada matriks teknis berikut.
| Parameter Teknis | Magisk (Magic Mount) | KernelSU (OverlayFS) |
|---|---|---|
| Mekanisme Mount VFS | Multiple bind mount individual per file/folder di user-space yang mengaitkan berkas modul ke target di /system | Penyatuan direktori tunggal berbasis Kernel OverlayFS (lowerdir/upperdir) langsung pada subsistem VFS kernel [7] |
| Overhead VFS & Lookup Dentry | Tinggi; overhead traversal meningkat secara linear O(N) terhadap jumlah mount point dan alokasi dentry baru | Rendah; traversal teroptimasi O(1) di level kernel via composite dentry tanpa redundansi tabel mount point |
| Deteksi /proc/self/mountinfo | Terekspos langsung pada mount table user-space; memerlukan isolasi namespace (unshare) manual via Zygisk | Transparan dan seragam; daftar mount point di user-space tidak menampilkan pecahan modifikasi bind mount per berkas |
| Domain Eksekusi & Privilege | Daemon user-space (magiskd) dengan domain SELinux permisif/khusus (u:r:magisk:s0) rentan inspeksi procfs | Kernel-space (Ring 0) berbasis Generic Kernel Image (GKI) hook tanpa daemon persisten di user-space [7] |
Jejak di /proc/self/mountinfo dan Celah Zygote Mount Leaking
Aplikasi perbankan modern mendeteksi modifikasi sistem bukan lagi lewat pencarian berkas biner su di direktori executable, melainkan membedah struktur entri mount point di /proc/self/mountinfo guna melacak anomali filesystem yang bocor dari namespace Zygote. Mekanisme deteksi ini mengevaluasi mount ID, parent ID, major:minor device number, serta root path setiap node VFS secara langsung lewat syscall openat native tanpa melewati wrapper libc, sehingga upaya hooking di tingkat userspace sering kali terlewati begitu saja. Begitu modul deteksi menemukan kejanggalan berupa target mount point partisi read-only yang menunjuk ke backing device tmpfs atau node loopback virtual yang tidak terdaftar di fstab bawaan OEM, pertahanan aplikasi langsung memicu pembatalan eksekusi.
Kenyataan di lapangannya begini: Zygote merupakan proses induk yang mewarisi namespace mount tunggal (CLONE_NEWNS) ke setiap child process aplikasi yang di-fork darinya. Solusi berbasis userspace seperti Magisk dan Zygisk mengandalkan hook pada daur hidup proses Zygote untuk menyuntikkan rutinitas unmount selektif, dengan harapan mount point modul sudah terlepas sesaat sebelum sandbox aplikasi ditutup. Masalahnya muncul ketika Android menangani App Zygote atau isolated process, subsistem khusus yang dirancang untuk menjalankan dependensi terisolasi seperti perender webview atau modul proteksi perbankan dengan privilege seminimal mungkin. Ada jeda fraksi milidetik yang krusial antara panggilan fork() dan penerapan kebijakan SELinux domain isolated_app. Ketika hook pembersih namespace terlambat dieksekusi beberapa instruksi saja, proses anak sudah kehilangan kapabilitas CAP_SYS_ADMIN dan hak akses DAC yang dibutuhkan untuk mengeksekusi syscall umount2(), menyebabkan operasi tersebut gagal total dengan galat EPERM (Operation not permitted).
Kegagalan pelepasan ini memicu fenomena mount leaking: struktur mount point modul yang seharusnya disembunyikan justru tertinggal permanen di namespace isolated process. Kondisi ini menjadi mimpi buruk bagi integritas sistem karena sekali sandbox isolated_app aktif dengan aturan seccomp ketat, tidak ada proses userspace non-root lain yang bisa masuk ke namespace tersebut untuk membersihkan sisa dentry yang tertinggal. Kita kerap menemukan skenario di mana proses utama aplikasi perbankan tampak bersih dari jejak modifikasi, namun sub-proses isolated miliknya justru mendeteksi tumpukan mount point modul di /proc/self/mountinfo pada cold-start pertama. Fenomena race condition semacam ini membuktikan kerapuhan manajemen namespace yang dikontrol murni dari userspace Zygote, terutama saat berhadapan dengan diversifikasi lifecycle proses di versi Android terkini.
Tantangan Kompatibilitas: Kernel Non-GKI hingga Modifikasi SELinux
Keunggulan arsitektur stealth KernelSU harus ditebus dengan ongkos engineering yang tinggi, terutama saat kita berhadapan dengan ekosistem kernel non-GKI (Generic Kernel Image) dan komplikasi penegakan SELinux. Magisk memang membawa beban VFS, namun kematangan userspace plumbing miliknya tetap menjadi standar keandalan lintas perangkat yang sulit digeser begitu saja.
Kenyataan di lapangannya begini: mengintegrasikan KernelSU ke kernel legacy (seperti Linux 4.14 atau 4.19) bukan sekadar menyisipkan kprobe atau menambal static hook ke source tree. Driver OverlayFS pada kernel lawas belum memiliki kesiapan fitur yang matang seperti upstream modern, terutama dalam penanganan multi-layer lowerdir dan locking primitive pada VFS inode. Ketika kamu memaksakan backport kode OverlayFS ke kernel kustom vendor yang sarat modifikasi driver penyimpanan out-of-tree, sistem sangat rentan mengalami race condition pada pemanggilan vfs_read() atau fungsi ovl_copy_up(). Hasil akhirnya fatal: NULL pointer dereference saat proses boot, dentry cache corruption, dan perangkat langsung terjerumus ke siklus kernel panic tanpa sempat melempar jejak crash ke userspace logcat.
Masalahnya semakin runyam saat kita menyentuh layer Linux Security Modules (LSM). Magisk menyelesaikan restriksi akses melalui biner magiskpolicy yang memodifikasi sepolicy di memory secara transparan, menyuntikkan allow rules ke target context secara presisi. KernelSU mengambil jalan pintas dengan melompati pemeriksaan kredensial proses langsung di kernel hook, namun pendekatan ini menuntut penyesuaian label konteks SELinux (seclabel) pada upperdir OverlayFS. Dari catatan pengujian lapangan, inkonsistensi label SELinux antara filesystem fisik (seperti f2fs atau ext4 bawaan vendor) dan layer virtual OverlayFS sering memicu kegagalan eksekusi senyap. Daemon sistem menolak membaca berkas biner termodifikasi karena audit subsystem mendeteksi anomali security context dan memuntahkan avc: denied, sekalipun proses pemanggil sudah memegang root UID 0.
Arah evolusi platform Android mempertegas garis batas teknis di antara kedua paradigma ini. Bagi kamu yang memelihara perangkat legacy non-GKI atau bergantung pada ekosistem modul lawas yang kompleks, arsitektur userspace bind-mount Magisk masih menjadi opsi paling rasional dan terprediksi. Namun, standardisasi GKI sejak kernel 5.10 telah memangkas friksi kompilasi KernelSU secara masif. Menggeser manipulasi filesystem dari userspace langsung ke internal VFS adalah lompatan tak terelakkan dalam menghadapi deteksi namespace modern: sebuah pergeseran dari sekadar menyembunyikan jejak di level pengguna menjadi rekonstruksi state langsung di jantung sistem operasi.
Pertanyaan yang Sering Diajukan
Mengapa granular bind mount Magisk menghasilkan VFS overhead yang lebih tinggi dibanding OverlayFS?
Granular bind mount Magisk menghasilkan VFS overhead lebih tinggi karena menciptakan entri struct mount terpisah untuk setiap file yang dimodifikasi ke dalam tabel mount kernel [7]. Setiap node bind mount individual ini memperbesar ukuran tabel mount serta memperpanjang waktu resolusi path dan lookup dentry pada Virtual File System. Sebaliknya, KernelSU memanfaatkan OverlayFS yang menggabungkan seluruh hierarki berkas ke dalam satu titik mount tunggal secara efisien.
Bagaimana mekanisme Zygote mount leaking terjadi dan mengapa hal itu memicu deteksi root?
Kebocoran mount Zygote terjadi saat proses aplikasi mewarisi tabel mount induk Zygote melalui syscall fork sebelum isolasi namespace mount selesai diterapkan secara menyeluruh [7]. Keadaan ini menyebabkan deskriptor mount serta path berkas Magisk tetap terlihat di dalam /proc/self/mountinfo milik aplikasi target. Mekanisme deteksi keamanan aplikasi perbankan memindai berkas mountinfo tersebut untuk mengenali modifikasi sistem dan mengidentifikasi keberadaan akses root.
Apa kendala terbesar saat mengimplementasikan KernelSU pada kernel Android non-GKI?
Kendala terbesar implementasi KernelSU pada kernel non-GKI adalah keharusan melakukan patching manual dan kompilasi ulang kode sumber kernel karena ketiadaan standardisasi antarmuka Generic Kernel Image [7]. Kernel non-GKI lawas kerap kehilangan dependensi penting seperti driver OverlayFS yang kompatibel, kprobes, maupun hook syscall execve. Modifikasi proprietary dari masing-masing vendor perangkat juga sering menimbulkan konflik simbol serta memicu kernel panic.
Pemberitahuan Risiko & Keamanan Teknis: Tindakan membuka kunci bootloader, melakukan flashing ROM/recovery, atau memodifikasi partisi sistem membawa risiko kerusakan perangkat (bootloop), kehilangan data, dan pembatalan garansi resmi. Pastikan Anda telah mencadangkan data penting secara menyeluruh dan memahami langkah mitigasi sebelum eksekusi.