Az Android Rust-invázió folytatódik

A Google már 2021 óta hivatalosan is támogatja a Rust nyelvet az Android Open Source Project (AOSP) fejlesztésében, de a mostani bejelentés szerint a folyamat felgyorsult. A cél változatlan: kiiktatni azokat a memóriabiztonsági hibaosztályokat, amelyek évek óta a legtöbb kritikus Android sebezhetőségért felelősek.

A Google mérnökei nem titkolják, hogy ez egy hosszú távú, több éves projekt, de az eddigi eredmények alapján megérte belevágni. A Rust nem váltja le egyik napról a másikra a C++-t az Androidban, hanem fokozatosan, komponensről komponensre terjed.

ℹ
Megjegyzés

Fontos leszögezni: az Android alkalmazásfejlesztés (Kotlin/Java, NDK) szintjén ez a váltás nem közvetlenül érzékelhető. Itt a platform belső, natív rétegeiről beszélünk, amit a legtöbb app-fejlesztő sosem lát.

Melyik rendszerkomponensek kapják a Rust-kezelést

A Google elsősorban azokra a területekre koncentrál, ahol a támadási felület nagy, és a kód közvetlenül külső, nem megbízható bemenetet dolgoz fel. Ide tartozik többek között:

  • a Bluetooth stack egyes moduljai (a Fluoride/Gabeldorsche újraírása),
  • az Ultra-Wideband (UWB) alrendszer,
  • a DNS-over-HTTP3 komponens,
  • valamint a Keystore2 és néhány kriptográfiai könyvtár.

Ezek mind olyan alrendszerek, amelyek folyamatosan hálózati vagy közeli (near-field) adatokat parse-olnak, tehát klasszikus célpontjai a buffer overflow és use-after-free típusú támadásoknak.

Egy tipikus feladat ezekben a komponensekben egy bejövő bináris csomag feldolgozása. Egy leegyszerűsített, de a mai (1.67-es) stabil Rust-tal ténylegesen lefordítható példa arra, hogyan néz ki egy ilyen parsing-logika biztonságosan, let-else szintaxissal:

fn parse_header(packet: &[u8]) -> Option<(u8, u16)> {
    let [opcode, len_hi, len_lo, rest @ ..] = packet else {
        return None;
    };

    let length = u16::from_be_bytes([*len_hi, *len_lo]);

    if (rest.len() as u16) < length {
        return None;
    }

    Some((*opcode, length))
}

fn main() {
    let raw = [0x01, 0x00, 0x02, 0xAA, 0xBB];
    match parse_header(&raw) {
        Some((opcode, len)) => println!("opcode={opcode}, len={len}"),
        None => println!("hibás csomag"),
    }
}

A let-else mintaillesztés (amit még 2022 végén stabilizáltak) itt kifejezetten jól illik a "korai kilépés hiba esetén" mintázathoz, ami ezekben az alacsony szintű parserekben állandóan előkerül.

Memóriabiztonság: miért ez a fő hajtóerő

A Google saját publikus adatai szerint évek óta a súlyos Android biztonsági rések 65-70%-a memóriabiztonsági hibákra vezethető vissza: use-after-free, buffer overflow, double free, uninitialized memory olvasás. Ezek jellemzően C és C++ kódban keletkeznek, ahol a fejlesztőnek manuálisan kell kézben tartania a memória életciklusát.

A Rust ownership rendszere és borrow checkere ezt a hibaosztályt fordítási időben szűri ki. Nem arról van szó, hogy a Rust "okosabb" futásidőben – egyszerűen nem engedi lefordulni azt a kódot, ami ilyen hibákhoz vezethetne.

struct PacketBuffer {
    data: Vec<u8>,
}

impl PacketBuffer {
    fn slice(&self, start: usize, end: usize) -> Option<&[u8]> {
        self.data.get(start..end)
    }
}

fn main() {
    let buf = PacketBuffer { data: vec![1, 2, 3, 4, 5] };

    if let Some(chunk) = buf.slice(1, 3) {
        println!("{:?}", chunk);
    }

    // A borrow checker nem engedné, hogy a `chunk` élettartama
    // túlnyúljon a `buf` élettartamán, így use-after-free
    // egyszerűen nem tud létrejönni ebben a kódban.
}
✦
Tipp

Ha eddig csak C++-ban dolgoztál natív Android komponenseken, érdemes kipróbálni a cargo check gyors visszajelzési ciklusát – sok olyan hibát elkapsz vele már írás közben, amit C++-ban csak egy ASAN-os teszt futtatásakor vennél észre.

Google belső számai

A Google mérnökei szerint az elmúlt két évben az Androidba bekerült új natív kód jelentős hányada már Rust-ban íródott, és ezekben a modulokban eddig nulla memóriabiztonsági eredetű súlyos sebezhetőséget találtak – szemben azzal, amit a hasonló méretű és funkciójú C++ kódnál statisztikailag várnának.

Az Android biztonsági csapata azt is közölte, hogy a Rust-ba írt komponensek felülvizsgálata (code review) átlagosan gyorsabb, mert a reviewernek nem kell minden egyes pointer-műveletnél az élettartamokon és a tulajdonjogon gondolkodnia – ezt a fordító már elvégezte helyette.

✓
Jó tudni

A Google explicit módon hangsúlyozza: ez nem azt jelenti, hogy a Rust-kód hibamentes. Logikai hibák, race condition-ök (ha unsafe blokkot vagy rosszul tervezett megosztott állapotot használnak) továbbra is előfordulhatnak. A memóriabiztonság csak egy – bár nagyon fontos – hibaosztályt zár ki.

Fejlesztői visszajelzések: C++-ról Rust-ra

Az áttérés nem volt zökkenőmentes. A Google belső mérnökei szerint a legnagyobb kezdeti akadály nem a szintaxis, hanem a gondolkodásmód-váltás: a C++-hoz szokott fejlesztőknek újra kell tanulniuk, hogyan tervezzenek adatstruktúrákat úgy, hogy a borrow checker is elfogadja őket.

A visszajelzések alapján a tanulási görbe 2-4 hét alatt éles, de utána a fejlesztők produktivitása gyakran meghaladja a korábbi C++-os szintet, elsősorban azért, mert kevesebb időt töltenek debug-olással és memóriahiba-vadászattal.

Sokan kiemelték a Rust típusrendszerének erejét is – például a generikus asszociált típusok (GATs) stabilizálása révén immár olyan absztrakciókat is le lehet írni könyvtári szinten, amikre korábban csak sablonmegoldásokkal vagy makrókkal lehetett kínlódni:

trait PacketSource {
    type Item<'a> where Self: 'a;

    fn next_packet<'a>(&'a mut self) -> Option<Self::Item<'a>>;
}

struct BufferedSource {
    buf: Vec<Vec<u8>>,
    pos: usize,
}

impl PacketSource for BufferedSource {
    type Item<'a> = &'a [u8];

    fn next_packet<'a>(&'a mut self) -> Option<Self::Item<'a>> {
        let item = self.buf.get(self.pos)?;
        self.pos += 1;
        Some(item.as_slice())
    }
}

Az ilyen mintázatok korábban vagy unsafe-et, vagy komoly kompromisszumokat igényeltek, a GATs stabilizálása óta viszont teljesen biztonságosan, nulla futásidejű overheaddel megírhatók.

Mit jelent ez a szélesebb mobil ökoszisztémára

Az Android lépései nem elszigeteltek. Ahogy egyre több gyártó és chipszállító natív driver- és firmware-kódot ír a platformhoz, a Google Rust felé terelése közvetve nyomást gyakorol az egész ellátási láncra. Több chipgyártó már most is kísérletezik Rust-alapú driver-prototípusokkal, mert a Google minőségbiztosítási elvárásai (és a Google Play Protect / biztonsági tanúsítási folyamatok) egyre inkább preferálják a memóriabiztos komponenseket.

Ez hosszú távon azt is jelentheti, hogy a más mobil platformok (embedded Linux disztribúciók, IoT-eszközök) fejlesztői is nagyobb eséllyel találkoznak Rust-tal írt komponensekkel, hiszen a hardvergyártók gyakran ugyanazokat a driver-köveket használják több platformon is.

⚠
Figyelem

Ha driver- vagy firmware-fejlesztéssel foglalkozol és még nem néztél bele a Rust embedded ökoszisztémájába, most van itt az ideje – a no_std környezetben is stabil, kiforrott eszközök állnak rendelkezésre, és a nagy gyártói érdeklődés miatt ez a terület valószínűleg csak nőni fog.

Összefoglalás

A Google és az Android projekt Rust-stratégiája nem marketingfogás: konkrét, mérhető biztonsági javulást hoz a natív kódbázis kritikus, támadható részein. A let-else, a GATs és a nyelv szigorú ownership-modellje együtt olyan eszköztárat adnak a fejlesztők kezébe, amivel a C és C++ évtizedes memóriabiztonsági problémái strukturálisan kezelhetők. A tanulási görbe létezik, de a Google belső tapasztalatai és a fejlesztői visszajelzések alapján ez az egyik legjobb befektetés, amit egy nagy platform biztonsági jövője érdekében tehet.