Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Informace v clanku nejsou az tak uplne korektni/presne, ve skutecnosti jde o tri ruzne varianty vulnereability a zde popisovany KPTI fix impactujici vykon CPU je pro variantu 3 ktera neplati pro AMD procesory.
Detaily uz znamy jsou protoze google zrusil NDA puvodne planovanou na pristi tyden: https://googleprojectzero.blogspot.cz/2018/01/reading-privileged-memory-...
Děkuji za doplnění informací. Článek byl psán ve chvíli, kdy NDA zrušeno ještě nebylo, a tak se o chybě mnoho nevědělo. Výše uvedený odkaz je sice delší čtení, ale pěkně podrobné.
Problemy Intelu jsou s Meltdown chybou. Spectre chyba(y) bude pravdepodobne resena aplikacne na urovni programu, podle komentaru, ktere jsem zatim cetl.
No nevim já jsem pošťouchnul naše IT oddělení s odkazem na uvedenou stránku už o 7:53, kdy na CDR/DIIT ještě nic nebylo ...
Jinak NSA asi právě přišlo o svůj největší hack - nevěřím, že toto nebylo v jejich arzenálu ...
to možná nebylo, ale článek mohl bejt psanej treba v noci, jestli se ranní obsah pripravuje predesly den... nekamenoval bych o tu +-hodinku, taky nejakou chvili ten obsah trva zpracovat, treba se tu oficialni vyjadreni taky objevi
Je to tak, jak píšete. Článek jsem psal včera večer/v noci, aby byl dnes připraven na vydání. Již je v přípravě článek s aktuálními informacemi.
Maly tip: byt Vami, zkusil bych udelat aktualizaci clanku ;)
Problém je, že aktualizace stejně většina čtenářů přehlédne. Na půlnoc chystám článek, možná z trochu jiného pohledu, který obsahuje některé další informace. Tohle se vyvíjí kontinuálně, takže žádný článek nemůže být zcela a stále aktuální.
Podla AMD
Variant / AMD Response Matrix
Google Project Zero (GPZ) Research Title Details
Variant One Bounds Check Bypass Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected.
Variant Two Branch Target Injection Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
Variant Three Rogue Data Cache Load Zero AMD vulnerability due to AMD architecture differences.
https://www.amd.com/en/corporate/speculative-execution
No jo, ale aby Intel v "rámci konkurenčního boje" neprosadil zpomalení i AMD :(
Mozno by trebalo informacie aktualizovat.
Intel sa uz vyjadril, aspon zbezne.
A aktualizacia je uz od vcera dostupna aj pre Windows.
A co mne a jinym pomuze ze se Intel vyjadril? nasrat mu do kalhot!, procesory exkluzivne prodrazene, to jo, ale kvalita sla za roky ukazkove bobkem, tipuji ze i ten slavny ony 18 jaderny procesor nepastovany za 2100€ touhle chybou trpi tez, nepodpora funkce ECC je jiz tomu jenom slehacka na zaver.
Spise si tipuju ze timhle budou trpet i nasledujici procesory jejichz vyvoj uz byl vicemene dokoncen protoze fix bude zrejme znamenat vyraznou zmenu architektury.
Nerev. Nikto ta to nenuti kupovat.
Ta aktualizacia zo vcera neriei ten to problem - je to ine KB, hoici je to tiez aktualizacia jadra ohladom x86_64
Prodeje nových PC mají již několik let klesající tendenci. Stagnující byznyš je potřeba rozhýbat... Tak zavřeme zadní vrátka, snížíme tím výkon, aby se začali prodávat nové CPU s novými zadními vrátky. Win win situace - rozhýbou se prodeje, třípísmenková agentura o zadní vrátka nepřijde, akorát zákazníci si zaplatí, ale slovy klasika: "Na lidi se vysrat, je jich jako sraček".
Popíšu sem zjednodušeně vektor útoku, protože mi přijde nesmírně zajímavý. V procesorech jsou už od dob (myslím) 386ky tzv. ringy - což je úroveň izolace kódu. Normálně jsou čtyři nebo pět - ring 0 až ring 3, při zapnuté virtualizaci ještě ring -1, kde běží hypervisor. Procesor se hardwarově stará o to, aby v daném ringu mohl kód číst / zapisovat paměť daného ringu a všech s vyšším číslem, tzn. v ringu -1 jde číst veškerá paměť, v ringu 0 jde číst paměť ringů 0, 1, 2 a 3 a tak dále, až v ringu 3 je přístup pouze do ringu 3. Operační systémy jsou designované tak, že jaderný kód běží v ringu 0 a userspace programy v ringu 3. Kernel tedy může číst celou paměť a userspace nemá do kernel paměti přístup.
Pokud tedy máme instrukce:
mov rax, [kernelmemory]; (načti do registru rax něco z paměti jádra)
mov rbx, [usermemory]; (načti do registru rbx něco z paměti procesu)
...provádění se zastaví na první instrukci a vyhodnotí ji jako neplatnou, druhá instrukce se vůbec neprovede. Nebo ano? Co když procesor pomocí spekulativního provádění instrukcí načne ještě druhou instrukci a načte opravdu kus paměti, který pak zahodí? V podstatě je to jedno, není způsob, jak by se uživatel dostal k výsledku druhé instrukce, protože tato větev provádění byla zahozena uvnitř procesoru. Ale nezanechá to náhodou za sebou nějakou stopu, nějakého ducha?
Zkusme tyto instrukce:
mov rax, [kernelmemory]; (načti do registru rax něco z paměti jádra)
and rax, 1; (nastav rax na 0, pokud hodnota byla sudá, na 1, pokud byla lichá)
mov rbx, [usermemory + rax]; načti do rbx hodnotu z adresy usermemory + 0 nebo usermemory + 1
První instrukce je zablokována samotným procesorem na úrovni hardwaru, takže k provedení druhé a třetí nedojde. Nebo možná je procesor v rámci spekulativního provádění provede, ale pak tuto větev výpočtu zahodí, protože první instrukce nebude provedena (nedozraje) do konce. Není to jedno? Je?
Není! Můžme se totiž pokusit najít jakéhosi ducha, který po zahození výpočtu zůstane. Kde? V cache! Pokud jsme spekulativně načetli adresu "usermemory", pak ji máme z cache dostupnou zásadně rychleji, než "usermemory + 1", což se stalo, pokud adresa kernelmemory obsahovala sudé číslo. Naopak pokud byla lichá, tak přístup k "usermemory + 1" bude zásadně rychlejší, než k "usermemory". Rozdíl mezi cache a pamětí může být až 40x, což není problém detekovat.
Přečíst paměť jádra se nám tedy nepodařilo přímo, ale našli jsme jakéhosi ducha, který zůstal po zahozeném spekulativním provedení instrukce.
Zdroj: https://nakedsecurity.sophos.com/2018/01/03/fckwit-aka-kaiser-aka-kpti-i...
Teď si představte, jak funguje patch jádra. Při přepínání kontextu mezi jádrem a userspace musí jádro vyprázdnit citlivé části paměti jádra pro jistotu úplně, při přepínání do kernel space je zase nahrát. Pěkný hnus.
Jinak mi přijde poměrně haluzní, že toto funguje jenom u Intelu. Nicméně jak jsem prohrabával těmi PDFky, našel jsem informace, že podobné duchy lze detekovat i u AMD / ARMu, jenom není zatím úplně známý způsob, jak je deterministicky využít, u Intelu se to už povedlo.
Další vektor je taky hrozně cool:
1) Alokuju 256 stránek a flushnu TLB.
2) Udělám relativní MOV pro čtení z této paměti. Jako offset použiju bajt na adrese v prostoru jádra a jako koeficient velikost stránky (byte x = mem [(*p) * 4096];)
3) To mě samozřejmě pošle do háje, protože na ten bajt v jádře přístup nemám.
4) Jenže procesor do TLB spekulativně fetchne stránku, ze které by se četlo, kdybych na ten bajt přístup měl.
5) Do TLB taky nevidím, ale přístup ke stránkám, které v TLB jsou, je mnohem rychlejší. Zkusím tedy všech 256, změřím rychlost přístupu, a voilà, znám hodnotu bajtu z jádra.
6) Opakuju pro všechny ostatní bajty.
Pár řádků kódu.
Ve zprávách na ČRo Plus tvrdí, že chybu našel Google a chyba se týká i procesorů AMD a ARM, v článku nic takového není. Jak to tedy je?
Právě o tom mluvili ... (od 12:13) http://www.rozhlas.cz/plus/zaznamy/#/2018-01-04
Prý se nejedná jen o Intel.
no ty slabiny tam jsou celkem tri.. prvni uz je vyresena v sw patchich a slo teda spis o problem na sw urovni.. druhou se na hw amd na rozdil od intelu nepodarilo zneuzit a amd tvrdi ze tam je skoro nulova sance, ze by se to mohlo podarit.. a treti se amd netyka vubec pze co je k jejimu vyuziti treba na hw urovni ma amd reseny uplne jinak nez intel.. u arm je to asi slozitejsi..
Tak a ted si kupte ty slavne, prodrazene ale ve vysledku silne nekvalitni Intel procesory, nestaci ze se jejich jadra k IHS jiz nepaji ale potiraji pastou horsi nez si zakaznik dokaze sam zakoupit, ze se nasilne skrze mikrokod omezuje kompatiblita tehleh procesoru v jinak pinove identickem socketu, ze za nedostacujici ctyrjadra za-platili zakaznici kym neprijel RyZen od AMD krvave castky, ze na HEDT platforme X299 si museji zaplatit jeste sa NVMe RAID dodatecne i kdyz zakladni deska stoji vic jak 450€, ne jeste k tomu prijde interni hw chyba(!) ktera umoznuje z citlive, interni pameti cache procesoru vykradat intimni logovaci data, klice, hesla, a pote verte ze sou vase soukroma data v bezpeci, ze je Windows 10 zadarmo, ja bych nebyl daleko od pravdy ak by dana dira byla cilene Intel-em pripravena/otevrena a jenom o ni "laicka" spolecnost nevedela ale NSA ano, hadam si nekdo nemysli ze by v Microsoftu nebo Intel-u, firmach kde se toci miliardy dolaru rocne a disponuji nadanyma lidma/mozky, nevedelo o tomhle zneuziti, ono se to dobre vedelo ale naschval se to tak nechalo, co se tyce znizeni vykonu, kdyz to bude citelne znizeni intel si pote sam nasral do kalhot a dal nechapu kdyz AMD neni tymhle dotcene proc se ma aplikovat dotcena oprava i pro jeji procesory? inu kdyz se posira intel ma se lepsi AMD svezt umele s nim? a nebo jde jeste o cil nasilne vymenit starsi pocitace a tak umele podporit prodej novych pc-ček nejlepe zas s posranymi intely a windows 10 ktery se na vic nezmaha? po praktikach automobilek, spolecnosti Apple, se nemusi vubec jednat o konspiraci ale o tvrdou, skazenou pravdu.
"chyba se týká i procesorů AMD a ARM", navzdory tomu co je uvedené v článku. ;-)
Není pravda, jak podle článků na jiných webech, tak podle vyjádření přímo AMD, kde si vzal tu dezinformaci?
ČRo Plus (od 12:13) http://www.rozhlas.cz/plus/zaznamy/#/2018-01-04
Jestli je CR+ zrovna idealni zdroj informaci o tom se da v klidu pochybovat :))
Není to IT rozhlas, na druhou stranu je důvěryhodnější než aeronet nebo sputnik. Jo a dávat mi mínusy za to, že uvádím kde jsem získal informaci, která nekoresponduje se zdejším článkem? Co k tomu dodat ... :-/
Já neříkám, že má jeden nebo druhý pravdu, ale ani zde v diskusi nenacházím nezvratné důkazy o tom, kdo s chybou přišel a jakých (dalších) procesorů se to s určitostí týká.
Takže předem díky za další mínusy. :-)
ode mě nemáš mínus za to, že si "získal informaci, která nekoresponduje se zdejším článkem"....to je naopak podle mě v pořádku, mínus máš za to, že JPP v místním rozhlasu....t.a.
Proc ti davaji minusy nevim, ale spis bych zkusil aplikovat selsky rozum.
Kdyz jsem na IT magazinu, tak preci se asi ocekava zdroj napr. Z jinych IT periodik, ktere jsou urceny primarne pro fanouse stejneho druhu jako tady ;
CR+ fakt asi neee :)
"chyba se týká i procesorů AMD a ARM"
Je to trochu komplikovanejsi, jak uz to byva - tech nalezenych moznych zpusobu utoku (a chyb v CPU) je vic, a **nektere** (myslim ze jenom 1) se tyka i AMD, zbytek ne.
Ta chyba, kterezto reseni zpusobuje propad vykonu, v AMD neni. Oprava tech zbylych zadnej propad vykonu nezpusobi, jelikoz zadna oprava pro ne neexistuje :D plati pro AMD i Intel... proste nektere chyby lze resit jenom redesignem hardwaru.
Tak sis jako obvykle zanadával, zahejtoval, zakonspiroval... A co si pečlivě přečíst dokument hned z prvního komentáře a pokusit se pochopit jeho obsah. V procesoru není HW chyba, je to zranitelnost způsobená tím, že někdo dokáže analyzovat zpoždění při operacích v cache a tím může být schopen odhadnout výsledek v ní uložený. Někdo tedy vymyslel techniku, jak "se podívat do popelnice" aniž by otevřel víko. Podobná zranitelnost se týká asi všech prcesorů se spekulativním prováděním instrukcí a s datovou cache (tedy všechny současné CPU včetně ARMů).
nesir tu nesmysly, prave rogue data cache load co tu popisujes se amd netyka vubec.. (:
Jsem to asi neformuloval správně, někde jsem tam ztratil slovo kupříkladu, každopádně zranitelnosti plynoucí ze spekulativního zpracování kódu se jich týkají (nebylo zatím zkoumáno dostatečné množství CPU), problém s cache "rogue cache load" se AMD skutečně netýká.
http://www.amd.com/en/corporate/speculative-execution
Hele, tady mas vyjadreni Linuse.. ja myslim, ze v jeho pripade se da kompetentnost predpokladat a nenechava na Intelu nit suchou...a nazyva to "marketingovymi zvasty" :))
“ A *competent* CPU engineer would fix this by making sure speculation doesn’t happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.
I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.
.. and that really means that all these mitigation patches should be written with „not all CPU’s are crap“ in mind.
Or is Intel basically saying „we are committed to selling you shit forever and ever, and never fixing anything“?
Because if that’s the case, maybe we should start looking towards the ARM64 people more.
Please talk to management. Because I really see exactly two possibibilities: Intel never intends to fix anything OR these workarounds should have a way to disable them. Which of the two is it?
Linus Torvalds“
Jo, ten si nikdy nebere servítky. :-)
On si Intel zaslouží po papuli, ne že ne, ale tak nějak věcně a odborně, abych tak řekl, umlátit je argumenty bez hospodského nadávání.
Nerev. A nasad si alobalovu ciapku.
Je někde seznam _konkrétních_ procesorů, kterých se to týká a kterých ne?
Podle toho co ctu (muzu se mylit):
Vuci kernel readable pages (PTI) jsou zranitelne vsechny Intely minimalne od Ivy Bridge, nejspis i dal zpatky. AMD zrovna tenhle bug nema.
Vuci tem utokum na spekulativni cache read, jsou nejspis zranitelne vsechny CPU ktere maji TLB a spekulaci, tj asi tak zhruba 100% vyrobenych CPU od zacatku milenia ;) teoreticky by mohli byt OK in-order procaky..
Ano, některé z nejranějších in-order Atomů jsou OK.
Hmm...
"Prozkoumání patche ale odhalilo, že fix je aktivní pro všechny x86 procesory, a to i přesto, že v dřívějších commitech do Linux kernel gitu byla pro AMD výjimka. To naznačuje, že žádosti AMD o neošetřování problému na jejich procesorech nebylo vyslyšeno, a je tak možné, že se zhoršení výkonu bude týkat i jich. Ideálně by se nyní AMD měla snažit dokázat, že bugem nejsou jejich CPU dotčeny, aby na systému s CPU AMD nebyl patch aplikován (aktivován)."
Podle toho, co jsem cetl ja, tak to bylo trochu jinak, nicmene: patch je uz v git masteri Linuse:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/
x86/cpu, x86/pti: Do not enable PTI on AMD processors
Takze AMD je (castecne) v suchu.
tak AMD sa to netyka:
http://www.guru3d.com/news-story/amd-rsponds-on-amd-processor-security-s...
Podle aktualnich odhadu bude vykonostni dopad 5-30% - herni aplikace by nemely byt timto zasazeny. Sice jsem intelak, ale nejdriv pasta sedivka a ted tohle, to opravdu intel produkuje polo-shity jelikoz nemel od AMD nekolik let poradnou konkurenci a tim padem si mohl dirigovat co chtel?
Finalni porada pred propagaci noveho produktu u intelu asi vypada takto:
Inzenyri: "Vime o nekolika chybach a je mozne, ze se procesory kvuli nekvalitni paste budou prehrivat i s kvalitnim chlazenim."
Management: "Pripadne chyby opravite za behu. Muzete pripravit i Kckovou verzi pro taktovani?"
Inzenyri: "...."
Kupoval jsem Intel, protože byl lepší. Už není :)
Vykon, spotreba, teploty - ano to byl lepsi jak AMD, je asi zbytecne rikat "co kdyby" AMD bylo celou dobu konkurenci. Jsme zvykli, ze od intelu dostaneme za sve penize kvalitu, ale jak to posledni 1-2 roky pozoruju, tak intel jede na nejakou setrvacnost - velmi rad si priplatim 2 eura, aby mel CPU poradnou pastu pod IHS a nemusel jsem svuj "taktovaci" CPU delidovat.
Mam doma 2 stroje, jeden jede jeste na i7 920 taktovana na 4.1GHz (noctua nh-d14, 60 stupnu max), druhy jede na 7700K - bohuzel jsem musel delidovat i na zakladni fekvenci, chlazeno noctua nh-d15, nejmenovany zeleny ufon mi neuznal reklamaci, ze jde o cpu zmetek - 85 stupnu v idlu bez taktovani, takze jsem to risknul a po delidu 50 stupnu dole, cili v idlu 35 stupnu. Timhle u me intel hodne klesl a slavne coffee lake kde udelali pomalu "jen" pridame 2 jadra a zvysime trochu takt oproti kaby lake je slabota.
Velmi fandim AMD a ZEN platforme, kez by mely Ryzeny (snad druha generace) podobny vykon na jedno jadro jako Intel - rad hraju, hlavne Arma 3 multiplayer a to chce vykon jednoho jadra co to jen jde. Obecne se mi Ryzeny jevi jako hodne kvalitni produkt co mel sice na zacatku problemy s optimalizaci na win 10, ale aspon nema technologicke kiksy jako intel, odpoved intelu v podobe coffee lake (pro me recyklovane kaby lake) je trochu dukazem toho, ze si nas Intel za ta leta vycvicil kupovat jejich produkt za penize, ktere k jeho kvalite nejsou primerene.
Vůbec bych se nedivil.....kdyby se ukázalo, že nějaký IT specialista ( čti zástupce firmy Intel ) zásobuje media zprávami o tom že se ty chyby týkají procesorů všech značek.....
lid je třeba krmit těmi správnými informacemi...(to k tomu českému rozhlasu výše) ...reportáž jsem slyšel......a funguje to tak, že i když to někdo později vysvětlí (uvede na pravou míru) tak ta původní informace je už rozšířená :(
Příští patch zakáže cache... další zakáže celej procesor a ten poslední přijde chlápek a ustřihne elektroměr )))
:D
prej existuje nějaký seznam postižených CPU a i5ky tam nejsou. Že by to byly jen procáky s HT ?
Seznam je dlouhy, ale celkem jednoduchy. Postizeny jsou vsechny x86 intel cpu s out-of order. To jest od roku 1995 a pentia pro. Postizeny nejsou x86 intel cpu s in-order, coz jsou atomy nekdy do roku 2013.
https://spectreattack.com/
Meltdown: 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).
Spectre: Almost every system is affected by Spectre. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
Ví se číslo záplaty, která tyhle chyby ve Win řeší?
Zajímavý je, že se to teď na Intel hrne ze všech stran - s ARM v podstatě prohrál, s AMD teď zrovna taky, na nanometry nejspíš prohraje v nejbližší době. By mě zajímalo, co se ještě najde :)
CEO asi vi proc prodal vsechny akcie ktere mohl :)
Tak s AMD neprohral ani zdaleka... na nanometry mozna prohraje "ciselne" ale realne jsou jejich procesy porad lepsi nez podobne cislovana konkurence... a obcas maji par zajimavych produktu (Optane, Xeon Phi) ktere ale z nejakeho duvodu nejsou schopni poradne rozjet. Nebo mozna jim vyhovuji ty brutalni marze vic nez high-volume mass market. Ale jinak souhlas, s novymi trhy maji docela problemy... podle me jejich zasadni problem je, ze navykli akcionare na brutalni marze, jenomze tuhle pisnicku lze hrat jenom na velmi malo trzich, a ne moc dlouho... SSD - jenom podnikova, procaky - jenom kdyz je AMD v pytli (zrovna ted neni), mobilni trh - nulova sance porazit ARM dokud trvaji na tech marzich...
Tak už je Vám jasné, proč nové Opterony šifrují data uložená v paměti?
Něco za něco, s tím, že to "za něco" se intelu moc nepovedlo. Jestli to tak půjde s intelem dále, tak si HW diverzitu doma neudržím :(
A co na to Redmarx? :)
Redmarx pride s informaci, ze ted uz jedine zase Ryzen ;)
chyba se týká i AMD...
Ta nejzavaznejsi co bude mit nejvetsi dopad na vykon se AMD netyka.
Oprava na Win 7 64bit má číslo KB4056894/KB4056897 (Montly Rollup/Security-only)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.