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?)
+1
+3
-1
Je komentář přínosný?
Jsem zvědavý na nějaké
He3lix https://diit.cz/profil/jan-vlasak
5. 1. 2018 - 01:04https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseJsem 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?)https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110118
+
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.
+1
+9
-1
Je komentář přínosný?
Spíž koupím si 10 rohlíků a
Ensidia https://diit.cz/profil/ensidia-ensidis
5. 1. 2018 - 07:52https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseSpíž 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. https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110154
+
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í.
+1
+10
-1
Je komentář přínosný?
No fér to rozhodně není,
He3lix https://diit.cz/profil/jan-vlasak
5. 1. 2018 - 11:07https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseNo 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í.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110253
+
Jo, to je "privatizace zisků a socializace nákladů" v praxi. :-)
+1
+3
-1
Je komentář přínosný?
Jo, to je "privatizace zisků
peliculiar https://diit.cz/profil/peliculiar
5. 1. 2018 - 12:16https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseJo, to je "privatizace zisků a socializace nákladů" v praxi. :-)https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110343
+
5. 1. 2018 - 11:20https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseNo 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=1https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110274
+
5. 1. 2018 - 01:29https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseDěkuji za první nestranný článek na toto téma.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110121
+
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ě :)
+1
+3
-1
Je komentář přínosný?
Ehm to s tím časem je trochu
Milan Bačík https://diit.cz/profil/mildaiv
5. 1. 2018 - 01:44https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseEhm 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ě :)https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110124
+
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.
+1
+7
-1
Je komentář přínosný?
K té poslední větě: Pokud vím
Vláďa2 https://diit.cz/profil/vladimir-pilny
5. 1. 2018 - 09:54https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseK 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110193
+
"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.
+1
+2
-1
Je komentář přínosný?
"Jenže na úrovni
Tralalák https://diit.cz/profil/tralalak
5. 1. 2018 - 03:00https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse"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. https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110127
+
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
+1
0
-1
Je komentář přínosný?
Takový názor slyším prvně.
no-X https://diit.cz/autor/no-x
5. 1. 2018 - 10:40https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseTakový 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_hierarchyhttps://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110214
+
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.
+1
0
-1
Je komentář přínosný?
Oki dík za ujasnenie formy,
Tralalák https://diit.cz/profil/tralalak
5. 1. 2018 - 12:13https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseOki 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110340
+
"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.
+1
0
-1
Je komentář přínosný?
"ako by k nim operačná pamäť
Hrdina https://diit.cz/profil/david-baranek
5. 1. 2018 - 14:44https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse"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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110499
+
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.
+1
0
-1
Je komentář přínosný?
Ci sa budu urovne oznacovat
ventYl https://diit.cz/profil/ventyl-ventyl
6. 1. 2018 - 16:46https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseCi 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110766
+
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ť ?
+1
+1
-1
Je komentář přínosný?
Chcem sa spýtať či je
Gaunter https://diit.cz/profil/anton-gajdos
5. 1. 2018 - 07:28https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseChcem 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ť ?
https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110142
+
Na Meltdown je venku už proof-of-concept (tedy ukázkový kód, který funguje).
+1
+8
-1
Je komentář přínosný?
Na Meltdown je venku už proof
TyNyT https://diit.cz/profil/tynyt
5. 1. 2018 - 07:44https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseNa Meltdown je venku už proof-of-concept (tedy ukázkový kód, který funguje).https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110145
+
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.
+1
-5
-1
Je komentář přínosný?
S zneužitelností této chyby
Jack FX https://diit.cz/profil/jackfx
5. 1. 2018 - 07:45https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseS 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110148
+
Navic ono co nejkatsi je pomerne dlouhe a dost spatne se pocita s citlivimi daty, kdyz jsou sifrovana. O vyhledavani v nich nemluve :D .
+1
0
-1
Je komentář přínosný?
Naproste nepochopeni problemu
Bespi https://diit.cz/profil/bespi
5. 1. 2018 - 08:05https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseNaproste 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 .https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110157
+
Hledáš data i šifrovací klíč k nim, oboje je někde v paměti (ten klíč zcela jistě v '"ring 0").
+1
0
-1
Je komentář přínosný?
Hledáš data i šifrovací klíč
Hrdina https://diit.cz/profil/david-baranek
5. 1. 2018 - 08:12https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseHledáš data i šifrovací klíč k nim, oboje je někde v paměti (ten klíč zcela jistě v '"ring 0").https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110163
+
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.
+1
+6
-1
Je komentář přínosný?
Ne, diskutabilni tam neni
franzzz https://diit.cz/profil/franz-z
5. 1. 2018 - 09:04https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseNe, 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110172
+
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
+1
+6
-1
Je komentář přínosný?
Arm se k tomu postavil celem.
PPK https://diit.cz/profil/ppk
5. 1. 2018 - 07:47https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseArm 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-updatehttps://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110151
+
Samsung a Qualcomm používajú deriváty. Kirin 970 má A73. Podobne TSMC v test vehicloch použila A72.
+1
-2
-1
Je komentář přínosný?
Zaujímavé je, že A75
Dolan https://diit.cz/profil/jogar-gobz
5. 1. 2018 - 10:33https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseZaují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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110205
+
Jak se ten Cortex-A75 procesor od Intelu jmenuj?
Byl by nějaká odkaz?
+1
+1
-1
Je komentář přínosný?
Jak se ten Cortex-A75
SGaba https://diit.cz/profil/stepan-gabriel
5. 1. 2018 - 11:16https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseJak se ten Cortex-A75 procesor od Intelu jmenuj?
Byl by nějaká odkaz?https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110259
+
5. 1. 2018 - 11:32https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskusePô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/https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110292
+
To je ale standardní implementace od ARM jenom vyrobená technologií Intelu.
+1
0
-1
Je komentář přínosný?
To je ale standardní
SGaba https://diit.cz/profil/stepan-gabriel
5. 1. 2018 - 11:54https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseTo je ale standardní implementace od ARM jenom vyrobená technologií Intelu.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110313
+
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
+1
-1
-1
Je komentář přínosný?
Viem, len vravím že je
Dolan https://diit.cz/profil/jogar-gobz
5. 1. 2018 - 12:09https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseViem, 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? :Dhttps://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110328
+
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.
+1
+1
-1
Je komentář přínosný?
Jasně, v pořádku. Jen mně to
SGaba https://diit.cz/profil/stepan-gabriel
5. 1. 2018 - 12:50https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseJasně, 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110385
+
5. 1. 2018 - 12:08https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseA co Snapdragon 845? Tam je A75 v Kryo385 Gold.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110322
+
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.
+1
0
-1
Je komentář přínosný?
To je právě derivát Cortex
SGaba https://diit.cz/profil/stepan-gabriel
5. 1. 2018 - 12:43https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseTo 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110367
+
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...
+1
-3
-1
Je komentář přínosný?
Nevím, jestli to je to náhoda
Hrdina https://diit.cz/profil/david-baranek
5. 1. 2018 - 08:10https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseNeví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...https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110160
+
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.
+1
+3
-1
Je komentář přínosný?
Mne sa po nainstalovani macOs
Nox https://diit.cz/profil/nox
5. 1. 2018 - 12:25https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseMne 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. https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110349
+
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?
+1
+1
-1
Je komentář přínosný?
Niekde na zaciatku kauzy som
dajan https://diit.cz/profil/dajan
5. 1. 2018 - 08:16https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseNiekde 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?https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110166
+
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é)
+1
0
-1
Je komentář přínosný?
Otázkou je důvod, proč a čím
Tiktak https://diit.cz/profil/jan-kadlcek
5. 1. 2018 - 12:35https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseOtá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é)https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110358
+
Takze Ryzenaci maju na Windowsoch smolu,trest bude kolektivny a ziadna vacsia zmena pomeru sil ku Coffelaku nehrozi.
+1
-1
-1
Je komentář přínosný?
Takze Ryzenaci maju na
dajan https://diit.cz/profil/dajan
5. 1. 2018 - 13:08https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseTakze Ryzenaci maju na Windowsoch smolu,trest bude kolektivny a ziadna vacsia zmena pomeru sil ku Coffelaku nehrozi.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110427
+
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é...
+1
0
-1
Je komentář přínosný?
To není úplně tak pravda -
Tiktak https://diit.cz/profil/jan-kadlcek
5. 1. 2018 - 14:08https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseTo 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é...https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110484
+
5. 1. 2018 - 14:36https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseZda 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/commit/?id=694d99d40972f12e59a3696effee8a376b79d7c8https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110508
+
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ý :)
+1
0
-1
Je komentář přínosný?
Je to jen drb.. Viděl jsem
arakan94 https://diit.cz/profil/david-novak
5. 1. 2018 - 17:07https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseJe 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ý :)https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110604
+
5. 1. 2018 - 09:21https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseBTW 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.pnghttps://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110184
+
"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?
+1
0
-1
Je komentář přínosný?
"Běžného domácího uživatele s
sarlej https://diit.cz/profil/sarlej01
5. 1. 2018 - 11:35https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse"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?https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110298
+
Ř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 :-)
+1
+4
-1
Je komentář přínosný?
Řadový BFU cpe osobní
no-X https://diit.cz/autor/no-x
5. 1. 2018 - 12:54https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseŘ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 :-)https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110397
+
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.
+1
0
-1
Je komentář přínosný?
Hesla a podobne citlive udaje
sarlej https://diit.cz/profil/sarlej01
5. 1. 2018 - 15:25https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseHesla 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110550
+
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.
+1
0
-1
Je komentář přínosný?
Aha, SharedArrayBuffer jsem
Kaj https://diit.cz/profil/petr-neuman
5. 1. 2018 - 16:12https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseAha, 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.https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110574
+
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.
+1
0
-1
Je komentář přínosný?
Bezni uzivatele aktualizuji
JoHnY3 https://diit.cz/profil/johny3
6. 1. 2018 - 02:15https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseBezni 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.
https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110682
+
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?
+1
0
-1
Je komentář přínosný?
Myslíte, že to Google objevil
Kaj https://diit.cz/profil/petr-neuman
5. 1. 2018 - 12:58https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseMyslí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?https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110412
+
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...
Muze te nekdo zkusit taky premerit?
..tady uz prestava sranda
+1
0
-1
Je komentář přínosný?
Tady jsou vysledky mereni po
tombomino https://diit.cz/profil/tombomino
6. 1. 2018 - 12:28https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseTady 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_of_windows_patch_and_bios/
"Heavy multitasking" -9%
"Image editing" -21%
"Encoding" -9%
"System score" -12%
Muze te nekdo zkusit taky premerit?
..tady uz prestava srandahttps://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110724
+
6. 1. 2018 - 21:03https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseMyslím, že ta pravá standa by byla, kdyby se ukázalo, že to v Google odhalila umělá inteligence z toho jejich projektu DeepMind. :)https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1110796
+
8. 1. 2018 - 15:51https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuseJaký dopat výkonu na 4k Porno se píše ?https://diit.cz/clanek/vyrobci-komentuji-x86-kernel-bug/diskuse#comment-1111408
+
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.