Hardveres "törésvédelem" kerül a PC-s processzorokba

Hardveres "törésvédelem" kerül a PC-s processzorokba
2004-01-16T10:12:19+01:00
2004-01-17T11:37:51+01:00
2022-07-01T09:07:00+02:00
  • Apropó nem tudja valaki hogy honnan tudnám az SSE3 utasításkészlet leírását letölteni? Az Intelnél még mindig nem rakták fel, pedig érdekelne hogy mit tudtak alkotni az SSE2-höz képest!
    Mutasd a teljes hozzászólást!
  • Na arról van szó hogy az AMD csinált egy olyat hogy a lapleírók 63. bitjét kinevezte NX bitnek (No Execution) és így erről a lapról nem enged utasíst futtani és dob egy #GP -t! De ezt a bitet nem ellenörzi minden egyes utasítás végrehajtásakor hanem csak akkor ha frissül a TLB! Ezt a tulajdonságot az egyik rendszerregiszterbe lehet engedélyezni, és ennek a regiszternek a meglétét a CPUID-vel lehet lekérdezni! Valamint ez a védelem nem használható minden lapozási módban!

    Egyébként nem tudom hogy ebben mi a nagy újdonság ez már 2002 közepén publikálva volt, és nem hiszem hogy ennek túl nagy jelentősége lenne!

    Én is azon a véleményen vagyok hogy szegmentálást megoldás lenne a problémára csak hát tudni kellene használni!
    Mutasd a teljes hozzászólást!
  • Additionally, Microsoft is working with microprocessor companies to help Windows support hardware-enforced "no execute" (or NX) on microprocessors that contain the feature. NX uses the CPU itself to enforce the separation of application code and data, preventing an application or Windows component from executing program code that an attacking worm or virus inserted into a portion of memory marked for data only.


    Sztem ez az, Itanium tamogatja jelenleg.

    netchan
    Mutasd a teljes hozzászólást!
  • Biztos végigolvastad a hírt?
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Hat ja, SPARC, Alpha, es talan MIPS is legalabb 10 eve tudja ezeket.

    Ha valakit erdekel a teme itt van egy link amiben az OpenBSD leader leirja, hogy mit csinaltak az i386 architekturan, amivel megkerultek a proci gyengesegeit:
    http://marc.theaimsgroup.com/?l=openbsd-misc&m=105056000801065&w=2
    Mutasd a teljes hozzászólást!
  • Nem rossz, de ezt 10 évvel ezelőtt kellett volna.
    Mutasd a teljes hozzászólást!
  • Rovid kereses utan sikerult arra a kovetkeztetesre jutnom, hogy az uj vedelem valoszinuleg egy code/data bit lesz a lapleirokban (page table entries). Ez annyit jelent, hogy csak olyan lapok lesznek futtathatoak, amiket kodkent jelolt meg az oprendszer. (azaz a betolteskor egy program vagy egy dll code section-jehez tartoztak) Gyakorlatilag ennek tamogatasahoz csak a lapkezelest es a modulbetoltest kell egy-egy helyen atirni. A kodteruletekre meg erdemes lehet ratenni egy implicit read only (csak olvashato) tulajdonsagot is. Valami hasonlot emlegetnek az interneten talalhato leirasok is.
    Mutasd a teljes hozzászólást!
  • Mármint a szegmensregiszterek betöltése növelheti a végrehajtási időt (mihez képest???). Amikor flat modell esetén a rendszer a felhasználói és a felügyelői módok (vagy nevezzük, ahogy akarjuk) között kapcsolgat, privilégiumszintet vált, és ehhez szegmensregisztereket kell cserélni.

    Mellesleg egy swappelési művelet sokkal tovább tart, úgyhogy nem tudom mit kell ezen aggódni. Nem aggódnak a virtual machine-eken sem. Persze, mérlegelni kéne az előnyöket is, és nem csak egy hátrányra kell összpontosítani.

    Összvissz annyit kellett volna csinálni, hogy a kód és az adatszegmens ne lapolódjon át. Így megmarad az az előny, hogy az összes adat egy címterületben marad, és továbbra is egyetlen mutatóval végigcímezhető. Továbbá a program nehezebben fér hozzá a saját kódjához (csak olvasásra persze); felülírni nem tudja. DE! figyelembe kell venni, azt a tényt, hogy a kód ilyenkor külön címterületben van és ezt a fordítóprogramoknak figyelembe kell venniük; vagyis különbséget kell tenniük a kódra, illetve az adatra mutató pointerek között, ami megnehezíti a fordítóprogramokat fejlesztő cégek dolgát. Vagyis csak annyiban, hogy kicsit hasonlít a Harward-architektúrához.

    Talán a DOS-os időben elterjedt "small modell" kifejezés takarja legjobban azt, hogy mire gondolok.
    Mutasd a teljes hozzászólást!
  • A témanyitó hozzászólásomhoz hozzátenném, hogy nemcsak lustaságból, hanem a kicsit kényelmetlen kezelés miatt sem használták ki az i386 lehetőségeit.

    A flat modell alkalmazásának performance okai vannak, nem pedig lustaság. A külön szegmensek jó dolgok, csak éppen drasztikusan növelik a végrehajtási időt. Gondolhatod, hogy nem lustaságból választották ezt az összes modern x86 OS-nél.
    Mutasd a teljes hozzászólást!
  • A puffer-túlcsordulásos támadások lényegében azt használják ki, hogy a ma legelterjedtebb PC-s architektúrák az adatokat és a programkódot közös területen tárolják, és így akár az eredetileg adatként bevitt bájtsorozatokat is képesek programként futtatni.


    Mármint a ma legeltejedtebb PC-s operációs rendszer architektúrák.

    A Windows NT operációs rendszer például megalkotása óta támogatja az adat- és kódterületek különválasztását, de a hardveres támogatás hiányában korábban csak Alpha processzoron futó változatain volt kihasználható ez a lehetőség.


    i386-on is ki lehetett volna használni ezt a lehetőséget, de a hordozhatóság (már amennyire hordozható ) miatt nem tették.

    Az AMD most bejelentett Execution Protection eljárásának lényege, hogy lehetővé teszi a puffer- és a kódterületek szeparált jelölését, és a pufferterületeken lévő adatok programként történő futtatásának megakadályozását.


    Hát igen, nem átlapolódó kód- és adatszegmensek.

    A témanyitó hozzászólásomhoz hozzátenném, hogy nemcsak lustaságból, hanem a kicsit kényelmetlen kezelés miatt sem használták ki az i386 lehetőségeit. Lehet, hogy az AMD ezt kényelmesebbé teszi, és az oprendszerfejlesztők nekiállnak használni? Ebben az esetben a hardvergyártóknak nem kellett volna előbb lépniük ezügyben?
    Mutasd a teljes hozzászólást!
  • Írjanak meg minden app-ot Java-ban, vagy .Net-ben, ott nem lehet elkövetni ilyentet. A VM-eket meg írják meg jól, aztamindenit nekije !
    Mutasd a teljes hozzászólást!
  • Nem tudom, hogy ebben mi az újdonság, mert az i386 védett módban ezt már mind-mind tudta! Úgy hívják, hogy szegmentált memóriaszervezés, csak éppenséggel senki sem úgy használta, ahogy kellett volna; mindenféle kényelmi (=lustaság ) okokból a lapozást és az abban rejlő védelmi mechanizmusokat részesítették előnyben, holott már kezdetől fogva kombinálni kellett volna a két lehetőséget, és akkor nem lehetne puffer túlcsordulással kódot bejuttatni. :damn:

    Ez egy amolyan neszesemmifogdmegjól, de legalább rájöttek, hogy ki kéne használni egy ilyen ilyen hardveres lehetőséget, ami már egy évtizede létezik x86 architektúrán!

    Amúgy miben más az AMD megoldása? Azon túl, hogy adtak neki egy jól hangzó nevet? Kíváncsi vagyok rá. Tényleg kíváncsi vagyok rá, hogy végülis miben hoz be újdonságokat az informatika világába az i386 (ki nem használt) tudásához képest.

    Mutasd a teljes hozzászólást!
abcd