Spectre a Meltdown, bezpečnostní chyby v procesorech

Jann Horn z týmu Project Zero společnosti Google detailně popisuje bezpečnostní chyby v procesorech umožňující číst privilegovanou paměť postranním kanálem. Chyby byly pojmenovány Spectre (pdf) a Meltdown (pdf). Jedná se o zranitelnosti CVE-2017-5753 a CVE-2017-5715 (Spectre) a CVE-2017-5754 (Meltdown). V Xenu je řeší XSA-254. Bezpečnostní chyba Spectre se týká procesorů Intel, AMD i ARM. Chyba Meltdown pouze procesorů Intel.

4.1.2018 00:11 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Jendа]

TL;DRbot: Nechť máme na adrese 0xABCD data, která nesmíme číst.

Spectre: Provedeme

int arr[2] tak, aby mezi prvky ležela hranice cacheline;
int * x = 0xABCD;
int a;
vyhodit arr z cache;
if(nějaká podmínka, která je true, ale branch predictor ji vyhodnotí jako false) {
  return;
}
a = arr[x[0]&1];

Tj. k x[0] program nedošel (kdyby k němu došel, tak by se vyhodila výjimka a dostali bychom přes tlamu), ale procesor již spekulativně nahrál potřebné hodnoty z paměti.

Nyní máme v cache arr[0] pokud je na uvedené adrese sudé číslo a arr[1] pokud je tam liché. Stačí nám k jednomu z nich přistoupit a změřit, jak dlouho to trvalo. Opakujeme i pro ostatní bity.

Meltdown: místo podmínky, kterou neuhádne branch predictor, uděláme nějakou neočekávanou věc, která přehodí běh programu jinam. Například dělení nulou.

[pc2005]

+1 (pro počítadlo kvalitních komentářů bystrousaakova :-P).

[Bystroushaak]

:)

[Petr]

+1 Hezké vysvětlení, díky.

[prqek]

Pěkně vysvětleno, ale pořád mi nejde do hlavy v čem je přesně ten rozdíl mezi Meltdown a Spectre. Podle tohodle popisu mi přijde celkem zanedbatelný - liší se to v tom, čím z branch predictoru udělám hlupáka. Uniká mi ale, jakto, že jednou to může vést až ke čtení paměti jádra (nebo snad dokonce libovolné fyzické adresy?). Vysvětlí mi to, prosím, někdo, pro koho ty pdf nejsou TL;DR? Díky :)

[Jendа]

Dneska jsme to řešili ve škole. Mýlil jsem se a můžu se mýlit dál: Meltdown je čtení z paměti, kterou mám namapovanou, ale nemám k ní read práva (tj. to, co jsem dával za příklad, lhostejno zda dělám nepredikovaný branch nebo něco jiného. Spectre je čtení z paměti cizího procesu: najdu si v nějakém cizím procesu kód, který vypadá podobně jako ten pseudokód, co jsem uváděl, a potom mu podstrčím taková data, aby si ten útok sám způsobil a dívám se, jak dlouho mu to trvalo.

Ke čtení paměti jádra může vést obojí, Meltdown přímo (a dá se tomu bránit tím patchem, který jádro odmapuje), Spectre nepřímo (tím, že v jádře najde vhodnou podmínku a indexování něčeho přijatou hodnotou) a nijak rozumně se mu bránit nedá, jen nastavením kompilátoru by šel zkomplikovat.

[prqek]

To dává smysl. Díky :)

[Jendа]

A TL;DR softwarová oprava: Zařídit, aby program ve svém adresovém prostoru vůbec neměl tajná data (dosud je tam měl, ale nesměl je číst, a zakázání čtení jde právě tímto útokem obejít). To znamená držet dva virtuální adresní prostory, jeden s tajnými daty a jeden bez nich, a při každém vstupu do kernelu (syscall, přerušení) je přepínat. Jenže na starších procesorech vyžaduje přepnutí flushnout TLB (cache, kde se ukládají resolvnutá mapování stránek) a za běhu ho znova naplnit (což vyžaduje pagewalk, což je vlastně průchod B-stromu hlubokého 4, takže to jsou 4 náhodné přístupy do paměti). To znamená značnou degradaci výkonu. Na novějších procesorech mají naštěstí záznamy v TLB informaci ke kterému adresovému prostoru patří a používají se automaticky pouze ty správné, takže není potřeba TLB vyprazdňovat.

[snajpa]

Vyborne jsi to sepsal pro ostatni, diky. Ja napjate cekam, ze co s EL6 based OpenVZ na pristich par desitek dni, nez pri absolutnim nespani budeme moct prejit na vpsAdminOS... Nebo tak neco. A pokukuju jak to natupo vyresit prave jenom tim vylejvanim (protoze CPU feature infrastrukturni kod vubec v kernelu nemame a portovacka by to byla jedno peklo vedle druhyho k doportovani). Ale stejne se mi to jevi jako obrovskej kus prace a porad jsem zvedavej, s cim prijde Red Hat. Podle toho budu panikarit dal.

[Jendа]

Proč si vlastně zase stavíte kontejnery a nepožijete KVM? Chápal jsem to tehdy, ale dneska máme HW virtualizaci s nulovou režií a membaloon (na IRC někdo psal, že mu baloon nefunguje, ale fixnout to asi bude jednodušší než si psát LXC věc).

A co dělá kernel jiného než právě to vylejvání?

[little-drunk-jesus]

Predpokladam ze se nechteji starat o QEMU, ktereje proste velike prolezle bugama(tech CVE tam v loni take nebylo malo) a celkem narocne na udrzbu.

On i ten Amazon chce jet KVM s vlastnim resenim a ne QEMU jestli se nepletu, google ho imho take nepouziva.

KVM je moc fajn ale samo o sobe toho moc neumi(myslim ted kernel cast). QEMU alternativy jako novm a kvmtool by mozna slo pouzit, otazka je co tomu chybi pro nejaky public hosting.

[snajpa]

Jak zase? vpsFree *je* a vzdycky bylo o kontejnerech, my jsme s nima tady prorazeli - snad to nezni moc nafoukane, ale chci v tom spis reflekovat ruzne porodni bolesti jako uctovani pameti, nebo vubec, mit toho na jednom serveru tolik, ze pul milionu context switchu nebylo zadny prekvapeni uz pred lety apod. My jsme s tim zacinali, kdyz si u nas vsichni mysleli, ze budou muset simulovat desky starych x86 pocitacu, aby si mohli pocitace rozdelit na vic kusu. Fast forward do dnesni reality a zase vidime, ze se lidi s kontejnerama nenaucili delat. Napriklad, neexistuje kontejnerizace, co by mela dobre zvladnutou podporu userns, simply proto, ze se vsichni soustredi na klasicke linuxove "user si jde pustit neco sam pro sebe pod svym accountem, tak si dneska misto programu naspousti i par kontejneru". My razime kontejnerizaci na levelu kernelu jako primarni metodu, jak sdilet x86 hardware - ruku na srdce, x86 hardwarovou virtualizaci proste neumi. Umi hardwarove berlicky pro virtualizaci, ne hardwarovou virtualizaci. Prodej nam ve velkym Power 9 za levno a pak se mozna budeme bavit v jinych rozmerech. A to jeste jedine a pouze v pripade, ze vyhodime QEMU, pres to taky nejede vlak. Kdyz uz nekdo potrebuje virtualizovat, mela by to byt last resort zalezitost, co si pusti po tom, co usoudi, ze mu veskery ten overhead (aj s adminskym casem) stoji za to.

[trekker.dk]

ruku na srdce, x86 hardwarovou virtualizaci proste neumi. Umi hardwarove berlicky pro virtualizaci, ne hardwarovou virtualizaci.

A když odhlédneme od ošklivých nálepek, v čem přesně je problém, když platí, že "máme HW virtualizaci s nulovou režií"?

[snajpa]

A mame? Ono se na Linuxu s KVM nevyskakuje kvuli disku do kernelu? Kdyz chce aplikace bezici ve virtualu pod QEMU udelat zapis na LVM, jak to udela celou cestu tak, aby nepotkala hostitelsky kernel, ale bavila se s diskem primo? Sitovani jde vyresit virtualizaci primo v sitovce. Tahle indirekce na indirekci a skakani na skakani dava Linuxu velky prostor zdrzovat. Obzvlast, jakmile toho zacne byt na masine na limitech toho, co stiha. Mit veci schovane pod Intelovskou virtualizaci bude ted znamenat jeste nasobnejsi vylejvani cachi a zdrzovani, nebo se mylim?

[trekker.dk]

Ono se na Linuxu s KVM nevyskakuje kvuli disku do kernelu? Kdyz chce aplikace bezici ve virtualu pod QEMU udelat zapis na LVM, jak to udela celou cestu tak, aby nepotkala hostitelsky kernel, ale bavila se s diskem primo?

To mě nezajímá, ani jedno z toho. Podstané - přinejmenším pro mě - je to, že když jsem to naposledy testoval (rok 2010, kernel 2.6.32), tak jsem se s KVM většinou dostal na stejný výkon, který jsem dostal i na hostitelském stroji. Jediná výjimka byl paralelní sekvenční zápis velkých souborů, což je zátěž, kterou nepovažuju za důležitou (ze zjevných důvodů)

[trekker.dk]

Sitovani jde vyresit virtualizaci primo v sitovce.

Pokud mluvíš o VFIO, tak jo, ale jen do určitého počtu hostů. Třeba u Intel síťovek je to 7 - kromě těch nejnovějších, kde je to 63.

[snajpa]

No (ne ze bych o tom nevedel, ale ja to teda znam pod SR-IOV), ale vidis, jak jsi to sam pekne potvrdil, jak je to omezene, cele. My muzem mit na hostu kontejneru klidne 120, aniz by mel nekdo duvod si stezovat. Absolutne nemyslitelne s "full" virt. Ja to ale opakuju furt a porad dokola a porad se najde nekdo, kdo to nechape - proste s radoby "plnou" virtualizaci na x86 zdaleka nejde dosahnout takove denzity, jako s kontejnery. Tudiz, v mych ocich minimalne, je "full"virt placanim prostredku. Ze to tebe pri 10ti, heck, 40ti virtualech na stroji nezajima, je trochu mimo denni vpsFree realitu

[Stanislav Petr]

SR-IOV ma dalsi spoustu omezeni, napriklad nefunguje s nim live migrace atd... Z tohodle pohledu je zajimavejsi 802.1Qbg - Edge Virtual Bridging (http://www.ieee802.org/1/pages/802.1bg.html).

[trekker.dk]

ale vidis, jak jsi to sam pekne potvrdil, jak je to omezene, cele

No tak jestli ti jde o to něco si potvrzovat tím, že si vybereš, co se ti hodí, tak budiž. Používat takhle virtuální funkce v síťovce vůbec není podmínkou, brige bohatě stačí. Jasně, při některých typech DDoS útoků to nebude fungovat, ale to ty úžasné popelnice, pardon, kontejnery taky ne.

Absolutne nemyslitelne s "full" virt. Ja to ale opakuju furt a porad dokola a porad se najde nekdo, kdo to nechape

Ale doprdele, to nám měl někdo říct včas. Teď máme hromadu "nemyslitelných" snajpa-not-approved "to nejde" serverů.

[Michal Kubeček]

120-127 (přinejmenším Intel, Mellanox a Broadcom), NIC s 63 už jsou spíš ty starší. A údajně už existují i karty, které jich podporují 220.

[snajpa]

Vcera jsem se bavil s par lidma, co jedou KVM/QEMU ve vetsim a dosli jsme k tomu, ze budou muset ponasazovat realnejsi HW virtualizaci, tj. prave poodelovat sitovani a nechat QEMU na procesoru dyl, aby si tam procesy taky mohly neco popocitat a k necemu vubec nejaky cache v procesoru byly. Disky jsme ale nevymysleli, lokalni storage resit moc dobre nejde, leda ze by nekdo hodil na PCIe kartu nejaky vetsi procesor a pustil na nem neco jako LVM/ZFS/.. a mapoval jeho kusy pameti primo guestum. Ono to neni zadne terno kdyz tech virtualek bezi na masine vic a ty v sobe maji jeste hojnost procesu kazda, ktere chteji sem tam nejaky CPU cas. Jeste kdyz Intel v poslednich generacich L3 cache zmensil, misto aby pridal.

[snajpa]

Jedine rozumne reseni na disky, aby nebyla zdrzovacka, je poslat je po low latency siti na nejaky vetsi box, co zas zvladne delat rozumnou agregaci. Ale pak se clovek skoro 100% pripravi o skvelou latenci NVMe ulozist. Cekam netrpelive na PCIe-based storage HW s PCIe po optice v ramci ulicky v datacentru. Ale taky cekam, ze to bude stat raketu, takze je otazka, jestli vlastne ma smysl vubec agregovat NVMe storage pri virtualizaci - v dohledne dobe, rekl bych, moc ne.

[Käyttäjä 11133]

Disky jsme ale nevymysleli, lokalni storage resit moc dobre nejde, leda ze by nekdo hodil na PCIe kartu nejaky vetsi procesor a pustil na nem neco jako LVM/ZFS/.. a mapoval jeho kusy pameti primo guestum.

Nebo si prostě koupit FC HBA?

[snajpa]

Ja FC teda vnimam jako legacy technologii.

[pc2005]

Se vlastně divím, že procesory cache v té spekulativní běhové větvi vůbec plní, že si to neukládají někam bokem. To je dost děsivý, že si procesor jen tak ledabyle načte nějaký data z RAM a pak je možná použije.

Mě to přišlo divný už na 486, kde se načetl obraz BIOSu do cache, vypnuly se mechanismy, co by tu cache flushly a pak se pracovalo v BIOSu v cache (proto může počítač pípat bez vložených RAM modulů).

Škoda že zneviditelnění RAM s SMI/ME kódem nejspíš řeší řadič RAM a ty adresy se už CPU nedostanou. To by bylo mnohem vtipnější.

Jinak mě teda vždycky přišlo, že koexistence kernelspace na stejném HW jako userspace musí nutně dříve nebo později přinést problémy. Lepší by IMO bylo kdyby spolu oba prostory komunikovaly nějakými mailboxy na vlastních výpočetních jednotkách ...

Ale třeba všechno zlé bude pro něco dobré, třeba díky tomu intel zveřejní vnitřní mikroarchitekturu svého x86. Ideálně ve formě HDL . V čem vlastně navrhují v Intelu procesor?

[snajpa]

Ono s vicelayerovym propojenim tranzistoru a jejich mensi velikosti by uz asi bylo mozny odshadowovat spoustu veci, tj. jeste vic bigass cores. Ale zastavi to porad vsechny timing attacky?

[pc2005]

To bylo na ty specializované kernel jádra? Tak minimálně tím, že userspace fyzicky nepojede na prostředcích (fyzicky oddělené třeba jen jednobitovým flagem kernel/user) pro kernelspace se obě jádra zjednoduší a protože taková architektura by byl novej start, tak nebude nutno udržovat zpětnou kompatibilitu s postupně nalepovanými featurami.

Například podpora segmentace je v x86 zbytečná od chvíle do přešel windows na stránkování (a to segmentace uměla i něco jako NX bit). Není potřeba, aby SMI kód měl k dispozici jádro s SSE a myslím, že nyní, kdy jsou v CPU 3 servisní jádra, není SMI mód potřeba vůbec. Všechny 32bit a níž módy jen zatěžujou testovací část vývoje.

[snajpa]

No, jak jsem byl unaveny uz, tak jsem napsal jenom pul myslenky. Myslel jsem, ze by se dalo prave procesory nechat hardwarove jeste vic resit izolaci procesu mezi sebou tak, ze se toho vic odshadowuje. Pravda ze by to timing attacky nevyresilo, ale myslim si, ze pokud se shodneme, ze je spekulativni reordering a exekuce energeticky dobry napad, asi dojdeme k nejakym castem cipu, co budou resit policing, aby kod nemohl zacit delat takove zbesilosti. Tj. jeste ke komplexnejsim raketoplanum.

[pc2005]

No nejsem si plně jist, že by měl být spekulativní reordering nějaká spása. Moje pracovní teorie (?) je že důležitý je mít kvalitní základní architekturu. Cache, reordering a spekulace jsou už jen taková znouzectnost jak z kódu s malou výpočetní a časovou hustotou vymačkat vyšší výkon.

Ale hlavně čím delší je spekulativní větev, tím víc se stav diverguje od té správné větve a tím víc se pak musí zpětně opravovat (a víc trackovat stav před větvením).

[jdsulin2]

Cache, reordering a spekulace jsou 3 veci, proc jsou soucasne procesory tak rychle. Hlavni duvod je samozrejme moznost provest vice intrukci v jednom cyklu. Vykon ale nestoupa, pokud musis cekat na vysledek predchozi operace nebo cekat na zdroje. Co se tyka reorderingu, tak neco za tebe muze udelat kompiler v ramci optimalizace ale branching nezvladne. Co ale docela nechapu je fakt, ze spekulativni provadeni kodu muze pristupovat ke cache libovolne - vzdyt prece vi, ze je v user rezimu a stranka je pristupna jenom pro kernel (nemuze samozrejme vyvolat vyjimku). Kdyz uz v ramci pristupu muze sahnout na cache, dokonce nahrat stranku, tak prece musi vedet, jake opravneni ta stranka ma ne ? A zastavit provadeni kodu. Dokazal bych pochopit, ze overeni muze zpusobit zpomaleni, ale jestli ta spekulace dokaze nacitat do cache, tak to uz samo o sobe je zpomaleni ne ? Resp. co me zajima je fakt, ze navrharum procesoru prijde zpomaleni dane overenim mensi nez samotne nahrani stranky.

[Michal Kubeček]

Dokazal bych pochopit, ze overeni muze zpusobit zpomaleni, ale jestli ta spekulace dokaze nacitat do cache, tak to uz samo o sobe je zpomaleni ne?

Můžete se na to dívat jako na prefetch, tedy mechanismus, kdy se data z pomalého média načítají předem, aniž bychom si byli jisti, že je opravdu budeme potřebovat. To se používá i v mnoha jiných situacích, třeba z disku se běžně přečtou s požadovaným blokem i nějaké za ním, o které si zatím nikdo neřekl, protože je slušná šance, že budou za chvíli potřeba (read-ahead). Podobně webové prohlížeče mívají volitelnou funkci přednačítání odkazů ze stránky, kterou právě čtete. Případně mne napadá geeqie (a nejspíš i další prohlížeče obrázků), který umožňuje načíst z adresáře několik dalších obrázků, aby pak byl přechod při sekvenčním prohlížení rychlejší.

Tady je průšvih v tom, že detekce toho, zda se prefetch provedl nebo ne, vám umožní zjistit hodnotu, ke které byste neměl mít přístup. Navíc nezapomínejte, že samotný prefetch tu není problém, ten "meltdown" útok nestojí na prefetchi dat, ke kterým nemáte přístup, naopak, prefetchují se data, která číst smíte, ale trik je v tom, že v závislosti na hodnotě bitu, který znát nesmíte, se procesor rozhodne, co se bude prefetchovat.

[jdsulin2]

Jasne, ale prece si nemuze spekulativni cast vyzadat v userspace rezimu data z casti do ktere nema pristup a uz vubec ne je pouzit pri nejakem vypoctu, ktery zmeni stav a nedojde k navraceni.

Kdyz to prirovnam ke geeqie, tak je to to stejne, jako kdyby si ten prohlizec obrazku nacetl z textaku hesla vsech uzivatelu, akorat se pak proste nezobrazily. Nebo jako kdyby mi server ve spolupraci s webovym prohlizecem poslal i sifrovanou tabulku users a funkci pro overeni. Abych si pak prihlaseni nemusel overovat na serveru, ale primo u sebe. (To je uz trochu prehnane, ale narazim na to, ze tu tabulku nebo textak muzu z pameti nejak vydolovat - v tomto pripade prefetchem stranky na zaklade hodnoty, kam nesmim).

To ze uz pomoci prefetche zjistim hodnotu je jedna vec, ale to ze s tou hodnotou vubec muzu pracovat je vec druha. Tady je presne ten problem, ktery vidim - kdyz to rozdelime na 2 faze -> ve fazi 1 mi dovoli CPU nacist pamet, ke ktere nesmim a ve fazi 2 me s tim co jsem nacetl jeste umozni provest dalsi vypocet a nacist dalsi pamet a v pripade neuspechu po sobe uklidi (nedostatecne). Ja si myslim, ze at uz je ziskani tech dat jakekoliv (faze 2), nemela by byt moznost se vubec dostat za fazi 1. Jasne pokud najdes jiny side-channel utok na cache, tak se tady bavime o kravinach, v takovem pripade staci pouze precist cache / pamet po nejakem syscallu okolo toho mista. Akorat tohle je bohuzel uz v procesoru.

[pc2005]

Cache, reordering a spekulace jsou 3 veci, proc jsou soucasne procesory tak rychle.

Jo a to je právě to. Základní architektura zamrzla a rychlost výpočtu se honí speciálníma případama, který se daj "komprimovat".

A zastavit provadeni kodu.

Tak pokud je ten nevalidní kód v podmínce, která se nikdy skutečně neprovede, tak by to byla blbost shazovat celej program jen kvůli spekulaci. V té podmínce může klidně být regulérní pointer, ale zrovna v aktuálním běhu se ten pointer ničím nenaplnil a proto je podmínka zablokovaná.

ale jestli ta spekulace dokaze nacitat do cache, tak to uz samo o sobe je zpomaleni ne ?

No právě proto že to je spekulace, tak kdyby se nakonec ukázalo, že se provede, tak ušetříš extrémní množství cyklů tím, že jsi to přednačetl. (však píšu, honění výkonu přes kód, který jde "zkomprimovat" v čase)

co me zajima je fakt, ze navrharum procesoru prijde zpomaleni dane overenim mensi nez samotne nahrani stranky.

No jelikož to postihlo všechny procesory od intel pentia pro, tak bych řekl, že si toho nikdo nevšiml.

[kralyk z abclinuxu]

Jo a to je právě to. Základní architektura zamrzla a rychlost výpočtu se honí speciálníma případama, který se daj "komprimovat".

Líčíš to jako by to byla špatná věc Mně to přijde dobře, protože díky všem těmhle technikám můžeme z fyzicky podobně výkonného CPU vytřískat vyšší výkon, ie. díky tomuto výzkumu značně vzrostla energetická efektivita.

[pc2005]

Jo ale po tom co vymyslíš takovouhle "komprimaci" kódu, tak nakonec stejně skončíš před problémem jak zrychlit celou architekturu. Akorát teďka musíš brát v úvahu tyhle urychlovací přílepky pro speciální případ kódu.

Například předělání procesoru na plně asynchronní design (například pokus ARM AMULET) bude mnohem jednodušší, když to bude obyčejná RISC pipeline, než když tam budou návraty na místo forku, odkud běžela spekulace, která selhala.

A ta elektronika taky stojí routovatelnost. Když vedle pipeline flákneš obvody na tagování spekulace, tak budeš muset vést některé dráty oklikou, což jim zvýší delay. Ona není náhoda, že nejvyšší rychlosti dosáhne v FPGA microblaze, který má, co nejmíň volitelných parametrů (samozřejmě je pak pomalejší, ale taková RAM tam běží tak 8x rychleji - DDR, 64bit a bursty).

No a jak jsem už psal, tak čím víc těchto urychlovacích obvodů pro specifický kód, tak tím větší je šance, že se něco přehlédne.

[jdsulin2]

Spekulace je prave to, proc jsou procesory tak rychle. Predpokladam, ze vis, co je to retezeni instrukci (pipelining). Tak kdybys nedelal spekulativni provadeni jedne vetve, pak kazde zretezeni skonci u skoku a tech je v programu pomerne dost. A protoze se prediktor trefuje vice nez 50%, dochazi k velkemu zrychleni. V pripade, ze bys to zakazal by doslo k nasledujicimu: procesor si jede 4 instrukce za cyklus a najednou bum skok, tak zastavime - vyprazdnime pipeline, skocime - a zase se musime rozjet, naplnit pipeline, vyresit operandy, ktere jsou v pameti, atd.

Cache je zase dobra proto, ze pristup do pameti je pomalejsi nez rychlost procesoru. Resenim by bylo samozrejme udelat takovou pamet, ktera bude mit rychlejsi pristup. Jenze takova pamet je o dost drazsi. Kdyby mel procesor 16 GB L3 cache, tak je hotovo.

Reordering je sice neco, co muze byt vyreseno kompilerem, akorat jednou pro konkretni procesor. Reordering primo na CPU zajisti, ze instrukce se provadeji v optimalnim poradi na kazdem CPU, at uz je kod jakykoliv.

Neni to zadna znouzecnost.

S tou chybou trochu souvisi i ten prefetch - cpu vi, kterou pamet bude potrebovat uz pri dekodovani instrukce, proto zada pozadavek predem k jejimu nacteni do cache. Nebyt tehle veci, tak rychlost nacteni te pameti je pomalejsi nez se dojde k vyhodnoceni toho skoku. Proto utocici program s danou adresou provadi nejaky syscall, aby mel jistotu, ze uz v cache je a nacteni pameti bylo rychle. To ze v tu chvili nezahlasi cpu vyjimku pri cteni userspacu z casti pameti, kam nema pristup, je vec druha (samozrejme nemuze shodit program ve spekulativni vetvi) a to, ze s takovou hodnotou jeste provadi dalsi vypocet je vec treti. Podle me by se prave v tuto chvili mel zastavit, protoze kdyby ta spekulativni vetev byla provedena, pak by se to presne na tomto miste zastavilo. To by melo byt vyreseno a nejspis to jinak nez hardwarove nepujde. A resi to i tu druhou chybu - pri reorderingu proste zastavit retezeni instrukci a reodering, pokud saham na pamet, kterou nemam - i kdyz jsem na ni jeste fyzicky nesahl a jenom zadal pozadavek pro nacteni do cache. Z hlediska vykonu by to nebyl takovy problem, protoze pokud se to na toto misto dostane, stejne dojde k preruseni a zastaveni pipeliningu. Soft reseni by sice stacilo to, ze s nactenou hodnotou se uz nebude provadet dalsi vypocet, ale to nezabranuje jinemu side-channel utoku.

A na zaver trochu mimo - nejlepsi by z hlediska vykonu samozrejme bylo, kdyby se obe vetve podmineho skoku resily zaroven a jedna cast zahodila - proste by mohly mit oddelenou cache, ktera by se v pripade neuspechu smazala. Jenze to by vyzadovalo zduplikovat tolik veci, ze uz je z toho skoro plnohodnotny procesor. Navic pro 1 skok jsou 2 moznosti, pro 3 skoky za sebou uz 8.

[pc2005]

Tak kdybys nedelal spekulativni provadeni jedne vetve, pak kazde zretezeni skonci u skoku a tech je v programu pomerne dost.

Podmíněné skoky ale nepotřebuješ, můžeš udělat podmíněné operace.

Reordering je sice neco, co muze byt vyreseno kompilerem, akorat jednou pro konkretni procesor.

A v případě SMT i v závislosti na kombinaci kódu dvou a více vláken.

Neni to zadna znouzecnost.

Já to chápu, pokud nechci mít počítač na výpočetní úrovni Atomu s vypnutým cache, tak tyhle optimalizační algoritmy potřebuju, ale znouzecnost to je právě proto, že nedokážeme udělat plain pipeline taktovanou třeba na 100GHz, L1 rychlostně ekvivalentní RAM apod. Navíc takhle "komprimovat" běh kódu se nedá do nekonečna a stejně člověk skončí časem na tom, že potřebuje ten 100GHz (už jsem to tu někde +- psal). Mezitím ale v CPU vznikl nemonotónní guláš, kde jedna instrukce s určitými daty ve určitý čas může trvat úplně jinak dlouho než v jiný čas nebo s jinými daty. A celý by se muselo při každý úpravě znova verifikovat. A taky to zhoršuje možnost toho samotnýho zrychlení, protože musíš najednou sesynchronizovat mnohem víc tranzistorů (na ovládání cache, flagy, BTB, reorder, switche na execution (?) sloty, ...). Proto jsem v tom OP napsal, že je lepší mít lepší základ a na něj pak nalepit tyhle gadgety. Než se snažit zrychlovat celej balík s gadgetama.

Podle me by se prave v tuto chvili mel zastavit, protoze kdyby ta spekulativni vetev byla provedena, pak by se to presne na tomto miste zastavilo.

Njn ale podle čeho budeš ověřovat, že je ta adresa zrovna nevalidní. To budeš muset udělat novej hardware do spekulativní větve, kterej bude číst stránkovací údaje a porovnávat zda má oprávnění na požadovaný region ne? Další tranzistory navíc.

nejlepsi by z hlediska vykonu samozrejme bylo, kdyby se obe vetve podmineho skoku resily zaroven a jedna cast zahodila

Jo na to mám návrh na hobby procesor .

Jinak mě to připomíná (nejsem fyzik) kvantový počítač: počítáme s oběma variantama zároveň a na konci se podíváme, která to vlastně byla.

Jenze to by vyzadovalo zduplikovat tolik veci, ze uz je z toho skoro plnohodnotny procesor.

Ovšem obě takový pipeline by nepotřebovaly BTB. A možná by šly i dále zjednodušit, že by třeba nepotřebovaly reorder a tak.

[Michal Kubeček]

Tak kdybys nedelal spekulativni provadeni jedne vetve, pak kazde zretezeni skonci u skoku a tech je v programu pomerne dost.

Podmíněné skoky ale nepotřebuješ, můžeš udělat podmíněné operace.

Není to z hlediska (ne)potřeby spekulativního provádění instrukcí jedno? (Kromě speciálního případu, kdy následující instrukce nemohou záviset na výsledku té podmíněné.)

znouzecnost to je právě proto, že nedokážeme udělat plain pipeline taktovanou třeba na 100GHz, L1 rychlostně ekvivalentní RAM apod. Navíc takhle "komprimovat" běh kódu se nedá do nekonečna a stejně člověk skončí časem na tom, že potřebuje ten 100GHz (už jsem to tu někde +- psal).

Já to vidím trochu jinak. V určitém okamžiku přestane být extenzivní vývoj udržitelný a je potřeba přejít na intenzivní. Dokud byla všude spousta volné půdy, stačilo ke zvýšení produkce zabrat další kus a udělat tam pole; když už bylo všechno rozebrané, nezbylo než zvýšit výtěžnost. K získání nerostných surovin stačilo kdysi "kopnout do země", ale jak se bohatá (a snadno přístupná) ložiska vyčerpávají, potřebujeme stále sofistikovanější metody, jak se k surovinám dostat (a jak je zpracovat, abychom vystačili i např. s chudšími rudami). Výkon aut už se také nezvyšuje tím, že "tam prostě přidáme další (větší) válce". Stejně tak televizní vysílání muselo postupně z neefektivního analogového vysílání přejít na DVB-T/MPEG-2 a DVB-T2/HEVC (tam se dokonce "životní prostor" zmenšil tlakem vnějšího usurpátora).

Nejsem vůbec přesvědčený, že musíme opravdu nevyhnutelně dojít k tomu, že se zase začne dál a dál zvyšovat frekvence. Nejsem si ani jistý, jestli to bez nějaké zásadní (nebo spíš principiální) změny technologie vůbec půjde. V každém případě je ale realita taková, že vývoj se prostě začal ubírat jiným směrem. Nejdřív vyladěním efektivity (to jsou právě ty pipeliny, predikce, spekulativní provádění), ale tam už jsme dost možná také na hraně (teď se možná ukázalo, že někdy i kus za ní). Další krok bylo zvyšování počtu jader. Teď se pro HPC čím dál víc prosazují specializované externí procesory (trochu se zdráhám tomu ještě říkat GPU) a hybridní architektury. Možná máte pravdu a díky nějakému technologickému průlomu se skutečně časem podaří začít zase navyšovat frekvenci. Ale stejně tak je možné, že ten průlom bude spočívat v přechodu na úplně jinou koncepci.

[pc2005]

Není to z hlediska (ne)potřeby spekulativního provádění instrukcí jedno? (Kromě speciálního případu, kdy následující instrukce nemohou záviset na výsledku té podmíněné.)

Při neexistenci podmíněných skoků nemusíš řešit to, že najednou se začnou brát data z jiné části RAM a čas ušetřený při návrhu odkud naplnit pipeline daty po skoku můžeš využít na verifikaci toho zda spekulace nevrací postranní informace. Nemáš tam tu zpětnou vazbu na začátek pipeline. Zpětná vazba se musí správně naroutovat, aby se řídící signály dostaly na obvody včas s hodinama (jde proti proudu toku dat). U podmíněných operacích se normálně provede instrukce v pipeline a s ní jde (po proudu toku dat) informace o tom, že je spekulativní a že závisí na výsledku předchozí instrukce (která už může čekat na konci pipeline).

ad druhá část: Jo ale pokud na tom "poli" pořád orají zabugovaným traktorem z roku 95, tak to zvýšení výtěžnosti bude problém, protože budou muset ten lakatoš (:P) přemontovat, aby jezdil třeba 120km/h.

Tak tranzistory dneska jedou snad i na těch 100GHz. Akorát při takové frekvenci topí tolik, že by se v hustotě integrace moderního CPU roztavily. Pokud by jich bylo rapidně míň, tak by celý čip topil taky míň (a tedy by mohl jet i na 100GHz).

[Michal Kubeček]

Možná si to s něčím pletu, ale IIRC u současných procesorů většina tranzistorů v nich tvoří cache. Je-li to tak, není příliš reálné očekávat významné snížení počtu tranzistorů při zjednodušení logiky.

[pc2005]

Ale cache se nepočítá celá najednou (SRAM = static → nemusí jet na 100GHz) a struktura bez velkých zpětných vazeb (snad jen na úrovni SRAM buňky) je na zrychlení mnohem jednodušší. Takže ano počet tranzistorů se moc nesníží, ale zvýší se možnosti taktování.

[Michal Kubeček]

Takže je to vlastně strašně jednoduché. Jen je mi záhadou, proč to v těch firmách ještě nikoho nenapadlo. :-)

[pc2005]

jsem říkal, že to je jen moje motto (o té kvalitní základní architektuře)

[snajpa]

No, kdyz rikas, ze SRAM nemusi jet na frekvenci jader (nebo blizko) - pak je o tolik zbytecnejsi, kolikrat je pomalejsi oproti jadru, preci, ne? Minimalne instrukcni a datovou L1 asi chces mit na frekvenci jadra, nebo velmi blizko, jinak nedava moc smysl, nebo se mylim?

[snajpa]

Nebo jsi to myslel tak, ze sice teda nevykona dana bunka 100 miliard cyklu, ale treba jenom 1-2-3 miliardy? No ale musi to stihat tak rychle, jako kdyby na tech 100 GHz jela. OK, tak to nebude topit. Ale myslim si, ze pri 100x rychlejsim access time a 100x mensi toleranci k jitteru, narazis jeste vic na data locality problem - SRAM o kousicek fyzicky vedle uz te nemusi trapit, protoze se k ni stejne nestihnes dostat relevantne rychle.

[pc2005]

No myslel jsem to tak, že procesor nepřistupuje ke všem L1 cacheline najednou každej takt 100GHz. Problém s taktováním by byl, kdyby chtěl každej 100GHz takt každej bit invertovat. To je věc co by žrala u CMOS neskutečně (a třeba u FPGA ho tím můžeš i odpálit - když uděláš třeba posuvnej registr ze všech LUT-RAM a FF). Navíc L1 je dost malá, tam těch tranzistorů moc nebude tak jako tak.

O tom o čem se dá (z hlediska počtu tranzistorů) bavit je L2. Ale tam z jedné strany přistupuje k jedné položce jádro (třeba 100GHz, ale zbytek položek L2 spí). A z druhé strany přistupuje řadič RAM (nebo L3), který má třeba jen 10GHz.

[kralyk z abclinuxu]

Podmíněné skoky ale nepotřebuješ, můžeš udělat podmíněné operace.

No je ale použitelné jen pro krátké větve kde se udělá jedna nebo několik málo operací...

Já to chápu, pokud nechci mít počítač na výpočetní úrovni Atomu s vypnutým cache, tak tyhle optimalizační algoritmy potřebuju, ale znouzecnost to je právě proto, že nedokážeme udělat plain pipeline taktovanou třeba na 100GHz, L1 rychlostně ekvivalentní RAM apod.

Fór je v tom, že i kdyby výrobci byli schopní vytvořit takovou pipeline, stejně by nejspíš chtěli mít tam všechny tyhle vylepšováky, protože ten CPU je s nima prostě výrazně rychlejší (což je mimo jiné i konkurenční výhoda atd.).

Njn ale podle čeho budeš ověřovat, že je ta adresa zrovna nevalidní.

Možná by něco nedochází, ale proč by to nešlo stejným mechanismem, jaký se používá v běžném vykonávání? Není to koneckonců to, co dělá do jisté míry AMD?

[pc2005]

No je ale použitelné jen pro krátké větve kde se udělá jedna nebo několik málo operací.

Pro smyčky to je IMO ekvivalentní. U ekvivalentu dlouhého podmíněného skoku asi může být kód podmíněných operací delší, ale je lineární a ani nemusíš hrabat do fronty instrukcí (která je rychlá, protože se ti plní hezky v burstech) a ani do instrukční cache, protože není najednou skok někam do paměti. Jelikož nemusíš napřeskáčku plnit I cacheline, tak na ní ani tolik nečekáš a nemusíš ani tolik dopředu spekulovat.

Fór je v tom, že i kdyby výrobci byli schopní vytvořit takovou pipeline, stejně by nejspíš chtěli mít tam všechny tyhle vylepšováky ...

JO ale to by museli ohýbat ty vylepšováky (upravovat, vymýšlet znova od nuly + s tvorbou nové designové verifikace (!)), aby se na 100GHz naroutovaly se správným dopravním zpožděním. A ne naopak, že by museli ohýbat celou architekturu s i 8086 kompatibilitou včetně vylepšováků z 95 na těch 100GHz.

Možná by něco nedochází, ale proč by to nešlo stejným mechanismem, jaký se používá v běžném vykonávání? Není to koneckonců to, co dělá do jisté míry AMD?

No ten HW v běžném vykonávání je nejspíš zrovna používanej tou nespekulativní větví. Bys musel možná duplikovat. AMD má špatně navrženou spekulativní část taky (spectre funguje, dokáže IMO číst v cizí paměti). V meltdownu má štěstí v tom, že má asi jinak řešená práva pro přístup ke kernel paměti, ale to nebude vlastnost spekulativního běhu, ale nějaké jiné jednotky. To že můžeš ve spekulativní větvi persistentně ovlivňovat stav cache má stejně blbě jako intel. Jenom tu chybu prostě ta architektura zachytí na jiném stupni kontroly. Takže ano jejich řešení je v tuto chvíli bezpečnější, ale určitě bych ho nedal okopírovat intelu, protože obsahuje stejnou fundamentální chybu.

[kralyk z abclinuxu]

Btw.

Jinak mě to připomíná (nejsem fyzik) kvantový počítač: počítáme s oběma variantama zároveň a na konci se podíváme, která to vlastně byla.

XKCD souhlasí

[Michal Kubeček]

lots of servers are vulnerable to regular hammers, too

Tak proto jsou S/390 pořád tak populární… :-)

[pc2005]

Byl babbageův analytický stroj nýtovaný?

[pc2005]

Ale třeba všechno zlé bude pro něco dobré, třeba díky tomu intel zveřejní vnitřní mikroarchitekturu svého x86. Ideálně ve formě HDL .

Protože tenhle bug je něco, co by se mělo testovat u branch prediktoru v prvé řadě. Zda se správně zahazují všechny informace z té špatné větve. Ideálně by jim měl DRC vypsat, že se jim ukládají data někam, kam se podle platných instrukcí ukládat nemají (s tím že ta miss/fail větev jsou nevalidní instrukce).

[jdsulin2]

Ideálně by jim měl DRC vypsat, že se jim ukládají data někam, kam se podle platných instrukcí ukládat nemají

A do ktere cache patri kernel data ? Misto do L1 do KernelL1 ? Samozrejme, ze jsou v te stejne. To uz muzes rovnou oddelit RAM na obyc a KERNEL RAM (a ze to neni uplne spatny napad pro bezpecnost).

Prvni problem je, ze to nacteni vubec umozni a druhy problem je, ze s hodnotou jeste dale pracuje. Sice pak vysledek zahodi, ale neco po sobe zanecha, co na te hodnote zavisi - v tomto pripade stav cache.

[pc2005]

No abych pravdu řekl, tak nevím jak bych to testovací pravidlo napsal, protože nemám podrobné HDL popisy nad kterým bych to simuloval. Asi bych provedl variantu úspěšné větve se segfaultem a neúspěšné větve, kterou spekulace zahodí a nad nějakým stavovým prostorem virtuálního CPU, bych pak udělal diff. Takže teoreticky bych měl být schopnej zjistit, že se mě někde mění řádek cacheline i když vlastně nemá. Ale taky bych to mohl samozřejmě přehlédnout nebo zamítnout s tím, že nějaká změna cache navíc za validní data je zanedbatelná.

Člověk by si ale mohl rýpnout, že když intel žádá vyšší cenu za výrobek, tak má i testy s vyšším pokrytím .

To uz muzes rovnou oddelit RAM na obyc

Však jsem to tady v jiném komentáři u psal.

[Jendа]

To je dost děsivý, že si procesor jen tak ledabyle načte nějaký data z RAM a pak je možná použije.

Já nevím, mně to přijde jako celkem zjevná optimalizace a je to jeden z důvodů, proč mají dneska procesory při stejné frekvenci o řád větší výkon než mělo první Pentium 4.

Mě to přišlo divný už na 486, kde se načetl obraz BIOSu do cache, vypnuly se mechanismy, co by tu cache flushly a pak se pracovalo v BIOSu v cache (proto může počítač pípat bez vložených RAM modulů).

Tomu se dneska říká cache-as-RAM a BIOSy to běžně používají při trainingu paměti. Druhá možnost totiž je napsat kompilátor, který jako RAM používá všechny možné registry (debug registry, SSE a AVX už je dneska klidně několik kB, což stačí), což prý někdo z corebootu udělal, ale prej to nechcete dělat .

[pc2005]

mně to přijde jako celkem zjevná optimalizace a je to jeden z důvodů

To neznamená že to je není děsivý z hlediska paranoidní bezpečnosti. Spousta šifrovacího softwaru si po sobě schválně maže uložená data a v Intel procesoru (AMD tvrdí, že to architektonicky nepodporuje) se jen tak mírnixtírnix načítaj kernel data.

Ten druhej bug, kde se načítaj data mezi userspacem je samozřejmě taky problém.

Tomu se dneska říká cache-as-RAM

Jo, a vypovídá to o tom to, že je ta cache až nějak moc nebezpečně flexibilní.

[R]

Pocitac moze pipat bez RAM preto, ze bootblock BIOSu (kde je aj zakladna inicializacia RAM a pipanie, ked sa nepodari) bezi priamo z ROM (resp. flash). Az po inicializacii RAM sa precita a rozbali hlavna cast BIOSu do RAM. Potom mozes BIOS vybrat z dosky a vobec si to nevsimne :D

Cache sa da pouzit ako RAM. Lenze 486 ma L1 cache tusim 8 KB, tam sa zmesti akurat tak stack. L2 cache na doske vobec nemusi byt.

[pc2005]

Já mám dojem (10 let zpět ale), že CAR inicializace byla v BIOSu mý 486 velmi brzo.

Jinak můj pípající duron podle mě musí mít CAR před inicializací RAM. Protože by si měl najít obsazené sloty (a to byla duální SDR a DDR1 deska) a ze SPD eeprom natáhnout profil. To se bude pouze s pár registrama 32bit x86 dělat blbě.

[j]

Tvle vis co veci se da delat s 8kB? .... nemuzes se na to ovsem divat ocima .NET patlala. I jen smesny 2kB stacej na hromadu veci.

[R]

Viem. Nemozes do nich rozbalit BIOS, ktory je aj v zabalenom stave vacsi.

[pc2005]

Ale většina BIOSu jsou různé moduly (int 13h, vbios, eth bios) a třeba TUI kód. Ty před inicializací RAM stejně nepotřebuješ.

[Kvakor]

Navíc FLASH paměť je na základních deskách připojená přes SPI a z toho se stejně nedá kód spouštět přímo, musí se prvně nekam načíst.

Jinak to vyndavání jde použít k tzv. hot-flashování BIOSu, pokud je v dispozici deska se stejným typem FLASH paměti jako ta zcihlená (nejlepěší je mít dvě stejné desky) a samotná paměť je sokcetovaná (jde to i bez toho, ale to už je pomalu lepší si ubastli vlastní SPI programátor). Osobně jsem to použil jen jednou v životě a byl to docela adrenalinový zážitek

PS: Některé ARMy tohle řeší tak, že na procesoru je malinká dedikovaná paměť (v řádech desítek KB), kterou se v normálním provozu používají různá zařízení jako buffery a podobně, a do té se načte uživatelský bootloader (ROM bootloader je natvrdo v ROM jako součást procesoru), který nastaví časování řadiče paměti a načte do RAM bootloader druhé úrovně (typicku U-Boot).

[little.owl]

Navíc FLASH paměť je na základních deskách připojená přes SPI a z toho se stejně nedá kód spouštět přímo, musí se prvně nekam načíst.

Ne, Execute-In-Place je casto podporovan na SPI FLASH pametech, pokud mate QSPI, bottleneck je spise rychlost pameti.

[pc2005]

Moje flash je přes LPC, ten je přímo adresovanej. Myslím, že SPI se dá přímo adresovat taky. Proto jsou limity na 16MiB čip, protože se posílá 24bit slovo. Myslím, že čipset v mým ADSL modemu to umí (samozřejmě to pak bude pekelně pomalý).

SPI flash se už ani socketovat nemusí, stačí kolíček.

[Peter Fodrek]

Jinak mě teda vždycky přišlo, že koexistence kernelspace na stejném HW jako userspace musí nutně dříve nebo později přinést problémy. Lepší by IMO bylo kdyby spolu oba prostory komunikovaly nějakými mailboxy na vlastních výpočetních jednotkách ...

Preco mi toto Vase riesnie primoneulo jadro M3 ako alternatiovu k L4 v TU Dresden OS

viac v clanku

M3: A Hardware/Operating-System Co-Design to Tame Heterogeneous Manycores Nils Asmussen

Marcus Volp

Benedikt Nothen

Hermann Hartig

Gerhard Fettweis

Technische Universitat Dresden Nothnitzer Straße 46, 01187 Dresden, Germany {nils.asmussen,marcus.voelp,benedikt.noethen,hermann.haertig,gerhard.fettweis}@tu-dresden.de

https://os.inf.tu-dresden.de/papers_ps/asmussen-m3-asplos16.pdf

[Conscript89]

Nestaci jednoduse rict mikrokernel?

[pc2005]

Tak ono se k tomu lehko dostane úvahou, že userspace nemá, co lízt do oblastí správy systému (registry, stránkování, virtualizace, pameť kernelu), což implikuje to, že by ani nemuselo být na stejným HW.

[pc2005]

[joke] Já bych to nazval McFly attack. Protože se to chová podobně jako když se Márty z Návratu do budoucnosti snaží dát své rodiče dohromady (po tom co tomu zabránil) ještě před tím než ho to smaže z existence . [/joke]

[Jendа]

Ještě poznámky:

• Útok byl popsán v nějakém blogpostu již v létě, jenom nikoho okamžitě nenapadlo to dotáhnout do konce a exploitnout (jsou tam různé problémy, jako že ty věci, které nakonec selžou (podmínka u spectre, dělení nulou u meltdownu), musí trvat dostatečně dlouho na to, aby se stihla provést ta dereference adresy s tajným obsahem, ale současně musí být dostatečně krátké, protože spekulativní engine kouká jenom kousek dopředu - a to se ještě mění podle mikroarchitektury a verze procesoru (notebookové verze mají tady ty věci osekané, protože to žere energii))
• Když si přečtete specifikaci formálně verifikovaných systémů, například seL4, tak tam explicitně píšou, že nepokrývají cache timing attacks (primárně proto, že moderní procesory nemají tyto údaje zveřejněné, takže je prostě nevíte).
• Útok lze v podstatě stejným způsobem (+ samozřejmě opruz že na ty pointry nemůžete sahat přímo) provést i z interpretovaných jazyků jako třeba JavaScript (tipuji že s takovým web assembly to bude jednodušší), takže očekávejte webovou stránku, která vám ukradne šifrovací klíče, a to prosím i když browser máte puštěný ve virtuálu (z toho paperu jsem nepochopil, jak to dělají, protože jsem myslel, že nested page tables nemají namapované ostatní virtuály/host OS, ale tvrdí, že to jde).

[Jindřich Makovička]

U Androida tenhle problém Google zazáplatoval znepřístupněním přesného časovače v API. V případě Javascriptu to taky bude nejspíš nejednodušší řešení.

[marbu]

Více viz: Google’s Mitigations Against CPU Speculative Execution Attack Methods:

On the Android platform, exploitation has been shown to be difficult and limited on the majority of Android devices.

The Android 2018-01-05 Security Patch Level (SPL) includes mitigations reducing access to high precision timers that limit attacks on all known variants on ARM processors. These changes were released to Android partners in December 2017.

Future Android security updates will include additional mitigations. These changes are part of upstream Linux.

[kralyk z abclinuxu]

Jak přesný časovač je potřeba (cca, řádově) na meření cache hit / cache miss?

[kralyk z abclinuxu]

Tak to vypadá, že Mozilla se chystá snížit přesnost timerů , např. přesnost window.performance.now() by měla být snížena na 20µs. Čekal jsem, že bude potřeba víc.

[kralyk z abclinuxu]

btw. ten paper, co tam odkazují, je moc zajímavej, mimo jiné je tam např. pěkně ukázáno, že prosté zaokrouhlení timestampu reálně z hlediska bezpečnosti jeho přesnost vůbec neomezuje.

[pc2005]

Divný nějak mě nedocvakává jak měření času souvisí s meltdownem. Tam to snad není potřeba ne?

Nestačí měřit čas v instrukční smyčce?

[jdsulin2]

Z toho zjednoduseho prikladu: potrebujes zjistit, zda arr[0] nebo arr[1] jsou v cache - nacetl je tam spekulativni vypocet. A to zjistit tak, ze na danou adresu pristoupis a vypocitas jak dlouho ti to trvalo.

[pc2005]

Jo dík za opravu, měl jsem zkrat . Já jsem si to pak uvědomil v jiném komentáři.

[jdsulin2]

Nepotrebujes casovac, staci ti ve vedlejsim vlaknu pocitat smycku - napr inkrementaci hodnoty od nuly. A podle vysledku zjistis, zda to byl cache hit nebo cache miss. Reseni zasadni chyby, ze precist data z cache muzes ve spekulativnim rezimu bez overeni prav nespociva v timeru. Akorat si myslim, ze rozumne softwarove reseni neexistuje, proto to lidem, kteri jsou mnohem chytrejsi nez ja trva pul roku a stejne na nic neprisli. Chapu, ze v JS nebo v user rezimu na androidu nikdo nejspis tak presny casovac nepotrebuje, ale co kdyby - problem to nevyresi a nekomu muze uskodit.

[kralyk z abclinuxu]

Nepotrebujes casovac, staci ti ve vedlejsim vlaknu pocitat smycku - napr inkrementaci hodnoty od nuly.

Ano, ale na to zase potřebuješ rychlou komunikaci mezi vlákny, proto chtějí dočasně odebrat ten SharedArrayBuffer.

Samozřejmě, že obojí je workaround a není to řešení problému jako takového, ale jak sám říkáš, problém jako takový se řeší softwarově blbě, proto celkem dává smysl tyhle workaroundy použít, navíc vzhledem k tomu, že oboje API nejsou na webu na běžné věci používané.

[jdsulin2]

Ano, ale na to zase potřebuješ rychlou komunikaci mezi vlákny, proto chtějí dočasně odebrat ten SharedArrayBuffer.

Presne tak ... problem toho, ze soused muze osposlouchavat vyresime tak, ze mu rozbijeme hodinky.

[kralyk z abclinuxu]

Čemu přesně nerozumíš na slovíčku "workaround"?

[jdsulin2]

:D :D

[jdsulin2]

Spatne jsem to ale napsal - vyresime to tak, ze rozbijeme hodinky VSEM

[pc2005]

+1

Útok byl popsán v nějakém blogpostu

Jo tenhle jsem četl včera jako první. Docela ironie jestli ho nenapadlo dát tu segfaultující instrukci do té spekulativní větve nebo udělat segfault handler (ten snad dokonce vrátí hodnotu toho registru ).

že moderní procesory nemají tyto údaje zveřejněné

Zlatý architektury, který maj veřejně známý HDL.

třeba JavaScript

FFFFFUUUUU ... To abych si koupil Ryzen :-/

protože jsem myslel, že nested page tables nemají namapované ostatní virtuály/host OS, ale tvrdí, že to jde

No já jsem si taky myslel, že je virtuální paměť v linuxu řešená nějak líp a ne že je pro všechny namapovanej celej prostor a rozlišuje se jen podle práv kódu (ring 0/3). Třeba to maj pro zrychlení podobně (ale VM jsem zatím nezkoumal).

[j]

Coz je jen dalsi (v tomhle pripade metrakovy) zavazi na tu stranu vahy ktera rika, ze js ma bejt v browseru vypnutej.

[xm]

Hezký: Using #Meltdown to steal passwords in real time

Všechny demo kódy (včetně tohoto) budou zveřejněny nejspíš během příštího týdne

[BigBoss]

Mohli byste poradit, co by mel clovek udelat, kdyz tu zaplatu snizujici vykon nebude chtit nainstalovat?

Ta oprava bude jen na urovni OS, nebo take BIOSu? Bude naprikad stacit, kdyz si nenainstaluju novou verzi biosu?

Dik!!!

[MadCatX]

Na Linuxu můžeš startovat s jaderným parametrem nopti, který tu ochranu proti Meltdownu vyřadí. Opravovat to na úrovni BIOSu nelze, protože mapování paměti řeší OS. Zatím jsem to nestihl celé přečíst ale minimálně Meltdown vypadá dost zle na to, abych si dovolil PTI vypnout.

[j]

Na urovni biosu muzes zmenit mikrokod procesoru. Ale pravdepodobnost, ze pro libovolnou vic nez mesic starou desku bios vyjde je exaktni nula.

[Michal Kubeček]

1. Exaktní nula samozřejmě ne, třeba na ten ME/AMT problém updaty postupně vycházejí.

2. Update mikrokódu není potřeba dělat v BIOSu, to umí i Linux.

3. Podstatný průšvih je ale v tom, že "meltdown" updatem mikrokódu řešit nepůjde. A podle toho, jak se to Intel snaží bagatelizovat a tvářit se, že to takhle vlastně z principu fungovat musí (i když nemusí), mám podezření, že i na opravu v nových modelech procesorů si nějaký pátek počkáme.

[Kate]

3) Tak ona to dost možná podle popisu chyby nebude úplně primitivní oprava, kterou vyřeší revize čipu :/

[little.owl]

Revize cipu to vyresit muze, jenze takove zmeny zaberou mesice.

[Kate]

A to už se to pak vyplatí nacpat rovnou do další řady, ne? :)

[little.owl]

To zalezi v jakem stadiu rozpracovanosti maji nastupce soucasnych procesoru. Dost dobre se muze stat ze zpozdi vyvoj, opravi stavajici radu a prodaji ji jako next generation.

[pc2005]

No jestli zapomínají po sobě vymazat cache, tak budou muset například přidat nějakej trackovací bit, co rozhodne, že takhle cacheline patří ke spekulativnímu vláknu. Nebo třeba celou spekulativní cacheline.

Ideální by bylo kdyby nějak rozšířili TLB, že by každej ring měl svojí. Nebo že by každej proces měl svojí TLB (mám dojem že nějaký nbit pole na PID v TLB má i softcore microblaze ).

Všechno znamená vymyslet/upravit novou verzi architektury. A čip se vyrábí několik týdnů až měsíců.

[jdsulin2]

Podle me by hlavne cacheline nemel vubec naplnit, pokud k ni nema pristup a spekulativni vypocet ukoncit (signalizaci vyjimky, ktera se pri skutecnem provedeni vyvola , ne podle nej dal pocitat a prefetchovat pamet.

[pc2005]

Hmm pro kernel adresu asi jo. Ale pro nevalidní userspace adresu se naopak spekulace hodí. Například proto, že se pak zavolá swap.

Ale jak jsem psal už včera, tak nejlepší by bylo, kdyby paměť pro ring 3 a ring 0 byla na daném jádře tomu druhému nepřístupná.

[little.owl]

Tim byste dosti komplikovat cachovaci algoritmus a rozbil jeho asynchronni/prediktivni pristup nekterych radicu. Staci checkovat prava pred ctenim, ne potom.

[Michal Kubeček]

Jak už jsem vás upozorňoval před chvílí, tady nejde o cache prefetch dat, která nesmíte číst, ale přesně naopak: vy potřebujete cache prefetch něčeho, co číst smíte, jen se podle dat, která číst nesmíte, rozhodne, která cacheline se prefetchne.

[jdsulin2]

Jasne, ale ty data, ktere cist smis se nactou podle dat, ktere cist nesmis. Asi jsem to spatne pojmenoval. Vlastne nejde o to, jestli ty zakazane data v cachi jsou nebo ne (jestli jsou, tak je to pro utok vyhoda), ale o to, ze se nactou a pak pouziji pro dalsi vypocet. V momente kdy prijde instrukce mov rax, [tady_nemuzu] to uz musi skoncit a to bud na tom, ze ta instrukce pri zpracovani pri dekodovani zjisti, ze pozaduje adresu na kterou nesmi - to zabrani i jinemu side channel-utoku, ale to by nejspis prineslo zpomaleni, protoze takto nechame overeni pameti na pozdeji nebo na tom, ze tuto adresu skutecne do registru presune pri provedeni instrukce. Vysledek se sice zahodi, ale zustane po nem informace a to takova, ze nejake dalsi data, ktery byly predtim z cache vyhozeny tam ted jsou.

[jdsulin2]

Jeste to trochu rozpitvam na tom mov rax,[tady_nesmim] zpracovani:

1) fetch - tady nic zajimaveho 2) decode - taky nic zajimaveho, ale uz teoreticky vim, ze budeme cist z pameti 3) read EA - tady si myslim, ze uz mel dostat pres prsty, at uz je v sebespekulativnejsi vetvi nebo sebevic out-of-order 4) execute - tady by podle me nemel vubec dojit uz po predchozi casti, ale jestli dojde, tak by to v zadnem pripade nemel provest a vyvolat vyjimku -> nejakou interni, ktera zastavi provadeni spekulace, ale ne program.

[Michal Kubeček]

S tím samozřejmě souhlasím, to je to, co tvrdím od začátku: na prefetchi dat z paměti do cache jako takovém není nic špatného, problém je v tom, že se při spekulativním provádění nekontrolují (vždy) oprávnění, protože si někdo neuvědomil, že i spekulativní provedení následující instrukce, které se potom zahodí, může mít měřitelný efekt.

Mimochodem, chvíli mi vrtalo hlavou, proč do toho pletete zápis do paměti, než mi došlo, že pořád existují lidé, kteří používají assembler s intelí mnemonikou (a obráceným pořadím argumentů). :-)

[little.owl]

že se při spekulativním provádění nekontrolují (vždy) oprávnění, protože si někdo neuvědomil, že i spekulativní provedení následující instrukce, které se potom zahodí, může mít měřitelný efekt.

Oni se kontroluji, jak u Intelu, tak AMD. Rozdil je IMHO v tom ze Intel napred cte a pak testuje, a AMD napred testuje a pak cte - coz je korektni pristup.

[kralyk z abclinuxu]

+1 ... na druhou stranu Intelí syntaxe má imho hezčí to indexování ... ideálně bych bral AT&T syntaxi s Intelím indexováním, ale to asi není úplně realistický...

[pc2005]

BTW podle čeho bys vyhodnocoval, zda z té paměti můžeš číst nebo ne?

[Michal Kubeček]

Ano, podle mne ten zásadní problém je, že si někdo zjednodušil práci (nebo ji spíš chtěl zjednodušit procesoru) a při spekulativním provádění se rozhodl neprovádět test oprávnění s tím, že pokud selže, přijde se na to včas, až se "pojede naostro". A neuvědomil si, že ta data se mohou dostat do nějakého postranního kanálu.

Na druhou stranu, podle dostupných informací se to týká i (některých) 20 let starých procesorů, takže ten problém podle všeho vznikl v době, kdy nějaké postranní kanály byly spíš teoretickou hračkou potrhlých vědátorů (ono třeba ani SSL nebylo zrovna denní chleba).

[Michal Kubeček]

To je IMHO hodně pravděpodobné, ale protože neznám detaily té implementace, odvolával jsem se na nepřímé indikátory.

Osobně bych se vůbec nedivil, kdyby ještě nějakou ne úplně krátkou dobu vydávali i nové modely, kde to opravené nebude.

[pc2005]

Zalít do betonu a odpojit od sítě .

Nespouštět žádné programy, které nebyly auditovány tvou důvěryhodnou autoritou (= průzkum zdrojového kódu). Nespouštět javaskript (ted prohlížeč a nejspíš ani žádný jiný neznámý interpretovaný jazyk).

Na AMD bude snad ta zpomalující záplata defaultně vypnutá. Aspoň v prosinci poslal zaměstnanec AMD patch s tím, že není potřeba.

Zatím jsem nepřečetl popis Spectre, ale tam by prej měly být rizikové skoro všechny výkonější (= out of order) procesory. Tam je riziko přenosu informace mezi uživatelskými procesy.

[roumen]

Na AMD bude snad ta zpomalující záplata defaultně vypnutá

Patch uz je v git masteri Linuse, konkrentne tenhle: "x86/cpu, x86/pti: Do not enable PTI on AMD processors"

[Jendа]

Vypneš v konfiguraci jádra PTI. nopti kernel parametr má co jsem četl taky nějakou režii, i když mnohem menší.

[pc2005]

Škoda že v té spekulativní větvi nejdou provádět i privilegované instrukce .

BTW Anketa: myslíte si, že tenhle útok NSA zná? A jak dlouho?

[Pali]

Nestačilo by použiť tento starší prvoaprílový patch a deaktivovať ním implementovaný "turbo mode"? https://lwn.net/Articles/682223/

deaktivácia "turbo mode" v tom patchi zapína 30. bit (cache disable) v CR0 registri. https://en.wikipedia.org/wiki/Control_register#CR0

[snajpa]

Nevypada, ze by se dalo caching zakazat.. https://software.intel.com/en-us/forums/software-tuning-performance-optimization-platform-monitoring/topic/278571

[pc2005]

Jo poslední funkční procesor bylo pentium 1, takže oprava spočívá v rollbacku tamtéž .

Škoda že asi nepůjde vypnout reordering, to by se hnedka rozdíl mezi OOO a IO snížil.

[marbu]

Píšou že to nepostihuje Itanium a staré Atomy (což mě nepřekvapuje vzhledem k tomu, že tyto vůbec instruction reordering nebo speculative execution neměly):

every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013).

Měl bych vyhrabat svůj netbook z roku 2012 a ověřit to :)

[pc2005]

Mě ten příklad z blogu na procesoru z roku ~2006 funguje/matchne string (ale jen když běží zkompilovanej na 32bit).

[little.owl]

Zda se ze AMD z toho vybuslilo dobre, viz zde. Prvni variantu jsou schopni vyresit pres SW/microcode update, druha je nepravdepodobna a nepodarilo se ji zatim demonstrovat a treti - Meltdown - se jejich procesoru netyka.

Skutecny prusvih je prave Meltdown, viz treba zde a Intel evidentne nema zadne rozumne reseni.

Nastesti vsechny me PC a laptopy jsou postavene na AMD ... .

[MadCatX]

Já bych zatím nebyl až tak optimistický. V kapitole 6.4 článku k Meltdownu se píše, že na AMD i ARM čipech nejprimitivnější příklad principu útoku funguje také, zatímco výrok zaměstnance AMD tvrdí, že by fungovat neměl. Dál se mi zdá, že hlavní problém Meltdownu - pomalejší volání syscallů - může být důsledkem implementace PTI/KAISERu v jádře, kterým tohle scheisse potírají. Asi těžko soudit, dokud nebudou k dispozici pořádné benchmarky na různých OS.

[little.owl]

V kapitole 6.4 článku k Meltdownu se píše, že na AMD i ARM čipech nejprimitivnější příklad principu útoku funguje také

Ne, nepise. Z clanku 6.4:

We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD.

Pouze pisi:

However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

To ze dochazi k out-of-order execution neni problem pokud interni security check zabrani externe pozorovatelnym zmenam.

[kralyk z abclinuxu]

Podle blogu Project zero na AMD funguje "Varianta 1":

A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.

ie. to, co popisuje Jenda v 1. komentáři. Paměť kernelu se tedy na AMD zřejmě atakovat nedá, ale ta Varianta 1 mi sama o sobě přijde jako dostatečný průser. AMD k tomu píše, že:

Variant One - Bounds Check Bypass - Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected.

... o čemž úplně nevim, co si mám myslet, když nejsou k dispozici detaily.

[little.owl]

... o čemž úplně nevim, co si mám myslet, když nejsou k dispozici detaily.

IMHO je to opravitelne updatem microcodu - coz neni velka tragedie - v podstate se tak deje porad.

[little.owl]

Paměť kernelu se tedy na AMD zřejmě atakovat nedá, ale ta Varianta 1 mi sama o sobě přijde jako dostatečný průser.

Hlavne, vse je limitovano na stejny proces, nikoliv ze muzete cist vsechno jako u Meltdown.

[kralyk z abclinuxu]

Hlavne, vse je limitovano na stejny proces, nikoliv ze muzete cist vsechno jako u Meltdown.

Ano, ale to je stále problém, viz paper:

As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs.

V Chromu JS zřejmě běží v render procesu. Nedaří se mi dohledat, k čemu všmu má tenhle proces přístup, ale IMHO minimálně k historii přístup mít bude. A jestli i třeba věci jako cookies, tak by to mohl být problém.

[little.owl]

Tak ja nerikam, ze to ted neni problem, ale jsou tam rozumne cesty k reseni: (a) update microcode, (b) modifikace SW - u Chrome treba JITu a (c) modifikace kompilatoru, IMHO pro clang jiz k dispozici. Inteli Meltdown je uplne jina kategorie a uz jsem slysel hlasy lidi - OK, od ARM v Cambridge - ze navrzene PTI nemusi byt definitivni uzavreni moznych rizik a jedina cesta je opravit HW.

[kralyk z abclinuxu]

Tak jasně, že u toho Intelu to je mnohem horší. Předpokládám, že v AMD už několik dní bouchají šampáňa. Nicméně to neznamená, že AMD nemá problém, ten side channel tam prostě je taky.

[pc2005]

Fakt? To se mě nezdá. Na jedný stránce bylo napsaný, že stránkování má definovanou celou RAM a jen privilegiem kernel/userspace zamezuje userspace, aby lezl do kernelu. Tenhle bug to obchází a na AMD to řeší jinak, takže se přes tenhle bug nedá referencovat kernelspace ani ve spekulaci. Ale že mezi procesy v userspace by to šlo.

[MadCatX]

No AMD říká, že:

The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

ale Meltdown článek tvrdí, že provádění té spekulativní větve běží dále i na AMD, i když se v ní vyskytne operace čtení z neplatné adresy. To IMHO mohli zjistit jen cache-timingem, takže stav CPU cache se i tam nějakým způsobem změní. Je samozřejmě otázka, co je výsledkem té nepovolené čtecí operace. Aspoň teda tak jsem to z toho článku pochopil...

[little.owl]

To ze se neco stane v cache nevadi, pokud se pred jejim ctenim checkuje privilege bit a to se zde byt hlavnim rozdilem mezi Intel and AMD.

[MadCatX]

Privilege bit by se měl IMHO kontrolovat už v té spekulované větvi a zastavit ji, když nesedí a to se - aspoň dle textu článku - na AMDčkách neděje. Ono k tomu page faultu nakonec dojde i na Intelech ale to už se dá z cache vyčíst a uniklá hodnota.

[little.owl]

Nevim kam mirite. Problem neni spekulativni exekuce cehohokoliv, pokud vysledne side-effecty nejsou potom volne pristupne.

[pc2005]

To není přesně pravda. Tím že víš, kdy vypadne nějaká cacheline můžeš udělat sidechannel mezi dvěma oddělenými procesy (a protunelovat kontejnery).

[little.owl]

Porad nemuzete prekonat checkovani pristupovych prav a cache coherency algoritmus, ktery obsah cacheline automaticky prepise.

[pc2005]

Nemyslím tím, že se přímo přečte cizí paměť, o tom spectre ani meltdown není. Jde o to že těmi postranními kanály může uniknot dost informací, ze kterých se to dá zrekonstruovat.

Tím že budeš měřit kolik cache miss nastalo za určit čas můžeš zjistit třeba kolik znaků má cizí heslo (driver klávesnice bude posílat data a volat různý funkce).

Tipuju že to spekulativní čtení nechává koherenci cache na pokoji.

[little.owl]

Nemyslím tím, že se přímo přečte cizí paměť, o tom spectre ani meltdown není.

Meltdown o tom je.

Tím že budeš měřit kolik cache miss nastalo za určit čas můžeš zjistit třeba kolik znaků má cizí heslo (driver klávesnice bude posílat data a volat různý funkce).

Velmi tezko. Navic pro mereni cache miss a podobnych veci uz mame HW support jako ruzene performance countery a ja pevne doufam ze nikoho nenapadne ve svetle soucasnych udalosti tyto nastroje odebirat.

[pc2005]

Ale meltdown je přesně o tom, že měříš jak dlouho trvá načtení toho tvého pole "0" a "1" (viz Jendův post) do cache. Ten únik dat není přes to, že si procesor přečte nějakou cizí paměť, to dělá každou chvíli. Ten je o tom, že porovnáváš čas, za který dostaneš položku 0 s časem, za který dostaneš položku 1.

Kdyby měla ta spekulativní větev vlastní dočasnou cacheline, která by se při miss prostě vygumovala. Tak by nejspíš problém nebyl a bylo by jedno, co do ní načítá, protože při tom kernel čtení a hitu by to vlákno stejně spadlo.

V meltdown paperu je odkaz na cache timing útoky (sekce 2.3).

[MadCatX]

Nemyslím tím, že se přímo přečte cizí paměť, o tom spectre ani meltdown není.

Meltdown o tom je.

Meltdown i Spectre útoky čtou cizí paměť specifickým způsobem. Vtip je v tom, že hodnota, která z cizí paměti unikla se získá cache-timing útokem na oblast paměti, která patří útočícímu procesu, takže k žádné výjimce nedojde.

Tím že budeš měřit kolik cache miss nastalo za určit čas můžeš zjistit třeba kolik znaků má cizí heslo (driver klávesnice bude posílat data a volat různý funkce).

Velmi tezko. Navic pro mereni cache miss a podobnych veci uz mame HW support jako ruzene performance countery a ja pevne doufam ze nikoho nenapadne ve svetle soucasnych udalosti tyto nastroje odebirat.

Cache-timing je základní pilíř Meltdownu i většiny Spectre variant a aspoň s Meltdownem jim fungoval s chybovostí cca 0.03 %. Na zjištění doby přístupu používají TSC. Přiznej se, že's ten článek pořádně nečetl?

[little.owl]

Meltdown i Spectre útoky čtou cizí paměť specifickým způsobem.

To bezesporu. Pointa je v tom ze u Meltdown jde o cteni cizi pameti.

Přiznej se, že's ten článek pořádně nečetl?

V podstate jsem se k tomu v detailech jeste nedostal, presto ze se tady vykecavam, jsem na to nemel cas, az o vikendu. Pochybnosti jsem mel spise k uhadnuti poctu znaku pres cache miss, zejmena s ohledem na to jak funguji drivery [USB] klavesnice USB.

[jdsulin2]

U meltdown jde o cteni pameti kernelu, ktery je namapovany do pameti kazdeho procesu - z duvodu prepinani mezi user a kernel modem. Reseni by samorejme bylo tu pamet rozdelit a prepinat pri prepnuti rezimu (syscall). Jenomze to nejakou dobu trva. A kdyz ti procesor garantuje (spis garantoval), ze v user space tu kernel adresu proces nikdy nemuze precist, nemas duvod to jadro nenamapovat.

[pc2005]

No já si taky přečetl jen meltdown a začátek spectre paperu a ten google blog jsem skončil někde úplně na začátku.

Pochybnosti jsem mel spise k uhadnuti poctu znaku pres cache miss

Nevím no, ale v odkazovaných článcích u meltdownu je článek o tom jak cache timing použít k hádání RSA.

[little.owl]

Cache-timing je základní pilíř Meltdownu i většiny Spectre variant a aspoň s Meltdownem jim fungoval s chybovostí cca 0.03 %. Na zjištění doby přístupu používají TSC.

Kdyz na tim uvazuji, ano, precizni cache timing je podstatny k male chybovosti, nebot muzete detekovat zdali data v cache jsou ci ne. Nicmene si myslim, ze nepresny timing lze nahradit vhodnou statistikou, i za cenu mensi rychlosti cteni nez 500kB.

[Rezza]

Ale zaroven pisou - "First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage.". Cekam, ze si s tim ted lidi budou dost hrat a treba se slavy docka i AMD a ARM. Nebo ne. Ale na 100% bych to netvrdil a pokud bych byl paranoik, tak i na ostatnich cpu bych si KPTI nechal :D.

[pc2005]

The Pentium Pro is a sixth-generation x86 microprocessor developed and manufactured by Intel introduced in November 1, 1995

[joke] Člověk by řekl, že se na nový rok něco rozbilo a datum přetekl na 1995, včetně rychlostí procesorů.[/joke]

[little.owl]

Cekam, ze si s tim ted lidi budou dost hrat a treba se slavy docka i AMD a ARM.

Taky bych rekl, tady se otevrela Pandorina skrinka.

[little.owl]

Linusova reakce na chovani Intelu zde .

[pc2005]

Jo pár dekád starej algoritmus a nikoho nenapadlo to otestovat.

[Hawk]

Proč se vlastně neopraví chyba tak, že process, co sáhne na paměť, na kterou nesmí, tak je okamžitě killnut?

[kralyk z abclinuxu]

Protože z hlediska OS proces na tu paměť nešáhl.

[little.owl]

Pristup do pameti nelze kontrolovat bez podpory HW a prave HW je u Intelu neopravitelne zmrseny, takze OS o pristupu nema informaci.

[MadCatX]

Tím bys IMHO rozbil celý koncept out-of-order zpracování. Představ si třeba tenhle kód:

size_t getlen(const char *s)
{
	size_t idx = 0;
	while (s[idx++] != '\n');

	return idx;
}

int main()
{
	const char s[] = {'M', 'o', 't', 'y', 'k', 'a', '\n'};
	size_t idx = 0;

	while (idx < getlen(s))
		putchar(s[idx++]);

	return 0;
}

Při každé otočce cyklu se CPU podívá, jak je vypisovaný řetězec dlouhý a podle toho buď cyklus zastaví, nebo provede. Out-of-order CPU nebude čekat, až bude k dispozici výsledek kontroly délky řetězce, ale spekulativně ten cyklus provede, protože výsledek předchozích sedmi kontrol byl "proveď cyklus". Při osmém průchodu může idx klidně odkazovat na pamět mimo prostor procesu. Kdyby mělo tohle vyvolat segfault, spadlo by ti dříve či později úplně všechno.

[little.owl]

Kdepak je petrfm a jeho opevy na kvalitni procesory Intelu pro profiky?

[ehm]

Rozepíná knoflíky, aby se mohl vymočit, ale v té opilosti to nějak nejde. Mezitím vedle přichází profík Radek Hulán, zatáhne za zip, vymočí se, odchází.

[petrfm]

A mezitím ehm tráví další nudný večer u počítače a oběma závídí, tak vyblije aspoň nějaké hejty, co?

[pc2005]

Nebo ponkrác a óda na rychlost pipeliny x86 .

[petrfm]

A způsobuje ta chyba snad nějaké pády? Chyby mají všechny procesory. Dokonce i tyhle chyby se projevují na všech procesorech, tak o co jde? Ale čekal jsem, že se toho nějaký exot, kterému leží moje kritika AMD v žaludku hned chytí

[MadCatX]

Únik citlivých dat je daleko horší než nějaký crash a aspoň dle AMD je Meltdown specifický pro Intely a ten softwarový fix má za následek nezanedbatelnou degradaci výkonu. Nějakému MadCatXovi může být vesměs u prdele, jestli mu ty kompilace a simulace poběží o chvíli déle. Oproti tomu techničtí šéfové z Amazonu budou určitě blaženi, když si budou muset vybrat mezi "za stejné náklady obsloužíme o 10 % méně zákazníků" a "zákazníkům může z jejich VPSek kdokoliv vykrást data".

[little.owl]

Zatim to vypdada na nejvetsi prusvih jaky jsme meli, unik dat je horsi nez pady.

[petrfm]

Byl to samozřejmě džojk Ale věřím, že se to brzy vyřeší a že to nebude chyba pouze Intelu.

[petrfm]

Hrozně moc textu na mě... Mám X230, s Intelem. Je to problém? ANO/NE? Pokud ano, jak ho řešit?

Dík

[MadCatX]

Ano, je. Nainstaluj jádro, které obsahuje softwarový workaround.

[urban]

od kdy v CR davaji poldum thinkpady?

[Adolf Kernel]

Mozno ho len ukradol :D

[petrfm]

Klid Slávku, v ČR se věci normálně kupujou,. Jenom vaši spoluobčané nám sem jezdí na čórky. Nebudeš ty jeden z nich?

[pc2005]

O co, že v reakci vytvoří intel novej běhovej ring .

[ehm]

Tove Torvalds je šestinásobná mistryně Finska v karate. Pokud s Linusem občas trénuje, zvát ho do ringu se nejeví jako nejmoudřejší. Aha, ty jsi vlastně psal o běhovém ringu. Bere se chůze jako dostatečný trénink? No, musím říct, že bych fakt nechtěl být v pozici Intelu. Kam se hnou, tam dostanou na držku.

[pc2005]

Fajn výběr slov není moje silná stránka, zvlášť pokud komunikuju v několika diskuzích zároveň a změním jen jedno slovo :P.

Hmm tak například privilegovaný režim, ale to moc nesedí k management engine.

[ehm]

Ale ne, to nebyla narážka na tebe. Na tom tvém komentáři ani nebylo nic „špatně“, ne?

[Jana J.]

Intel má údajně příští týden vydat opravu...

Tak jsem zvědavá...

[Michal Kubeček]

Možná jsem skeptik, ale formulace té tiskové zprávy, zejména odvolávání se na "OS vendors" a formulace jako "Intel continues to believe that the performance impact of these updates is highly workload-dependent", IMHO naznačují, že nepůjde o žádnou opravu, ale chtějí tím jen říct, že vydají update mikrokódu (na "problém 1") pro ty procesory, pro které ještě není, a že meltdown se podle nich má řešit workaroundem na úrovni OS (KAISER/KPTI/…).

[pc2005]

která bude řešit problémy Spectre a Meltdown na 90 % procesorů uvedených za posledních pět let.

T7600 Release date: August 2006

D'Oh!

[Matlák]

A co teprv tohle

[pc2005]

Na druhou stranu 2007 byl rok vydání (teda aspoň toho mýho mobile c2d) a poslední firmware je z roku 2010. Možná pár chyb ještě opravili.

[pc2005]

Tak mě napadá, když dokáže meltdown přečíst celý kernel space a vlastně celou RAM. Dokáže se pomocí toho taky dostat ven z procesoru na IOMEM (třeba PCIe zařízení)?

[R]

Pristup k IO pamati ma vedlajsie ucinky, takze nemoze byt cachovatelna a nemoze do nej procesor svojvolne pristupovat.

[pc2005]

No moje grafika je minimálně "prefetchable".

Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M]

[debian+]

A to nemas integrovanu, kt. ma pamet grafickej karte celu zdielane - tj. v RAM.

[petrfm]

Četli jste diskuzi na novinkách?

Někteří exoti už dokonce vymysleli, že zpomalení je způsobeno tím, že se na procesorech začne těžit kryptoměna Na to mu kdosi oponuje, že kryptoměny se těží na GPU. Doporučuju nakouknout. Člověk se fakt pobaví i u tak vážného tématu.

[kralyk z abclinuxu]

Ve mě teda diskuse na novinkách vyvolávají spíše depresi než pobavení a to celkem bez ohledu na téma článku...

[Michal Kubeček]

Ve mně spíš skutečnost, že to, co tam člověk čte, není produkce nějakých "kremlobotů", jak se nám někteří snaží namluvit. Stačí vyjít "mezi lidi" (tj. opustit svou informační bublinu) a zjistíte, že takové, věci, jaké se píší v diskusích na novinkách, říkají i skuteční lidé z masa a kostí, ne jen virtuální weboví trollové. To mi připadá mnohem depresivnější.

[Rezza]

Tak on prece kazdy vi, ze za Meltdown a Spectre muzou uprchlici.

[Conscript89]

Ale notak, prece Kalousek!

[Michal Kubeček]

Za Kalouska přece taky můžou uprchlíci. Nebo Kalousek za uprchlíky? Už v tom mám hokej…

[Rezza]

To je kampan! Ucelovka!

[petrfm]

Náhodou ta konspirace s těžbou kryptoměn, to mě dostalo. V hlavě prosťáčka to musí tak dokonale do sebe všechno zapadat. Propad bitcoin, těžba na počítačích nic netušících nebožáků, no a teď, prosím pěkně, ještě otevřeně prohlásí, že se všechny počítače zpomalí. Ještě do toho nějak zamontovat Putina a KLDR a máme hned v lednu pořádně vysoko nasazenou laťku na konspiraci roku

[little.owl]

A EU!

[little.owl]

Ted si uvedomuji, ze to je castecne pravda, protoze cast vyzkumne prace byla financovana z grantu EU ... .

[Michal Kubeček]

Vidím nedostatky v základní terminologii: žádní uprchlíci ale migranti. A EU taky nezní dost odpudivě, musí se použít aspoň něco jako byrokrati v Bruselu.

[petrfm]

Výborně! A už jsi skoro kremlobot

[xvasek]

Slabota. Kde jsou sluníčkáři a vítači?

[petrfm]

Občas, když tam zavítám, připadá mi, že ti lidi jsou v těch příspěvcích tak nasraní a otrávení životem proto, že tu diskuzi nejdříve četli Že přece nemůže být někdo tak v prdeli. To přece za normálních okolností nejde.

[petrfm]

Už někdeo ví jak je to s ARMem a mobily s Androidem? Apple je taky v prdeli, co jsem četl, ale mám mobil s androidem, kterému skončila podpora před rokem, Počítám, že jedna zranitelnost půjde řešit updatem prohlížeče, ale co ta druhá? Je to nějak zneužitelné?

[marbu]

Přehled oprav co dělá Google je linkovaný v komentáři 25. Jinak si zjisti, jaký procesor máš v telefonu a podívej se na Vulnerability of Speculative Processors to Cache Timing Side-Channel Mechanism.

Pokud na ten telefon už nechodí aktualizace a procesor je zranitelný, tak je to hádám neopravitelné.

[petrfm]

Cortex A-53 a ten v tom seznamu vůbec není 8-)

[little.owl]

Intel procesory, ktere maji problem:

    Intel® Core™ i3 processor (45nm and 32nm)
    Intel® Core™ i5 processor (45nm and 32nm)
    Intel® Core™ i7 processor (45nm and 32nm)
    Intel® Core™ M processor family (45nm and 32nm)
    2nd generation Intel® Core™ processors
    3rd generation Intel® Core™ processors
    4th generation Intel® Core™ processors
    5th generation Intel® Core™ processors
    6th generation Intel® Core™ processors
    7th generation Intel® Core™ processors
    8th generation Intel® Core™ processors
    Intel® Core™ X-series Processor Family for Intel® X99 platforms
    Intel® Core™ X-series Processor Family for Intel® X299 platforms
    Intel® Xeon® processor 3400 series
    Intel® Xeon® processor 3600 series
    Intel® Xeon® processor 5500 series
    Intel® Xeon® processor 5600 series
    Intel® Xeon® processor 6500 series
    Intel® Xeon® processor 7500 series
    Intel® Xeon® Processor E3 Family
    Intel® Xeon® Processor E3 v2 Family
    Intel® Xeon® Processor E3 v3 Family
    Intel® Xeon® Processor E3 v4 Family
    Intel® Xeon® Processor E3 v5 Family
    Intel® Xeon® Processor E3 v6 Family
    Intel® Xeon® Processor E5 Family
    Intel® Xeon® Processor E5 v2 Family
    Intel® Xeon® Processor E5 v3 Family
    Intel® Xeon® Processor E5 v4 Family
    Intel® Xeon® Processor E7 Family
    Intel® Xeon® Processor E7 v2 Family
    Intel® Xeon® Processor E7 v3 Family
    Intel® Xeon® Processor E7 v4 Family
    Intel® Xeon® Processor Scalable Family
    Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
    Intel® Atom™ Processor C Series
    Intel® Atom™ Processor E Series
    Intel® Atom™ Processor A Series
    Intel® Atom™ Processor x3 Series
    Intel® Atom™ Processor Z Series
    Intel® Celeron® Processor J Series
    Intel® Celeron® Processor N Series
    Intel® Pentium® Processor J Series
    Intel® Pentium® Processor N Series

[pc2005]

Předpokládám že to je jen seznam těch, který ještě intel podporuje. Minimálně to demo z blogu mě jede i na 65nm C2D.

[little.owl]

Podle vseho ano, starsi verze nejspise nedostanou upgrade microcode.

[pc2005]

Pohoda, nebude upgrade, bude jinej vendor .

[little.owl]

Jaky test jste spustel?

[pc2005]

No ten na spectre z blogu.

[little.owl]

Navic se zda, ze treba Microsoft nutny update microcode nedistribujuje, poskytuje ho bud vyrobce CPU nebo HW ve firmwaru ... viz. zde:

Customers who only install the Windows January 2018 security updates will not receive the benefit of all known protections against the vulnerabilities. In addition to installing the January security updates, a processor microcode, or firmware, update is required. This should be available through your device manufacturer.

Coz mi prijde atipicke a trochu budi dojem, ze Intel (a mozna i AMD) neni jeste schopen poskytnout stabilni update microcode, ktery by Microsoft mohl distribuovat.

[Ondrej Santiago Zajicek]

Rekl bych, ze Spectre (narozdil od Meltdown) nelze oznacovat za bezpecnostni chybu v procesoru, ale v aplikacich. Procesor nabizi urcite mechanismy pro oddeleni bezpecnostnich domen (ringy a MMU), ale tezko muze neco zarucovat o bezpecnosti v ramci jedne takove domeny. Az teprve software se snazi rozdelit jednu 'procesorovou' bezpecnostni domenu na vice 'softwarovych' bezpecnostnich domen (napr. prohlizec a javascriptovy kod), ale dela to zpusobem, ktery je nedostatecny.

[kralyk z abclinuxu]

Souhlasim, že aplikace jako browser by mohly v tomhle určitě být napsány lépe / defensivněji, ale IMHO to stále je bezpečnostní chyba CPU, protože to umožňuje čtění paměti bez čtení paměti.

Pokud by to měl řešit software, otázka je, jestli vůbec může. IMHO může pouze snižovat dopad problému, např. tím, že browser oddělí vykonávání JS do jiného procesu, který nebude mít přístup k citlivým informacím. Nicméně tam je zas problém zajistit, aby ten proces skutečně k těm informacím neměl přístup (JS engine potřebuje přístup ke všemu možnýmu), navíc ten engine jako takový a veškerá jeho data bude díky Spectre pro JS kód de facto zcela průhledný, což může potenciálně dost usnadňovat využití jiných (i třeba ještě neexistujících) bezpečnostních chyb v aplikaci.

Další věc která mě napadá je formálně verifikovaný software, nejsem na tohle odborník, ale intuitivně mi přijde, že tahle chyba do jisté míry verifikaci znemožňuje.

[pc2005]

např. tím, že browser oddělí vykonávání JS do jiného procesu, který nebude mít přístup k citlivým informacím.

To je už teďka ne? A proto museli vypnout tu sdílenou paměť, protože ty můžes spectrem tricknout ten nevinný proces, aby ti poslal data mimo tu sdílenou oblast.

[little.owl]

Sdilena pamet umozni implementovat presne mereni casu - timer.

[pc2005]

Hmm nejsem si jistej jak je sdílená paměť pro JS v prohlížecích (natož chrome) řešená, ale sdílená paměť pro timer je jen berlička v jazycích, který nemají timer (třeba ten RDTSC, nebo že ho někdo vypnul). Ve spectre je hlavní použití sdílené paměti právě ten útok na zjištění, která cacheline odpovídající tajnému bajtu a zároveň indexu ve sdílené paměti zrovna vypadla. A ano pro zjištění doby vypadnutí cacheline můžeš použít druhou sdílenou paměť na for loop timer.

[little.owl]

Mozilla vam to pise jasne:

... and the SharedArrayBuffer feature has been disabled because it can be used to construct a high-resolution timer.

[pc2005]

OK

[kralyk z abclinuxu]

To je už teďka ne?

No, třeba v Chromiu čistě vykonávání JS svůj vlastní proces nemá. JS se vykonává v procesu, kterej řeší renderování myslimže jednoho tabu. Nevim, k čemu všemu má ten renderer proces v paměti přístup, to se mi nepodařilo dohledat (ale je pravda, že jsem tomu nedal kdovíkolik času). Zmiňoval jsem v nějakým jiným komentáři např. podezření, že má přístup k historii, protože informace z historie jsou potřeba k renderování.

[pc2005]

že tahle chyba do jisté míry verifikaci znemožňuje.

No minimálně by měla jít verifikace toho procesoru. Tam by neměl být problém zjistit, že stav cache je po zabití spekulativní větve změněný.

[snajpa]

EPYC FAIL

[Michal Kubeček]

Všetečná otázka: máte nainstalovaný příslušný update mikrokódu?

[Ondrej Santiago Zajicek]

A on je nejaky update mikrokodu, ktery by resil bound check bypass utok?

[Michal Kubeček]

Tak jsem překontroloval changelogy a na CVE-2017-5753 by měl stačit update jádra, ten update mikrokódu (pro family 17h) byl kvůli CVE-2017-5715.

[Ondrej Santiago Zajicek]

AFAIK neni zadny update jadra, ktery by univerzalne resil bound check bypass utok (CVE-2017-5753). Updaty jadra osetruji specificke bound checky v jadernem API (a krom toho je tu podpora KPTI kvuli Meltdownu, CVE-2017-5754).

[snajpa]

Mam to z druhe ruky, ale chtel jsem byt dramaticky. Proveruju

[pc2005]

Zajímavý další krok intelu by byla možnost větší konfigurace mikrokódu (aby nebyla, v případě takovéhle chyby, nutnost předělat křemík). S technologií od Altery má docela dost příležitostí jak to vyřešit.

[petrfm]

Aby to nebyla zase další bezpečnostní díra a ten mikrokód si nemohl aktualizovat sám malware

[little.owl]

Rozumne technicke shrnuti na AMD reddit. Jinak off-topic, Intel Coffee Lake triky ohledne vypocetniho vykonu zde, cim dale lepe. Chlapik ma zajimava videa - a silny skotsky prizvuk, coz mu cas od casu daji sezrat ... .

[petrfm]

Tak mě napadá, stačí udělat apt-get update & upgrade, nebo musím dělat něco víc? Nebylo by špatné publikovat nějaký návod pro člověka, kterýmu je u (_!_), jak ta zranitelnost funguje, ale zajímá ho, jak se dá zneužít a jak se tomu bránit,.

[pc2005]

Proti meltdown nainstalovat poslední verzi jádra (až bude v repu, nejspíš už je) a pak sledovat zda nejsou updaty. Systém pojede až 30% pomalejc. Proti spectre zatím nainstalovat update prohlížeče, sledovat zda nevyjde na tvůj procesor novější firmware (BIOS flash/microcode ramdisk) a nainstalovat všechny updaty. Četl jsem něco o patchi GCC, ale nevím zda se tahle varianta nakonec vybrala. V případě že jo tak pak reinstalovat všechny balíčky na ty patchnutý. Oprava spectre sníží výkon systému max asi 1% (čísla někde z diskuze během téhle kauzy).

IMO v tuhle chvíli na nepatchnutým systému s intelem tě teoreticky může kdokoliv na světě rootnout (třeba přes ten javaskript v neupdatovaným FF/chrome). Víceméně stačí útočníkovi mít schopnost pustit u tebe vlastní algoritmus nad větším polem a schopnost měřit čas běhu své rutiny.

Modlit se, aby se neobjevila nějaká ještě šílenější věc, co jde se spekulativním kódem dělat.

Až vypěstujou :D v Intelu/AMD novej procesor s opravenou branch predictor architekturou, tak koupit novej.

[petrfm]

To mě teda těší Na druhou stranu, asi teď dramaticky spadne cena repasů a ojetin vůbec, že?

A už někdo ví jak je to třeba s těmi army? Raspberry Pi apod? Spousta lidí na tom má servery.... Buď se to dramaticky zpomalí, nebo to bude na vyhození? A jak třeba otestovat, že můj hosting už má zalepené ty díry? Dá se to nějak testnout v PHP?

[kralyk z abclinuxu]

Raspberry Pi netrpí žádnou z těch chyb, protože ARM CPU použité v Raspeberry nemá specutalive execution.

[snajpa]

Tak, ze se dalo koupit 2x 8mijadro se 128GB RAM za 27k CZK s dani, mi teda prislo podezrele levny aj na jetej hardware. Az mi to tak podezrely neprijde, ze to Rackspace a Amazon prodavali tak pod cenou... nebo je to normalni hodnota HW ke zbaveni se, kdyz jeste muze po kapitalisticku vyrabet? Leda, ze byste vedeli, ze tem CPU se za nedlouho provali monstrozni chyba, tak honem pryc, tu do 3/4 roku zadne nemame...

[Käyttäjä 11133]

Az mi to tak podezrely neprijde, ze to Rackspace a Amazon prodavali tak pod cenou...

Velcí cloud provideři (a obecně enterprise IT service provideři) neprodávájí hardware na sekundárním trhu, ale vracejí ho vendorům v rámci buy-back guarantee programu a zpravidla znají výkupní cenu (výši slevy na nový HW) dlouho dopředu.

nebo je to normalni hodnota HW ke zbaveni se, kdyz jeste muze po kapitalisticku vyrabet?

Vysoké hrubé marže :)

Leda, ze byste vedeli, ze tem CPU se za nedlouho provali monstrozni chyba, tak honem pryc, tu do 3/4 roku zadne nemame...

Paranoid much?

[little.owl]

ale vracejí ho vendorům v rámci buy-back guarantee programu a zpravidla znají výkupní cenu (výši slevy na nový HW) dlouho dopředu.

Jenze to padne v okamziky, kdy uz neplanuji nakup od stejneho vendora a sleva na novy HW je nezajima, ne?

[Käyttäjä 11133]

Jenze to padne v okamziky, kdy uz neplanuji nakup od stejneho vendora a sleva na novy HW je nezajima, ne?

Ale cílem buy-back programu je vendor lock-in, takže umisťování HW na sekundární trh je zakázáno v rámcovkách... A mimo jiné, někteří vendoři nabízejí buy-back i pro hardware konkurence :)

[snajpa]

Tak to jsem nevedel, ze v ramci Open Compute Project u nekoho z hardware dodavatelu funguje buy-back. Supermicro, ktere prave v tech datacentrech jelo pred OCP, buy back teda nedela. Aspon jsem o tom tedy nikdy neslysel - asi se bavime o totalne jinym svete. Mne nezajima totalne premarzovanej enterprise, na takovych vecech Internet nestoji. Viz cely Supermicro second-hand, to je dost kategorie masin sama pro sebe.

Ono Marku ja se fakt nebavim o tvoji enterprise sfere, pro mne fakt neni relevantni, co se tam pece jak pekne proprietarne a predrazene. Myslim, ze pro vetsinu Internetovyho sveta - vcelku zrovnatak. Fakt mne nezajima 5 masinek, co pocita nejaky Oracly, middlewary a JBossy, kdyz cely, jak to je, je to v hodnote nekolika ulicek Open Compute Hardware. To mne zajima, jake dava levnejsi a levnejsi computing moznosti, ne cover-your-ass corporate pristup k hardwarovani, kdyz to mam rict po svem, s klasickou nadsazkou ke konci

[Käyttäjä 11133]

Někteří ztěchto určitě Minimálně Dell EMC a HPE.

[snajpa]

Jo no, ale zrovna od nich maji v tech datacentrech naproste minimum, protoze jsou drazi. OCP HW je velka otevrena soutez na to, kdo do toho standardu doda levnejsi zelezo. Wiwynn treba dost vali.

[snajpa]

Vcelku dost by mne zajimalo, co musi clovek udelat, aby mu Dell prodal OCP HW, anyway. Zkusim to prubnout. Ale co vim, tak po Evrope OCP HW v malem mnozstvi pujde sehnat akorat od tech ne-znacek, ktere toho vyrabi nejvic, ne veci, na ktere se po kusech ceka, az se vyrobi na miru vetsim zakaznikum. Pro Dell neni az tak existencne dulezite, aby se ucastnil race-to-the-bottom, jakym OCP je, tedy hlavne dokud je to domena tech nejvetsich cloudovych hracu. Umim si predstavit, ze je to stve, ze se toho ucastni v druhe a treti koleji, ale nemaji s tim, co udelat.

[marbu]

Jan Wildeboer vypracoval (a bude průběžně aktualizovat) přehled souvisejících událostí: How we got to #Spectre and #Meltdown A Timeline.

[trekker.dk]

Moc pěkná je ta část, kdy CEO prodal akcie za $35M. Toho člověka by měli zavřít za americkej ekvivalent zneužití informací v obchodním styku

[Michal Kubeček]

Podstatnější než za kolik je IMHO to, že prodal přesně všechny, které směl, a nechal si jen tolik, kolik podle firemních předpisů musel. Jestli se mu i tak podaří uhádat, že to bylo v pořádku, je to s jejich právním systémem horší než jsem myslel.

Zarážející ale je, že propad cen akcií sice byl, ale ne až tak závratný a v podstatě se dá říct, že polovina už je ho zpátky.

[trekker.dk]

Protože Intel sice neumí moc dobře dělat bezpečný hardware, ale za to má excelentní marketingové oddělení.

[Michal Kubeček]

Nedělal jsem si iluze, že by investoři rozuměli technické stránce natolik, aby pochopili, jak velký bullshit prohlášení Intelu jsou. Ale říkal jsem si, že zprávě typu "CEO v předstihu prodal všechny akcie, které mohl" by rozumět mohli.

[trekker.dk]

No jo, ale vypadá to, že to firmu nepoloží, tudíž je to vlastně dobrá investice, protože teď je cena akcií nízká. (Pořád to nedává smysl? Njn, velký obchod, co naděláte.)

[little.owl]

To ze se cena nepropadla vice, neznamena ze investori nevi o co jde, spise naopak. Intel procesory do dvou let nejak opravi, AMD nema kapacitu Intel zastoupit a navic bude treba nahradit starsi procesory (~ > 5 let), pro ktere Intel neposkytne update microcodu. Za par tydnu diky marketingu a vlivu na sdelovaci prostredky, kde Intel utraci za reklamy, bude u vetsiny zapomenuto/prominuto a pojede se dale.

Zde oblibene Thinkpad X220/X230 mohou byt trochu dead in water, protoze zadny update microcode pro ne uz asi nebude.

[Käyttäjä 11133]

Proč by mělo být podstatné o kolik se rozhodl snížit svojí rizikovou expozici? Prostě se rozhodl snížit svou expozici vůči riziku na minimální možnou hranici a divestovat svá aktiva do alternativ za účelem vytvoření více diversifikovaného portfolia aktiv. Já bych teda osobně viděl rozdíl pouze mezi "prodat dost na nové auto pro dceru", nebo "prodat dost na byt pro syna" vs. "protat libovolné množství akcií jen tak bez nějakého zjevného důvodu".

[kralyk z abclinuxu]

Moc pěkná je ta část, kdy CEO prodal akcie za $35M. Toho člověka by měli zavřít za americkej ekvivalent zneužití informací v obchodním styku.

Insider trading si myslim, ale IANAL.

[marbu]

Jo, jasný insider trading, jak už tady někdo linkoval. Navíc ohledně věci, za kterou je ten člověk jako CEO z definice spoluzodpovědný.

Ale jak ukazuje nedávný případ úniku dat z firmy Equifax, je možné, že mu to projde (jakkoli absurdně to může znít):

It was also revealed that three Equifax executives sold almost $1.8 million of their personal holdings of company shares days after Equifax discovered the breach but more than a month before the breach was made public.[57] The company said the executives, including the chief financial officer John Gamble,[58][27] "had no knowledge that an intrusion had occurred at the time they sold their shares".[59] On September 18, Bloomberg reported that the US Justice Department had opened an investigation to determine whether or not insider trading laws had been violated.[60]

Plné odkazy viz Equifax#Criticism.

[marbu]

Ah, ten závěr tam není linkovaný:

none of the four executives had knowledge of the incident when their trades were made, that preclearance for the four trades was appropriately obtained, that each of the four trades at issue comported with Company policy, and that none of the four executives engaged in insider trading

Ale jak to tak čtu, tak to vypadá docela rozumě. Beru zpět.

[Conscript89]

A i kdyby to vedeli v ten moment prodeje, tak by to porad jeste nemusel byt insider trading pokud by ten prodej byl naplanovany jeste pred obdrzenim te informace. Muze jit taky prodej za ucelem nakupu automobilu, nemovitosti ktere jsou delsi dobu planovany.

Soudy bez blizsich informaci jenom protoze neco nejak vypada jsou hodne nebezpecne. Obvineni a vysetrovani jsou ale naprosto v poradku.

[little.owl]

porad jeste nemusel byt insider trading pokud by ten prodej byl naplanovany jeste pred obdrzenim te informace.

Podle vseho to byl naplanovany odkup jiz pred tim nez dostal informaci o chybe. Nedelam si iluze, ze to ma osetrene, jinak by do toho asi nesel. Spise bych cekal ze mohl posunout dobu, kdy se o tom informuje verejnost a tady ma Intel dosti co vysvetlovat. Alespon adminum nespackali Vanoce, hadam ze ted maji perne chvilky.

[Käyttäjä 11133]

Spise bych cekal ze mohl posunout dobu, kdy se o tom informuje verejnost a tady ma Intel dosti co vysvetlovat.

Jako o té chybě? Nevidím jediný důvod proč by Intel o té chybě vůbec MUSEL informovat.

[Michal Kubeček]

Jistě, nemusel, tedy přinejmenším z právního hlediska. Na druhou stranu, stejně tak byla od Googlu jen a jen jejich dobrá vůle (a profesionální etika), že byli ochotni počkat (tak dlouho).

[Käyttäjä 11133]

Jasně, dvě velké společnosti vždycky raději spolupracují, než aby si dělaly naschvály A posunout oznámení nějaké security díry o nějaký čas do budoucna je jednoduché, nic to nestojí a vždycky se hodí mit tzv. službičku v záloze.

[ehm]

Nač se obtěžovat, že. Snad někdy nepoletím letadlem, jehož výrobce neviděl jediný důvod, proč by o závažné konstrukční vadě, o které věděl, musel informovat. Aby se CEO rychle mlčky zbavil všech akcií, kterých se může zbavit, a tím „snížil svou rizikovou expozici“ (#231), je taky úplně v pořádku.

[Käyttäjä 11133]

Holt o některých věcech musíš nekteré lidi / organizace dle zákona / obsahu smluv informovat a o některých prostě nemusíš; proč se kvůli tomu chceš zlobit na Intel? Uzavři si obrovskou rámcovku s Intelem že odebereš miliardu jejich CPU když tě budou o všech objevených chybách informovat do 48 hodin, když ti na tom tak záleží, třeba na to přistoupí

[ehm]

Hele, mně je celkem fuk, co v tomhle případě Intel podle zákona dělat musí, nebo nemusí. Když se chtějí na drtivou většinu zákazníků s updatem firmwaru vysrat (i poté, co ztratí až desítky procent výkonu kvůli Meltdownu), tak tedy prosím. Osobně tento jejich přístup zohledním – a doufám, že nejsem sám – při výběru dalších procesorů. Koneckonců, x86 je prohnilá sračka, což ví každý, kdo na ní měl co do činění s assemblerem, a používat to mě děsí už roky. Pokud člověk nepotřebuje používat proprietární software, snad by stálo za to zvážit postavení i desktopového počítače na ARMu (ano, vím, že toho se Spectre týká rovněž). Že soudruhům do Intelu adresuji (pěkně pomocí dvou šestnáctibitových registrů) srdečné pozdravy.

[snajpa]

A ktery jadra dosahujou vykonu porovnatelnyho s Intelima x86, kdyz odhlidnu od toho, jaka je to silena splacanina? Cenovy faktor je jedine, co mne osobne u x86 drzi. S prichodem Zenu je aspon zase na vyber mezi dvema vyrobci, ale kdyz budu chtit ne-x86, co mam realne za moznosti? Talos Workstation, Opteron A1100, co dal? Talos je mi ze soucasnych moznosti teda nejblizsi, protoze na desktopu nechci kalkulacku, ale neco, co mne nebude pri praci zdrzovat. Notebook jako terminalek on-the-go bych asi prezil s nejakym malinkym jadrem v pohode, kdyz bude v dostatecnem poctu (tak 4x Cortex A53 s maximalkou aspon 2 GHz).

[little.owl]

Odchod od x86 jeste nejakou dobu potrva.

Zajimave je na na trh (znovu) vstupuje treti hrac s x86 licenci - Zhaoxin - coz je joint-venture VIA Technologies a Shanghai Municipal Government. V soucasne dobe maji dva produkty KX-5000 and KX-6000 SoCs.

Parametry KX-5000, 2017, jiz vyraben a dodavan:

Up to 8 x86-64 core
Up to 8MB L3 Cache
AVX, AVX2, AES, SHA, SSE4.2
28nm BULK by HLMC
DDR4 MC
PCI-e 3.0
GPU DX11 by S3

Parametry KX-6000, jaro 2018, vyroba pripravena u TSMC:

Up to 8 x86-64 core
Up to 8MB L3 Cache
AVX, AVX2, SHA, SSE4.2
16nm FF+ by TSMC
DDR4 MC
PCI-e 3.0
GPU DX11 by S3

Vysledky nejakeho benchmarku jsou zde a nevypada to spatne.

Vedle techto malych SoC pracuji na skalovatelnem serverovem reseni, zpocatku pouze pro cinsky trh, pozdeji pro export, cil rok 2019.

[ehm]

Určitě jsi na toto téma informovaný lépe než já, tak asi neumím moc odpovědět. Čekal bych, že s výkonem to obecně horší bude. Na druhou stranu, mám teď 5 let starý procesor (pravda, i5 od Intelu) a bottleneck to není skoro nikdy. Bez nějakých benchmarků / testování si ale fakt netroufám říct, jestli by to nějaký ARM mohl uspokojivě nahradit (tj. tak, abych to při mém používání skoro nerozeznal) a kolik by stál. Příjemně mě překvapilo, že ARM umí i virtualizaci – tu bych zrovna nečekal.

[Michal Kubeček]

jestli by to nějaký ARM mohl uspokojivě nahradit (tj. tak, abych to při mém používání skoro nerozeznal) a kolik by stál

Nahradit by to mohl, pokud nepoužíváte něco, co běží jen na x86_64, ale bylo by to samozřejmě dražší, protože se to vyrábí v menších sériích.

Příjemně mě překvapilo, že ARM umí i virtualizaci – tu bych zrovna nečekal.

To je tím, že když se řekne ARM, většina lidí si představí hračky typu Raspberry Pi nebo telefony. Jenže ARM jsou také 96-jádrové chipy s I/O dimenzovaným tak, že z toho přechází zrak. Problém je ale v tom, že pořád chybí "něco mezi", i když už se objevují první vlaštovky.

[Jendа]

ARM jsou také 96-jádrové chipy

To je pěkné, ale ten Firefox nebo LibreOffice při vykreslování více jader nepoužívají. Jak je takový stroj použitelný na desktopu?

[Michal Kubeček]

Tohle není pro desktop… Ona se snad virtualizace používá jen na desktopu?

[Jendа]

Přišlo mi, že v #272 se mluví o desktopu. A proto mě zajímalo, jestli už existuje ARM jádro, které by mělo výkon na jádro srovnatelný s low-end x86.

[Michal Kubeček]

Kdybych přímo neocitoval konkrétní větu, na kterou tím odstavcem odpovídám, pochopil bych, že někomu ten kontext nedojde. Ale takhle?

[kralyk z abclinuxu]

Koneckonců, x86 je prohnilá sračka, což ví každý, kdo na ní měl co do činění s assemblerem, a používat to mě děsí už roky. Pokud člověk nepotřebuje používat proprietární software, snad by stálo za to zvážit postavení i desktopového počítače na ARMu (ano, vím, že toho se Spectre týká rovněž).

S tím hodnocením x86 souhlasim, nicméně ARM mi nepřijde o moc lepší. Už taky za svou existenci zvládl nabalit solidní množství balastu (např. podpora dvojí ISA v jednom CPU - ARM vs Thumb, AArch64, různá rozšíření,...), navíc nejenže také Spectrem, ale některé nové / výkonnější CPU trpí i Meltdownem.

Alternativ opravdu moc není. Měl jsem nějakou dobu příležitost pracovat se Sparcem a architektonicky to není vůbec špatné. Ale bohužel zřejmě nemá moc perspektivu.

[deda.jabko]

např. podpora dvojí ISA v jednom CPU

Prisne vzato se jedna o jednu ISA, ale vic ruznych kodovani instrukci.

různá rozšíření

Tohle je mnohem vetsi prusvih. Pomalu, co procesor, to jina kombinace dostupnych instrukci.

Měl jsem nějakou dobu příležitost pracovat se Sparcem a architektonicky to není vůbec špatné.

SPARC je pekne navrzena architektura a pro nektera nasazeni na servru neni spatna. Na druhou stranu mu ujel vlak diky tomu, ze se soustredili na to jak dostat na procesor vice vlaken, pricemz Intel si vybral cestu drobnych kontinualnich vylepseni/zrychleni, na coz asi zakaznici slyseli vic a diky cemuz tu mame tyhle dve hezke bezpecnostni chyby.

Mimochodem, zdrojaky UltraSPARC T2 jsou k dispozici pod GPL, takze, kdo chce, muze si svuj procesor nejen udelat, ale muze si i overit, ze mu tam nikdo nedal back door. ;-]

[ehm]

Díky za komentář. Jsem biased, protože o ARMu narozdíl od x86 skoro nic nevím. SPARC neznám vůbec. Mám v TODO podívat se na oba blíž.

Jinak mou pointou bylo hlavně to, že x86 nemusí být nutné ani žádoucí, tj. vedle Intelu a AMD pak lze zvažovat i další výrobce. Třeba u mainstreamových herních PC by to snad vůbec nemělo smysl zvažovat, ale u linuxového desktopu je situace výrazně příznivější.

[little.owl]

+1

[Conscript89]

Je potreba delat rozdil mezi security a safety. Pokud jde o zdravi, tak je neomluvitelne neinformovat o znamem problemu. V pripade ochrany dat je ale lepsi chybu zatajit (na strane vyrobce SW/HW) do doby, nez se najde oprava, pripadne nez je chyba znama a zneuzivana, ale to se tu uz resilo nekolikrat. Vubec bych nebyl rad, kdyby se informovalo o chybe jeste pred vydanim jeji opravy, nicemu to nepomuze, spis naopak.

Ohledne hodnoceni jestli meli na vytvoreni a vydani opravy dost casu, to nedokazu posoudit, nepracuju v Intelu a nemam znalosti o designu CPU a mikrokodu.

[trekker.dk]

Problém je v tom, že ty dva těžko oddělíte - je dost pravděpodobné, že ten procesor někdo používá někde, kde jeho zneužití rozhodně vliv na to "safety" mít bude.

pripadne nez je chyba znama a zneuzivana

Problém je v tom, že tady o tom problému vědělo tolik lidí, že tu chybu určitě někdo zneužíval, zatímco všichni ostatní kromě velkých korporátů neměli šanci se jakkoliv bránit.

[Conscript89]

Pokud se nepletu, tak pomoci obou chyb lze cist, ne zapisovat pripadne jakkoliv ovlivnovat beh sytemu => vliv na "safety" nevidim. Prosim aspon o nejaky priklad.

tu chybu určitě někdo zneužíval

"urcite", "samozrejme", "prirozene" jsou krasna slova, kerymi se podklada tvrzeni. Pred vydanim opravy vi o security chybe pomerne hodne lidi, je tam spolecny zajem na oprave chyby a na informovani kritickych zakazniku/vlad o tom ze je nejaky problem ktery bude potrebovat opravit. Pokud se nedari najit opravu, tak takova "siroka" informovanost muze trvat delsi dobu. V Intelu nepracuju, takze nevim jak to tam probihalo narozdil od hromady jasnovidcu, nebo maji vazne kvalitni zdroje. To ze je to prusvih rozhodne zastirat nechci.

[little.owl]

Jen pro ilustraci, DragonFly BSD implementovalo patch proti Meltdown v dobe kratsi nez tyden a byla to v podstate jen one-man-show prace Matthew Dillon. Tech sedum mesicu pro megamolochy se tezko zduvodnuje.

[snajpa]

Obecne je tady na tom prusvihu videt, kdo maka, vs. kdo se opira o par svych zamestnanych nerdiku a dela hlavne PR, vs. kdo ty nerdiky nema vubec a zbylo jim jenom PR. Zase se ukazuje, ze komunita je silnejsi nez vsechny "co nejlip kooperujici" korporaty, co koho napadnou. Kde komunita muze jit a svobodne zacit makat (a neresit, ze za chvili padla, proste makame, dokud to neni... a nebo dokud neni potreba si odskocit pro doplneni kafe/energetaku). Tohle se s korporatem srovnavat neda. Mega se mi libi, ze komunitni "podporu" se neda si podplatit, to proste musite byt soucasti te komunity a resit to s nimi, jak se jede kupredu. Zas a znova se ukazuje, ze nema cenu pro mne ani uvazovat v rozmerech, kdy bych mel jednat s nejakymi obchodaky nad takovymi nerdiky - lepsi je, si nerdiky vytahnout bokem, az prijdou z korporatu domu - a pak neco pachat. Korporat je zlo jeste horsi, nez stat.

[Conscript89]

Tak nejak mi to pripomnelo ANO - nekecat a makat :) Ale to bude tim, co zrovna ted posloucham. Zajimalo jak by tech par nerdiku delalo support procesorum prodavanym v rozsahu jako Intel. Nedokazu si predstavit, ze by si stat objednal provozovani kriticke infrastruktury od skupiny nerdiku (tim vnimam ze nejsou nijak organizovani, nemaji za sebou nejaky dalsi support). Pokud by vznikla nejaka skoda, tak by ji meli potom cely zbytek zivota a i jejich potomci statu splacet? Rozhodne jsou mista kde se hodi vic, nez nejaka velka spolecnost ktera si sama klade vic pozadavku nez zadavatel. Na druhou stranu i ty velke zle korporatni spolecnosti maji sve misto, protoze proste dokazou nabidnout to co skupina nerdiku ne.

[snajpa]

Ale vubec, politiku bych do toho prave netahal. Jsem dost za to, jak svoje projekty vedou lidi typu Linus Torvalds, nebo Theo de Raadt. Ti za sebou taky nemaji ansabl plny prizivniku, ktery aniz by rozumeli jejich praci, chteji jejich praci ridit.

[Conscript89]

Jenom mi to tak vyznelo - nekecat a makat :). Open source komunita je krasny, rozhadany a pestry svet ve kterem verim stale vetsina lidi chce predevsim pro sebe a sdilenim i pro ostatni dobro :)

[little.owl]

Pracoval jsem v male firme (~20 lidi) nez nas koupil moloch (~ 220000 lidi), takze mohu srovnavat. Produktivita prace spadla diky ruznym processum a nutnosti komunikace tak na 30%, casto prava ruka nevi co dela leva, ale na stranu druhou muzeme pracovat - kdyz tedy muzem pracovat - na vecech ktere bychom si jako mala firma nemohli dovolit, nebot by byly bud drahe ci riskantni.

[Conscript89]

Sice nemam zadnou zkusenost s firmou o 20 lidech, ale za tech 8 let co jsem v Red Hatu, tak hodne vyrostl. Se vsim vsudy.

[Conscript89]

Patch v DragondFly BSD, v Linuxu nebo Windows tu chybu v procesoru ale prece neopravuji, ne?

[little.owl]

To nema SW reseni a to muselo byt Intelu jasne uz po mesici. Pointa je v tom, ze SW patch mel byt a mohl byt k dispozici mnohem drive.

[little.owl]

Patch, ktery alespon snizuje pravdepodobnost utoku.

[Conscript89]

Ok

[Michal Kubeček]

Ono je veřejným tajemstvím, že si za předčasné odhalení Intel nejspíš z velké části může sám. Kdyby totiž dali linuxovým vývojářům informace dřív (přičemž použitelnost těch informací byla sama o sobě tristní), mohl celý kaiser/kpti projít relativně standardním procesem bez nějakého velkého pozdvižení. Jenže když takhle zásadní patchset s takovým dopadem na výkon, Linus (který není žádný fanda hardeningu na úkor výkonu) bez řečí zamerguje do rc6, přestože za normálních okolností by s tím kohokoli mimo merge window vyhodil, začne holt lidem vrtat hlavou, jestli za tím asi bude něco většího.

[kralyk z abclinuxu]

Jen pro ilustraci, DragonFly BSD implementovalo patch proti Meltdown v dobe kratsi nez tyden a byla to v podstate jen one-man-show prace Matthew Dillon. Tech sedum mesicu pro megamolochy se tezko zduvodnuje.

A není to tak, že ten BSD vývojář měl už v té chvíli k dispozici popis řešení a případně i implementaci někoho dalšího? (ie. Linux?)

[little.owl]

Dragonfly BSD kernel je vyrazne jiny a ma jinou licenci nez Linux, zacinalo se z nuly. Popis reseni byl navrzen lidmy co na to prisli, ostatne uvodni implementace pro Linux v te dobe jiz existovala (KAISER) - Linux nemusel zacinak od nuly a soucasny linuxovy patch je jeho upravou.

[little.owl]

Obecnejsi cast z mailu od Dillona, kde oznamil zmeny:

I should note that we kernel programmers have spent decades trying to reduce system call overheads, so to be sure, we are all pretty pissed off at Intel right now. Intel's press releases have also been HIGHLY DECEPTIVE. In particular, they are starting to talk up 'microcode updates', but those are mitigations for the Spectre bug, not for the Meltdown bug. Spectre is another bug, far more difficult to exploit than Meltdown, which leaks information from other processes or the kernel based on those other processes or kernel doing speculative reads and executions which are partially managed by the originating user process. Spectre does NOT involve a protection domain violation like Meltdown, so the Meltdown mitigation cannot mitigate Spectre.

These bugs (both Meltdown and Spectre) really have to be fixed in the CPUs themselves. Meltdown is the 1000 pound gorilla. I won't be buying any new Intel chips that require the mitigation. I'm really pissed off at Intel.

[ehm]

Pokud se nepletu, tak pomoci obou chyb lze cist, ne zapisovat pripadne jakkoliv ovlivnovat beh sytemu => vliv na "safety" nevidim. Prosim aspon o nejaky priklad.

Útočník přečte z paměti heslo v plaintextu, připojí se a získá kontrolu nad kritickou infrastrukturou. Dosaď si libovolnou obměnu téhož.

[Conscript89]

Presne tuto reakci jsem cekal. Opet, ta dana chyba je "security", nelze pouze a jen diky teto chybe ohrozit zdravi/hmotny majetek. Transitivne je cokoliv ohrozenim cehokoliv.

[kralyk z abclinuxu]

A nemáš spíš na mysli takovéto klasické rozdělení "CIA", tj. Confidentiality, Integrity, Availability?

Z toho pohledu Meltdown & Spectre jsou (IMHO) narušení Confidentiality, ale ne těch druhých dvou zásad.

[Conscript89]

No, mohl bych citovat prvni prednasku predmetu "Ochrana dat a informačního soukromí" od prof. RNDr. Václav Matyáš, M.Sc., Ph.D. vyucovane na FI MUNI, kde bylo hned na zacatku predmetu vysvetlovano co je bezpecnost a ze v cestine pokryva 2 terminy "security" a "safety", kde "security" je to o cem se tu bavime a v pripade "safety" je bezpecnost kde jde o zdravi/majetek. Napr. bezpecnost roentgenu je "safety", zabezpecovaci zarizeni na zel. trati (to nebylo zmineno, to ted pridavam ja) je bezpecnostni prvek.

Confidentiality, Integrity i Availability jsou v tomto vnimani vsechny pod "security". Diky ale za zmineni, musim se priznat ze toto deleni neznam, pamatuju si akorat, ze vypadky dostupnosti sluzby jsou obecne povazovany za bezpecnostni chybu (availability predpokladam). Jak kym ale.

[Conscript89]

Je dost mozne ze se to ale deleni bezne nepouziva a co jsem se zbezne podival, tak nedokazu ted rychle najit jiny relevantni zdroj. Ono toto safety je dost specificka oblast, jednodusene receno jde o to, aby se SW/HW nezblaznil a delal to co ma delat a ohrozil by tak majetek/zdravi. To se hodne diskutuje treba v pripade autonomnich aut.

[ehm]

To máš recht. OK.

[little.owl]

To se muze snadno preklopit. Jednak rada utoku je vedena roboty a pokud se dostanou do systemu, mohou vam udelat v systemu slusnou paseku. Jiz dvakrat jsem zazil, kdy se kvuli napadenym nemocnicnim informacni systemum posouvaly planovane operace (kveten 2017 ransomware, cca 2003 Windows XP - nez prisel SP2) a tam jiz zacina jit o zdravi lidi.

[Käyttäjä 11133]

No minimálně Květen 2017 zneužival chyb kdy chyby byly nejen publikované, ale včetně záplat od vendora, takže chyby byly zjevně na straně provozovatelů infra.

[Jendа]

Tak proč je tedy potreba delat rozdil mezi security a safety?

[Conscript89]

Safety chyby jsou jineho charakteru nez security. Pokud se napr. zamkne auto a nejde zevnitr nijak otevrit tak je to safety a ne security chyba. Pokud by procesor daval neocekavatelne vysledky operaci, napr. Pentium FDIV bug tak to muze byt povazovano za safety chybu - probehne spatne vypocet kvuli kteremu vznikne skoda na zdravi/majetku, ale uz neni moznost jak tu chybu zneuzit z pohledu security. Proc je jednoduche, v pripade safety je potreba do nalezeni opravy zhodnostit rizika a zavest protiopatreni, protoze chyba se muze sama projevit. Narozdil od security, kde po objeveni chyby je doba kdy se chyba nejprojevi, dokud ji nekdo nezacne vyuzivat.

[Michal Kubeček]

Pokud by procesor daval neocekavatelne vysledky operaci, napr. Pentium FDIV bug tak to muze byt povazovano za safety chybu - probehne spatne vypocet kvuli kteremu vznikne skoda na zdravi/majetku, ale uz neni moznost jak tu chybu zneuzit z pohledu security.

Zrovna u FDIV je zneužití asi dost nepravděpodobné, ale obecně bych tvrzení, že chybný výsledek operace nelze zneužít, označil za příliš optimistické. Stačí si připomenout, jak často třeba jen nenápadná chyba v počítání referencí vede na privilege escalation.

[Conscript89]

Ano, je to dost nepravdepodobne, chtel jsem vzit priklad ktery se stal. Omlouvam se, nechtel jsem aby to vyznelo ze v obecne rovine chybny vysledek v operaci nelze zneuzit. Cele tvrzeni se vztahovalo ciste k FDIV a nespravne jsem pouzil "neni moznost", nevim ani jestli v dobe objeveni te chyby byly znamy zpusoby jak tuto chybu zneuzit, potom je uz asi nikdo nehledal.

[Michal Kubeček]

nevim ani jestli v dobe objeveni te chyby byly znamy zpusoby jak tuto chybu zneuzit

Těžko. Ta chyba byla objevena v roce 1994, to se ještě bezpečnost nebrala moc vážně.

[trekker.dk]

Volně přeloženo security chyba se stane safety chybou až tím, kdy ji někdo zneužije a způsobí škody na zdraví nebo majetku. Dokud se jenom baví tím pocitem, že může, ale ještě nezmáčknul entr, tak to safety chyba není.

Jo, to dává smysl...

[Conscript89]

Vubec ne. Pokud ma security chyba primy dopad na safety (moznost nezadoucim zpusobem ovlivnit chod HW/SW), tak ano, potom je to security i safety problem. V pripade security chyby kdy ma utocnik moznost cist neco k cemu by nemel mit pristup, napr. credentials ale uz ne ovlivnit chod systemu, tak tou samotnou chybou, muze a nemusi byt schopen zneuzit takto ziskane credentials k ovladnuti systemu, napr. pokud ma system dvoufaktorovou autentizaci, tak ackoliv doslo k leaku informaci v dusledku security chyby, nema ta chyba vliv na safety.

Security a safety chyby nejsou podmnozinou jedne ani druhe, ale maji svuj prunik. Muzu tady uvest priklady chyb, ktere jsou ciste safety a nedoslo k nim po naruseni security: Ariane 5 Flight 501 Therac 25

Priklad chyby ktera by byla v pruniku security a safety mnozin by byla napr. hypoteticka baterie notebooku ktera by explodovala (poskozeni zdravi a majetku) pri urcitem prikazu pres I2C ktery by byl vyvolatelny pomoci beznych API, napr. v prohlizeci. Skoda na majetku a zdravi by v tomto pripade znacne prevysovala samotnou cenu za "unavailability" (ktera by mohlo byt povazovano za security chybu).

[trekker.dk]

Pokud ma security chyba primy dopad na safety (moznost nezadoucim zpusobem ovlivnit chod HW/SW), tak ano, potom je to security i safety problem. V pripade security chyby kdy ma utocnik moznost cist neco k cemu by nemel mit pristup, napr. credentials ale uz ne ovlivnit chod systemu, tak tou samotnou chybou, muze a nemusi byt schopen zneuzit takto ziskane credentials k ovladnuti systemu, napr. pokud ma system dvoufaktorovou autentizaci, tak ackoliv doslo k leaku informaci v dusledku security chyby, nema ta chyba vliv na safety.

To je pěkné. Akorát o pár příspěvků ve vlákně výše to bylo formulováno takto: "Útočník přečte z paměti heslo v plaintextu, připojí se a získá kontrolu nad kritickou infrastrukturou."

Zjevně tedy má možnost nežádoucím způsobem ovlivnit chod HW/SW. Pokud ta infrastruktura něco řídí (stroje, dopravu, whatever), tak z toho máte safety chybu jak vyšitou.

A o pojmenování vůbec nejde - jde o zranitelnost systémů, které se používají ke všem možným účelům, přičemž ta zranitelnost je před uživatelem takového systému utajena. (Narozdíl od spousty jiných lidí - celé se to řešilo rok a půl, nezávisle na to přišlo několik výzkumníků, takže o tom zjevně věděla spousta lidí.)

Příklad s auty: je to jako kdyby 80% jezdících aut na trhu, když se na ně správně zabliká baterkou, přestalo brzdit. Protože moc moc závažná chyba a neví se, jak rychle se ji povede opravit, tak se utají, takže řidiči rok a půl jezdí autem, které může přestat brzdit - ať už náhodou, nebo cizím zlým úmyslem. Přičemž se to během toho roku a půl postupně dozvídá víc a víc lidí - kromě těch řidičů.

A ať mi nikdo nezkouší tvrdit, že ten rok a půl se fakt intenzivně přemejšlelo nad tím, jestli to půjde opravit a jak. Prostě u Intelu zkoušeli, jestli to náhodou nevyšumí, nebo jestli nakonec na něco nepřijdou v tichosti a nepovede se jim to nějak opravit jako undisclosed problem (vizte changelogy microkódů)

[Conscript89]

Todle nema smysl, proste ten rozdil nevidis, primy a transitivni vztah ti nic nereka, ani pro jednoho z nas nema smysl v tomdle rozhovoru dal pokracovat.

[little.owl]

Spise jde o to, ze vy si neuvedomujete ze safety a security jsou dve strany teze mince.

[Conscript89]

To ze jsou ruzne bezpecnostni chyby ruznym zpusobem zneuzitelne si uvedomuju. Rozhodne lze napachat mnoho skody (priprava ne teroristicky utok, obohaceni se na ukor nekoho jineho, znepristupneni sluzby, zmena hlasu ve volbach, neopraveny pristup ke credentials) kvuli security chybe, to taky nezpochybnuju. Existuji i security chyby s mensim dopadem (zjisteni ze neci email je pouzivan v ramci konkretni sluzby). Nedavno nalezene chyby jsou z meho pohledu velmi zavazne a cile pro ktere mohou byt zneuzity jsou siroke. Rozhodne by bylo pro vsechny lepsi, kdyby byly opraveny co nejdrive a kdyby nebyly nadale prodavany procesory u kterych je vyrobci zname ze takovou chybou trpi v tom jsem se vsemi zde v souladu.

V cem se lisim je to, ze nemam tak resolutni postoj a znalosti o tom jak to probihalo v Intelu od momentu co se o chybe dozvedeli. Rozhodne bych byl rad, kdyby byla moznost se pridat do nejake hromadne zaloby, protoze jsem taky poskozeny a byl bych rad, kdyby byla situace objektivne vysetrena nezavislym organem.

[little.owl]

To ze jsou ruzne bezpecnostni chyby ruznym zpusobem zneuzitelne si uvedomuju. Rozhodne lze napachat mnoho skody (priprava ne teroristicky utok, obohaceni se na ukor nekoho jineho, znepristupneni sluzby, zmena hlasu ve volbach, neopraveny pristup ke credentials) kvuli security chybe, to taky nezpochybnuju.

Ja zase nezpochybnuji, ze security a safety neni uplne totez. Nicmene v oblasti PC a serveru, s ohledem na jejich uziti v infrastrukture a beznem zivote, a nasi zavislosti na nich, lze v podstate konstatovat ze zavazna security chyba je zaroven safety chybou.

Rozhodne by bylo pro vsechny lepsi, kdyby byly opraveny co nejdrive

Presne tak. Znovu, zlatym standardem je pro me odpoved Dragonfly BSD - oni se dozvedeli, ze se neco deje po kernel patch od AMD. Behem tydne implementovali ochranu proti Meltdown, za tri dny proti Spectre, s tim ze ted, kdyz jsou jejich uzivatele uz pred nejhorsim chraneni, budou nasledujici tydny pracovat na optimalizaci a dalsich zlepsenich. Potom skutecnost, ze jsme byli mesice vedome nechani ve stavu kdy vam pres prohlizet mohli vyrabovat pocitac, firmami ktere maji desetitisicinasobne vice zdroju nez Dragonfly BSD, zanechava proste trpky pocit.

V cem se lisim je to, ze nemam tak resolutni postoj a znalosti o tom jak to probihalo v Intelu od momentu co se o chybe dozvedeli. Rozhodne bych byl rad, kdyby byla moznost se pridat do nejake hromadne zaloby, protoze jsem taky poskozeny a byl bych rad, kdyby byla situace objektivne vysetrena nezavislym organem.

Co se stalo v Intelu nevime a asi vedet nebudem. Nicmene s ohledem na to ze Intel je klasicka byrokraticka molochoidni organizace s X vrstvama managementu a velkym mnozstvim vnitrni politiky, muzem s klidem drze spekulovat jak to vypadalo. Po te co management akceptoval stanovisko inzenyru po nekolika iteracich "nemame reseni" a "try harder", odhadem mesic, a spatna zprava probublala do nejvyssich pater, pak mesice resili co dale a jak z toho vybruslit, a zajmy [malych] konecnych uzivatelu - tedy moje a vase, ale i mensich poskytovalu serveru a sluzeb - byly na druhe koleji.

[kralyk z abclinuxu]

Nicmene v oblasti PC a serveru, s ohledem na jejich uziti v infrastrukture a beznem zivote, a nasi zavislosti na nich, lze v podstate konstatovat ze zavazna security chyba je zaroven safety chybou.

+1

zajmy [malych] konecnych uzivatelu - tedy moje a vase, ale i mensich poskytovalu serveru a sluzeb - byly na druhe koleji

To je skoro ještě dost optimistické. Jinak moc nevim, proč někoho tohle chování Intelu překvapuje. Mě na tom překvapuje maximálně tak to, že tohle někoho překvapuje

[Conscript89]

V tom cleneni mame pohledy rozdilne, nemyslim si ale ze je to nejak zasadni vzhledem k tomu ze mame stejny pohled na potencialni dopady tech chyb. Ve zbytku v podstate souhlasim (a jsem za to rad). Dragonfly BSD se musim priznat neznam, vypada to jako maly hrac a komunitni projekt s nezavidenihodnou pozici kde takove chyby muzou akorat hasit a to navic asi ani nemaji informace pred tzv. embargem.

[trekker.dk]

Jo, pokud mám názor, že bezpečnostní chyby se mají řešit, ne zatajovat, tak se s vaším postojem, že je bezpečnější je tajit před lidmi, které ohrožují, opravdu neshodnu.

[Conscript89]

Ja nekdy rekl ze je lepsi je zatajovat nez resit?

[Conscript89]

Pokud ano, nebo pokud to tak vyznelo, tak to se omlouvam. Rozhodne bych nechtel, aby misto snahy o uplne reseni problemu se chyba proste ignorovala a zatajovala.

[trekker.dk]

Slovem řešit bylo myšleno buď přijít s opravou v rozumném čase, nebo jít s pravdou ven a říct, že to vyřešit nepůjde a že se musí postarat někdo jiný. Jak je vidět u zmíněného DragonFly, někdo jiný se dokázal postarat docela rychle.

[trekker.dk]

"urcite", "samozrejme", "prirozene" jsou krasna slova, kerymi se podklada tvrzeni.

Stačí zapojit rozum. Za fungující exploity se platí nemalé peníze a je spousta firem a státních organizací, které jsou na přesně tomhle - zneužívání chyb - založené. Jedna citace z LWN z 20.12.:

There are clear indications that more issues of this type will come to light in the near future. What we think of as "hardware" is increasingly made up of software with all of the problems that afflict software at higher levels.

Pokud o problému ví i (primárně) novinář a (v druhé řadě) řadový vývojář kernelu, který se nejvíc stará o dokumentaci, je dost naivní si myslet, že třípísmenkové organizace a hacker teamy jej přehlédnou a nevyužijí, dokud to jde.

[Ondrej Santiago Zajicek]

U chyb v software to dava smysl, protoze tam uzivatelum nakonec prijde oprava. Ale u chyby v procesoru tady Intel nekolik mesicu zatajoval kupujicim neopravitelnou vadu vyrobku.

[Conscript89]

Ano, s tim souhlasim, ze to je problem.

[ehm]

Vubec bych nebyl rad, kdyby se informovalo o chybe jeste pred vydanim jeji opravy, nicemu to nepomuze, spis naopak.

O tom řeč vůbec nebyla, ne? Spíš o tom, jestli vůbec někdy musí informovat. Ze zákonného hlediska asi nemusí, ale o to mi nešlo. Jen že by se možná vyplatilo místo cpaní peněz do reklam spíš vydat updaty firmwaru (a samozřejmě informovat a nezlehčovat to, působí to absurdně).

[marbu]

Jo souhlasím, proto jsem dohledal a linkoval tu zprávu o výsledku vyšetřování.

Na jednu stranu si neumím představit, že by se v případě CEO Intelu jednalo o legální postup, ale to jsem si původně nepředstavoval ani u toho Equifaxu ...

[Bystroushaak]

Tak přemýšlím, co s tím dělat na Mintu. Koukal jsem do fóra distribuce, a nevypadalo to, že by se zrovna chtěli přetrhnout.

[snajpa]

Prozatim nahod nekoho fixnuty kernel a pak muzeme vsichni cca cekat, co se vyvrbi s retpoline. Mozna nas ceka rebuild uplne vseho od kernel space po posledni userspace program. A mezitim vesele cekame na microcode update, aby zaclo chodit IBRS.

[little.owl]

Mozna nas ceka rebuild uplne vseho

Pevne doufam ze ne. Dopady na nektere aplikace mohou byt velke a retpoline navic podle vseho nemusi nic resit minimalne od Skylake vyse.

[pc2005]

Hlavně pokud opraví implementaci, aby na konci neúspěšné větve procesor zahodil opravdu všechny změny, tak by efektivně vznikl fork. Distribuce by musely dodávat retpoline balíčky a future-fixed-arch balíčky. FFA by sice na současných CPu jely, ale byly by otevřené útoku a retpoline by na budoucích jely taky, ale byly by zbytečně neoptimalizované.

[kralyk z abclinuxu]

Google [1]:

We shared Retpoline with our industry partners and have deployed it on Google’s systems, where we have observed negligible impact on performance. (...) In our own testing, we have found that microbenchmarks can show an exaggerated impact.

[little.owl]

To zalezi na aplikaci, takze na hodnoceni bych pockal. S LLVM patchem jsem videl propad 5-15%, coz mi jako "negligible" uplne neprijde, u gcc patche nevim.

[pc2005]

Na funkčním budoucím HW jsou slepé kusy kódu zhoršující čitelnost kódu zbytečné.

[little.owl]

Rozhovor s Lisa Su, AMD CEO na toto tema zde.

[trekker.dk]

3 minuty povídání o ničem

[kralyk z abclinuxu]

Tjn., ale zas musim ocenit tu ne-odpověď na tu otázku, jestli navrhli své cpus vědomě proti těmhle chybám

[little.owl]

To je tezke - ona je CEO, tak o takovych vecech vi nejspis kulovi a lhat ze zakona nesmi ... .

[Michal Kubeček]

Řekl bych, že před rozhovorem na takhle citlivé téma si nechá CEO připravit podklady od techniků i od právníků.

[Käyttäjä 11133]

lhat ze zakona nesmi ... .

Ze zákona se nesmí lhát, nebo to je nějaká specifická věc pro CEO?

[petrfm]

Lhát je právě zákonem výslovně povoleno. Je to právo každého obviněného člověka, že může lhát, pokud by pravdou poškodil sebe, nebo osoby sobě blízké Každá druhá reklama lže. Takže proč by nemohl lhát CEO. Spousta lidí začíná lhát už při podání ruky na otázku "jak se máte?".

[trekker.dk]

Můžete ocitovat příslušnou pasáž nějakého zákona, který v takovém případě povoluje lhaní? Mám o tom docela pochybnosti.

[snajpa]

A hele, zajimavy thread Ale aniz bych se pokousel ho rozbit - ja jsem si myslel, ze rozumne nastavene zakony funguji obracene, nez rozumne nastaveny firewall. Tedy ze se nezadouci chovani zakazuje, ne ze se vse zakaze a pak se delaji vyjimky.

[snajpa]

A lez samotna, preci trestna neni. Jenom v urcitem kontextu - pod prisahou, nebo pokud je ta lez zakladem podvodu, ktery je pak dokazan v trestne-pravnim rizeni. Tedy, nejdriv musime zaskodnikovi prokazat, ze lzi skodil. Moje navazujici otazka zni - mam ja nejaky dosah, jako obcan CR, nejak vznest podnet k prosetreni na osobu, ktera nema obcanstvi Ceske ani nikde v EU; ale presto je to osoba, ktera mne svym chovanim poskozuje? Jestli se nepletu, kdybych chtel delat moc velkej bugr, asi bych mohl zalovat primo ceskou organizacni pobocku Intelu, ale k cemu by to bylo? AFAIK maximum, ceho muzu od nas dosahnout, je tak maximalne rozpusteni Intel Czech Tradings, Inc., organizační složky.

[Käyttäjä 11133]

Podat tretní oznámení / civilní žalobu v zemi kde ta osoba sídlí? Bude to mít jednu nespornou výhodu; soudní systém v USA je mnohem efektivnější než ten český :)

[trekker.dk]

ja jsem si myslel, ze rozumne nastavene zakony funguji obracene, nez rozumne nastaveny firewall. Tedy ze se nezadouci chovani zakazuje, ne ze se vse zakaze a pak se delaji vyjimky. ... A lez samotna, preci trestna neni.

No jasně, ale zákon, který toto nežádoucí chování zakazuje, existuje: trestní zákoník, § 346 Křivá výpověď a nepravdivý znalecký posudek (zbytek v #311)

[Michal Kubeček]

Ono se to především týká jen svědka (nebo žalobce), od obžalovaného se to tak nějak čeká, že bude lhát (je-li vinen). Na druhou stranu ale souhlasím, že LZPS IIRC povoluje pouze odmítnout výpověď, lež by IMHO pořád byla důvodem k obvinění z křivé výpovědi.

Uniká mi ale relevance k tématu, tady šlo o obyčejný rozhovor pro média, tam může každý lhát podle libosti a riskuje tim jen svou pověst.

[Käyttäjä 11133]

Na druhou stranu ale souhlasím, že LZPS IIRC povoluje pouze odmítnout výpověď, lež by IMHO pořád byla důvodem k obvinění z křivé výpovědi.

V tom co dovoluje Listina máš pravdu, ale právní řád tvoří i judikatura a přestože nemám po ruce patřičný judikát, ani jsem ho nečetl, tak podle známého právníka z velké a prestižní právní kanceláře se kterým jsme to téma diskutovali je v trestněprávních sporech u obviněného lhaní naprosto akceptovatelným způsobem obrany.

[Michal Kubeček]

Kontext… přečti si větu předcházející té, kterou jsi ocitoval.

[little.owl]

OK, jinak - jako CEO verejne obchodovatelne firmy nesmi podavat verejne nepravdive informace, coz znamena ze nesmi [okate] lhat. Mlzit, zavadet a generovat vety s minimalnim faktickym obsahem muze a take je to casti jeji kvalifikace - o tom i vznikaji vedecke prace v duchu "Jak poznat, ze CEO lze.", treba zde.

[Käyttäjä 11133]

OK, jinak - jako CEO verejne obchodovatelne firmy nesmi podavat verejne nepravdive informace, coz znamena ze nesmi [okate] lhat.

Zdroj? To se IMHO bude týkat pouze informací, které se týkají finančního výkaznictví / můžou zásadním způsobem ovlivnit cenu akcií...

NOTE: Všimni si slovního spojení "zásadním způsobem".

[little.owl]

Musel jsem si vyzadat pomoc od znameho z Bar Council, zacinate me tlacit nekam, kde tomu moc nerozumim. Tohle se podle nej v anglosaskem svete ridi predenty. Verejna komunikace CEO verejne obchodovatelne spolecnosti se chape jako soucast jeho komunikace s akcionari ci potencionalnimi akcionari, kdy zejmena ti minoritni nemaji casto mnoho jinych cest jak si vytvorit obrazek a lzive vyjadreni CEO muze vest k nakupu nebo prodeji akcii a pripadnym skodam, takze tady nejde jen o cenu akcii. Podle jeho vyjadreni to ma v UK i legislativni podporu, jak je to USA si neni jist.

[trekker.dk]

Podle jeho vyjadreni to ma v UK i legislativni podporu, jak je to USA si neni jist.

Z toho, co jsem různě slyšel z amerických médií, je to v USA stejně.

[petrfm]

Nesmí okatě lhát? Takže když řekne, že si dal cestou do kanceláře hamburger, přitom z kamerového záznamu jasně vyplyne, že byl v KFC na křidýlka, tak kolik let mu hrozí? Plácáš nesmysly. Lže se zcela běžně a zcela běžně je taková lež prokázána, přesto nikomu nic nehrozí. Třeba prezident Drahoš lže přímo do kamery a to kandiduje na CEO České Republiky. A nikdo ho za to nemůže zavřít.

[petrfm]

Pardon, překlep, prezident to není a pevně věřím, že nikdy nebude.

[ehm]

Předřečník očividně myslel lhaní o záležitostech týkajících se firmy.

[petrfm]

A v čem je ku*va rozdíl? Tak řekne že všichni zaměstnanci firmy se stravují zdravě. I když žerou KFC. Už se konečně dozvím kolik let mu hrozí? Hrozí mu HO-V-NO.

[petrfm]

Lhaní vyjma pár jednotlivých případů, například zmiňované svědectví u soudu, atd. NENÍ TRESTNÉ. To by musela sedět půlka národa, protože všichni jsou ku*vy prolhané.

[ehm]

Za běžných okolností bych ti doporučil, aby sis nastudoval pojem klamavá reklama, ale když vidím tvoje chování nejen v tomto příspěvku, doporučil bych ti spíše přemístění do pavilonu opic, kde se otázkami, na které intelektuálně nestačíš, nemusíš trápit a spory se soukmenovci můžeš řešit tak, že po nich mrskneš HO-V-NO.