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.
Jsem zvědavý na nějaké rozsáhlejší testy po "zaslepení" přítoku žumpy a nemyslím to nějak zle vůči Intelu a ostatním, ale.......Představte si situaci, že by udělali výrobci cashback :D, a proč ne?..taky nejdete do krámu pro deset rohlíků a domů jich donesete osm :D (nebo jo?)
Spíž koupím si 10 rohlíků a pak příjde pekař že si dva bere zpátky. Ale teď je spíž otázka jestli obejde i lidi co nakoupily rohlíky jinde u kvalitních pekařů. Už se těším na testy ryzen vs keby,coffi. A pak vyjádření Intelu. Ale Intel je neuvěřitelná špína že to chce hodit na všechny aby výkon sundali všem.
No fér to rozhodně není, zvlášť pokud to ostatní výrobce ta chyba jen "škrtne". Ale co čekat od kněze, který tu pár let vedl kázání o čtyřjádrovém nebi, že nic lepšího nemůže být a platili se mu nehorázný odpustky, konkurence velikosti školního kroužku, kde členové hrají na cymbál, kterým se chodil smát do okna. Pak cymbálka rozjela turné, vstupné za pade a černoprdelník se chytal za hlavu a přepsal písmo svaté v naději, že se mu zvýší návštěvnost, která mu trochu opadla, aby dohnal svojí nenažranost. Pak příjde do kostela bezpečák a řekne knězi ať si sežene dvacet hasičáků a jeho nenapadne nic lepšího než potopit v tom celou vesnici. Typický obraz dnešní doby "já ne, to voni" a nedej bože abyste na tom byli lépe než ostatní, úspěch se neodpouští.
Jo, to je "privatizace zisků a socializace nákladů" v praxi. :-)
No ono to nakonec zas tak hrozne asi nedopadne, ale ty testy nepokryvaji vse, v nejakem specifickem pripade to uz muze byt znatelne...
https://www.phoronix.com/scan.php?page=article&item=linux-kpti-pcid&num=1
Děkuji za první nestranný článek na toto téma.
Též se musím přidat, napsané jasně a srozumitelně.
Ehm to s tím časem je trochu jinak. Spekulativně spuštěný kód čte z paměti, která je mimo rozsah. K tomu dochází proto, že procesor ještě rozsah nezná. A teď to hlavní - spekulativně spuštěný kód nemá normálně jak předat data nespekulativní větvi programu. To obejde tím, že načtě konkrétní část paměti do cache. Nejde o to, co v této paměti je. Jde o adresu této paměti. Tato adresa totiž musí být přístupná i nespekulativní větvi programu. Tato nespekulativní větev potom vyzkouší, za jak dlouho načte data z této adresy - rychle = 1, pomalu = 0. Tím došlo k přenosu informace ze spekulativní větve programu do nespekulativní. Toto je problém značený googlem jako 1 a "trpí" jim všechny CPU. Jediné co se podařilo obejít, je kontrola rozsahu, což samo o sobě není problém, pokud v daném adresním prostoru není nic, na co by se progem neměl dostat.
Problém (Google ho označil jako 2) u Intelu ovšem je, že při spekulativním provádění kódu je možno přistupovat i k paměti, ke které nespekulativní kód přistupovat nemúže. Tyto kontroly jsou odloženy až na dobu, kdy se zjistí, že tato spekulativní větev se provede. Jenže za použití techniky ad 1 lze tyto informace předat a tím se přístup k této paměti všem kontrolám vyhul.
Ono po pravdě Google to zkoušel pouze na procesoru Haswell a samotné tvrzení AMD u 2 že to téměř jistě nejde nezní moc sebejistě :)
K té poslední větě: Pokud vím, tak je nesmírně obtížné a u složitějších problémů téměř nemožné dokázat, že žádný postup neexistuje. Opak je snadný - stačí najít jedinou funkční metodu. Pokud je problém 2) definován spíš principem, než jedinou možnou implementací, tak se odpovědi AMD nelze divit.
"Jenže na úrovni spekulativního provádění mohl kód běžet dál, provést ještě další instrukci (či instrukce) a pozůstatky po těchto úkonech zůstávají ležet v cache procesoru, dokud nejsou přepsány. Protože cache nižší úrovně nebo operační paměť funguje pomaleji než cache vyšší úrovně, existuje určitý čas k těmto datům, ke kterým neměl mít uživatel přístup, přistupovat a případně si je zkopírovat a dál je využít."
no-x: troška ma zmiatlo pomenovanie tých úrovni cache nižšej a vyššej.
Cache nižšej úrovne je predsa L1 cache voči vyššej úrovni L2 cache atď. pričom platí, že L1 cache je extrémne rýchla doslova by sa dalo povedať, že je taká rýchla ako samo jadro.
Takový názor slyším prvně. Cache vyšší úrovně je blíže jádru (L1) než cache nižší úrovně (L2). Jako LLC, tedy last-level cache (cache nejnižší úrovně) bývá označována ta nejvzdálenější, obvykle L3 nebo L4. Viz např. https://en.wikipedia.org/wiki/Cache_hierarchy
Oki dík za ujasnenie formy, ale skôr mi išlo o obsah pretože v podstate ide o ten čas ruka v ruke s prístupom do jednotlivých úrovní cache, kedy procesory AMD (ako aj VIA) využívajú exclusive L2 cache (obsah L1 cache nie je skopírovaný do L2 cache) a Intel používa inclusive L2 cache (obsah L1 cache je skopírovaný do L2 cache) aj keď z pohľadu tohto ďalšieho rozdelenia napr. AMD Ryzen L3 voči L2 funguje “mostly exclusive” ako jej victim cache.
Tým chcem povedať pozostatky inštruckcie (inštrukcii) tak zostávaju v najrýchlejšej L1 cache (resp. L1-I) vyššej úrovne a takpovediac stihnú sa skôr prepísať ako by k nim operačná pamäť vôbec stihla prristúpiť resp. skopírovať a ďalej využiť, keďže ani nižšie úrovne L2 (L3) vžďaka exclusivite v vrámci smart cache subsystému do nej nemajú prístup.
"ako by k nim operačná pamäť vôbec stihla prristúpiť "
Ten celej exploit kód běží v procesoru v tu chvíli (scheduler, TLB a L1 cache), je malej a teprve výsledky probublají do nižších úrovní cache a poté paměti. Paměť je blbá a nikam nesahá, že procesor na ni čeká, než něco najde a "sáhne mu" do L3(/4/5/6) cache (procesor si to tam z ní zkopíruje - vydal před desítkami cyklů požadavek fetch a čeká na oznámení o ukončení přenosu), tak to je zvrácená logika.
Ci sa budu urovne oznacovat smerom od procesora, alebo smerom od RAM je nepodstatne. Podstatne je, ze co je v tom odstavci napisane je fakticky nespravne. Podstatou utoku nie je to, ze spekulativne vykonany kod spristupni nejake data, ktore by spristupnit nemal. Podstatou utoku je to, ze je mozne z nespekulativne vykonaneho kodu ovladat, co spekulativne vykonany kod skusi vykonat a potom je mozne zistit, co sa vykonat pokusil. Nie je mozne citat data, ktore sa dostali do cache vplyvom spekulativne vykonaneho kodu, ale je mozne zistit, ktore data sa do cache dostali. Ak sa spekulativne vykona kod, ktory vyzera vhodne, je tym mozne docielit ovplyvnenia toho, ktore data sa dostanu do cache na zaklade obsahu pamate v chranenom / cudzom pamatovom priestore.
Intel ma maly bonus v tom, ze spekulativne vykonany kod, ktory bude zostreleny HW vynimkou zjavne ignoruje pravidla ochrany pamate. Skoro to vyzera tak, ako keby sa pri inteli tieto pravidla kontrolovali az po ukonceni vykonavania instrukcie, alebo memory manager kopiroval data do cache v momente, ked nadabi v bufferi na nieco, co vyzera ako pointer.
Moc hezky zpracovaný článek, díky.
Chcem sa spýtať či je potvrdené že tú chybu niekto aj prakticky využil, alebo je to celé len v teoretickej rovine v tom že to môže niekto zneužiť ?
Na Meltdown je venku už proof-of-concept (tedy ukázkový kód, který funguje).
S zneužitelností této chyby je to myslím dost diskutabilní. Jedna z věcí, které se při bezpečnostních auditech software testuje je to, jak nakládá s citlivými údaji, např. hesly. Správně by se tyto nikdy neměly dlouhodobě nikde vyskytovat v otevřené podobě, to znamená, že i v paměti by měl program heslo použít pro ověření, a před tím než paměť uvolní musí správně její obsah vynulovat.
Pro případné využití je tedy potřeba další chyba v nějakém SW při práci s hesly, klíči atd.
Naproste nepochopeni problemu.
Navic ono co nejkatsi je pomerne dlouhe a dost spatne se pocita s citlivimi daty, kdyz jsou sifrovana. O vyhledavani v nich nemluve :D .
Hledáš data i šifrovací klíč k nim, oboje je někde v paměti (ten klíč zcela jistě v '"ring 0").
Ne, diskutabilni tam neni zhola nic.
Pote co clovek odemkne sifrovany disk, je cisty klic v nejake podobe v pameti jadra celou dobu, do chvile nez ho zase zamkne nebo vypne komp, coz muzou byt klidne hodiny / dny.
To same plati pro zbytek. Vseobecne se nejakym zpusobem (asym. krypto, PBKDF, atd) z hesla generuje / odemkne skutecny klic pouzity pro sym. krypto, a ten pak zustava v pameti do konce pouziti (disku, HTTPS spojeni, VPN, atd), coz opet muzou byt hodiny/dny.
Jedine reseni je vyhodit to heslo z pameti po chvilce necinnosti, a pak otravovat uzivatele az je ho znovu potreba, ale tohle reseni by vam v praxi uzivatele velmi rychle omlatili o kebuli.
Arm se k tomu postavil celem. Vydal jasnou a prehlednou tabulku postizenych jader, kde je jasne napsano kterou z tech tri chyb je jake jadro postizeno. A75 postihuje i meltdown (takze v tom fakt intel neni sam), nektere postihuje jeho lehci verze https://developer.arm.com/support/security-update
Zaujímavé je, že A75 implementoval len Intel.
Samsung a Qualcomm používajú deriváty. Kirin 970 má A73. Podobne TSMC v test vehicloch použila A72.
Jak se ten Cortex-A75 procesor od Intelu jmenuj?
Byl by nějaká odkaz?
Pôvodne mal byť už v tohtoročných LG ale je 10nm takže ho ešte nevydali.
Zatiaľ ho majú len na waferi (osobne pochybujem či vôbec funguje a už vôbec či dosahuje tých sľúbených 3GHz).
https://newsroom.intel.com/news/intel-technology-manufacturing-day-china/
To je ale standardní implementace od ARM jenom vyrobená technologií Intelu.
Viem, len vravím že je zaujímavé že jediný ARM ktorý má vážnejší problém je ten, ktorý používa výhradne Intel.
Náhoda? :D
Jasně, v pořádku. Jen mně to zajímalo. Jsem zvědav co Qualcomm Centriq.
Intelem to v tomto případě asi nebude když návrh jádra je od ARM a Intel dodal jen výrobní technologii.
A co Snapdragon 845? Tam je A75 v Kryo385 Gold.
To je právě derivát Cortex-A75, tedy ne referenční jádro od ARM.
Jestli se tam ta chyba vyskytuje je otázka. K tomu by se měl vyjádřit Qualcomm.
Nevím, jestli je to náhoda, ale posledních asi 14 dní mi začal padat komp (win 10) na access violation stop code exception nebo tak nějak. Někdy 3 x denně (max), někdy ani jednou... Že by MS už něco zazáplatoval a do té doby takovéto "rogue" chování vyjímku nezpůsobovalo? A co vy?
Ale může to být novými drivery od Intel GPU a/nebo novým Firefoxem Quantum...
Kamaradovy padaji Win10 od doby upgradu z Win7.... presne stejnym stylem, ktery popisujete .. nahodne :)
Mne sa po nainstalovani macOs 10.13.2 (ktora vraj obsahuje zaplatu na meltdown) citelne spomalilo browsovanie. Akoby prestala fungovat akceleracia grafikou, kazde vykreslovanie stranky vytazuje CPU.
Niekde na zaciatku kauzy som cital domnienku, ze oprava bodu 3 cez Windows sa vykonovo dotkne aj Amd procesorov, napriek tomu, ze ju nepoterbuju. Co je na tomto pravdy?
Otázkou je důvod, proč a čím (kým) je k tomu vydavatel softwaru nucen, ale prozatím jsou záplaty aplikovány na OS bez rozdílu toho, zda danou zranitelností procesor trpí, nebo ne.
Tím pádem jsou pro třetí variantu chyby záplatovány i stroje jedoucí na AMD - a ten patch prostě implicitně má znatelný dopad na výkon. (znatelný... to je také rozporuplné tvrzení, ono záleží na typu využívání, kdy nejvíc trpí serverové nasazení, kde se neustále skáče z jedné úrovně oprávnění do druhé)
Takze Ryzenaci maju na Windowsoch smolu,trest bude kolektivny a ziadna vacsia zmena pomeru sil ku Coffelaku nehrozi.
To není úplně tak pravda - patch v určitých případech vynucuje vymazání cache procesoru. Zatímco Intel tento krok bolí, pro AMD je to vyloženě zásah do nejcitlivějšího místa. Takže v konečném důsledku to klidně může být Ryzen, co to odnese nejvíc.:)
Prozatím bych se ale radši vyhnul spekulacím, nechal to odležet a počkal si, jak to dopadne v reálu.
edit: Linuxáci také...
Zda Windowsáci netuším, to si počkám až ten patch někdo reverse-engineerne, nicméně do Linuxu se ten patch, vyjímající AMD z KPTI, nakonec dostal. Resp. už před 47 hodinami: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi...
Je to jen drb.. Viděl jsem několik komentářů, kde někdo spouštěl ten skript na zjištění stavu na opatchovaném Win a na AMD platformě je to vypnutý :)
BTW vsichni to mate uplne spatne, zadny bug neexistuje. Tady je to vysvetleno:
https://s3.kuschku.de/public/intel_meltdown_meme_patrick_wallet_2.png
Cast vpravo je primo ze stranek Intelu, ta vlevo je vysvetleni pro mene chapave ;) Tak jeste jednou, opakujte po me: Bug ? What bug ? There is no bug.
BTW2 firma intel ohlasila nove logo:
https://i.redd.it/2xyoxg8hl1801.png
+1 :D
"Běžného domácího uživatele s Haswellem či Broadwellem asi hypotetické riziko místního útoku bude trápit méně, než jistý výkonnostní propad ve hrách a aplikacích."
A co javascript na webu?
Řadový BFU cpe osobní informace, přístupy k mailu a svoje hesla korporacím dobrovolně a s radostí, takže mu to imho bude zcela jedno :-)
Hesla a podobne citlive udaje vetsinou ani bfu nesdileji kazdemu. Proto mi prijde zvlastni doporucovat vymenit rychlost za bezpeci. Nehlede na to ze diky webu a javascriptu se nemusi jendat jen o lokalni utok.
Bylo by dobre tu posledni vetu alespon trochu preformulovat a upozornit na moznost utoku pres browser.
JavaScript neumožňuje přímou práci s pamětí.
https://www.bleepingcomputer.com/news/security/mozilla-confirms-web-base...
Aha, SharedArrayBuffer jsem neznal. Ale na ošetření by mělo časem stačit aktualizovat prohlížeč, či mu do té doby tuto funkci vypnout.
Bezni uzivatele aktualizuji browser a muzou byt docela v klidu, protoze jde o lokalni exploit.
Prusvih je meltdown na verejnem cloudu, virtualizaci nebo obecne tam, kde potencialne neduveryhodni lide uzivaji HW spolecne s vami. Pokud tomu spravne rozumim, tak libovolny user vm/konteineru/serveru teoreticky potrebuje jen prava spustit binarku nebo pristup k interpretu s presnymi timery a primym pristupem do RAM. Pak muze celkem pomalu scannovat celou RAM a zaznamenavat si vsechno zajimave. Jako bonus nezustavaji zadne snadno viditelne stopy.
Myslíte, že to Google objevil náhodou nebo při pokusech dozvědět se více o Intel ME bežícího až v ring -3?
Tady jsou vysledky mereni po aplikaci patche ve Windows pro Meltdown a nahrani noveho Intel Mikrokodu pro Spectre "2" variantu pres Asus X370 MB. Vysledky zacinaji byt zajimave (pokud jsou korektni) a dochazi k dost necekanym poklesum vykonu
https://www.reddit.com/r/pcmasterrace/comments/7obokl/performance_impact...
"Heavy multitasking" -9%
"Image editing" -21%
"Encoding" -9%
"System score" -12%
Muze te nekdo zkusit taky premerit?
..tady uz prestava sranda
Myslím, že ta pravá standa by byla, kdyby se ukázalo, že to v Google odhalila umělá inteligence z toho jejich projektu DeepMind. :)
Nebude to apokalypsa
https://www.youtube.com/watch?v=JbhKUjPRk5Q
Jaký dopat výkonu na 4k Porno se píše ?
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.