Miért a WinXPSP2-ben jelenik meg? Abba minek?

Ha tényleg csak az A64 és az Itannium támogatja, akkor elég volna a 64 bites verziókba beletenni.

Azert, mert A64-en is megy a 32 bites WinXP, es mig az XPsp2-bol mostanaban lesz vmi, addig ugyanezt nem mernem teljes bizonyossaggal elmondani a 64 bites verziorol...

Ja, A64-en is megy a 32 bites WinXP, és tudjuk, hogy milyen rengeteg FX53-as gép van ahol lényeges az ilyesmi.
Ha meg kijön a 64 bites XP, szerintem hülye lenne bárki sima XP-t használni rá.

lámák márpedig vannak... :DDD

Arra még nem gondoltatok, hogy a jövőbeni 32 bites processzoroknak lesz ez lényeges az SP2-ben? Vagy esetleg arra, hogy a sok ''szerinted hülye lenne'' ember aki a 64 bites programok és driverek hiánya miatt 32 bites XP-t rak fel a 64 bites processzorára?

De gondoltam rá, de mivel a cikkben külön megemlítették, hogy Intelléktől az Itannium fogja támogatni...

Egyébként milyen 64 bites programok hiányáról beszélsz? A 32 biteseknek elméletben gond nélkül futniuk kell 64 bites XP-n is. Persze a valóság különbözhet ettől, de erről mosot kár lenne filozofálgatni...

Driverek szempontjából persze igazad lehet ideiglenesen, de új hardvereknél meglepődnék, ha nem adnának ki 64 bites változatot is.

Kérlek akkor mutass néhány 64 bitre fordított alkalmazást vagy játékot!
Ha nem tudsz, akkor pontosan ezeknek a hiányáról beszélek :D

A cikkiro egy kicsit jobban is korulnezhetett volna, mielott lenyomja ezt az AMD marketingrizsat!

Az OpenBSD-ben most jelenik meg ez a stackvedelem W^X neven (ha jol remlik, nem vagyok egy BSD guru), illetve a Linux kernelhez mar regota letezo PAX nevu patch is tud ilyet. Jobb processzorok (ertsd: nem x86 architektura) pedig mar regota tamogatjak ezt.

Ez megint olyan, mint az MMX volt annak idejen: a SPARC es az Alpha mar reges regen ismerte a SIMD utasitasokat. Csak ok szepen bevezettek a hasznalatat es nem vertek ugy a nyalukat, mint a PC-processzorgyartok.

[Szerkesztve]

De nem érted, hogy az A64-ben pont az a jó, hogy nem kell 64 bites alkalmazást használni? A mostani 32 bites alkalmazások is ugyanúgy kell, hogy fussanak a 64 bites WinXP-n.

''Ez megint olyan, mint az MMX volt annak idejen: a SPARC es az Alpha mar reges regen ismerte a SIMD utasitasokat. Csak ok szepen bevezettek a hasznalatat es nem vertek ugy a nyalukat, mint a PC-processzorgyartok.''

És vajon melyik stratégia vált be jobban? :U

És te nem érted, hogy 64 bites WOW miatt lassabban futnak rajt a 32 bites alkalmazások, és amíg nincs 64 bites alkalmazás, addig nincs értelme váltani?

Nem tudom, erről még nem hallottam közelebbit. Van valami linked róla?

OpenBSD-ben már benne van egy ideje ez a fajta memóriavédelem, SPARC-on és Alphán működik, de mi köze ennek az A64-hez és az XPSP2-höz, minek kellett volna utánanéznie a cikkírónak?

Nem-x86 architektúrák között már rég van, ami ilyet támogat (Legjobb a Harvard: Fizikailag lehetetlen a puffertúlcsordulásos támadás :) )

Viszont a(z x86-os) Linuxban, meg mindenféle OS-ben található eddigi megoldás softveres, azaz teljesítménycsükkenéses, pont amiatt, hogy eddig az x86 nem támogatta. Ez az NX a hardveres támogatása ennek - és újra is kell rá programozni (mondjuk nem lesz ez nehéz szerintem..)

freya: A WOW nem feltétlen lesz lasabb... Nézd meg ezt: [L]http://www.anandtech.com/systems/showdoc.html?i=1961[/L] A 32 bites DivX 5.1.1 15%-al volt gyorsabb a WinXP 64 bit Extended beta alatt, mint a WinXP SP1 alatt (ugyanazon hardveren).

Az egyik Linux pl tud olyat a x86-64 alatt, hogy a 32 bites proginak 2 db 32 bites változóját egyként tudja kezelni. Meg nem mondom hogyan. (Bár az is lehet, hogy kamu, de elképzelhetőnek tartom)

Tehát ha nem lesz lassabb a 32 bites progi 64 bites Win alatt, és csak a 64 bites proci támogatja az NX-et, akkor szerintem megint csak fölösleges berakni az XP2-be, maradjon csak a 64 bit extended verzióban... Az Itanium más tészta, ara már régen van egy másik, 64 bites Windows...

mar volt errol szo egyszer, mikor ez meg csak terv volt, es ott irtak tobben is, hogy ez meg roszul is elsulhet:
mi van ugyanis, ha a szoftverirok elengedik magukat, mondvan, hogy majd a processzor kivedi, de meg nem lesz a piac 100%-osan lefedve az ilyesfajta vedelmet nyujto processzorokkal?

A mostaninál jobban elengedni magukat? Lehetséges az? :DDD

Egyreszt attol meg, hogy nem lehet exploitolni, meg lefagy tole a program, vagyis tovabbra is bug az overflow.
Masreszt meg a programnyelvek frontjan is valtoznak a dolgok, Javaban pl nem kell buff.ov. miatt aggodni.

Nem érzek ellentmondást a cikk és az állításod között. Szerintem tök független egymástól az, amit te mondasz és amiről írtam.

Hogyne, a forrás kulcsszavait RND generátor rakja egymás után, csak a változók számát kell megadni, meg a basic testcase-eket megírni, és kitenyésztődik a kód. Ha lefordul, és a basic testcase-ek nem jeleznek hibát, akkor már jó. :D

Ha nem áll meg az első siker után, és még a teljesítményt is nézi, akkor nem olyan rossz módszer ez. Csak kissé sokáig tart még... :))

Valaki homályosítson már fel! Ha jól értelmezem a hírt, akkor az a proci, amiben benne van ez a védelem, az nem futtatja le a szarul megírt programot ugye? Mert ha lefuttatná a hibás programot, akkor sebezhető a gép. Ha viszont nem fut a program, akkor cumi. Most mindent újra kell írni, ami eddig túlcsordulást okozott? :F

[Szerkesztve]

Lefut a progi, de amikor a puffernél nagyobb inputot be akarná illeszteni a pufferbe (és azon kívülre) akkor mondjuk kirak neked egy szép kis hibaüzit az OS, és a program kiakad.
Szóva a bug marad, csak nem lesz sebezhető emiatt a géped.

Tehát nem fut le progi, mert hibaüzenettel elszáll. Erre voltam kíváncsi!

Igen, de nem kell újraírni a progikat!

Mert ha a megengedettnél többet írsz a pufferbe, akkor most is elszáll, csak az a különbség, hogy most ezt az oprendszer nem kezeli le, és ezért vissza lehet élni vele/ más proginak is bekavarhat...

A védelemmel már csak a progi fog elszállni, és azt is csak úgy, hogy mást nem fenyeget a veszély.

És maga a hibás progi is fut rendesen, amíg elő nem idézed szándékosan, vagy véletlenül a kezeletlen hibát. Ugyanúgy mint ahogy most is a védelem nélküli rendszereken.

[Szerkesztve]

hááát, az én olvasatomban ez azt jelenti, hogy ha te a csében egy k állandónál gyorsabban nyomkodod a billentyűket (ergo nagyobb az időegységre jutó inputja a klaviatúrának, és átlépi az ominózus k küszöbszámot), akkor a windoze fogja magát, és kib@ssza a programot, mint macskát sz@rni. egyébként lefut, szépen... :DDD
na jó, a hasonlat sántat egy kicsit, mert a billentyzet már sokkal hamarabb megunja a csépelést, és elkezd neked visítani. de attól még jóóóóóóóóó. :DDD

Ezt az AMD mellett az Intel Itanium processzorok is támogatják. A szoftverek közül először a Windows XP Service Pack 2-ben jelenik meg ez a megoldás.

Próbáltam rávilágítani, hogy nem csak ezek a processzorok támogatják, valamint már régen van olyan operációs rendszer, ami csinál ilyet.

Én úgy tudom, hogy minden AMD64-es prociban benne van az NX, vagy nem?

üdv,

Csak akkor, ha ez nincs lekezelve a CS-ben.
És ha ez így lenne, akkor védelem nélkül is simán kiakadna a program, csak esetleg még magával rántaná az egész rendszert is.

ez volt az alapszitu. ha le van kezelve, akkor nincs miről beszélni. :P

Dehát az eddigi A64-ekben is van NX, nem?