Vlákno názorů k článku
Středně vážné zranitelnosti sudo-rs se týkají i Ubuntu 25.10
od cc - Hlavně, že to je memory safe!
-
Jestli vůbec.
1) Ani safe Rust tohle nezaručuje, protože v kompilátoru jsou bugy (staré i několik let, kdy v safe kódu můžete přistupovat třeba k již uvolněné paměti).
2) Každá pátá knihovna na crates.io obsahuje unsafe kód, který může být špatně. V některých případech ani nejde říct, zda je dobře či špatně, protože Rust zatím nemá žádnou specifikaci pro aliasing ukazatelů, takže se vlastně nedá říct, zda třeba tokio je v pořádku nebo ne.
3) Psaní unsafe kódu v Rustu je těžší než psaní C kódu (nebo Odin, Zig, C3),
protože po programátorovi se očekává mnohem víc - ty invarianty co musíte dodržet jsou mnohem složitější a je mnohem snazší je porušit. Navíc ten program v Rustu často může zatím fungovat, i když ve skutečnosti obsahuje nedefinované chování. -
Bugy v kompilátoru věřím, že vyřeší.
Ale množství unsafe kódu v různých knihovanách asi ne - to by se musel Rust změnit, aby to co se dnes píše v unsafe kódu, šlo napsat v safe kódu a běželo to stejně rychle (nebo rychleji).
Ideální by bylo, kdyby Rust přišel s nějakým jednoduchým modelem pro aliasing, který zároveň umožňuje optimalizace. Jediný kandidát je zatím Tree Borrows, ale úplně jednoduchý není (možná totiž žádný jednoduchý model pro aliasing ani neexistuje).
-
> A proč je unsafe kód v rustu takový problém?
Protože ty chyby v něm jsou vidět hůř než v C. Viz třeba problémy, co našel nástroj Miri.
> Ten unsafe kód je krásně izolovaný a obecně ho není moc.
Bohužel ten problém s unsafe kódem se může projevit i mimo unsafe blok. Takže verifikaci musíte provádět většinou na celém modulu včetně safe částí. A ověřujete, že jakékoliv volání safe funkce nezpůsobí nedefinované chování. A pak, že jakékoliv volání unsafe funkce, které splňuje invarianty (z dokumentace), nezpůsobí nedefinované chování.
A ten hlavní problém jsou IMO právě aliasing pravidla, která jsou přísnější než v C.
Například jsem přepisoval kód ze standardní knihovny Rustu do C3 a výsledek byl zhruba 3x kratší - protože v Cčkovém jazyce jsem nemusel řešit problémy s aliasingem (konkrétně se jednalo o B-strom a soubor node.rs, který měl v Rustu 1800 řádků kódu a v C3 600 řádků - algoritmus zůstal stejný).
-
K diskuzi doplním, že ačkoli C/C++ jsou "unsafe", je k nim spousta externích nástrojů, které typické chyby, které Rust odhaduje již v době kompilace, také najdou. Takže jazyk C/C++ jako takový "bezpečný" není, ale ekosystém jako celek ano. Jen to není by default a součástí jazyka jako takového.
12. 11. 2025, 15:26 editováno autorem komentáře
-
Vývojáři kernelu si to nemyslí. A Rust taky nepodchytí všechno, takže stejně nakonec bude koexistovat s externími tooly jako ten Miri.
-
Takto jsem to nemyslel.
Ono teď tu máme nový memory safe jazyk, a hle... Další a další CVE, dokonce v tak důležité aplikaci jako je sudo. Nakonec zjistíme, že šance na logickou chybu je mnohem větší než šance na nějaký buffer overflow.
Co jsem si všiml, tak hlavně v rustu si hodně lidí myslí, že když se to zkompiluje, tak to je bezchybné. Já se osobně ale přikláním k tomu, že jsou potřeba i testy, a hodně.
-
S tím nesouhlasím.
Já píšu i asm, tam kde to má benefit, a abych byl upřímný, tak udělat chybu v asm, díky které projdou testy a program nespadne je mnohem mnohem těžší, než udělat chybu třeba v C++.
V asm se nepíšou aplikace, jen kritické funkce, které není problém kompletně otestovat.
Třeba v golangu se asm píše běžně (je to jediná možnost jak něco optimalizovat v go) a není to v podstatě žádný problém pro celý ekosystém - neslyšel jsem o chybě v asm, spíš zase ty logické chyby v go, popř. data race.
12. 11. 2025, 11:30 editováno autorem komentáře
-
Psaní unsafe kódu v Rustu je těžší než psaní C kódu
Jen taková OT myšlenka, který mě napadla už když jsem poprvé viděl syntax Rustu a nutnosti u každé proměnné označovat, jestli je to move, borrow apod, tak jsem se zamyslel, proč to tam vůbec je a jestli vůbec existuje jazyk, který by všechny tyhle problémy převedl na formální správnost, tedy zkompiluju pouze formálně správný kód, u kterého lze dokázat nějakou kvalitu. Potom by bylo jednak naprosto jasné, co se musí a nemusí kopírovat a hlavně by se snadno dělalo něco (můj sen), jako automatická paralelizace do mnoha threadů (což je třeba u share nothing modelu trivka).
ČLÁNKY DO MAILU