Názory k článku
Dirty COW a Rowhammer lze použít k získání roota na Androidu
-
Petr StehlíkZlatý podporovatelNechápu, jak můžeme používat počítače, které mají HW chyby při přístupu do RAM. To bylo kdysi poprasku, že Intel Pentium trošku špatně dělí čísla, ale že teď v paměti není to, co do ní bylo uloženo, ale něco jiného, často zcela náhodného - to nikoho nepálí? Vždyť je to vyloženě vadný kus hardware, na reklamaci, ne? Jak tím můžeme počítat SETI, dělat firemní fakturaci, vést lékařské záznamy, řídit jaderné elektrárny, provozovat Datové schránky se zaručenými elektronickými podpisy a hrát si ve virtuální realitě? Vždyť tam musí kvůli Rowhammeru vznikat tuny chyb v datech...
-
Rowhammer je opakované zapisování stejné hodnoty do jednoho paměťového řádku (samozřejmě necachovaně), zatímco sousední řádek se nečte ani nezapisuje. Musí se zapisovat opravdu rychle, aby se efekt projevil dřív než ten sousední řádek obnoví refresh. Která běžná aplikace takovým způsobem používá paměť?
-
Petr StehlíkZlatý podporovatel
Proč bych měl vědět, která aplikace tak pracuje? V paměti počítače mi běží stovky věcí, které vůbec neznám (ps ax | wc -l), a to jsem ještě na desktopu nic nespustil. A pak používám desítky aplikací a ani o těch netuším, jak přesně pracují s pamětí. Co já vím, jestli třeba unrar nebo mpeg decoder nedělá něco dost podobného? Nebo co dělá Chrome, když kreslí SVG či provádí nějaký NaCl? To mám jako zjišťovat a pak takové aplikace nepoužívat?
Je to jasná HW chyba. Že statisticky nenastává moc často mě nemůže uklidnit. Když se to dá použít k rootnutí zařízení, což mi přijde jako docela sofistikovaná věc, tak náhodná změna hodnoty kteréhokoliv bitu v RAM bude nejspíš mnohem jednodušší a tím pádem statisticky častější. Dřív jsem si do serverů kupoval alespoň ECC paměti proti kosmickým paprskům, ale na desktopu a v mobilu běžné nejsou (ani u serverů už je nevídám).
-
FíkZlatý podporovatelTouto HW chybou trpí skoro všechny počítače s DDR3 pamětmi, výjimkou jsou snad ECC a DDR2. Trochu pomůže zvětšit časování, ale ztratíte výkon a není to stoprocentní.
-
Lael Ophir (neregistrovaný)
Jak už někdo psal, ten problém není tak velký, protože při běžném způsobu použití paměti se vyskytuje sporadicky. Row hammering vyžaduje rychlé necachované zápisy do jednoho řádku paměti.
Navíc problém není nijak nový. Už u ferritových pamětí se dalo docílit podobných efektů. A i bez raw hammeringu jsou paměti poměrně poruchové. Google provedl studii, kdy počítal chyby ECC pamětí v produkci (bez ECC ty chyby těžko zjistit). Vyšlo jim, že na 8GB RAM připadá cca 4.6 bitů chyby za hodinu. Jak vidíte, k těm chybám dochází i bez raw hammeringu. Co je inovativní je použití raw hammeringu k privilege escalation.
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdfAd Jak tím můžeme počítat SETI, dělat firemní fakturaci, vést lékařské záznamy, řídit jaderné elektrárny, provozovat Datové schránky se zaručenými elektronickými podpisy a hrát si ve virtuální realitě - servery většinou používají ECC paměti, které chyby odchytí (nebo alespoň detekují). Desktopy holt občas mají problém. Ale překlopení bitu většinou nevede k problému, který by uživatel postřehnul. Daleko spíš narazíte na nějaký z té přehršle bugů, kterými je veškerý SW prorostlý.
-
FíkZlatý podporovatel
to ECC se přeceňuje, na stroji 16GB RAM, 45 dní uptime, podle vás by mělo být 10 tisíc chyb, ve skutečnosti 0 (cat /sys/devices/system/edac/mc/mc*/*_count)
-
Lael Ophir (neregistrovaný)
Ve studii, kterou jsem linkoval, došlo minimálně k jedné chybě paměti (overall correctable error incidence + overall uncorrectable error incidence) u 33.49% strojů. Podle platformy (resp. výrobce) to bylo 17-50% strojů. Takže pokud u vás během 45 k chybě paměti nedošlo, moc to nedokazuje, že k nim obecně nedochází.
To je celé otázka distribuce těch chyb: pokud řekněme dvě třetiny strojů nemají během roka žádnou chybu, a zároveň nám vychází, že v průměru by tam těch chyb měla být velká spousta, tak zřejmě chyby "vyžerou" ve velkém množství stroje, na kterých k nim dochází. Koukněte na kapitolu 3.1: average number of correctable errors per year is over 22,000; for all platforms, 20% of the machines with errors make up more than 90% of all observed errors for that platform; in more than 93% of the cases a machine that sees a correctable error experiences at least one more correctable error in the same year.
Zdroj:
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdfCo to za mě znamená?
1. Příští stroj musí mít ECC paměti :)
2. Když máte větší množství strojů bez ECC (třeba tisíce desktopů), a některý z nich se chová fakt divně, bude to dost možná chybami paměti.
3. Před případným přechodem na in-memory database se velmi dlouze zamyslím -
A teď ještě najít ten notebook s podporou ECC… Obávám se, že notebookové procesory to nebudou podporovat.
Nevím, jestli to je reálné, zvlášť pokud ECC není jediný můj požadavek, ale mohlo by to být fajn.
Nevýhoda ECC, kromě ceny/dostupnosti, je v tom, že teoreticky poskytne více dát pro cold boot attack. Ale zase musí mít útočník asi docela speciální vybavení, protože ECC paměť musí být standardně při bootu vymazána (jinak bychom měli spurious errors).
-
Lael Ophir (neregistrovaný)
Namátkou jsem našel HP zBook. Je pravda že to není nejlevnější řada, a asi ani nevyhraje soutěž o sexy notebook roku :). Ale to si člověk holt musí vybrat, co pro něj má prioritu.
Co jsem četl, tak ECC paměti by se při bootu měly mazat. Teoreticky by to tedy cold boot attack mělo naopak znemožnit.
-
V nejlevnějších modelech nehledám, vzhled řeším s trochou nadsázky ve stylu „pokud to není růžové, je to OK“. Ale ECC samozřejmě není jediný sledováný parametr, mezi priority patří mj. bezpečnost, chci mít vhodný hardware pro rozumně bezpečný OS (QubesOS), takže určitě podporu VT-d/IOMMU, 16+GB RAM a grafiku nejlépe Intel.
Co se týče CBA, ECC je dvousečná zbraň. Jednoduché útoky to zastaví, protože se při startu vymaže paměť. Bez toho bychom měli při čtení spurious failures. (To jsem mimochodem psal.) Při pokročilejším útoku útočník RAM zchladí a dá mi do stroje, který z ní bude umět číst i bez přepsání. Možná bude stačit upravit BIOS (ostatně desku si teď volí útočník, takže je na něm, aby si zvolil desku, kde to takto jde), možná bude potřeba speciální hardware, ale ani tady bych se nedivil, kdyby šlo něco sehnat za pár stovek USD. Možná něčemu pomůže i raw přístup, kdy bychom si error correction řešili následně sami. ECC potom bude pracovat samozřejmě ve prospěch útočníka, protože:
1. Větší část bude přečte chyb.
2. Ví, co se poškodilo a co nejspíš ne. Tím může omezit bruteforce na menší množství bitů.A jak víme, o jediný bit méně na vyzkoušení znamená, že nás čeká poloviční práce na brueforce.
Záleží to ale na threat modelu a na prioritách. Rozhodně neříkám „ECC nebrat“.
-
Ještě se zeptám, jak jste hledal ty notebooky s ECC. Je možné někde hledal takto podle parametrů (včetně ECC a podobných, které asi nebudou zajímat každého BFU)?
Samozřejmě pokud mám tip na notebook a chci ověřit, zda má ECC, je možné dohledat dokumentaci a zjistit to, ale tento postup je vhodný spíše pokud se chci ujistit, že je ten notebook OK. Méně pohodlné to bude, pokud mi vypadne třeba 95% notebooků, což u ECC čekám.
-
FíkZlatý podporovatel
hledá se to blbě, ale třeba Thinkpad P50 a P70 mají mít s Xenonem podporu ECC DDR4: http://www.lenovoblog.cz/2015/08/mobilni-pracovni-stanice-thinkpad-p-xeon-64-gb-ddr4-ecc-4k-sonda.html
-
Škoda, čekal jsem něco jako vyhledávání podle parametrů na Heuréce, ale pokročilejší.
Zrovna k Lenovu nemám až tolik důvěry. Nejde jen o Superfish (OK, může se stát, i když by nemělo, beru to ale jako nedbalost). Ale plevel v BIOSu mi přijde jako síla a nevím, co všechno ještě mohu od Lenova čekat: http://m.theregister.co.uk/2015/08/12/lenovo_firmware_nasty/
-
Lael Ophir (neregistrovaný)
Bohužel žádný vyhledávač, který by uměl ECC paměti, jsem nenašel. Ale notebooky s CPU Intel Xeon většinou ECC mají, minimálně jako option. Jde o Dell Precision, MSI WT, Lenovo P a HP zBook.
Podle Intelu mají podporu ECC ještě některé nyní prodávané modely Pentií a Celeronů, ale nevím jestli i notebookové verze, a nenašel jsem žádný model.
Update: když na amazon.com půjdete do kategorie laptopů, vyhledáte ECC a zadáte cenu vyšší než $500, tak vypadnou opravdu jen laptopy s ECC. Jsou to ovšem jen ty co uváděl výše.
-
Díky za tipy. Bohužel Xeony nemají integrovanou grafiku, což je docela nevýhoda – jednak kvůli spotřebě a jednak kvůli případnému XenGT (https://wiki.xenproject.org/wiki/XenGT ).
Pentia a Celerony bych dal mimo hru. Ideálně nějakou i7 s podporou všeho potřebného (ECC, VT-x, EPT, VT-d, AES-NI), ale to jsem v posledních svou generacích nenašel: http://ark.intel.com/search/advanced?s=t&FamilyText=6th%20Generation%20Intel%C2%AE%20Core%E2%84%A2%20i7%20Processors&FilterCurrentProducts=true&InstructionSet=64-bit&ECCMemory=true&VTX=true&ExtendedPageTables=true&VTD=true&AESTech=true
-
FíkZlatý podporovatel
no to sice nedokazuje, že k ECC chybám nedochází, ale podle mých zkušeností (ne jen jeden počítač a ne jen 45 dní) je "na 8GB RAM připadá cca 4.6 bitů chyby za hodinu" silně nadhodnoceno o dost hodně řádů - jinak bych ECC chyb už viděl milióny
v jednom případě jich bylo několik za týden, ale to šlo o vadný modul, po výměně už žádná chyba
-
Lael Ophir (neregistrovaný)
Google ve studii použil čísla z velkého počtu strojů za 2.5 roku. Nevím berete v úvahu co jsem psal dříve (malé procento strojů vychytá velké procento chyb), nebo jestli jsou vaše data lepší, nebo jestli máte víc štěstí, nebo jestli se paměti od roku 2009 nějak výrazně zlepšily (při zvyšování hustoty bych to nečekal). Každopádně teď oba víme jak vypadají čísla od Googlu, a také to že vy máte jinou zkušenost. Víc k tomu těžko říct.
-
FíkZlatý podporovatel
Google alespoň ze začátku kupoval velmi levný x86 HW, když ještě bojoval s Altavistou a jejich drahými DEC/Alpha. Navíc ve zprávě jde jen o DDR2, já mám zkušenost s DDR3, i když bych si myslel, že s integrací by se to mělo zhoršovat.
Když by google ty chybující moduly měnil nebo alespoň vyřadil ze statistiky, tak by těch náhodných chyb díky kosmickému záření bylo daleko méně.
Je ale pravda, že ten můj chybující modul procházel bezchybně i velmi dlouhý memtest86+ (několik dní), takže ECC je rozhodně daleko citlivější diagnostika chyb a to ještě za chodu.
-
Lael Ophir (neregistrovaný)
Google kupoval stroje s ECC pamětí, což mi nepřipadá jako nejlevnější z x86 HW. Samozřejmě souhlas v tom, že veškerý x86 HW byl proti DEC/Alpha velmi levný. Rovněž souhlas v tom, že s DDR3 by se dala čekat spíš vyšší chybovost, protože se zvyšuje hustota integrace. Ale ať se chybovost zvýší nebo sníží, těžko čekat, že to bude více než o jeden řád. A to znamená, že spolehlivost pamětí je pořád problém.
Ad ten můj chybující modul procházel bezchybně i velmi dlouhý memtest86+ (několik dní), takže ECC je rozhodně daleko citlivější diagnostika chyb - no právě. Bez ECC byste mě chyby paměti (těžko říct jak často), a hledal byste nejspíš problém v SW. Kdybyste nakonec začal podezřívat HW a sjel memtest, tak byste nic nezjistil. Tady vidím velký přínos ECC.
Ad Když by google ty chybující moduly měnil nebo alespoň vyřadil ze statistiky... - no jo, jenže co z toho plyne pro stroje s ne-ECC pamětí? Tam chybu nezjistíte, a to často ani memtestem (jak zcela správně píšete níže), na který navíc často vůbec nedojde.
Já tu studii interpretuji tak, že u stroje s ne-ECC paměti je výskyt chyb podobný (oprávněná domněnka), cca třetina strojů má do roka minimálně jednu chybu paměti, a nějaké menší procento strojů má velkou spoustu chyb ( i když velkou spoustu... 23000 bitů za rok, to je méně než 3kB). Bohužel se tenhle problém bez ECC špatně zjišťuje. Navíc tu máme row hammer, který umožňuje poškodit obsah sousedních řádků cíleně. Za mě to má implikace pro můj budoucí HW, kde chci ECC, protože se mi pak nemůže stát, že budu mít z paměti kůlničku na dříví a nebudu o tom vědět. A silněji si uvědomuji to jsem věděl už dříve: když se ve větším množství strojů bez ECC pamětí (typicky stovky a tisíce firemních desktopů) najde pár kousků, které se chovají divně, tak za tím dost možná bude paměť.
-
tisnik (neregistrovaný)
Ciste amatersky pohled: nektere patterny memtestu jsou ciste cileny na to, aby detekovaly, zda elektrony tuneluji mezi sousednimi bunkami nebo jestli naboj proste neunika spatnym odizolovanim bunky od substratu. Takze se napriklad vytvori tento patter:
111 101 111
nekolikrat (a to jako hodnekrat :-) se zapisou ty jednicky okolo a potom se testuje, jestli nula uprostred je porad jeste nula. A - ted jen spekulace - mozna to nepocita s tim, ze k normalnim bunkam jeste pridali dalsi bunky pro ECC, ktere ty patterny rozbijou.
-
Lael Ophir (neregistrovaný)
Ad Pokud se obsah RAM poškodí a nebude se nikdy se číst (například se při nejbližší příležitosti přepíše), poznáte to nějak - záleží na systému. Intel Xeon používá memory scrubber. V té studii 3 systémy používaly scrubber, a tři ne (vizte těsně před 2.2). Zajímavé je, že se četnost chyb příliš neliší mezi systémy s memory scrubberem a bez něj.
http://www.intel.com/Assets/PDF/whitepaper/323479.pdfAd jak může něco takového projít Memtestem - záleží jestli Memtest vůbec může takový problém detekovat, a jak často se problém demonstruje. Pokud nějaký systém má řekněme 30kb chyb ročně, tak je klidně možné, že Memtest za dobu běhu testu neodhalí nic. BTW u systému s ECC pamětí určitě nic neodhalí, pokud nedojde k neopravitelné chybě (tedy jestli nemonitoruje i ECC Correctable Errors, o čemž pochybuji).
-
Pokud má 30k chyb ročně, pak při 24/7 má přes 3.4 chyby za hodinu. To by už nástroj jako Memtest86+ mohl zvládnout detekovat. Samozřejmě jsou tu otázky:
* Jak rovnoměrně jsou ty chyby rozloženy? Pokud je RAM celý rok v pohodě a pak projede okolo (s nadsázkou) auto s uranem, které způsobí 30k chyb najednou, bude to zjistitelné hůř. V tom případě by mohla být zase podezřelá korelace paměťových chyb u více strojů (a ostatně by tak silné záření ovlivnilo nejen počítače), ale mohou tu být i méně extrémní situace, které nebudou tak podezřelé z ani jednoho hlediska. Tzn. paměť bude náchylnější na vnější vlivy, a tak třeba několik dní v roce bude vykazovat větší množství chyb. I takovéto věci by ale mohl odhalit systematický výzkum, pokud se na to někdo zaměří.
* Jak dlouho u memtestu uplyne mezi zápisem a čtením? Pokud se hned po zápisu čte a dál se to ignoruje, není tu moc velký prostor pro zachycení takovéto změny. Ano, Memtest86+ zřejmě čte hned (při 2*8GiB mi dovedl najít chyby tak do minuty), ale řekl bych, že autoři tomu budou asi rozumět lépe než já a v nějakém z testů (kterých je tam víc) by se mohlo přečíst vše až po nějaké době. (Klidně se to může dít i v tom prvním, četlo by se třeba dvakrát.)ECC Correctable Errors u Memtest86+ jsou otázkou. Našel jsem o podpoře ECC jen to, že ji Memtest86+ umí detekovat. Jestli umí využít ECC Correctable Errors, to jsem nenašel, ale nemuselo by to být až tak těžké na implementaci.
-
FíkZlatý podporovatel
nějaká stará verze memtest86 uměla ECC vypínat a zapínat, ale nebylo to spolehlivé
nejlepší je ECC vypnout v BIOSu; ten můj problematický modul prošel memtest i s vypnutým ECC v BIOSu
jestli chcete zapsat, pak čekat a až pak číst, tak použijte "bit fade test" v memtestu, pokud si dobře pamatuji tak čekal 90minut, ale snad to jde změnit
-
Vypnutí ECC asi taky nebude úplně ono. Pokud o dobře chápu, tak ECC RAM má typicky 10b na byte, a vypnutím ECC se z nich bude testovat pouze 8b.
Ano, pokud je problém způsobený špatným stíněním pouzdra, projeví se v mnoha buňkách a test nejspíš failne tak jako tak.
Ano, chyba na všech redundantních bitech sama o sobě (bez chyby na zbytku) by měla u vhodných error codes podle teorie způsobit přinejhorším hard ECC failure a ne tiché poškození dat.
Ale pořád je lepší testovat se zapnutým ECC, pokud nástroj umí detekovat i soft ECC failures.
-
FíkZlatý podporovatel
IMHO memtest86 ani memtest86+ neuměl detekovat correctable errors, takže malé chyby by systém sám potichu opravil a test nic neukáže
-
atarist (neregistrovaný)
Kde jsi vzal 4.6 bitu chyby za hodinu? Pisou tam jen, ze okolo 8% masin melo aspon JEDNU chybu za ROK.
Ale jinak pravda - v praxi prakticky nikdy nenastane ta situace, ktera povede ke zminene chybe, protoze i ten utocici kod na desktopech nekdo "vyrusi" (DMA disku, wifi atd.), obejit cache taky neni zrovna typicka vlastnost SW atd. To je asi podobne jako mrskat hlavickou disku takovou frekvenci, ktera povede k rezonanci jeho ploten; asi to teoreticky jde, v praxi to nikdo nevidel.
-
FíkZlatý podporovatel
toto je asi ten správný odhad, na jednom stroji jedna jediná ECC chyba v průměru za 12 let
-
Lael Ophir (neregistrovaný)
První strana, třetí odstavec, třetí řádka: we observe DRAM error rates that are orders of magnitude higher than previously reported, 25,000 to 70,000 errors per billion device hours per Mbit
Horní odhad 70k bits per 1G hours per Mbit, tj. 0.00007 bits per hour per Mbit, a protože v 8GB máme 8*1024*8=65536 Mbitů, tak je to 4.58752 bits per hour per 8GB.
Dolní odhad je pak 1.6384 bits per hour per 8GB.
8.42% DIMMů mělo jednu nebo více chyb za rok. V textu za citací hned následuje 8%, v tabulce 1 najdete těch 8.42% (overall correctable error incidence + overall uncorrectable error incidence). Pokud jde o stroje, tak ty měly zjevně průměrně 4 DIMM moduly, takže 33.49% strojů (overall correctable error incidence + overall uncorrectable error incidence) mělo alespoň jednu chybu za rok.Při brouzdání Facebooku a Youtube uživatel bit-flip error nejspíš ani nepozná, ale osobně bych to viděl jako špatnou zprávu třeba pro in-memory databáze.
Ad v praxi prakticky nikdy nenastane ta situace, ktera povede ke zminene chybe, protoze i ten utocici kod na desktopech nekdo "vyrusi" (DMA disku, wifi atd.), obejit cache taky neni zrovna typicka vlastnost SW atd. - samovolně k chybám způsobeným "mícháním" dat opravdu dojde poměrně vzácně. Ale raw hammering funguje, a to poměrně spolehlivě (BTW na obejití cache existuje instrukce clflush). Nakonec o tom je zprávička, pod kterou diskutujeme.
-
atarist (neregistrovaný)
Ano ja to cet a to je asi prave ten problem zprumerovani :) To taky mohlo vypadat tak, ze ty stroje v pohode bezely, prumerne trikrat do roka se neco nahlasilo (to ale taky muze byt tim, ze obvod pro detekci chyby nestiha atd.) a potom jedna masina silenym zpusobem zhucela s milionem chybnych bitu. Bohuzel jsem tam nenasel vysledky ve chvili, kdy se odstrani spodnich a hornich 5 (10)%.
Ad v praxi....: reagoval jsem na Petra, ktery se zminoval o tom, jak muze verit takovemu HW. Pri bezne cinnosti opravdu nikdo (zadna aplikace) nebude kazdou druhou instrukci flushovat cache, aby se dostal primo na DRAM.
-
Lael Ophir (neregistrovaný)
Tam vidím jako zajímavé 20% of the machines with errors make up more than 90% of all observed errors for that platform, a Figure 2, kde najdete přesně údaje které hledáte.
Ad Pri bezne cinnosti opravdu nikdo (zadna aplikace) nebude kazdou druhou instrukci flushovat cache, aby se dostal primo na DRAM - naprostý souhlas, propsat se do sousedních buněk lze teoreticky i při dostatečně intenzivní běžné práci s daty, ale je to krajně nepravděpodobné. Mě víc děsí, že kdokoliv může dát do Storu "méně běžnou" aplikaci, nebo že by se něco podobného dalo provést v browseru. Vizte implementaci v JavaScriptu.
https://arxiv.org/pdf/1507.06955v1.pdf
