Názory k článku
Rustls je rychlejší než OpenSSL a BoringSSL na ARM64

No a ma za sebou nejaky audit?

https://www.reddit.com/r/rust/comments/h8za2s/rustls_the_tls_implementation_in_rust_just_got_a/

Tak nevim, nevidim tam zadnou analyzu kolik a jake chyby ten audit nasel, 5 let stara informace a zpravicka zminuje arm64…

Celá zpráva z auditu v r. 2020 je tady:
https://github.com/rustls/rustls/blob/master/audit/TLS-01-report.pdf

Jinak historie CVEček:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rustls
https://rustsec.org/packages/rustls.html

Zdá se, že projekt má pár poměrně high-profile sponzorů (AWS, Google, německý Sovereign Tech Fund atp.) a už se to pár let vyvíjí. Jasně oboje per se neznamená, že je to automaticky bezpečné, ale na druhou stranu, kdyby to bylo nějak fundamentálně blbě, podle mě by do toho nešli.

Dekuji!

Existuje vlastne i nejaka analyza, ktera by odpovedela na zrejmou otazku, proc je vlastne rychlejsi (a v pripade BoringSSL prakticky stabilne)?

Protoze na prvni pohled, bud je OSSL i BSSL psana opravdu hodne spatne, coz se mi po tech letech nezda i kdyz mozne to je, nebo tam muze byt nejaky podstatny rozdil (neco kolem side channel attacku?)

C narazilo na praktické meze v oblasti optimalizace výpočtů?

Jako, že by HW instrukce co oba projekty používají měli jinou rychlost v rustu a C? To asi ne...

Spíš to bude lepší async, protože tady jde o handshake, takže o trochu rychlejší dispatch a rozdíl je na světě.

Nejde o HW instrukce, ale některé věci Rust optimalizuje v zásadě sám a v ASM to holt dá práci.

Já to chápu tak, že když napíšete nějakou konstrukci, tak tím, jak ji napíšete svazujete kompilátoru ruce. A v C, tím jak je navržený, tak kompilátor svazujete víc/jinak, než Rust.

Vždyť dělali benchmark handshake - tam se čeká, takže to není o optimalizacích kompilátoru, ale o návrhu všech těch knihoven co to používá, a potom zabudovanou podporu async v rustu.

Nehledej tam něco, co tam vůbec není...

Tipoval bych dvě příčiny:

– Stáří projektu – zpětná kompatibilita (podpora starých alogirtmů, starých architektur) a stáří kódu (některé věci by třeba po odstranění podpory něčeho starého šlo přepsat lépe, ale nikdo to neudělá).

– „Přehnaná opatrnost“ – kontroly, které by se možná po detailní analýze kódu ukázaly jako zbytečné, ale v kódu psaném v C musí být, protože tu detailní analýzu nikdo neudělá. Případně to mohou být kontroly, které kód psaný v C dělá až za běhu, zatímco Rust je udělá už během kompilace.

Tj. za mne je to opačně – bylo by divné, kdyby projekt psaný na zelené louce a v modernějším (ale stejně zaměřeném) jazyce nebyl rychlejší.

Takova analyza by asi zabrala dost casu. Jednou jsem obetoval 2 mesice svyho zivota tim ze resil proc je kod v Java 2x rychlejsi nez ten samy v C/C++. Postupne jsem nachazel veci jako zbytecny kopirovani strigu, deep copy stromu, naivni implementace hash map... Vitezem bylo jedno makro kde bylo "if (b() && a=='x')" zatimco v Jave bylo vsude "if (a=='x' && b())".

OpenSSL je rozsahly projekt, hodne veci je optimalizovanych primo v asembleru tam by rozdil byt nemel. Ale jinak bych hledal problem u predavani hodnotou vs predavani referenci.

> OpenSSL je rozsahly projekt, hodne veci je optimalizovanych primo v asembleru tam by rozdil byt nemel.

A zrovna tady bych se ani moc nedivil. Udržovat nějaký starý kód v assembleru je dost náročné. Klidně se mohla změnit situace a najednou je ten assembler silně neoptimální, nebo tam překladač mohl napáchat nějaké nečekané divočiny.
A pokud ten výkon najednou není úplný průšvih, tak se to dá zjistit jen hodně těžko.

Cekal bych, ze primarni rozdil bude v tom, ze je to deravy jak reseto === chybi tam tisice ifu osetrujicich ruzne mezni situace. Coz se samozrejme behem nasledujicich let potvrdi, a pak uz to rychlejsi nebude, protoze ani byt nemuze.

A nebo je to rychle proto, ze si v kodu nenesete ruzny podivny historicky balast, o jehoz bezpecnosti jde ve vysledku take vcelku uspesne pochybovat. Ostatne to i na OpenSSL je videt, ze se nektere chyby opravuji nazpet klidne az do verze 1.0.2 z roku 2015 (ktera ma uz jen enterprise/komercni podporu).

Jenze ten "balast" o kterym (typicky) nikdo nevi co vlastne dela tam vznika v prubehu let proto, ze se narazi na ty ruzne situace.

Kdyz ti hodim na monitor hlasku "Zadej cislo:" ... tak co tam zadas? Ja treba 0xefac. A to je presne ono. Moderni automatismus kterej dela vsechno sam.

U toho sifrovani narazis na presne totez. Treba klic nulovy nebo jeste lip zaporny dylky ...

Tak sis zanadával na moderní časy a teď si o tom Rustu zkus něco přečíst...

"protoze ani byt nemuze"

No nepovídej.

Jiste, kdyz budu neco prekladat necim, co (pry) "samo" osetruje (vybrany typ) neschopnosti vyvojare, tak to urcite bude rychlejsi, protoze v tom vubec nemusi byt hromada, casto zcela zbytecneho, kodu navic.

Většina těch checků je compiletime.

> a pak uz to rychlejsi nebude, protoze ani byt nemuze.

Ale může. C má pár překvapivých vlastností, které hodně komplikují optimalizátoru práci.