Már véd a Microsoft C/C++ fordítója a Spectre processzorhibával szemben
2018-01-18T14:00:54+01:00
2018-01-24T10:27:40+01:00
2022-07-21T08:16:46+02:00
  • Mik a programozási vonatkozásai ?

    Nem tőlem fogsz erre igazán részletes választ kapni, az én olvasatomban a lokalitás elve az, ami fejlesztési szempontból felértékelődik.

    A fájlelérések, olvasások/írások teljesítménye változik esetleg ?
    A memóriaintenzív kódok lassulnak inkább a lapozások miatt ?
    Az aszinkron kódok teljesítménye változik ?

    Amennyire én értem, minden user-kernel váltás lassabb lett az extra laptábla-töltögetés miatt. Tehát kb. tökmindegy, hogy mit csinál a kernel, az a gond, ha bármi dolga van.
    Mutasd a teljes hozzászólást!
  • Amennyire én értem, a Meltdown esetében annál rosszabb a helyzet, minél több oprendszer-hívást végez a program, mert a kontextusváltás sebessége csökken le. Ez alapján a CPU-intenzív programok érintettek a legkevésbé, az IO-intenzív programok a leginkább.

    A Spectre-t már nehezebb összefoglalni. A linkelt leírás alapján a Microsoft-féle védelem olyan kódot lassíthat be, amiben van tömbhatár-ellenőrzés, ami ugye elég sok kódban lehet. A védelem viszont nem kapcsolja ki teljesen a spekulatív végrehajtást ilyen kódoknál, csak megakasztja a veszélyes pont előtt, vagyis a spekulatív végrehajtás nyújtotta előnyök egy része megmarad.
    Mutasd a teljes hozzászólást!
  • Mik a programozási vonatkozásai ?
    A fájlelérések, olvasások/írások teljesítménye változik esetleg ?
    A memóriaintenzív kódok lassulnak inkább a lapozások miatt ?
    Az aszinkron kódok teljesítménye változik ?
    Úgy érzem, hogy pl. a funkcionális programozással pure function-ben megírt részek  nem igazán érintettek, ellenben a globális változókkal, vagy osztályváltozókkal működő függvények sokkal inkább cachelhetőek a processzor által, így a patchek ezt a teljesítményt rendesen visszavehetik.
    Mutasd a teljes hozzászólást!
  • Elég nyomós ok ez, hogy többen vegyenek erosebb procit, pl. az i9-et  Persze 21-rol 4 sec-re az sem hozza vissza...

    Ismet beigazolodik a mondas, miszerint: "A szamitastechnika azokra problemakra ad valaszt, amelyek a szamitastechnika nelkul nem is leteznenek."
    Mutasd a teljes hozzászólást!
  • Hát, ez bizony így is lesz. Mivel ez nem igazán programozós téma, a PC Fórumon volt (és már van megint) róla elég sok cikk, pl. Nagyon durva: Ennyire lassítja le a gépeket a Meltdown elleni folt
    Mutasd a teljes hozzászólást!
  • Nekem is az az érzésem, hogy az intel core i5-ös gépemen az ubuntu az új kernellel lassabban fut, mint egy hete :(
    Mutasd a teljes hozzászólást!
  • Nem tudom, hogyan csinálták, de azzal már tényleg nem megy.

    Emlékeim szerint kb. az a nagy trükk, hogy user módba kapcsolva a kernel lapjait kiveszik a laptáblából (eddig bent maradtak, hiszen a direkt elérésükre nincs lehetőség). Ez sajnos lassú, cserébe ekkor a spekulatíven futó "érvénytelen" kód sem tud hozzáférni, hiszen nem része a címtérnek.
    Mutasd a teljes hozzászólást!
  • Volt megint egy kis időm és próbálgathattam.

    A régi 4.10.0-42-generic kernellel látható, hogy sudo nélkül lehet olvasni az adott memóriaterületet.
    A bal felső sarokban nincs semmiféle sudo.
    Szerencsére az új kernellel nincs ilyen gond.
    Nem tudom, hogyan csinálták, de azzal már tényleg nem megy.
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Rajtad kivul szerintem mindenki levagta, hogy poenbol irtam az egeszet. Persze nekik konnyebb volt a dolguk, mert nem futi oket a nagy szelmalomharcos hevulet, dehat nem veletlenul cimeztem pont neked. ;)

    Egyebkent meg:

    A procin nincs mit backdoorokkal telepakolni. 

    Az intel management engine sztori nem remlik tavaly elottrol? szmajli-> :DDD 
    Mutasd a teljes hozzászólást!
  • + Spectre-ről néhány szó:

    Ezt csak akkor érdemes elolvasni, ha a meltdown-t már érted az alapján, amit az előzményben megpróbáltam részletesen leírni.

    Így ugyanis a fentiek megértését követően úgy tekinthetjük, hogy a spectre ennek a gondolatmenetnek az összes különféle olyan változata, ahol az Intel hiba nincs még pluszban ott. Tehát nem akarsz extrém módon te magad access violation-t spekulatívan végrehajtani (mert nem lehet), de például a javascript sandbox range check-jeit aknázod ki hasonló célokra.

    Ugye mint egy sandbox-ban futó kódnak, neked nincs jogod a Firefox, vagy a V8 engine process ramjának bármelyik részét "csak úgy olvasgatni", ezért a nyelvbe épített soft korlátok miatt erre nincs lehetőséged. Nyilván ha valaha is volt, az eddig normális sebezhetőség volt. Ilyenkor van az, hogy túlindexelsz, meg hasonló kalóz dolgokat művelsz A'la pdf-ben írottak és utána hasonló kiméregetéssel kiméred, hogy mi volt ott az adat. Nyilván itt nem lesz normális memory bandwith-ed, mintha csak simán a ramból olvasnál és ezért van olyan 2k/s sebesség, ha nem optimalizálják ezt agyon.

    De ne ekézzük csak a Javascript engine-eket: Komoly probléma ez ahol VM-ek futnak, vagy a cloud szolgáltatók gépei, ahol nyilván nem egyedül vagy az AWS vason, hanem talán éppen egy bitcoin exchange szerverrel osztozol úgy, hogy az összes privát kulcs ott mászkál a ramban. Nyilván nem kispista fogja felhekkelni ezeket a rendszereket, de egy távol-keleti titkosszolgálati hacker már lehet hogy ráállítható a dologra

    De mondok egy viccesebb és kevésbé komoly példát: ha egy játékban elrejted a játékos pozícióját, akkor ilyesmivel luascriptből is ki tudod (elméletben) olvasni, hogy hol a gonosz - csak hát erre nincs szükség, mert ha így van megcsinálva, akkor sudo-val te magad olvasod ki a ramból. Na az a különbség, hogy itt ez bevett problémaforrás és a multiplayer játék erre jó esetben felkészül, míg az nem bevett problémaforrás, hogy egy weblab olvasgatja az összes más megnyitott weblap kódját, vagy hogy az AWS egyik szervere olvasgatni tudja a teljesen más ügyfél által telepített cuccokat - és ez csak skill függvénye.
    Mutasd a teljes hozzászólást!
  • Ránéztem. Te is ránéztél? Linux alatt ráolvasni a pagemap-ra, az aztán nagyon skill. Win alatt is meg tudom csinálni, hogy adminként debug supportot kérek az OS-től, és bármelyik másik program memóriájába beleolvasok. Sőt, bele is írok, ha akarok

    Ja. Kár, hogy ehhez admin jog kell. A Meltdown meg admin jog nélkül is lehetővé teszi ezt. Pont ez teszi hibává, sebezhetőséggé.

    Sőt, kódot is futtatok annak a processznek a saját területén az ő nevében (dll inject pld).

    Aminek semmi köze nincs az itteni sebezhetőségekhez.

    Nincsen abban a világon semmi bug. Hibakeresési célzattal építettek olyat bele minden OS-be.

    Ezért is teljesen érthetetlen, hogy miért hozod fel, amikor köze nincs jelen témához, sebezhetőségekhez.

    Nincsen a linkelt stuffban olyasmi, ami cpu mikrokód gyengeségre utalhatna.

    Rajtad kívül senki fel sem vetette, hogy erre utalnak. Egyszerűen csak megint olyan dolgokról mesélsz, amiknek köze nincs a témához. Nyilván azért, mert alapvető dolgokat sem értesz meg utóbbival kapcsolatban. Talán ha végre vennéd a fáradtságot és alaposan utánaolvasnál....
    Mutasd a teljes hozzászólást!
  • Szóval benne van a cache-ben egy olyan régió is, amit a programnak nem szabadna látnia, de az ügyködései végett mégis csak a cache-be került. Oké. Hogyan fognak a processzor saját utasításai hozzáférni ahhoz a memóriához, ami már ott van a cache-ben?

    Mert tudod, "már csak ki kell olvasni". Jó, mutasson nekem bárki működő példát arra a "csak"-ra. Pár laikusnak biztos sokkoló lesz a hírek, de az az egyetlen legutolsó hajszál nem éppen gyenge.

    Megpróbálok segíteni, két fontos infóval:

    1.) Amit hiányolsz azért nem találod, mert nincs: Se meltdown-ban, se spectre-ben nincs közvetlenül a példákban olyan, hogy egy védett területről jövő byte-ot - legyen az akár cache-ben, memóriában - egy közetlenül regiszterbe, vagy saját változóba írsz.

    2.) Pont az a lényeg, hogy enélkül is ki lehet szivárogtatni az ilyen byte-ok értékét.

    A pdf-ek maradék része arról szól, hogy ennek mik a módszerei.

    Ennek fényében még egyszer megpróbálom a meltdown-t - mert az szerintem egyszerűbb - elmagyarázni:

    ... (0)valami_lassu_muvelet ... (1)LOAD Reg1, [SomeKernelMemoryAddress] (2)LOAD Reg2, [BaseArrayAddress + Reg1*256] ...
    (1)-re neked nincs jogod, mert ez egy access violation exception. Nem baj, a spekulatív végrehajtás miatt, ennek ellenére az (1) és (2) stb. részben megtörténik Intel processzoron (ez a meltdown probléma). Szerintem ez baj, az Intel szerint ez nem bug, hanem (khm. khm) ...

    Mi történik?

    - Amikor a CPU (0)-hez ér, akkor látja, hogy a be kell olvasni valamit a cache-be és ez sokáig tart(*), ezért spekulatívan tovább megy.
    - Végrehajtja (1)-et (!!!) (2)-t és az utána lévő "..."-ból ami belefér az időbe és a keretbe. Ezek a parancsok azonban csak "végrehajtódnak", de nem "retire"-olódnak. Ez kb. olyan, mint egy adatbázisnál, hogy megtörténik az insert, de még nem volt commit, vagy egy fájlnál amikor még nincs flush.
    - Amikor kiderül UTÓLAG, hogy access violation van, akkor ezeket a spekulatív dolgokat megpróbálja a CPU visszacsinálni - illetve ezen az utasítások nem "retire"-olódnak. Ha analógiát akarsz keresni, akkor ez egy rollback.

    Hol volt eddig a cache? Nem nagyon (*) volt sehol! Annak, hogy (2) végrehajtódik, a cache-hez nem annyira van sok köze, csak a spekuláció olyan formájának, hogy a protection ellenőrzést úgy fest a "retire"-be rakták és nem magába a művelet azt megelőző részébe. Ez az, amit egyébként az AMD nem így csinál, illetve ez az, ami ellen a KPTI patch véd.

    A fenti két sorban történik bármi más? Nem! Ennyi történik! Amit te kerestél eddig, az itt sincsen sehol.

    Hogyan szivárog ki az adat?

    Most jutunk el oda, hogy meg kellene nézni, hogy mit csinál a (2). Erről annyit tudunk, hogy:
    - Lefut (processed)
    - De később visszavonódik (not retired)

    BaseArrayAddress itt egy 64k méretű tömb a saját memóriádban. Ennek tehát semmi köze a kernel memóriához és minden további nélkül tudod olvasni.

    Ha megnézzük az utasítást, akkor látható, hogy [BaseArrayAddres+Reg1*256] a cím ahonnan olvasunk. A fentiek alapján ez egy olyan load, ami tehát a saját tömbünkből olvas. Tehát a Reg2 értéke hulladék, azt mi semmire se használjuk és nem is akartuk.

    Hol van akkor tehát a kiszivárgott adat? Hát ott, hogy Reg1 értékétől függ ez az olvasás és ha megnézed, akkor Reg1-ben viszont az van, amit nem szabadott volna kiolvasnunk.

    Fontos: Mivel nem történt meg a retire, így Reg1-et sose kapjuk meg természetesen. Ekkora baklövést tehát azért nem követett el semelyik intel gárda, se más vállalat.

    LÉNYEG: A probléma abban áll, hogy a "rollback"-nek van egy side effect-je!

    A side-effect annyi, hogy bár nem történt meg a retire és semmilyen regiszterben nem marad bent ez az érték, illetve semmilyen memóriába nem íródott ki ténylegesen, a (2) művelet feltölti a BaseArray[Reg1*256] címnek megfelelő cache-vonalat. Ezt nem kernel tartalommal tölti fel, hanem azzal a hulladékkal, amit mi benne hagytunk.

    A Reg1 spekulatív értéke viszont így kiderül, mert ha végigméz a BaseArray-on 256-osával és megméred melyiket tart a legrövidebb ideig betölteni (tehát melyik van bent a cache-ben), úgy utólag megtudod, hogy mi volt a Reg1-ben akkor, amikor az a spekulatívan végzett művelet eredményével lett feltöltve. Szóval hiába revertáltak mindent, mégis abból, hogy egy cache line betöltődik pontosan meg lehet mondani, hogy mi lenne az érték, ha erre jogunk lenne. A protection ellenőrzésnek van valamelyest költsége, így gondolom áttették a "retire"-ba, mivel "úgysem számít semmit, hiszen vissza lesz csinálva bármi is történik".

    Az a helyzet, hogy ez a cache-betöltődési mellékhatás mégis kiszivárogtatja a dolgokat. Ezt ezért hívják "SIDE CHANNEL"-nek. Tehát eleve az elnevezés is jól leírja, hogy nem egy elsődleges csatornán jutsz hozzá az információhoz, nem olvasod ki és nem látod alapvetően a regiszterben, vagy a ramban.
    Mutasd a teljes hozzászólást!
  • A procin nincs mit backdoorokkal telepakolni.

    Két fajta ember van. Az egyik észreveszi a mondat végén a szmájlit. Te a másik csoportba tartozol.

    Annak meg kb lottó 5-ösnyi esélyt sem adok, hogy páran csak azért loptak a gyártótól végbemérő üzemmódban hagyott procit, csak hogy megmutassák a világnak, lám mégiscsak létezik a sebezhetőség.

    Kiváló elmélet. Az egyetlen szépséghibája, hogy az exploitok az érintett processzorok minden kereskedelmi forgalomban kapható példányán is működnek. Abszolút nincs szükség hozzájuk semmiféle végbemérő módra.
    Mutasd a teljes hozzászólást!
  • A procin nincs mit backdoorokkal telepakolni. A kész exe-t lehet érdemes megspékelni egy benne hagyott (és a biztonság kedvéért titkosítással kíváncsi szemek elől elrejtett) szimbólum táblával, mintha valami debug verzió lenne. Rendeset könnyíthetne a programok változóinak / függvényeinek / folyamatainak a visszafejtésében, hogy könnyebb legyen hozzá valami beépülőt gyártani. Ahogy a mai világ működik, én azt tartom a legvalószínűbbnek, hogy olyasmit forgatnak páran a fejükben.

    Annak meg kb lottó 5-ösnyi esélyt sem adok, hogy páran csak azért loptak a gyártótól végbemérő üzemmódban hagyott procit, csak hogy megmutassák a világnak, lám mégiscsak létezik a sebezhetőség. Elég hamar a kezükre csapnának érte, és szakmailag különben sem kapnának hitelt. Valami hasonló dilis porhintés, mint marketing nevek emlegetése, sokkal könnyebben vakítja a parasztot. Nézd csak meg, ezen a topikon is mit művelt a magukat programozóknak nevező népekkel 
    Mutasd a teljes hozzászólást!
  • Ránéztem. Te is ránéztél? Linux alatt ráolvasni a pagemap-ra, az aztán nagyon skill. Win alatt is meg tudom csinálni, hogy adminként debug supportot kérek az OS-től, és bármelyik másik program memóriájába beleolvasok. Sőt, bele is írok, ha akarok. Sőt, kódot is futtatok annak a processznek a saját területén az ő nevében (dll inject pld). Nincsen abban a világon semmi bug. Hibakeresési célzattal építettek olyat bele minden OS-be. Nincsen a linkelt stuffban olyasmi, ami cpu mikrokód gyengeségre utalhatna.
    Mutasd a teljes hozzászólást!
  • Szócséplés helyett javaslom a következő linket megnézni mintapéldákkal.

    IAIK/meltdown

    Ott vannak a magyarázatok és a működő példák.
    Mutasd a teljes hozzászólást!
  • Ahogy Bill Gates "aids-terjeszto genmodositott malariaszunyoghadsereget" is, dehat aki nyitott szemmel jar, az ugyis tisztaban van az osszefuggesekkel...  ;P  :D
    Mutasd a teljes hozzászólást!
  • A chemtrailt és a gyíkembereket kifelejtetted az elméletedből...
    Mutasd a teljes hozzászólást!
  • Megnéztem a linkedet. Nincsen ott általánosan reprodukálható eljárás, ami közvetlenül cache blokkba tud belenyúlni a lineáris / fizikai címszámítás, és az ahhoz tartozó védelmek megkerülésével.

    Rajtad kívül senki fel sem vetette, hogy
    1. ott ilyen kód lenne,
    2. a hiba természete ebben gyökerezne
    3. bármi ilyesmi szükséges lenne a hiba kihasználásához.

    Mondom, hogy egyszerűen még nagy vonalakban sem érted, hogy miről szól ez a sebezhetőség, és miként lehet kihasználni. Amíg ez nincs meg nálad, addig felesleges szócséplés az egész.
    Mutasd a teljes hozzászólást!
  • Urban legend az egész.

    Sot, siman elkepzelheto, hogy ezek a sebezhetosegek azert kerultek pont most hirtelen napvilagra, hogy konnyebben lenyomhassak az emberek torkan a MKTME tervezetet, amivel aztan leleplezhetetlen modon pakolhatjak tele backdoorokkal a procit. ;)  :D
    Mutasd a teljes hozzászólást!
  • Megnéztem a linkedet. Nincsen ott általánosan reprodukálható eljárás, ami közvetlenül cache blokkba tud belenyúlni a lineáris / fizikai címszámítás, és az ahhoz tartozó védelmek megkerülésével. Az elnevezés ott van az oldalon, de a tartalom nincs 

    Urban legend az egész.
    Mutasd a teljes hozzászólást!
  • Én nem vagyok olyan jó a linkelgetésben, mint te, szóval téged kérnélek meg rá, légyszíves linkelj be magadnak valami érvelési hibát, ami tekintélyérveket állít be észérveknek

    Miért, ezt is elkövetted?

    Utána pedig magyarázd el nekem - és kivételesen tekintélyérvek helyett észérveket kérnék, mert a tekintélyérvelősdi már különben is megvolt előzőleg - ugyan mire lehet azt felhasználni, ha egy program tudomására jut, hogy az adott alkalmazás lineáris memória tartományának milyen blokkjai melyik cache-ben léteznek, vagy éppen nem?

    Elmondtam már. Olvasd el újra! Ha még mindig nem érted, akkor meg megint újra! Ha a 10. után sem érted, akkor meg nyugodj bele, hogy neked túl magas ez a dolog, és bízd inkább hozzáértőkre annak megítélését, hogy valós -e a probléma vagy sem! Nem bántásiból mondom - hanem mert ilyenkor sajnos csak ennyit lehet tenni.
    Mutasd a teljes hozzászólást!
  • Én nem vagyok olyan jó a linkelgetésben, mint te, szóval téged kérnélek meg rá, légyszíves linkelj be magadnak valami érvelési hibát, ami tekintélyérveket állít be észérveknek. Tuti biztos annak is van valami jól csengő neve 

    Utána pedig magyarázd el nekem - és kivételesen tekintélyérvek helyett észérveket kérnék, mert a tekintélyérvelősdi már különben is megvolt előzőleg - ugyan mire lehet azt felhasználni, ha egy program tudomására jut, hogy az adott alkalmazás lineáris memória tartományának milyen blokkjai melyik cache-ben léteznek, vagy éppen nem? Tegyük fel, teljesen feltérképezted. Na és akkor mi van?
    Mutasd a teljes hozzászólást!
  • Szóval benne van a cache-ben egy olyan régió is, amit a programnak nem szabadna látnia

    Nem. Az a memóriarégió, amire te gondolsz itt, nem védett területről származik. A védett területet egy előző utasítás (1. utasítás) címzi, illetve olvassa be. A gépi kód szintjén végül sikertelenül (mert kivételt vált ki), a processzor belső szintjén viszont (az ellenőrzések nélküli spekulatív végrehajtás miatt) sikeresen. Aztán egy rá következő (a spekulatív végrehajtás miatt szintén belsőleg, a kivétel keletkezésének idejére már rég végrehajtott) 2. utasításban a beolvasott érték indirekt indexként kerül felhasználásra egy újabb olvasásban.

    A gyorstár ott jön a képbe, hogy neki köszönhetően utólag, a kivétel keletkezését követően és/vagy a ténylegesen végrehajtásra kerülő, érvényes prediktív szálon meg tudjuk állapítani azt, hogy a 2. utasításban pontosan melyik memóriarégió elérése történt meg a végül eldobott/érvénytelen spekulatív útvonalon. Amit ha tudunk, akkor azt is tudjuk, hogy az ott az 1. lépésben kiolvasott memóriacella tartalma mi volt. Akkor is, ha az amúgy elvileg elzárt, védett területen van/volt.

    Oké. Hogyan fognak a processzor saját utasításai hozzáférni ahhoz a memóriához, ami már ott van a cache-ben?

    Úgy, hogy ráolvastatsz velük. Te nyilván ott zavarodsz össze, hogy "hozzáférés" alatt azt gondolod, hogy a gyorstárból egy érték kerül ki olvasásra. De nem, mert nem érték  kerül kiolvasásra, hanem csak az kerül megállapításra, hogy melyik régió került bele a gyorstárba. Aminek nemes egyszerűséggel gyorsabb lesz az elérése, mint a többinek - és innen lehet tudni, hogy ő került bele.

    Mert tudod, "már csak ki kell olvasni". Jó, mutasson nekem bárki működő példát arra a "csak"-ra.

    Itt egy rakás működő PoC kód.
    Mutasd a teljes hozzászólást!
  • Belenéztem a pdf-be, szenzációhajhász csúsztatás az egész.

    Egyszerűen csak nyilvánvalóan nem érted, hogy hogyan működik egy processzor és/vagy az exploit. Ha értenéd, akkor rövidke gondolkodás után belátnád, hogy valós a támadás. Ennyi az egész. Lásd még: A te érvelési hibád: Személyes kétely

    Mindenesetre legkésőbb akkor sejthetnéd, hogy nem kamu az egész, amikor a fél világ, köztük olyan óriáscégek, mint a MIcrosoft és a Google is javítást ad ki a problémára, illetve amikor ugyanígy a világ másik feléből egyetlen hozzáértő sem állítja, hogy kamu az egész - csak a dilettáns/dilis konteósok.

    Nem lehetséges olyat csinálni. A védett memória bekerül a cache-be (_ha_ tényleg bekerül), és ott is marad, nem kerül onnét tovább sehova sem.

    De nem a cache-be került memória tartalma az érdekes, hanem az, hogy pontosan honnan került be az adat a gyorstárba. Azt meg a számba jöhető címekre ráolvasással és az eltelt idő mérésével meg lehet állapítani. Innentől pedig már lehet tudni annak a memóriacellának az értékét is, ami indexként került felhasználásra egy spekulatív végrehajtott olvasási műveletben (hiszen ennek a cellának az értéke határozta meg azt, hogy honnan/melyik memóriacella tartalma került a gyorstársba.)
    Mutasd a teljes hozzászólást!
  • Belenéztem a pdf-be, szenzációhajhász csúsztatás az egész.

    kimeregesse a cache mind a 256 pontjat

    Nem lehetséges olyat csinálni. A védett memória bekerül a cache-be (_ha_ tényleg bekerül), és ott is marad, nem kerül onnét tovább sehova sem. Az összes "támadás", hogy elpocsékoltattál extra 0.00025 J elektromos energiát egy másodpercenként 115 J energiát kajáló processzorral. Jujj de kis huncut voltál 

    De most nekem már elfogyott az érvrendszerem, meg takarítani kell, szoval rábízlak inkább Sting bácsira. 

    Légyszíves ne fenyegess. Van, ami egyáltalán nem vicces.. 

    Az igazi problémám a történettel csak annyi, hogy bárki bármilyen sebezhetőséget is épített bele abba a C++ fordítóba (mert eddig nem volt sebezhetőség cpu szinten, de majd ezután lesz alkalmazás szinten, ha azt a fordítót használják), nekem senki nem szólt róla semmit, és nem is fizettek nekem azért, hogy csöndben maradjak. Legközelebb vegyenek be engem is a buliba 
    Mutasd a teljes hozzászólást!
  • "Tegyük fel, hogy az előreolvasás tényleg nem ellenőriz külön a szegmens szelektorból is"

    DE! Ellenoriz. Az Address unit az alapjan szamolja ki a fizikai cimet es azt is ellenorzi, hogy egyaltalan hozzanyulhat-e az adott korulmenyek kozott. Mivel hozzanyulhat (mert a sebezhetoseg egyik elengedhetetlen feltetele), ezert bele is fog kerulni a cache attol fuggetlenul, hogy egy félrejósolt IF itasitas vegul nem ér oda, igy a cache-on kivul mas hatasa nem lesz. De ez eppen eleg, hogy egy masik processz, amelyik ugyanabbol a cache-bol dolgozik, kimeregesse a cache mind a 256 pontjat, ami alapjan megtalalja, hogy mi volt a keresett 'kulcs' byte erteke.

    De most nekem már elfogyott az érvrendszerem, meg takarítani kell, szoval rábízlak inkább Sting bácsira. 

    * "szegmens szelektor" ez igy egyutt ertelmetlen, mert a protected mode-hoz pont amiatt talaltak ki a selector megnevezest, hogy meg lehessen kulonboztetni azt a real mode-ban eddig hasznalt segment-tôl.
    Mutasd a teljes hozzászólást!
  • Azért ignoráltam az első két felírásodat is, mert teljesen másik kontextusban gondolkodsz, mint ahol a jelenlegi téma zajlik.
    Mutasd a teljes hozzászólást!
  • Ha jól értem, nem arról van szó, hogy ki tudnád olvasni közvetlenül a cache-ből azt a memóriát, amire nincs olvasási jogod. Azt viszont ki tudod találni az olvasási sebesség alapján, hogy melyik cache line-ba került ez az adat. (Az alapján, hogy neked melyik olvasás a lassú, vagyis melyik cache-elt adatodat ütötte ki a megtámadott kód.)

    Szóval a támadható kódban három dolognak kell lennie:
    1. Indexhatár ellenőrzés
    2. Olvasás tömbből
    3. Az olvasott adattól függő további olvasás, ahol az olvasott cím függ a 2-es pontban beolvasott adattól.

    A támadó kód betanítja a branch predictort, hogy az 1-es pontot sikeresnek tippelje és spekulatíve lefuttassa a 2-es és 3-as pontot. Ha ez megvan, akkor a memória elérési sebességéből kitalálja, a 3-as pont melyik cache line-ba húzott be adatot, és ebből adott esetben következtetni tud arra, hogy mit olvasott a 2-es pont.
    Mutasd a teljes hozzászólást!
  • Tegyük fel, hogy az előreolvasás tényleg nem ellenőriz külön a szegmens szelektorból is, mert amúgy megtehetné, vannak rá regiszterei, ha keletkezik egy védett fizikai cím a prediction folytán, előre tudja, hogy az a hozzáférés tiltott. Egy dev board meg logikai analizátor kellene az igazolásához, amit meg lehetne csinálni, de azt mi most skip, kispóroljuk  Tegyük fel, hogy a jelenlegi processzorokból a gyártók is kispórolták költségcsökkentés végett azt a védelmet, ami a régebbiekben még benne volt. A mai világot illetően meggyőzhető vagyok arról, hogy ha az még nem is történt meg, a jövőben akkor is meg fog történni. Még akkor is ott a 20 forintos kérdésem, amire továbbra sem kaptam választ.

    Szóval benne van a cache-ben egy olyan régió is, amit a programnak nem szabadna látnia, de az ügyködései végett mégis csak a cache-be került. Oké. Hogyan fognak a processzor saját utasításai hozzáférni ahhoz a memóriához, ami már ott van a cache-ben?

    Mert tudod, "már csak ki kell olvasni". Jó, mutasson nekem bárki működő példát arra a "csak"-ra. Pár laikusnak biztos sokkoló lesz a hírek, de az az egyetlen legutolsó hajszál nem éppen gyenge.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd