Digitális történetek, kicsit másként.

Mennyit buksz a Meltdown miatt? Megmértük!

Facebook Tumblr Tweet Pinterest Tetszik
0
2018. január 05. - digitalstoryteller

meltdown-header.jpg

Mekkora teljesítményt buksz az Intel (meg az AMD és az ARM) processzorok nemrég felfedezett hibája miatt? Tényleg 5-30% lesz a bukó, ahogy a gyártók tippelték? Megmértük! 

Ha az elmúlt néhány napban egyáltalán nem olvastál (tech) híreket, akkor röviden update-elünk: találtak egy gigantikus hibát az Intel chipjeiben, ami az elmúlt 10 év összes inteles CPU-ját érintheti. A hiba egyik fajtája alól az AMD és az ARM sem mentes, szóval kis túlzással minden gép szarban van a világon. (Mivel hardverhiba, az oprendszer nem számít.) 

Van megoldás vagy legalábbis olyasmi. A gyógyír aprócska hibája, hogy az oprendszerben egy csomó mindent nehezebben elérhetővé tesz (hogy a kernelt érintő bugot ne lehessen kihasználni), így a teljesítmény is csökkenni fog. Windows alatt a megoldás neve KB4056892, amit mindenképp érdemes telepítened, ha meglátod. 

Na, de akkor mennyit is buksz emiatt az egész miatt? Lemértünk jónéhány (direkt elég eltérő teljesítményű) processzort a patch telepítése előtt és után is, hogy tisztábban lássunk! 

benchmark.gif

A kép 15 másodperc után vált, és százalékos különbséget mutat

Az adatok alapján úgy tűnik, hogy valóban 5% körüli csökkenésre lehet számítani majd. Ez még mindig jobb, mint a belengetett 30%, bár az is egyértelműnek tűnik, hogy az erősebb (drágább) processzorokat kevésbé viseli meg a patch, mint a gyengébb gépeket. A szomorú ebben az, hogy a gyengébb gépek, hát, eleve lassabbak, tehát rosszabb a helyzet. A másik zavaró tény, hogy az utóbbi években eléggé lelassult a generációról-generációra való teljesítménynövekedés, szóval most simán bukhatunk egy generációt teljesítményből.

Ez a teszt persze nem mutat meg mindent. Eleve túl kevés processzort teszteltünk. Ráadásul szintetikus benchmarkról van szó, ami nem minden esetben mutatja a valós eltéréseket. A várakozások szerint minél több érintett adathoz kell hozzányúlni egy feladathoz, annál jelentősebb lesz a lassulás. Ez főleg szervereknél lehet gond a várakozások szerint. Játékban ugyanakkor várhatóan nem lesz komoly a visszaesés: a tesztben is hivatkozott Guru3D tesztje minimális eltérést mutat, igaz, az általuk használt i7 5960X egy 350 ezres reaktor, és a legtöbb embernek az egész gépe nem kerül ennyibe. 

Szóval itt tartunk most: nyugodtan számolhatunk azzal, hogy 5% körül lassulnak a gépeink. És sajnos minél régebbi/gyengébb a vasunk, annál nagyobb lesz a csökkenés. 

32 komment
statisztika bug intel amd cpu spectre meltdown tldr

Ajánlott bejegyzések:

A bejegyzés trackback címe:

https://thedigitalstories.blog.hu/api/trackback/id/tr1413552523

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

2018.01.05. 23:38:57

Na jó, feladom a népművelést: legalább nézz utána kicsit a témának (ne a blikk.hu-n!), ha már arra kényszerít az a hang a fejedben, hogy blogolj róla!
Válasz erre 

RHalacska 2018.01.06. 00:16:52

Pontosan milyen minőségű az az OS, amelyik ilyen szintig leenged egy felhasználói programot? Van egy processzor, van egy OS. Ugye pár éve(10+) már nem illik az OS nek leengednie a processzor szintjéig az felhasználói programokat. Akkor most ki hibázott?
Válasz erre 

2018.01.06. 09:28:40

@RHalacska: hogy mi van???? Te miről beszélsz?
Válasz erre 

RHalacska 2018.01.06. 09:48:08

@hullajelölt88: Arról, hogy a kernel és a user módban futó programok memóriatábláit már rég izolálni kellett volna egymástól, ahogyan most a patchek teszik. Csak erre senki nem figyelt, és így el lehetett mondani, hogy hű milyen gyors a processzor. Nem építettek be egy biztonsági eszközt, mert az lassít.
Válasz erre 

2018.01.06. 09:58:29

@RHalacska: izolálja is, de ha megkéred a procit, hogy zárja el, és nem teszi, akkor mit csinálsz? pont arról szól a hiba, hogy hiába futtattad akár a full kódot virtuálban, mégis kilátott a proci hibája miatt. Nem az os-ben, hanem a prociban van a hiba, ezért érintett minden OS.
Válasz erre 

srip 2018.01.06. 10:13:56

@RHalacska:

A Meltdown sebezhetőség lényege, épp az, hogy az user szinten futó processz tudja olvasni más (akár kernel szintű) processzek memóriáját. Sajnos a weben található leírások elég nehezen követhetők, de azt hiszem, sikerült megértenem a működési elvet.

A mechanizmus, amennyire megértettem, a következő:
– a user szintű processz olvasni próbál egy védett memóriacímről;
– a processzor válasza erre access violation lesz, de ennek az ellenőrzésnek az eredménye csak néhány órajellel arrébb fog kiderülni...
– ... de addig is a csővonalas architektúra miatt a cache-be bekerül a védett címről kiolvasott adat, ...
– ... valamint egy, az védett memóriacím tetszőleges bitjének tartalmától függő (pl. JZ) utasítást is előre végrehajthatott a processzor (branch prediction)...,
– ... továbbá a JZ utáni két ágban egy-egy különböző (ezúttal a processz saját memóriájában levő, érvényes) címről történő olvasást is végrehajtott;
– az access violation detektálásakor ugyan a processzor érvényteleníti az azután végrehajtott utasítások hatását...
– ... de az, hogy a memória tartalmától függő és előre végrehajtott JZ utasítás melyik ágba ugrott, megtudható abból, hogy a JZ utáni két ágban történő olvasásból melyik cím van már a cache-ben;
– ezt onnan tudhatjuk meg, hogy megismételjük a JZ utáni mindkét ág olvasását, és mérjük, hogy melyik történik gyorsan (ez volt a cache-ben, tehát a JZ ebbe az ágba ugrott), és melyiket olvassa lassan (ez nem volt a cache-ben, tehát nem a JZ nem ebbe az ágba ugrott);
– tehát spekulatíve, a processzor olvasási sebességéből kiderítettük, hogy egy védett memória egy adott bitje 0 vagy 1 állapotban volt (ha a JZ ugrott, 0 volt, ha nem ugrott, 1 volt);
– egy adott memóriacímre ugyanezt 8-szor lefuttatva megvan a teljes bájt tartalma (mind a 8 bitet "végigtapogattuk";
– és N-szer lefuttatva megvan egy védett (akár kernel szintű) memória N bájtja.

Összefoglalva: egy nagyon szellemes módszerrel, kizárólag az olvasási idő méréséből spekulálva tudjuk meg a védett memória tartalmát, bár a processzor elvben teljesen korrektül elrejtette a user processz elől a védett memóriát. Az OS javítása pedig feltételezhetően abban áll, hogy a szálak váltogatásakor törli a cache-t.

Megjegyzendő az is, hogy az átlag felhasználót ez a hiba valószínűleg nem érinti, mert nem tud kárt tenni a rendszerben, csak a RAM-ban található védett adatokat tud kiolvasni.
Válasz erre 

srip 2018.01.06. 10:30:12

Ha jól belegondolok, a szálak váltogatásakor üríteni a cache-t igazából semmit se segít. Nem tudom, mit csinálhat a Windows patch, amitől a Meltdown nem tud működni...
Válasz erre 

RHalacska 2018.01.06. 11:01:24

@srip: Ez egy nagyon szép leírás, gratulálok!
Azt lehet tudni, hogy a védett memóriacímen mi van? Mert ha nem, akkor van egy bájtnyi adatunk. Legyen mondjuk 20 bájtnyi adatunk, vagy akármennyi, ha nem tudjuk mi ez, akkor igazából nem is tudjuk felhasználni. Persze ha tudjuk, akkor van értelme megírni. Csak úgy adatot kiolvasni, mert megtehetjük, meg minek is?
Válasz erre 

srip 2018.01.06. 11:21:25

@RHalacska: Köszönöm! Egy órám ráment, hogy megértsem, mi van, elég zavarosnak tűntek számomra a leírások (és 95%-ban bullshit megy a weben, csak néhány helyen jutnak el odáig, hogy konkrétumokról beszéljenek, azok meg nagyon bonyolultak).

Ami a kérdésedet illeti: mi egy nyomdai szoftvert írunk, és mivel ott rengeteg sebességigényes probléma van, az assembly és a cache ismerete fontos – de OS ügyekben nem vagyok illetékes. De például el tudom képzelni azt, hogy egy rosszindulatú szoftver elkezd 'halászni' a memóriában, keresve egy adott patternt, amiről tudja, hogy az X szoftverhez tartozik, és az X szoftver kódjának visszafejtésével meg lehet tudni, hogy milyen érzékeny adatot hol tárol.

Amennyire értettem, az egyik érzékeny célpont egy bizonyos típusú Google szerver lenne, amely enged felhasználói kódot futni, és amely így a többi felhasználói adatra rálátást engedne.
Válasz erre 

RHalacska 2018.01.06. 11:32:41

@srip: Én is kerestem, csak nem tudtam így összefoglalni, elismerésem a kitartásodhoz. Így érthető, hogy miért a Google mérnökei találtak rá. Legalább teszteltek rendesen. Ez alapján amit írtak az újságírók - jelszavak lopásáról stb.- az egyértelműen bullshit, de jó vele riogatni az egyszerű felhasználót. Van értelme kihasználni a hibát, de egyértelműen célzott támadáshoz, aminek rengeteg egyéb adat ismeretében van valódi eredménye. Itt jön a képbe, hogy mire lehet használni, és az átlagfelhasználót mennyire érinti. Jól gondoltam, hogy erőteljest feldobták a témával az állóvizet. Nyilvánvalóan az üzemeltetett szervereket jól át kell nézni, és figyelni a betörési kísérletekre, amíg a patch-ek ki nem jönnek. Szerintem magára a hibára is úgy jöhettek rá, hogy abszolút nem szabványosan kezdték kezelni a rendszert - tesztelésnél teljesen normális eljárás - és kibukott.
Ezt nem fogják normál vírusként használni, mert nem hatékony. Egy eltérített weboldallal előbb jutnak használható információhoz.
Válasz erre 

Papírzsepi · http://lemil.blog.hu 2018.01.06. 11:35:06

@RHalacska:
Két hiba is van. Az egyiknél azt használják ki, hogy a tiltott hozzáférés tényleges elvégzése és az agyoncsapása közötti rövid időben még pár utasítás lefuthat, amit a cache segítségével át tudja szivárogtatni az adatot egy másik szálba. Ez olyan 500kbit/sec sebességgel mehet, tehát nem kell olyan sok idő, hogy a teljes kernel fizikai memóriát beolvassuk. Abban meg minden van, és egy része bizony fix helyen. Gyakran a júzer memóriát is elérhetővé teszik kernelből, hogy egyszerűbb legyen az élet.
Két módon lehet védekezni ellene. Az egyik szerint randomizáljuk a memóriát, és akkor tényleg nehezebb kitalálni, hogy mi hol van és micsoda. Nehezebb, de nem lehetetlen. Ráadásul nem is feltétlen a kernel az izgalmas, hanem a többi alkalmazás. Ahol például a böngésző jelszavakat tárol...
A másik út, hogy úgy állítjuk be a memóriakezelést, hogy fizikailag ne is tudj belecímezni a kernelbe. Ez az izoláció sokat segít, bár szintén nem tökéletes. Viszont ettől kezdve a user-kernel átlépés sokkal több utasításba -kapuzásba- kerül, ezért van a lassulás. Minél több user-kernel átlépés (rendszerhívás) van, annál rosszabb a helyzet.

A másik támadás hasonló. Ott azt használják ki, hogy feltételes elágazásnál a processzor megtippeli, hogy merre megy majd a program, és előre dolgozik. Ha téved, akkor eldobja a fölöslegesen megcsinált utasításokat. Csakhogy ezeket sem ellenőrzni rendesen, így az egyik alkalmzás szabadon átcímezhet a másik területére. Majd az illegálisan kinyert adatot a cache segítségével átszivárogtatják egy másik szálba, mielőtt a processzor rájönne, hogy mégse arra fut tovább a program. Tehát itt az ugrási jóslót kell átverni, majd a cache segítségével szivárogtatni.
Ez utóbbi azért problémás, mert sokkal több idő van az illegális műveletekre, így akár egy java script kód (amit gépi kódra fordít a környezet) is elég, hogy mondjuk a böngésző saját memóriáját olvasgassa. Szintén pár 10 kbyte/sec sebességgel. Ez bőven elég, hogy kellő előkészületek után megtaláljuk a tárolt jelszavakat, és azért egy Paypal jelszó már sokba fájhat a júzernek.

Az alavető gond az, hogy a processzor előre dolgozása ma alapkövetelmény, általánosan elfogadott dolog, ráadásul az előredlgozós utasításokat nem is lehet rendesen védeni. Gondolj csak bele: ha egy utasítást a program hivatalosan nem hajt végre (csak a proci volt túlbuzgó), akkor azért nem lehet felelősségre vonni a progit. Adatokat szivárogtatni meg sokféle módon lehet.
Tehát nagyon kíváncsi vagyok, hogy az Intel mit talál majd ki. Optimális esetben egy mikrokód frissítés elég is lehet, ez a gyakorlatban a BIOS (és a management engine) frissítését jelenti. De nem lennék a helyükben....
Válasz erre 

RHalacska 2018.01.06. 11:54:57

@Papírzsepi: A tied a másik szakmai leírás, gratulálok. Kénytelenek lesznek valamit lépni, az biztos. Valószínűleg javítás a mostaniakhoz, áttervezés a jövőbeliekhez.
Felhasználni átlag felhasználó ellen nem fogják, mert sokkal egyszerűbb a social hacking, célzott támadásoknál gond lehet belőle.
Válasz erre 

munkanélküli informatikus 2018.01.06. 15:16:14

Lehet, hogy a veszély valójában nem is annyira nagy, mint amekkorára felfújják, viszont ha a javítócsomagok jó sokáig kizárólag Windows10-re lesznek elérhetők, azzal a trükkel a régebbi windows-ok felhasználóinak újabb csoportját sikerülhet csőbe húzni ;)
Válasz erre 

munkanélküli informatikus 2018.01.06. 15:20:02

A hibák kijavítása talán csupán néhány ezer byte módosításával megvalósítható. Szóval ismét várhatjuk a több száz megabyte-os (gyanúsan sok dolgot módosító) javítócsomagok megjelenését.
Válasz erre 

Papírzsepi · http://lemil.blog.hu 2018.01.06. 16:07:31

Bennem ilyenkor inkább az merül fel, hogy hány ilyen hiba van még, amiről nem tudunk.
Az Intel ökoszisztáma igen komplex, és a nagyrészéről az átlag júzer semmit sem tud.
Ott van például a Management Engine. Ez a déli hídban futó mikrokontroller, ami a BIOS - UEFI - segítségével gyakorlatilag teljes kontrollt élvez a rendszer felett (például altatáskor-hibernáláskor menti a teljes RAM-ot, állítgatja a processzor üzemmódjait, beledumál az oprendszerbe, és mivel hálózati hozzáférése is van, így mindez megy távirányítással is).
Persze védi magát, meg az Intel is próbálja minél inkább árnyékban tartani, de ha véletlenül hiba van benne, akkor onnantól a játéknak vége.
Találtak is benne nemrég sérülékenységet, csak nem kapott ekkora publicitást. Idő kérdése a következő, majd a rákövetkező.
A rendszereink annyra komplexek lettek, hogy gyakorlatilag nem lehet garantálni a hibamentességet, és korábban igazából nem is volt ez olyan fontos. Ha az öntanuló mesterséges intelligenciák előretörése ilyen ütemben zajlik, akkor ezt a komplexitás a csillagos egekig növeljük, és onnantól már semmi garancia nem lesz semmire.
Csak egy móricka-példa: intelligens otthonod van. A hacker olyan üzeneteket küld neki, amivel betanítja az MI-nek, hogy az egyik ablakod nyitásérzékelőja döglődik. Így amikor az "élőerő" benyomja az ablakodat, nem fog jelezni a riasztó, és buktad is a tévédet.
Válasz erre 

Zetor75 2018.01.06. 17:18:54

A cikkhez:
A probléma az átlagos felhasználókat általában annyira érdekli, mint egy pár döglött dingókutyavese. Nekik adatott 1 jobb-rosszabb CPU, némi memória, egy VGA (ha van), meg némi háttértár, ami akármekkora, az kicsi, de inkább kevés.
Gondolj bele, mennyi CPU-t használ egy felhőszolgáltató! (Google, Amazon, Microsoft, Apple, Facebook...)
Nem, nem 10esével vannak processzorok, hanem a Google esetében hajózó konténerenként ~1000es-10000es nagyságrendben. És ez csak a Google, rajta kívül vannak mások is. Namost, Te rendelsz tőle szolgáltatást, mert van egy honlapod, amint megy mondjuk egy webshop, ami alá kell valami adatbázis, meg levelezőszerver, stb. Ő erre kikalkulálja, hogy kéne neked adjon 2 procimagot, 10GB memóriát, 100M internetet stb. Erre jön valaki, aki azt mondja, hogy ácsi-bácsi, hibás a processzor, a javítás meg ~5-30 (néha 50% is) lassulást eredményet. Nos, a tervező (az a drága), azt mondja, hogy akkor neked nem 2 processzor mag kell, hanem ˇ3, vagy nem 10G ram, hanem 13. És ezt minden egyes (tetves) ügyfélre meg kell csinálja... Ergo, kell vennie még valahonnan processzort, meg memóriát, meg tárhelyet (emellé helyet, mert valahova tenni kell ezeket, áramot, plusz üzemeltetőt, mert aki most van, az is terhelt eléggé... stb). És itt eléggé nehéz a mérés, mert mi van, ha nem is lassult? (De, fog lassulni) Mi van, ha a lassulás "nem is annyira" érezhető, és mi van, ha a rendszer jelentős lassulást szenved? Ki mondja meg, hogy a kiajánlott erőforrások miatt beszerzendő új komponensek vajh' elégségesek e? És ha igen, azok nem szenvednek a hibától? Ráadásul a szolgáltatások egy része ki is esik, vagy lassul a szolgáltató oldali frissítések miatt (pl. Amazon leáll egy időre, MS szintén le-leáll ésatöbbi is), a kiesett idő ugye pénz, azt ki termeli vissza?
Nem véletlen indult már per az intel ellen...
Válasz erre 

Papírzsepi · http://lemil.blog.hu 2018.01.06. 18:20:34

@Zetor75: azért szerintem ez így túl van lihegve. A felhő fő előnye az, hogy skálázható, tehát karácsonykor simán venned kell még erőforrást a webshopodhoz, nyáron meg a 2 mag is bőven sok. Tehát a terhelés lengése sokkal nagyobb, mint az oprendszer lassulás effektje, így ezt elvileg minden látható jel nélkül toleránia kell.Neked, mint üzemeltetőnek persze nem öröm, de hacsak nem csúcson futtattad azt a webshopot - amit nem célszerű-, akkor nincs érdemi teendőd.
Az, hogy frissíteni kell néha, az igaz - bár nem értem, hogy a frissítéskor miért nem lehet átmigrálni az egészet egy másik gépre.
De mindegy is, nem ez a lényeg.
Tegyük fel, hogy veszel egy Open teherautót a cégednek. Ellopják. Ugyan a CASCO fizet, de pár napig akadozik a szállíás. Ekkor bepereled az Opelt, hogy lopható a termékük?
Vagy ugyanez a példa, de az Open visszahívja a kocsit, hogy frissítsék a lopásgátlót. Ezért 2 nap kiesik. Bepereled az Opelt, hogy miért nem csinálták meg elsőre jól?
Az Intel csinált egy legjobb tudása szerint tökéletes procit. De sosem mondta, hogy hibátlan. Te ezt tudtad, mégis megvetted. Miért is perelsz akkor?
Amikor az Intel szándékosan piacra dobta a pontatlanul számoló Pentiumjait, miközben tudtak a hibáról, akkor is megúszták: perszer le kellett cserélniük egy rakat procit javítottra, de végülis Intelre cserélték őket, a piac megmaradt.
Tehát szerintem most sem lesz itt sikeres per. Próbálkozni persze lehet...
Válasz erre 

Alick 2018.01.06. 18:59:35

Két észrevétel:
- Hasonló tesztet érdemes lefuttatni perifériákat intenzívebben használó programokkal is.

- A kernel problémákon való pánikolás :) nem több léggömbhámozásnál. Egyrészt hasonló rendszerszintű gyengeség még bőven adódhat, másrészt a rosszindulatú programokat nem ezen a szinten kéne megfogni (sopánkodunk, hogy a betörő megette a spájzból a sütit, pedig az a fő kérdés, hogy jött be egyáltalán a lakásba). Netes funkcióknak csak jól megírt menedzselt környezetben (ezt könnyebb karbantartani, mint egy rendszerközeli architektúrát) lenne szabad futniuk, natív kódok futtatásához pedig fontos a megfelelő engedélyezési mechanizmus.

Persze mindent ki lehet játszani, de ebben legalábbis a júzer error a leginkább sérülékeny pont. (engedélyt ad letöltésre, megnyitásra, amikor nem kéne).
Fontos lenne a security template-ek általános alkalmazása és a konfigurálásuk felhasználóbarát támogatása is - ha tudható, hogy a júzer milyen jellegű alkalmazásokat szeretne használni az oprendszerben, erre rá lehet szabni egy szoros, de nem feltétlenül kényelmetlen megoldást. Hatékonyabb megoldás, mint egy resource hog általános biztonsági program, víruskergető.
Válasz erre 

Alick 2018.01.06. 19:35:46

Ami elképzelhető probléma a patch után: online kereskedő (folyamatos adatforgalom) laptopja aksiról eddig elment 5-6 órát, ezután nem fog 3-nál többet.
Válasz erre 

Szabványok 2018.01.06. 19:51:12

@srip: Amit én láttam példát, az ennél picit gyorsabb. A kiolvasott kernel memóriatartalmával indexelve olvas egy nagy tömbből. Ezek után meg kell csak nézni a tömb melyik része, mennyi idő alatt olvasható ki. Amelyik gyorsan, annak az indexe volt a kernel memória tartalma.
Mit jelent ez?
Azt, hogy a júzer módú program a kernel memóriáját tudja olvasni. Igaz, baromi lassan. 10KB/sec. 32 bit esetén 4GB a terület, amit ki kéne olvasni, de ez napokig tart. És akkor még ki kell elemezni, hogy mit talált. 64bites üzemmódban, meg csak elenyészően ki részét lehet kiolvasni. Ezek után a kernel memóriáját (pontosabban az adatait, mert a kódja ismerhető) esetenként más helyre kell szétszórni a virtuális memóriájában, oszt keresse, nem fogja megtalálni. Másrészt nem kell olyan dolgokat tartani a kernel memóriájában, aminek kinyeréséből haszna lenne az olvasónak. Például a jelszavakat, rögtön el kell kódolni.
Vagy éppen az érzékeny részt egy helyre tenni és a kernelből való kilépéskor ezt a területet kiszedni a virtuális memória descriptorból. Persze ez lassít, de nem olyan sokat, mert egy program ne járkáljon folyton a kernelhez minden bájtért.

Megmondom őszintén, én mint magánfelhasználó, a 32GB RAM-mal rendelkező gépemmel nem vagyok betojva. Majd a következő gépemben már javított hardver lesz. Addig meg jó ez így nekem.
Válasz erre 

2018.01.06. 20:38:54

@Szabványok: vajon a linux kernelbe bekerült-e, ha igen, kb. melyik verzióba olyasmi, mint pl. ASLR? Mert ez _talán_ csökkentheti valamelyest ennek a mostani cirkusznak a kockázatát.
Egyébként ha igaz, hogy némely most felfedezett sérülékenységet akár javascript-ből is ki lehet használni... akkor én nem tudok ilyen nyugodt lenni, bármennyire is elhanyagolható az esélye annak, hogy az én gépemről nyúlnak le valami számomra fontosat...
Válasz erre 

srip 2018.01.06. 20:41:23

@Szabványok: a te példád első ránézésre nekem is elegánsabbnak tűnik, mert egyszerre több adatot, mondjuk 8 bitet is kinyerhetünk, például így (egyelőre 32 bites példa, még nem álltunk át 64 bitre...):

movzx al, [???] // olvasunk a védett memóriacímről egy bájt adatot
shl eax, 6 // szorzunk 64-gyel (vagy amennyi a cache line mérete)
mov al, [edx + eax] // indexelünk egy EDX bázisú , 256*64 bájtos tömbben

Ezután bevárjuk, hogy a cache line töltődjön be, kezeljük az access violation-t, majd nekiállunk végigpróbálgatni, hogy az EDX bázisú tömb melyik 64 bájtos eleme olvasható gyorsan (ez jött le előzőleg az L1 cache-be). De ha belegondolsz, itt 256 olvasás kell a 8 bithez (amiből 255 cache miss), az én példámban 16 olvasás (amiből 8 cache miss).

Nekem úgy tűnik, hogy az általam látott példa gyorsabb (amúgy az idő nem a néhány utasításra megy el, amivel a kernel memóriáját olvassuk, hanem a cache miss miatti várakozásra).

Meg lehet gyorsabban is oldani, mit ahogy én gondolom?
Válasz erre 

srip 2018.01.06. 20:53:14

@Papírzsepi: nem értem ezt a másik szálba történő cache átszivárogtatást, amiről beszélsz. El tudnád konkrétan magyarázni, hogyan is működik ez pontosan?

Amennyire én értem:
– a szálaknak semmi közük ehhez az egészhez,
– bár először én is úgy értettem, hogy a cache-be a védett memóriából betöltött adat valamilyen cache zsonglőrködéssel olvashatóvá válik, de nem, az Intel ilyen szempontból korrektül van tervezve, a védett adat nem hozzáférhető,
– a védett adathoz való hozzáférés kizárólag a cache olvasási sebességéből spekulálható vissza.

Rosszul értek valamit?
Válasz erre 

Papírzsepi · http://lemil.blog.hu 2018.01.08. 11:27:46

@srip: alapvetően jól érted.
A Meltdown így működik:
1. Támadó indít egy szokásos user-programot.
2. Lefoglal 256 lapnyi memóriát. Az a lényeg, hogy 256 különböző cache blokkhoz tartozzon mind.
3. A lefoglalt memória lapoknál gondoskodik róla, hogy egyik se legyen a cache-ben.
4. Indít egy új szálat. A meglévőt elaltatja.
5. Az új szál magára veszi a kivételkezelést. Ez azért kell, hogy csak ez a szál legyen lelőve egy esetleges illegális elérésnél.
6. Kiolvas egy bájtot a kernel memóriából. Ez persze illegális, de ennél a lépésnél a proci ezt még nem tudja.
7. Mivel a proci jóhiszemű, míg az illegális hozzáférés fut, azért beolvassa és elő-feldolgozza a következő utasításokat is. Ezek még nem futhatnak me, mivel az illegális kiolvasott bájtra várak.
8. Megjön az illegálisan olvasott bájt, és vele együtt a jelzés a hozzáférés-sértésről.
9. A processzor megkezdi a kivételkezelést. Ez egy kapun megy át, elég sok műveletből áll, lassú.
10. Viszont közben a már előkészített utasítások elindulhatnak, mert csak az adatra vártak. Az meg ugye megvan.
11. A következő lépés, hogy a bejött adat alapján beleolvasunk a 256 lefoglal memórialap egyikébe. Ha mondjuk 23 jött a kernelből, akkor a 23. lapon olvasunk egyet.
12. Az olvasás hatására a memóriavezérlő beolvassa a cache-be az érintett lapot.
13. Eddigre lefut kivételkezelés is. A processzor nullázza az illegálisan elért bájtot, és eldob minden eredményt, ami a "hibás" utasítások után volt. Amit nem is kellett volna végrehajtani.
14. Lefut a kivételkezelő, és kiirtja a szálat, az egésznek írmagja sem marad.
15. Ekkor éled az eredeti szál. Elkezdi olvasgatni a lefoglalt 256 lapot, és közben méri az eléréshez szükséges időt. Nagyon pontosan.
16. Ha a manőver sikerült, akkor egy lap már a cache-ben van, (a 23-as), itt gyors lesz az elérés. A többinél lassú. Ezzel át is van szivárogtatva az adat az illegálisan futó utasításokból a teljesen legális programszálba.
17. Ezt kell ismételgetni sokszor.
Ennyi.

A Spectre hasonló, de itt kicsit máshogy megy a menet.
1. Támadó programot indít, lefoglal 256 memórialapot (már tudod, hogy miért), de itt még kell egy áldozati függvény is. Ez ilyen formájú:
HA ParaméterJó AKKOR Olvasunk, majd az olvasott adattal indexelve memóriát érünk el.
Ez egy elég gyakori manőver, sok DLL-ben/SO-ban megtalálható.
2. Támadó meghívja az áldozatot párszor, helyes Paraméterrel. Ezért az ugrás-jósló megtanulja, hogy általában a feltétel IGAZ.
3. Ezután a támadó illegális hozzáférést végez, mondjuk egy másik alkalmazás területére nyúl be.
4. Mivel az ugrás-jósló optimista, így míg a paraméter ellenőrzése tart, hozzálát a hozzáféréshez. Így az illegális elérés megtörténik, a beolvasott adat alapján a második memória-elérés is elkezdődik, így ott cache-elés is van.
5. Ezután a feltétel kiértékelődik, és kiderül, hogy nem is kellett volna ezt csinálni. Tehát a proci eldob minden adatot, behinti sóval a fölöslegesen végrehajtott utasításokat, és vidáman visszatér, hogy "érvénytelen paraméter". De a cache-ben ott van információ
6. Támadó megkeresi, hogy melyik lap van cache-ben, és kész is.
7. Ugyanez sokszor.

Az a rossz a dologban, hogy az ilyen "előre dolgozás" során nincs védelem, nem is lehet.
Az sem szerencsés, hogy az itt leírt cache-es szivárogtatás mellett van más út is, lehet máshogy is csinálni. Szóval szélmalomharc.
Válasz erre 

srip 2018.01.08. 11:56:40

@Papírzsepi: a Meltdown rész tiszta, csak amit @Szabványok-nak is mondtam, azt most is tartom: a ti példátokban egy bájthoz 256 olvasás kell, amiből 255 cache miss, míg az én példámban 1 bithez 2 olvasás kell, amiből 1 cache miss, azaz egy bájthoz 16 olvasás és 8 cache miss kell. Tehát amennyire látom, a bitenkénti hozzáférés gyorsabb, kisebb memóriaigényű, egyszerűbb. Annyi elvi problémája van, hogy ha közben változik az adat, akkor korrupt bit jön le, de ez memóriamező olvasásánál bájt szinten ugyanúgy áll, tehát irreleváns.

A Spectre rész: ezt a részt nagyon nem értem. A Meltdown ugye AMD esetén nem működik. Nem tudom, miért, vagy az access violation ellenőrzés hatékonyabb (tehát védett memóriából kiolvasott adattal NEM történik semmiféle művelet), vagy a cache ürítését végzi okosabban. Ha ez így van, akkor nem értem, hogy tudja a Spectre átverni az AMD-t lényegében egy ugyanolyan trükkel, mint a Meltdown.
Válasz erre 

Papírzsepi · http://lemil.blog.hu 2018.01.08. 19:41:12

@srip: Úgy tudom, hogy a Meltdown azért nem működik AMD-nél, mert gyorsabban elkezdi a kivétel kezelését, így a parazita uatsítások nem futnak le időben. Míg az intelnél akár 3-5 utasítás is lefuthat, addi AMD-nél csak 1-2. Az meg kevés a stabil működéshez.
Valószínűleg rövidebb az utasítás pipeline, vagy csak más felépítésű.

A Spectre esetében a leírás szerint azért van sokkal több idő, mert nem csak a felolvasás és a kivételkezelés közötti idő áll rendelkezésre adatlopásra, hanem a teljes idő amíg a külső DRAM-ra vár a processzor. Ez utóbbi valóban sokkal lassabb, szóval nekem hihető.
Válasz erre 

srip 2018.01.08. 19:54:38

@Papírzsepi: Hát nekem nagyon nem tiszta az egész. Egyrészt ha az utasítások száma a probléma, akkor lényegében 2 utasításból meg lehet hekkelni:

xor eax, eax // töröljük az EAX-et
mov ah, [védett memória] // betöltjük a védett adatot 256-tal szorzott helyre...
mov eax, [edx + eax] // ... és rögtön fel is használjuk, ezzel már a cache-ben van a csali

Tehát lényegében 1 utasítással a védett olvasás után már be is fejeztük a hekket, benn van a csali a cache-ben. Ha az AMD engedne 2-3 utasítást lefutni, akkor a fenti kód menne ott is. Szerintem AMD-n azért nem megy a trükk, mert vagy egyből ellenőrzi, vagy a cache-et üríti.

És akkor megérkeztük a Spectre részhez, ahol ezek szerint AMD-n semmi esély, hogy ezzel a típusú trükkel átverhető lenne. Szerintem a Spectre valami egyebet csinál, csak én nem értettem, hogy mit.
Válasz erre 

digitalstoryteller 2018.01.10. 11:14:03

@Papírzsepi: @srip: Köszi szépen a hozzászólásokat, nagyon értékesek voltak, ritka ilyen jókat olvasni! A kommenteket fel is használtuk egy videóhoz, ami ma fog kikerülni. Ebben külön is megköszönjük az egészet, és hivatkozunk is rátok, mert tényleg tök jó, hogy így írtatok ide. Szóval köszi :)
Válasz erre 

SimanCsakBálint 2018.01.11. 13:10:00

És mindezektől lassult kb. 25%-ot a gépem?
Válasz erre 

digitalstoryteller 2018.01.11. 17:56:29

@SimanCsakBálint: Igen, jó esély van rá. Amúgy felkerült egy új poszt/videó, abban részletesebben is szó van a lassulásról. Amúgy sajnos erősen felhasználásfüggő, hogy mennyi is a lassulás.
Válasz erre 
süti beállítások módosítása