A Rust for Linux projekt már nem science fiction: a kernel 6.1-es verziója (2022 decemberében) óta a CONFIG_RUST opció bekapcsolásával fordítható a Linux kernel Rust nyelvi támogatással. Ez alapvetően infrastruktúra volt eleinte — bindgen-alapú kötések a C API-khoz, egy saját kernel crate, ami no_std környezetben nyújt biztonságos absztrakciókat a nyers C pointerek fölé. A cél nem az, hogy a teljes kernelt átírják Rustra (ez sem realisztikus, sem szükséges), hanem hogy az új driverek és modulok egy memóriabiztos nyelven íródhassanak, miközben a meglévő C kódbázis érintetlen marad.

Mi is az a Rust for Linux?

A kezdeményezést Miguel Ojeda vezeti, és 2022 óta a mainline kernel része. A projekt fő ígérete egyszerű: a C-ben írt driverek egy jelentős része memóriakezelési hibák (use-after-free, buffer overflow, double free) miatt okoz biztonsági réseket, és a Rust ownership modellje ezeknek a hibáknak jelentős részét fordításidőben kizárja. Linus Torvalds több alkalommal is nyilvánosan támogatását fejezte ki a projekt iránt, hangsúlyozva, hogy ez nem "C helyett Rust", hanem "C mellett Rust, ahol értelme van".

ℹ
Megjegyzés

A kernelben futó Rust kód nem a szokásos std könyvtárra épül, hanem no_std környezetben, a core és alloc crate-ekre támaszkodva. Ez jelentősen szűkíti azt, mi használható közvetlenül a standard könyvtárból.

Milyen driverek és modulok készülnek Rust nyelven

2023 nyarára több konkrét, kézzelfogható eredmény is született:

  • PL061 GPIO driver — ez volt az első valódi, produkciós célú Rust driver, amely bekerült a mainline kernelbe (a 6.4-es kiadásban). Egy ARM PrimeCell GPIO vezérlőt vezérel, és bizonyította, hogy a Rust absztrakciók nem csak minta (sample) kódra alkalmasak.
  • Null block device (rnull) — Andreas Hindborg munkája, egy Rust nyelven írt blokkeszköz-driver, amit főként tesztelési és referencia célokra használnak a block subsystem Rust-kötéseinek fejlesztésekor.
  • Android Binder driver átírása — a Google-nél Wedson Almeida Filho vezetésével zajlott egy nagyobb ívű kísérlet a Binder IPC mechanizmus Rustban való újraírására. Ez komplex, megosztott állapotot kezelő kód, így kiváló tesztje volt annak, mennyire skálázódik a Rust for Linux modell valós, nem trivi driverekre.
  • Apple AGX GPU driver kísérletek — az Asahi Linux közösség (Alyssa Rosenzweig és társai) elkezdte vizsgálni, hogy az Apple Silicon GPU driverét Rustban írják meg, mivel a GPU-kezelés komplex élettartam- és állapotkezelési logikája pontosan az a terület, ahol a borrow checker sokat segíthet. Ez még korai fázisban van, mainline integrációról egyelőre nincs szó.

Ezek mellett folynak kísérletek NVMe és hálózati driverek területén is, de ezek többsége még nem éri el azt a stabilitási szintet, hogy mainline patch-ként beküldjék.

Kernel fejlesztők reakciói és a mailing list viták

A lelkesedés mellett komoly ellenállás is van. A legnagyobb port 2023 nyarán Christoph Hellwig, a block és filesystem alrendszerek régi maintainere, és a Rust for Linux csapat között zajlott. Hellwig ellenezte, hogy a block layer DMA-kezelő kódjához Rust absztrakciókat adjanak, arra hivatkozva, hogy ez megnehezíti a C-oldali refaktorálást és plusz kognitív terhet ró a maintainerekre, akik nem ismerik a Rustot. A vita odáig fajult, hogy Wedson Almeida Filho — a projekt egyik kulcsfontosságú, korai szereplője — bejelentette, hogy visszalép a Rust for Linux maintainer szerepéből, frusztrációját kifejezve a folyamat lassúsága és a maintainer-i ellenállás miatt.

⚠
Figyelem

Ez nem elszigetelt eset. A kernel fejlesztésben a maintainerek vétójoga erős hagyomány, és sok régóta aktív C fejlesztő egyszerűen nem akar egy második nyelvet megtanulni ahhoz, hogy módosítani tudjon egy alrendszeren, amit egyébként ismer.

Ugyanakkor fontos hangsúlyozni: a vita nem a Rust technikai érdemeiről szól elsősorban, hanem arról, hogy ki és hogyan tartja fenn hosszú távon a vegyes nyelvű kódbázist. Torvalds több levelezőlistás hozzászólásában is jelezte, hogy a maintainereknek nyitottnak kell lenniük, de azt is elismerte, hogy a folyamat lassabb, mint amit a Rust for Linux csapat szeretne.

Milyen Rust nyelvi feature-ök szükségesek még

Itt jön a technikai lényeg, ami sok Rust fejlesztőt érdekelhet: a kernel rust crate-je jelenleg egy pinned nightly toolchain-re épül, nem a stabil csatornára. Ennek oka, hogy több olyan unstable feature-re támaszkodik, amelyek még nem stabilizáltak a mainline Rust compilerben:

  • allocator_api — szükséges ahhoz, hogy a kernel saját allokátorát (kmalloc/vmalloc) integrálja a Box, Vec típusokba.
  • new_uninit — inicializálatlan memória biztonságos kezeléséhez, ami kritikus egy kernel driverben, ahol minden allokáció drága és ellenőrzött.
  • receiver_trait és arbitrary_self_types — ezek nélkül nehéz elegánsan modellezni azokat az élettartam-mintákat, amik a kernel objektum-referencia számolásában (refcounting) előfordulnak.

Azok a feature-ök, amik viszont már stabilak 1.72-ben, és amiket a projekt örömmel használ ott, ahol lehet:

// GAT (Generic Associated Types) - stabil 1.65 óta
trait DriverBuffer {
    type View<'a> where Self: 'a;

    fn view(&self) -> Self::View<'_>;
}

struct RingBuffer {
    data: Vec<u8>,
}

impl DriverBuffer for RingBuffer {
    type View<'a> = &'a [u8];

    fn view(&self) -> Self::View<'_> {
        &self.data
    }
}

A GAT-ok pont azt a mintát teszik lehetővé, ami sok driver kódban előfordul: egy típus, ami különböző élettartamú "nézeteket" ad vissza a belső állapotáról, anélkül hogy klónozni kellene az adatot.

let-else szintén nagyon hasznos a hibakezelés egyszerűsítésére, ami kernel kódban rendkívül gyakori mintát jelent:

fn parse_register_value(raw: &str) -> Result<u32, &'static str> {
    let Ok(value) = u32::from_str_radix(raw.trim_start_matches("0x"), 16) else {
        return Err("invalid register value");
    };

    Ok(value)
}

A felhasználói térben (build szkriptekben, bindgen glue kódban, teszt eszközökben), ahol std elérhető, az OnceCell/OnceLock is hasznos mintát ad az egyszeri inicializálásra — ilyen problémára a no_std kernel oldalon a projekt saját sync::Once implementációt tart fenn, mivel a std verzió nem elérhető no_std környezetben:

use std::sync::OnceLock;

static DRIVER_REGISTRY: OnceLock<Vec<&'static str>> = OnceLock::new();

fn registry() -> &'static Vec<&'static str> {
    DRIVER_REGISTRY.get_or_init(|| vec!["pl061", "rnull", "binder"])
}
✦
Tipp

Ha kíváncsi vagy a kernel rust crate valódi kódjára, a rust-for-linux/linux GitHub repóban tudod böngészni — a samples/rust mappa jó kiindulópont, mielőtt a driverek forrásába mélyülnél.

A projekt jelentősége az iparág számára

Függetlenül attól, hogyan végződnek a mailing list viták, a Rust for Linux már most bizonyította, hogy egy memóriabiztos szisztémnyelv integrálható egy olyan, évtizedek óta C-ben írt, kritikus infrastruktúrába, mint a Linux kernel. Ez precedens más nagy C/C++ kódbázisok (böngészők, adatbázis motorok, tűzfalak) számára is: nem kell mindent egyszerre átírni, elég a kockázatos, gyakran bővülő részeket — jellemzően az új drivereket — egy biztonságosabb nyelven fejleszteni.

Az iparági érdeklődés nem véletlen: a Google, a Microsoft és több biztonsági kutatócsoport is rendszeresen hangsúlyozza, hogy a memóriakezelési hibák dominálják a kritikus súlyosságú biztonsági réseket. Egy driver réteg, ami fordításidőben kizárja a use-after-free és data race hibák nagy részét, közvetlen hatással van a teljes szoftver ökoszisztéma biztonságára.

Összefoglalás

2023 nyarára a Rust for Linux elhagyta a "kísérlet" státuszt, és néhány valódi, mainline driverrel (PL061, rnull) bizonyította létjogosultságát. Ugyanakkor a Hellwig-vita és Wedson Almeida Filho visszalépése jól mutatja, hogy a kulturális és folyamatbeli akadályok legalább annyira komolyak, mint a technikaiak. Nyelvi oldalról a projekt még nightly feature-ökre szorul — az allokátor API-tól a new_uninit-ig —, így a teljes stabil Rust-alapú kernel-integráció még várat magára. De az irány egyértelmű: a Linux kernel lassan, vitákkal kísérve, de biztosan nyit egy második, memóriabiztos szisztémnyelv felé.