Rust Masuk Kernel Linux: Revolusi Nyata atau Cuma Euforia RIIR?

Kalau kamu pernah iseng buka isi folder kernel Linux, kamu tahu di sana isinya cuma dua bahasa: C dan Assembly. Susunannya begitu terus selama lebih dari tiga dekade. Linus Torvalds sendiri terkenal sangat protektif soal basis kodenya, dan itu bukan cuma soal selera.

Waktu ada yang mengusulkan adopsi C++ di mailing list kernel, jawabannya keras dan dikutip orang sampai sekarang. Alasannya klasik: kompleksitas desain, overhead kompilasi, dan manajemen memori C++ yang dia anggap nggak bisa diprediksi di kernel space. Poin favoritnya waktu itu, bahasa apa pun yang suka menyembunyikan alokasi memori di belakang punggung pembacanya emang bukan pilihan bagus buat kernel.

Terus, di akhir 2022, ada hal yang tiga dekade sebelumnya kedengaran mustahil nih. Lewat inisiatif Rust for Linux, bahasa Rust resmi masuk ke pohon kode utama Linux 6.1. Bukan patch iseng yang nyangkut di mailing list, tapi infrastruktur yang benar-benar di-merge — sekitar 12.500 baris cuma buat kerangkanya, belum ada satu driver pun. 🎉

Sejak itu diskusinya ramai terus. Ini revolusi nyata di arsitektur sistem operasi masa depan, atau cuma kebawa euforia meme "Rewrite It In Rust" (RIIR) sih? Yuk bedah dari sisi teknis, mitigasi celah keamanannya, sampai realita adopsinya di industri. 🙂

Kenapa Rust baru diterima sekarang?

Klarifikasi dulu biar nggak salah paham: Linux nggak sedang ditulis ulang total ke Rust. Kernel Linux sekarang ada di sekitar 40 juta baris kode. Menurut Greg Kroah-Hartman, bagian core yang dijalankan semua orang cuma sekitar 5% dari angka itu. Sisanya dukungan hardware: driver, arsitektur, dan chip dari ratusan vendor.

Jadi kenapa Linus melunak? Jawabannya ada di satu masalah kronis yang menghantui industri software selama puluhan tahun: memory safety.

Datanya lumayan konsisten kok lintas proyek. Alex Gaynor mengumpulkan analisis CVE dari beberapa vendor, dan hasilnya seragam di kisaran 65-70%. Sampel CVE kernel Ubuntu selama enam bulan menghitung 65% kejadian memory unsafety, sementara Microsoft menyebut sekitar 70% CVE yang mereka tetapkan tiap tahun berasal dari sana. Buat proyek seukuran kernel, itu bukan angka yang bisa diabaikan.

Bentuk kesalahannya juga nggak banyak ragamnya sih. Semuanya sudah jadi kosakata harian buat yang pernah nulis C:

• use-after-free — mengakses memori yang sudah dikembalikan ke sistem
• buffer overflow — menulis atau membaca data melewati batas buffer
• double free — membebaskan blok memori yang sama dua kali
• data race — beberapa core mengubah data yang sama tanpa sinkronisasi

Di user space, bug seperti ini biasanya berhenti di crash atau Segmentation Fault. Di ring 0, satu pointer liar bisa langsung memicu kernel panic. Bisa juga merusak filesystem, atau membuka jalan bagi penyerang untuk duduk di kursi root.

Yang sebenarnya diincar: rimba driver hardware

Banyak orang mengira Rust langsung dipakai buat menggantikan scheduler CPU, virtual memory manager, atau filesystem inti. Padahal sasarannya jauh lebih spesifik nih: device driver.

Logikanya sederhana banget. Bagian core kernel yang tadi cuma 5% itu diurus oleh sekelompok maintainer yang ketat dan saling mengawasi. Sementara 95% sisanya isinya driver — GPU, modul Wi-Fi, kontroller NVMe, adaptor Bluetooth, sensor — yang ditulis ribuan engineer dari berbagai vendor hardware. Standar kualitas kode dan disiplin pengujian mereka beda-beda banget, karena memang nggak ada satu komite yang mengawasi semuanya.

Tambahan lagi, kode driver berubah paling cepat, dan bug memori paling sering muncul di kode yang baru saja disentuh. Jadi area paling rawan tuh justru area yang paling sulit diawasi manusia. Di situlah ownership dan borrow checker Rust masuk kerja: kesalahan referensi ditolak di tahap kompilasi, bukan ketahuan tiga tahun kemudian saat ada yang melaporkan kernel panic di mesin produksi.

// Contoh struktur dasar modul driver di Rust for Linux (API era 6.1)
use kernel::prelude::*;

module! {
    type: InvaSampleDriver,
    name: "inva_sample_driver",
    author: "Invasikode Team",
    description: "Contoh registrasi modul driver minimalis berbasis Rust di kernel Linux",
    license: "GPL",
}

struct InvaSampleDriver;

impl kernel::Module for InvaSampleDriver {
    fn init(_name: &'static CStr, _module: &'static ThisModule) -> Result<Self> {
        pr_info!("Rust driver berhasil diinisialisasi ke dalam kernel Linux!\n");
        Ok(InvaSampleDriver)
    }
}

impl Drop for InvaSampleDriver {
    fn drop(&mut self) {
        pr_info!("Resource driver dibersihkan secara otomatis dan deterministik!\n");
    }
}

Perhatikan impl Drop-nya. Di C, melepas modul driver berarti kamu harus ingat membebaskan semua yang kamu alokasikan di module_exit, satu per satu, di jalur yang jarang diuji. Di Rust, implementasi Drop memastikan sumber daya hardware dibebaskan saat modul di-unload, dan kompilator menolak kode yang meninggalkan referensi menggantung.

Satu catatan kalau kamu mau coba sendiri: signature init() di contoh itu mengikuti API era 6.1. Di rilis yang lebih baru argumennya tinggal &'static ThisModule, dan sempat ada usulan untuk menghapus argumen itu sekalian. Cocokkan dulu dengan dokumentasi kernel yang kamu pakai sebelum copy-paste dari artikel mana pun, termasuk yang ini. 😅

Faktor kedua yang jarang dibahas: regenerasi maintainer

Di luar urusan keamanan, ada alasan manusiawi yang sama pentingnya.

Maintainer inti kernel Linux didominasi insinyur veteran yang sudah mengurus subsistem C selama 20 sampai 30 tahun. Di sisi lain, generasi developer sekarang tumbuh dengan standar bahasa yang beda: manajemen paket terintegrasi, dokumentasi interaktif, sistem tipe yang ekspresif, dan tooling yang ngerti maksud kodenya. Bahasa yang nggak menyediakan itu terasa seperti kerja lembur tanpa dibayar.

Mendukung Rust di level kernel adalah langkah strategis untuk merangkul generasi baru developer sistem operasi. Tujuannya memastikan ada orang yang mau mengambil alih infrastruktur komputasi dunia sebelum angkatan C-nya pensiun. Buat proyek yang umurnya lebih tua dari banyak pembacanya, ini bukan kemewahan, tapi soal keberlanjutan.

RIIR di luar kernel: menang di CLI, kebablasan di tempat lain

Di luar kernel, antusiasme pada Rust melahirkan gerakan yang populer dengan nama RIIR. Di ekosistem developer tools, gerakan ini membuktikan diri secara nyata:

• ripgrep (rg) jadi standar baru pengganti grep, kencang karena mesin regex-nya pakai finite automaton plus optimasi SIMD
• fd menggantikan find dengan antarmuka yang lebih intuitif dan pembacaan direktori paralel bawaan
• bat menghadirkan versi modern cat dengan syntax highlighting dan integrasi Git
• Bundler dan compiler seperti SWC, Biome, dan Turbopack menulis ulang toolchain JavaScript dan CSS ke Rust, dengan klaim pemangkasan waktu build sampai belasan kali lipat

Buat poin terakhir, ada caveat yang perlu kamu tahu dulu. Angka "10x lebih cepat" dari Vercel pernah dibantah Evan You karena benchmark-nya membandingkan hal yang nggak setara: implementasi Vite-nya masih memakai Babel, sementara Turbopack dan Webpack sama-sama memakai SWC. Yang tetap berdiri adalah alasan arsitekturnya — paralelisme native dan komputasi inkremental di Rust menghapus batas single-thread yang selama ini menahan tooling Node.js. Angka pastinya bergantung proyekmu sendiri, jadi ukur aja, jangan percaya slide.

Sisi ekstremnya muncul ketika RIIR dipakai untuk menulis ulang proyek yang sudah stabil puluhan tahun tanpa urgensi teknis yang jelas. Menulis ulang kode yang sudah terbukti jalan demi tren bahasa sering menghabiskan biaya engineering raksasa tanpa peningkatan nilai yang bisa diukur. Bedanya dengan kasus kernel: di sana ada data CVE yang jelas, di banyak proyek RIIR lain cuma ada perasaan. 🤔

Jadi, revolusi atau cuma hype?

Kehadiran Rust di Linux 6.1 bukan hype sesaat. Ini adaptasi yang terukur dari proyek open source terbesar di dunia.

Lihat buktinya di Android. Google mendorong Rust untuk kode sistem tingkat rendah di sana, dan hasilnya terukur: porsi celah keamanan memori turun dari 76% di 2019 ke 24% di 2024, lalu di bawah 20% di 2025. Laporan terbaru mereka juga mencatat kepadatan kerentanan memori di kode Rust lebih dari seribu kali lebih rendah dibanding C dan C++, dengan rollback rate empat kali lebih kecil untuk perubahan berukuran sedang sampai besar, dan waktu code review yang 25% lebih singkat. Angka 76% dan 24% itu sendiri berasal dari post mereka setahun sebelumnya. Biaya investasi ke Rust terbukti lebih murah daripada menambal zero-day di lingkungan produksi.

Tapi jangan salah baca arah. C tetap jadi fondasi yang belum tergantikan. Portabilitasnya ke arsitektur prosesor apa pun dan kesederhanaan toolchain-nya nggak ada yang menyamai sampai hari ini. Kernel Linux pun nggak dibangun ulang — Rust masuk lewat pintu samping, di area yang paling rawan bug dan paling jarang diawasi, satu driver demi satu driver.

Jadi jawabannya tuh: bukan revolusi, bukan juga hype. Rust datang bukan buat membunuh C, tapi buat menambal kekurangannya tepat di titik yang paling gampang pecah — dan di titik itu, kita memang sedang butuh bantuan siapa pun yang mau menulisnya. Selamat ngoprek driver, dan semoga yang kamu tulis nggak perlu reboot buat ketahuan salahnya. 👋