Mozilla Glean Team: Co náhodně mění vaše bity?

Travis Long z Mozilla Glean Teamu řešícího v Mozille telemetrii (about:telemetry) se v článku Co náhodně mění vaše bity? zamýšlí nad chybou 1762568. Jak je možné, že přijata data místo "web.background-perceivable" obsahují "web.bAckground-perceivable" nebo místo "web.background" obsahují "web*background"? Rozdíl je v jediném bitu. Může za to kosmické záření?

19.4.2022 22:00 | Ladislav Hagara | Zajímavý článek

Komentáře

[senzace nebo chachna]

muze za to overclocking

[plostenka]

Nastesti inteligentni lidi vymysleli ECC a nekteri to jen zapomeli implementovat.

[billgates]

Paradoxne je v tomto smere najhorsi svet ARM. Najst nejaky rozumny SoM alebo SiP s podporou ECC a linuxu je extremne narocne.

[plostenka]

ECC je obecny algoritmus nad jakymikoli daty, klidne si ho muzes implementovat i softwarove. ECC v/nad RAM je jen hw akcelerace.

Jak rozsirene jsou ty hw akceleratory ve svete ARM netusim, mozna integritu dat resi jinak nebo jen pod jinym nazvem...

[billgates]

To zial nie je mozne, kedze data medzi RAM a rozhraniami malokedy prudia cez samotny procesor. Vsetky DMA prenosy medzi RAM a radicmi diskov a podobne proste budu neustale zavadzat chyby. Mozes do RAM cokolvek nahrat, spocitat ake chces checksumy, kludne mat aj dve kopie tych istych dat, ale potom das povel na zapis danej oblasti RAM napriklad na pevny disk a kludne sa moze stat, ze medzi tymito dvoma operaciami (tvoja kontrola a zapisom na disk) sa jeden bit zmeni. Preto ma ECC a ine kontrolne mechanizmy zmysel implementovat jedine v HW a to priamo na strane, kde tieto problemy vznikaju, resp. na prislusnom radici, cez ktory tie vsetky data musia nutne pretiect.

Keby sa to dalo implementovat v SW, tak to uz v takom kerneli davno je. Ved aj v roznych diskusiach a v mailing listoch sa neustale objavuju otazky, preco nie je ECC softverove, napriklad zmensenim RAM na polovicu a drzanim duplicitnych kopii, ako napriklad pri RAID1. A ludia potom stale musia dookola vysvetlovat, preco to nejde.

[Petr]

Jenze ono to jde, jen se nechce.

[plostenka]

To vis ze to softwarove jde, been there, done that. Vzdyt je to trivialni tabulka, kde pro vsechny mozne vstupy (treba 256 stavu kazdeho 1 B) predpocitas vystup (treba 12b, cim vetsi detekcni/opravna sila, tim delsi vystup) a ten si pak ulozis. Po precteni 12b se zase podivas do tabulky a bud najdes shodu, nebo najdes nejmensi rozdil (spravne ECC ma matematicky pekne vlastnosti, ktere ti pritom pomuzou).

Ma to smysl implementovat vsude, kde ti zalezi na integrite dat pri prenosu (nutne na obou koncich). Je uplne jedno, jestli resis chyby na urovni flipnutych bitu v RAM/HDD, fuzzujiciho utocnika, nebo SNR bezdratovych technologii.

[j]

Co nechapes na DMA? Aha ... nektery lidi by radsi meli mlcet, aspon by neustale neukazovali, jakymi blbci jsou.

---

Dete stim guuglem dopice!

[plostenka]

Co nechapes na tom, ze *ucinne* ECC musi pokryt *cely* proces zpracovani informace? Nektery lidi...

[j]

Co ty RETARDE nechapes na tom, ze to NELZE udelat SW cestou?

---

Dete s tim guuglem dopice!

[plostenka]

ECC je obecny algoritmus nad jakymikoli daty, klidne si ho muzes implementovat i softwarove. ECC v/nad RAM je jen hw akcelerace.

Inteligente.

[j]

Jak sem rek, debil zustane debilem, a ty ses uberdebil ...

"ECC v/nad RAM je jen hw akcelerace."

Protoze to zadna HW akcelerace neni, ECC je kus HW kterej zpatky systemu jen signalizuje, ze je to spatne, ale pocita si to sam. System pak muze z ty signalizace vycist tak maximalne ktery modul(slot) chybu hlasi(a i to jen nekdy). A protoze ses ten uberdebil, tak pochopitelne netusis, ze ani to nemusi nutne znamenat, ze existuje realnej problem s datama v ramce, protoze chyba muze byt klidne trebas prave v tom ecc. Jeste porad se mi tu vali R900 u kteryho to je znama zdokumentovana chyba kdyz ma plny sloty ramek ...

Vis o tom zcela zjevne uplnou picu!

---

Dete s tim guuglem dopice!

[plostenka]

"ECC v/nad RAM je jen hw akcelerace."

Protoze to zadna HW akcelerace neni, ECC je kus HW

Uz to nehul. Za domaci ukol se oprosti od jednoho konkretniho pouziti (modul RAM) obecneho algoritmu Error Correction Code...

[_]

kdo ti to nakukal?

[hefo]

Nad "dátami", ktoré nejaký SW explicitne spracúva, to samozrejme nejako urobiť ide, ale o možnosti urobiť túto SW kontrolu všeobecne (t.j. aj pre "živý" programový kód v pamäti) by som silne pochyboval...

[billgates]

Ako, ta kontrola na urovni protokolov/dat pri kazdom prenose je samozrejme potrebna, to nerozporujem. Problem je, ze samotny kod, ktory sa vykonava, je ulozeny prave v RAM (v jednom momente) a preto hrozi velke riziko, ze do CPU sa uz dostanu (a vykonaju) koniny. Cize v kode mozete mat kludne riesenu kontrolu integrity napriklad prijatych dat, ale co je to platne, ak instrukcia, ktora by po zlom vysledku jumpla prec sa vdaka zmenemeu bitu v RAMke zmeni na NOP alebo nejaku inu neskodnu instrukciu? Ako cisto v softveri overite, ze kod, ktory vykonavate, je naozaj to, co chcete vykonavat?

Mozete namietat, ze napisete kod, ktory bude neustale periodicky kontrolovat svoj checksum v RAMke a ked je zly, tak ukoncite vykonavanie. Ale co ak prave na mieste, ktory by ukoncil vykonavanie, bude chyba? Dalej namietnete, ze taketo kontroly budete mat dve a budete ich striedat. Je velmi nepravdepodobne, ze by sa na oboch miestach stala zmena, ktora by sposobila neucinnost oboch kontrol. Ale tu sa zasa moze stat, ze kod, ktory vola samotne kontroly, je poskodeny a prestane ich volat. Tak znasobite aj ten, ale opat to zniekadial je potrebne volat, atd.

To je prakticky neriesitelny problem, preto je snaha eliminovat vznikanie chyb na miestach, kde je najvacsie riziko. A prave RAMka je extremne zranitelna, lebo obsahuje vela malych buniek, ktore nepotrebuju vela externych vplyvov, aby nezelane zmenili svoju hodnotu.

My napriklad robime zariadenia pre zeleznice. Procesory, ktore pouzivame, maju samozrejme nejaku formu ECC na cache, na ramkach, na flashkach a este aj na vnutornej zbernici. A zo statistik vidno, ze prave RAM je miesto, kde vznika 99.9999% chyb typu flipnuty bit. Preto sa prakticky vsetci v tejto diskusii zameriavaju prave na RAM.

Dufam, ze uz chapete, co som myslel a preco pozadujem HW ECC pre RAM. Ak stale mate namietky, tak napiste nejaky kratky C kod, ktory bude riesit integritu sameho seba softverovo a ked je integrita narusena, tak skonci. Mozeme sa potom pozriet na to, ci sa flipnutim zopar bitov vo vyslednej binarke nedostaneme ku kodu, ktory nieco bude vykonavat, hoci checksum nebude sediet.

[j]

Hele, to nemusis psat, vysledek je vzdy je/jne ...

Ostatne, osobne sem nekolikrate "hackoval" aplikace, ktere prestali fungovat, protoze tvurce nekde neco vypnul(nebo zkrachoval) a stacilo zmenit jedinou instrukci.

---

Dete s tim guuglem dopice!

[_]

ten kod nemusi byt v ram,ale v kesi

[billgates]

Ano, je pravda, ze kod sa moze vyhnut RAM uplne a putovat rovno napriklad z NAND flash do cache. Pri pouziti linuxu a flash s nejakym filesystemom ale asi aj tak pretecie vacsina vykonavaneho kodu cez RAM.

Ako vlastne funguje mmap, ked si namapujem nejaky subor z disku (napriklad ext4), nastavim PROT_EXEC a dam kod vykonat. Pretecie cez RAM? Linux nie je moja silna stranka, tak o tomto nizkom fungovani nemam velmi dobru predstavu. Ak je tam nejaka vrstva typu LUKS, tak urcite. Ale ak je to cisty ext4 priamo nad mediom, mapuje to interne kernel tak, aby sa data neprehnali cez RAM?

[plostenka]

To je prece v pohode. RAM modul si hlida ulozena interne a pokud ECC umi i na sbernici, a zaroven ECC umi i CPU (neni to tak davno, co podpora ECC byla jen u highend produktu), tak je osetrena cela cesta mezi pameti a vykonavanim. Pokud ECC po sbernici umi i radic PCI/usb/... tak se da s trochou snahy osetrit cely proces zpracovani/prenosu dat na HW urovni.

O uroven vys se da softwarove resit integrita kernelu, FS, packetu,... a samozrejme i DRM, anticheat, sracky. Problem neni v nastroji, ale v uziti.

[billgates]

Ved cely cas sa tu bavime o tom, ze RAM/radic RAM nema podporu ECC a ty si tvrdil, ze to ide softverovo. O tom je komplet cela diskusia, ze to cisto v SW urobit nejde.

[Ruža Becelin]

Trochu předčasné vydávat článek s nějakými závěry o kosmickém záření, když v tom bugu mají:

To me it seems most likely that the bitflip happens on disk to the stored value.

Což vypadá na vadný FS nebo disk. Ale bez specifikací těch klientů je to celé jen výkřik do tmy.

Kromě toho se jedná o vzorek s Windows, žádný MacOS (tam má FF minoritu) a žádný Linux (protože Linuxáci nemají rádi telemetrii), takže chybí data z jiných FS.

[j]

A nebo je vysvetleni mnohem jednodussi ... podobny "zahadny" jevy totiz najdes u libovolny online servisy, a je to jednoduse o tom, ze lidi hledaj, kde nechal tesar diru, a kdyz nic jinyho, tak sejmout zrovna telemetrii urcite spoustu lidi potesi. Kolik provozovatelu nejak validuje co jim na vstup posles? Mno a pak se vetsinou zacnou dit uzasny veci.

---

Dete s tim guuglem dopice!

[Ruža Becelin]

To mě taky napadlo, vzhledem k "zdrojům" z Číny a Běloruska to i dává smysl, že si "někdo něco zkoušel"