Vlákno názorů k článku
Včerejší výpadek Cloudflare nezpůsobil útok, ale konfigurační chyba od tom111 - V článku dosť výrazne chýba informácia, že pád...

V článku dosť výrazne chýba informácia, že pád spôsobilo neošetrené pretečenie pamäte v Ruste, v kóde, ktorý predtým dlhé roky fungoval a potom bol prepísaný do Rustu.

Each module running on our proxy service has a number of limits in place to avoid unbounded memory consumption and to preallocate memory as a performance optimization (...) Again, the limit exists because for performance reasons we preallocate memory for the features.

When the bad file with more than 200 features was propagated to our servers, this limit was hit — resulting in the system panicking. The FL2 Rust code that makes the check and was the source of the unhandled error is shown below: (...)

This resulted in the following panic which in turn resulted in a 5xx error.

K žádnému přetečení paměti nedošlo. Daný kód vrátil validní Result type, který se Cloudflare rozhodl řešit přes explicitní panic při chybě. Což je věc která není u inicializace aplikace zas tak velké zlo, pokud ta chyba není recoverable. Správně by měli udělat rollback konfigurace a nahodit to znova.

19. 11. 2025, 14:58 editováno autorem komentáře

Souhlas, zjevně paměti bylo málo, kód detekoval chybu, se kterou kód vyšší úrovně nepočítal. Z hlediska Rust korektní chování.

Co mi tam chybí, je neschopnost identifikovat chybu poměrně dlouhou dobu. A tam nejspíš doplácí Rust na chybějící podporu vyjímek. U Java by se zpropagoval celý stacktrace a někde dole by bylo "file too big to fit into memory". U Rust a ostatních jazyků bez exception bude jenom Result-Err a hledej jehlu v kupce sena... Logování může samozřejmě pomoct, ale to se nedělá v low level funkcích, u kterých se ani neví, jestli chyba je běžná nebo neočekávaná.

Tohle nesouvisí s podporou nebo nepodporou výjimek. Pokud do svého programu dám log chyby "too many items in configuration", tak z jedné chybové hlášky je naprosto jasné, co je špatně.

"Pokud do svého programu dám log chyby"

Jenze to bys musel kontrolovat vstupy, a to dneska neni v mode.

- unwrap explicitně vrací stack trace.
- pokud by mohli něco zlepšit, bylo by to použití expect(), který by jim umožnil přidat důvod pro panic
- propagaci trace řeší snad každá knihovna pro zpracování chyb. Konkrétně třeba anyhow, eyre, miette, error_stack

Jinými slovy, je to sice memory safe, ale způsobilo to celosvětový výpadek? :)

Spekulace: Dalo by se tomu zabránit, kdyby to nepřepisovali?

Já jsem si ale celkem všiml, že v rustu toto lidi dělají - tak nějak předpokládají, že když se to zkompiluje, tak to nemá chyby - testů je většinou málo... ne všechny crates jsou kvalitní a často se mi stalo, že jsem něco jen zkoušel (nějaký rust program) a hitnul jsem panic prakticky hned. Možná se eliminovali memory-safety bugy, ale těch logických je mnohem víc? Stačí se podívat na uutils/coreutils, sudo-rs - všechno bylo způsobené ignorancí.

Asi opravdu záleží na kultuře - rust prostě není záruka bezchybnosti a je potřeba kultura testování, jinak sice přestaneme počítat memory bugy, ale začneme počítat logické bugy.

Jinými slovy, je to sice memory safe, ale způsobilo to celosvětový výpadek? :)
Memory safe neřeší všechny problémy světa a nikdo kromě odpůrců memory safe jazyků to netvrdí.

Dalo by se tomu zabránit, kdyby to nepřepisovali?
Přepis s tím nijak nesouvisí. Obě verze mají předalokaci (logicky) a obě verze selhávaly, akorát každá jiným způsobem.

To ví přece každý, že to neřeší všechny problémy světa - opět idiotská odpověď od vás.

Otázka jen je, jestli z těch memory safety bugů nebudou logické bugy. Ono jestli těch bugů bude ve výsledku stejně, jen budou jiná kategorie, tak v čem si polepšíme :) ?

Já dělám běžně v memory safe jazycích a těch logických chyb se udělá strašně moc. Takže nemám pocit bezpečí, jen díky tomu, že něco je memory safe.

To ví přece každý, že to neřeší všechny problémy světa
Pokud to ví každý, proč se tedy podivujete, že to nevyřešilo problém, který s memory-safe nesouvisí?

opět idiotská odpověď od vás.
Vždycky svou odpověď přizpůsobuju dotazu.

Otázka jen je, jestli z těch memory safety bugů nebudou logické bugy.
Nebudou.

Takže nemám pocit bezpečí, jen díky tomu, že něco je memory safe.
Prý všichni vědí, že memory-safe nevyřeší všechny problémy světa. Je tedy logické při použití memory safe jazyka mít pocit bezpečí, že v memory-safe kódu nebudou chyby v přístupu mimo platnou paměť. Ale bylo by nelogické mít pocit bezpečí v jiných oblastech, pokud nejsou chráněny jiným způsobem.

Podle toho co píšou měli ten limit nastavený uměle. Takže ano, v jiném jazyce by jim to spadlo stejně.

To je právě ta pravá otázka. Spadlo by to a nebo by to bylo ošetřené (jak to měli dřív nevím)? Ono v rustu je jednoduché to nechat tak nějak hitnout ten panic.

Stačí si přečíst post mortem od CF. Problém byl v obou verzích, jenom se to projevilo v každé verzi jinak.

Ve spoustě jiných jazyků je zas celkem triviální ignorovat tu chybu úplně, případně neošetřit výjimku a sestřelit celou službu na recoverable chybě.

Po praxi z C++, Pythonu a občasného příspěvku do software v Go u mě error handling Rustu jednoznačně vede.