Features AMD-chips ontwaken door update Windows XP

AMD zal binnenkort een nieuw voordeel van zijn processors ten opzichte van Intel kunnen noteren. Beveiligingsfeatures die in zijn 64-bit processors zitten ingebouwd zullen namelijk worden geactiveerd door een Windows XP-update, zo meldt MarketWatch. AMD heeft deze beveiligingen in nauwe samenwerking met Microsoft ontwikkeld om bescherming te bieden tegen Blaster en Code Red aanvallen. De code zit ingebakken in zowel de Athlon 64- als Opteron-processors en zal geactiveerd worden met een Windows XP-update die gepland staat voor midden 2004. De set beveiligingsfeatures zorgt ervoor dat buffer overflows niet meer mogelijk zijn, wat een wijd verspreid beveiligingslek is in computerprogrammatuur, en waar dankbaar gebruik van wordt gemaakt door hackers en virusmakers. Volgens analisten zit dergelijke code niet in Intel's nieuwe Prescott-processor of andere PC-produkten die de komende anderhalf jaar door Intel zullen worden uitgebracht en komt vergelijkbare veiligheidscode alleen voor in de dure Itanium serverprocessors. Met deze beveiligingsfeatures zal een belangrijke slag worden geslagen in de strijd tegen virussen en exploits:

The new AMD advance can theoretically stop Microsoft's time-consuming and expensive stream of buffer overflow software patches. It also could eliminate the need for IT managers to make sure all systems have the latest buffer protection. According to Kohout, instructions in AMD's PC processors allow memory to be labeled as readable, writeable, or executable. What AMD and Microsoft have done is design rules that prohibit executable code from running inside buffer areas that were designed for reading data.

Reacties (61)

[Olaf van der Spek]

De set beveiligingsfeatures zorgt ervoor dat buffer overflows niet meer mogelijk zijn, wat een wijd verspreid beveiligingslek is in computerprogrammatuur, en waar dankbaar gebruik van wordt gemaakt door hackers en virusmakers.

Buffer overflows zelf zijn nog wel mogelijk, maar het is niet meer mogelijk deze uit te buiten.

The new AMD advance can theoretically stop Microsoft's time-consuming and expensive stream of buffer overflow software patches.

Ik neem aan dat het process crashed op het moment dat zo'n overflow optreed. Als MS genoegen neemt met crashende apps kunnen ze inderdaad stoppen met patches ja. Ik heb liever apps (zonder bugs) die niet crashen en waar de overflow gewoon niet mogelijk is.

[Anoniem: 87832]

Óf de CPU gaat gewoon door met de operatie maar schrijft niks meer naar de buffer vanaf het punt van overflow, eventueel met een "buffer overflow" CPU statusbitje.

[Olaf van der Spek]

De CPU kan geen buffer overflow detecteren. Alleen executie van code in een non-executable buffer kan worden gedetecteerd. Op dat moment kan niet meer verder worden gegaan met normale executie, dus zal de app crashen (of zoals tommy84 aangeeft) abnormaal beeindigd worden.

[PuzzleSolver]

Alleen executie van code in een non-executable buffer kan worden gedetecteerd

Ook het schrijven in executable dataspace kan worden gedetecteerd. Het overschrijven van data van een ander programma kan gedetecteerd worden en nog een aantal dingen.

Het geheugen model van de huidige 32 bits applicaties zet alleen alle data achter elkaar in memmory (in één segment) waardoor er niet echt meer onderscheid is tussen stack en data. Dit komt omdat we graag met 32 bits pointers werken in onze software waardoor er geen ruimte meer is voor segment adressering, deze is dus derhalve maar gelijk gezet voor alle data (de segment registers SS,DS en ES wijzen dan ook vaak naar hetzelfde segment).
In oude 16 bits software die op een DPMI (DOS Protected Mode Interface) werkten waren de pointers ook 32 bits en daar werd dus een 16 bits segment nummer en een 16 bits offset (ja een 64K per blok limiet) in gedrukt. De processor weet van elk segment hoe groot het is en doet daar dus een hardwarematige bufferoverflow check op. In Borland Pascal, waar ik in die tijd in programmeerde, kun je een aantal geheugenallocatie variabelen aanpassen zodat voor elk blokje een nieuw segment aangevraagd wordt. Dit heeft als voordeel dat al de buffers hardwarematig gecontroleerd worden, dit is echter niet echt wenselijk want het vetraagd enorm en omdat je maar 65535 segmenten kan adresseren niet echt handig.

Verder heb je nog het hele Paging verhaal van de processor wat weer een laag dieper ligt welke ook nog controle per pageblok kan doen, (ga ik hier niet verder uitleggen).

Als windows nu dus iets doet om aan de processor de buffer groote informatie van aangevraagd geheugen door te geven kan er dus veel beter gecontrolleerd worden of er een bufferoverflow plaats vind, alleen heb je dan nog steeds geen bescherming van de stack. Tenzij er door de compiler ook nog info meegegeven kan worden door b.v. non accecable memory locaties mee te geven die zich tussen de variabelen bevinden.

Maar ik ben dus eigenlijk wel nieuwsgierig hoe dit nu echt werk op die AMD proc., want het kan er ook voor zorgen dat programmeurs hun buffer overflows binnen hun eigen software eerder vinden (in de praktijk geeft een bufferoverflow nu nl. een onvoorspelbaar resultaat en niet altijd een crash). Hierdoor zou software stabieler worden en heb ik ieder geval een reden om nu een AMD-64 te vragen voor de programmeurs hier.

[PuzzleSolver]

Ook het schrijven in executable dataspace kan worden gedetecteerd.

Hmm. Schrijven in read-only space kan gedetecteerd worden, jij schrijft dat een beetje raar op.

Mischien beter gezegd:

Het overschrijven van code is al beschermd in de huidige processor technieken sinds de 286.

Het OS gooit het erin door zelf het geheugen eerst writable te maken, daarna wordt het executable geflaged en kan het programma starten, dit houdt in dat het tegen schrijven beschermt is (lezen is soms wel handig, b.v. een plaatje ofzo in code gooien met ASM DB code zodat het niet met een resource editor veranderd kan worden).

Dus ik vraag me nog steeds af wat ze hier nou veel extra doen. Maar aangezien dit artikel van een manager site afkomstig is hecht ik niet zoveel waarde aan het artikel. Ik zal eens kijken of ik meer info kan vinden.

edit:

Het gaat dus om een uitbreiding, het executen van data was nog niet te beschermen, maar met de AMD-64 en de Itanium wel.[quote]

You may have been lazy and not bothered calling VirtualProtect(PAGE_EXECUTE) when you generated some code on the fly. You got away with it because the i386 processor page protections do not have a "read but don't execute" mode, so anything you could read you could also execute.

Until now.

Starting with Windows XP Service Pack 2, on processors which support it (according to the web page, currently AMD K8, Itanium, and AMD64), the stack and heap will not be executable. If you try to execute the stack or the heap, an exception will be raised and the code will not execute. In other words, execute page protection will soon be enforced, now that processors exist that support it. (Actually, I believe Windows XP for Itanium already used this new protection level, so those of you who have been playing around with your Itanium may have seen this already.)

If you were a good developer and followed the rules on page protections, then this has no effect on you. But if you cheated the rules and took advantage of specific hardware implementation details, you may find yourself in trouble. Consider yourselves warned.
[/quote]

http://blogs.gotdotnet.com/raymondc/commentview.aspx/f16e918b-43e2-4bb a-9260-3fb02a45faf6

[Olaf van der Spek]

Ook het schrijven in executable dataspace kan worden gedetecteerd.

Hmm. Schrijven in read-only space kan gedetecteerd worden, jij schrijft dat een beetje raar op.
Volgens mij werkt deze nieuwe beveiliging op page-niveau, dus niet met segmenten.
Buffer overflow exploits schrijven code op de stack en voeren dat dan uit. Zoals ik al zei is alleen het uitvoeren detecteerbaar, het schrijven niet.

[pietje63]

Volgens mij is er verschil tussn een crash en een commando vergelijkbaar met het linux kill dat de applicatie meteen afsluit.

[Anoniem: 2141]

ik heb begrepen dat 't nog steeds mogelijk gaat zijn.. je kunt namelijk voortaan alleen buffer overflowen binnen het data-deel van een proces, maar daarin staat ook de instructie pointer..
wanneer je die weet te overschrijven ben je er ook.. zo kan je ook bepaalde stukken code overslaan (waardoor bijvoorbeeld inloggen niet meer nodig is) of wellicht zelfs code uit het data-deel laten uitvoeren.

correct me if i'm wrong, maar ik heb begrepen dat dit niet omzeild is met deze security feature..

[Anoniem: 1999]

"DE" instructiepointer staat zeker NIET in data; het is een intern processor-register.
Hoewel het natuurlijk altijd mogelijk blijft dat een programmeur een waarde uit het datagebied gebruikt als pointer waar expliciet naar toe wordt gesprongen, maar dat moet dan echt zo geprogrammeerd zijn en bij het merendeel van de huidige buffer-overflow problemen zal dat niet het geval zijn. Bovendien is
dan nog steeds de vraag waar naartoe moet worden gesprongen, als de nieuwe processor-features weten te voorkomen dat het door de hacker m.b.v. een buffer-overflow aangepaste data-gebied wordt uitgevoerd als programma-code.

[Sjaaky]

@Bunny:
Je hebt gelijk, het is precies andersom. Het buffer-overflow gebied staat namelijk op de stack. Als je malafide data stuurt met een stukje code erin en ervoor zorgt dat je op de plaats op stack waar de huidige functie zijn EIP verwacht een pointer naar jouw stukje code neerzet, dan zal jouw code uitgevoerd worden.
Valt me eigenlijk tegen dat dit nu pas wordt opgelost. Al vanaf protected mode wordt er onderscheid gemaakt tussen code en data segmenten.

[Olaf van der Spek]

Al vanaf protected mode wordt er onderscheid gemaakt tussen code en data segmenten.

Maar moderne OSs gebruiken een flat addressing space. Een 32-bit pointers kan naar code en naar data verwijzen.
Waarom er eigenlijk niet twee aparte segmenten voor gebruikt worden weet ik niet.

[Olaf van der Spek]

De ret instructie popped EIP van de stack. Dat er geen code pointers in data areas staan is dus niet waar.

[Anoniem: 1999]

En hoe wilde je dan de stack veranderen? Lijkt me niet erg waarschijnlijk dat de stack in het buffer-overflow gebied staat namelijk!

[Anoniem: 2141]

als je gaat multitasken moet je per proces onthouden waar je gebleven was natuurlijk (DIE instructie pointer bedoel ik dus).. die wordt gekopieerd naar de instructiepointer in de cpu wanneer het proces weer aan de beurt is (zelfde geldt natuurlijk alle andere registers etc)

[Pther]

De mogelijkheid van scheiding van Data en Code segmenten bestaat al sinds de introductie van de 386 instructieset. Als dit fatsoenlijk gebruikt wordt, zijn buffer-overflows zoiezo niet meer te exploiten. Dit omdat uit een data-segment gewoon geen code uitgevoerd kan worden.

De reden dat dit niet gebruikt wordt is heel simpel: het is gewoon lastig te gebruiken. Voor een operating system is het gewoon heel gemakkelijk om al het geheugen in een keer aan te spreken en zelf de toegang te regelen. Jammer dat het niet wordt toegepast, want het zou in een keer een oplossing voor alle overflow-exploits betekenen.

[PuzzleSolver]

Reactie op Olaf:

Maar moderne OSs gebruiken een flat addressing space. Een 32-bit pointers kan naar code en naar data verwijzen.
Waarom er eigenlijk niet twee aparte segmenten voor gebruikt worden weet ik niet.

Voor code en data worden toch twee verschillende segmenten gebruikt. Start een debugger en kijk naar CS (code) en de data registers SS (stack), DS (data), ES (meer data). De data segment registers staan op een ander segment dan CS. Het was nu alleen nog mogelijk om door een buffer overflow data op b.v. de stack te krijgen (daar staan alle locale variabelen van procedure's en idd de return adressen van procedure's) en blijkbaar ook mogelijk om deze uit te laten voeren ondanks dat het geheugen als DATA gemarkeerd was, dit is dus nu te voorkomen.

[Pther]

Inderdaad zal je debugger aangeven dat er meerdere segmenten in gebruik zijn. Dit zijn echter logische segmenten. Fysiek gezien zijn deze segmenten niet zo netjes gescheiden als dat je denkt. Voor de processor is het namelijk eigenlijk één groot segment waar het gehele OS in draait. Zodoende dat er toch code uit een als DATA gemerkt segment uitgevoerd kan worden.

[PuzzleSolver]

Inderdaad zal je debugger aangeven dat er meerdere segmenten in gebruik zijn.

En om dat voor te zijn heb ik een test app geschreven die probeert het zelfde addres in het code segment te lezen, dit geeft dus gewoon een Access Violation. Dus niet dezelfde address space (of in ieder geval niet te lezen via dit segment).

Als iemand echt zou weten waar hij hier over praat dan zou hij weten dat geheugen access op de x86 eerst gaat via een segment register die in een descriptor tabbel (dit gaat via hardware op de processor) het bijbehorende hardware adres en acces flags en limiet ophaald.(eigenlijk wordt dit al gedaan bij het vullen van het segment register met een waarde, vandaar dat je daar ook een exceptie krijgt bij het zetten van deze op een ongeldige waarde).Bij het adres uit deze tabbelwordt dan de offset opgeteld die in het pointer register zit. Dan heb je een Virtual address (binnen 4Gb van flat address space), dit gaat dan vervolgens door de paging table die kijkt welk fisiek stuk geheugen er bij hoort, of als er nog geen fysiek stuk geheugen voor is wordt er een pagefault gegenereerd waarop het OS het eventueel nog uit een pagefile kan laden ten koste van een ander stuk fysiek geheugen.

Verder is het zo dat er meerdere segmenten naar hetzelfde flat virtual geheugen kunnen wijzen waardoor er op verschillende manieren gebruik gemaakt kan worden van hetzelfde geheugen. (bijvoorbeeld als code en als data). Maar ik weet niet of het OS dit nog toestaat (met DPMI kon dit via API's). Dus "Pher"

Zodoende dat er toch code uit een als DATA gemerkt segment uitgevoerd kan worden.

dit is dan niet benaderd via dit segment maar via een alternatief segment. En "Olaf" verkondig niet continu je eigen mening als de waarheid als je het niet zeker weet (hiermee verlies je geloofwaardigheid terwijl je best wel veel weet (het kan nattuurlijk ook zijn dat je probeert een andere mening uit te lokken om er zelf wijzer van te worden, in dat geval heb ik niks gezegd)).

[SG]

Dus buffer overflows zijn we mogelijk maar het geheugen waar de buffer op uitloopt is protected dus de overflow komt nog wel voor alleen de schade niet.

Als het geheugen wat naast de buffer zit, die overflowed, programma code is wordt dit niet overschreven dus de bug blijft er, maar het crashed niet omdat die code protected is en niet vermeubeld is door de overflow, zodat de code geldig blijft onbeschadigd en het programma door kan gaan

Maar 'n variable naast 'n bufferdie over flowed die wordt dan wel overschreven omdat ie writable geflagd is?

[n4m3l355]

ik vraag me of men dit ook te kennen geeft aan bijv. de Linux gemeenschap of de BSD/BeOS gemeenschap.. BSD maakt namelijk al een tijdje gebruik van random memory management. iets wat ze nu hardware matig in gaan bakken als ik het goed begrijp.

Dit geeft dus alleen maar weer aan hoe brak windows software is. onder linux en zeker onder BSD valt dit ver tegen te gaan (nog steeds niet volledig).
Verder heeft het weinig nut denkelijk op grote netwerken. De servers blijven overeind echter de backend netwerk switches/corebuilders vinden zoiets nog steeds niet lekker aangezien het netwerk dicht slipt.

Verder is hier wel een groot gevaar in... wat gebeurt er als de precieze info over deze chipset bij hackers over op de werkplaats terecht komt? Deze kunnen virussen/worms wahtever schrijven die specifiek deze chip telijf gaan waardoor de memory management volledig ontregeld wordt... gevaarlijk spelletje van AMD imo.. dit kun je toch beter afwikkelen in de switches/routers indien mogelijk en als dit niet zo is op software niveau ipv hardware...

verder vraag ik me af of dit wel de juiste doelgroep is die er serieus problemen mee heeft.. buffer overflows hebben voornamelijk effect op servers.. daar is AMD nog bij lange na niet aan toe

[seweso]

Deze kunnen virussen/worms wahtever schrijven die specifiek deze chip telijf gaan waardoor de memory management volledig ontregeld wordt...

Als je de processor te lijf kan gaan dan heb je meestal al volledige controle over de desbetreffende computer imho...

buffer overflows hebben voornamelijk effect op servers..

Ja dat is fijn maar met Windows Xp is elke pc standaard een server (zie lijst met services)

[YaPP]

Dit geeft dus alleen maar weer aan hoe brak windows software is. onder linux en zeker onder BSD valt dit ver tegen te gaan (nog steeds niet volledig).

Ik zal het niet direct brak noemen, hooguit hebben ze een aantal features nog niet geimplementeerd.

Gister heb ik mijn linux kernel met de grsecurity patch gecompileerd, en kwam ik interessante zaken tegen, o.a.:
- Enforce non-executable pages (komt ongeveer op dit amd verhaal neer)
- Randomize user stack base
- Chroot jail restrictions (chroot is een groot gemis in Windows, en nu is het nog veiliger gemaakt..!)
- Veel logging features
- Randomized process-ids, tcp ids, source ports
- Hide device/kernel information in /proc/
- Trusted path execution (alleen binaries uitvoeren in directories die niet door een user aan te passen is)
- Restrictions op sockets in het algemeen

Met andere woorden, ik denk dat Microsoft nog wat werk te verrichten heeft

[intGod]

Tja, dit is een typisch geval van goed en slecht. Het is goed dat de Buffer Overflows niet meer kunnen uitgebuit worden maar het zal de programmeurs toch weer 'luier' maken omdat ze dit soort beveiliging niet meer kunnen afvangen.

Ik ga er echter nog steeds van uit dat een goede programmeur dit soort zaken gewoon moet afvangen.

[Anoniem: 2141]

de pest is dat 't je code gewoon steeds meer overhead geeft.. iedere keer wanneer je bepaalde data op lengte moet checken voor je het in een variabele propt.. het maakt 't leven van de programmeur er niet leuker op je bezig houden met security tijdens het coden is het minst leuk natuurlijk, want het voegt niks toe aan de functionaliteit of stabiliteit van je programmatuur... kvind het dus wel prettig als je hier minder rekening mee hoeft te gaan houden in de toekomst.

[Olaf van der Spek]

Dat valt wel mee. Ik vind input validation eigenlijk echt geen feature die (alleen) onder security valt.
Als je per ongeluk een binary in Word opent, mag Word ook niet crashen.

[Anoniem: 2141]

olaf, "input validation" om buffer overflows tegen te gaan is niets meer dan kijken of de data in je buffer past of dat het wellicht te groot is.

[eggieman]

Het is natuurlijk wel de vraag hoe de processor in combinatie met Windows reageert, als die samen de applicatie afschieten, wordt je als programmeur nog meer op de feiten gedrukt.
Een overflow zal nu meestal niet eens gemerkt worden. (Er zijn veel voorbeelden te verzinnen waarbij buffers worden overschreven die niet eens meer gebruikt worden) Wordt de applicatie echter gestopt door Windows en de CPU, klapt een slecht programma er telkens uit. En dit vraagt dus meer werk van de programmeur.

[Frank-L]

Buffer overflows worden niet gedetecteerd met deze update!
Alleen is het niet meer mogelijk om code uit te voeren die een exploit d.m.v. een buffer overflow in een data segment van bijvoorbeeld de web browser weet te zetten.

[procyon]

Maar de ervaring leert ons dat dit heel erg vaak niet gebeurt, dan is het toch mooi dat het hardwarematig niet meer mogelijk gemaakt wordt?

[KompjoeFriek]

Ik zou zeggen:
"Test je software ook eens op de 486 die (nog) in je kast staat (router te spelen)."

[Nico de Vries]

"Het is natuurlijk voor thuisgebruiker geen must om zo'n beveiliging te hebben"

Integendeel. Het is JUIST voor thuisgebruikers heel belangrijk. Van bedrijven mag je verwachten dat ze patches en dergelijke op orde hebben. Veel consumenten hebben echter geen idee hoe het allemaal werkt en zijn daardoor een dankbare uitvalsbasis voor DDOS en andere grappen en grollen.

[jGS]

Denk je ?
Als jij als thuisgebruiker 1 of 2 pc'tjes staan hebt, is toch makkelijk up to date te houden ?
Hou als webhost of bedrijf maar eens je computerpark met 1000 den pc's up to date ...

[Anoniem: 2141]

de meeste bedrijven hangen al hun pc's wel achter een gateway, dus komen dat soort buffer overflowende attacks toch al nooit aan bij de workstations.

[Sjaaky]

Dat is niet waar, buffer-overflows kunnen echt overal in zitten. Outlook heeft er toch ook last van gehad?
Ook software die niet direct met internet te maken heeft kan er last van hebben.
Ik denk dat er nog zat bufferoverflows zitten in applicatiesoftware die gewoon nog nooit ontdekt en benut zijn. Ze zouden makkelijk in officebestanden kunnen zitten, of in unzip programma's, in gif/jpef viewers/editors, nieuwe mods voor je favo game.
Elk programma dat uitgaat van een vaste grootte van een datastructuur en dat niet checkt heeft potentie om uitgebuit te worden. De impact is waarschijnlijk niet zo groot en daarom is er nog niemand geweest die gericht naar bufferoverflows in niet internet gerelateerde software heeft gekeken.
Het is een goede zaak dat dit soort dingen hardware-matig tegengegaan kunnen worden. Als de w2k-bug bestreden had kunnen worden door de processoren van alle servers te vervangen, had dat denk ik een hoop geld en tijd gescheeld.

[Anoniem: 57003]

In de praktijk is dit niet het geval.. thuisgebruikers updaten hun systeem bijna nooit (omdat ze simpel weg niet weten hoe of niet durven omdat ze bang zijn de pc omzeep te helpen.)

De meeste DDOS packets komen af van thuisgebruikers die gehackt zijn en/of een trojan bevat en niet van de 1000 den pc's van een webhost.

[Anoniem: 72914]

Maar dat heeft weinig met hoeveelheid pc's te maken, maar meer met de internetverbinding. En meestal zijn die pc's bij een bedrijf allemaal hetzelfde, dus als je er 1 gekraakt heb, kan je bij allemaal....

[Pewwy]

Voor dat soort bedrijven zijn door Microsoft tools uitgebracht (gratis zelfs) waarmee je patches op geplande tijdstippen kunt aftrappen. Helaas worden deze nog te weinig gebruikt, maar mocht je Windows 2000/XP werkstations in je computerpark hebben dan kun je deze oplossing hier: http://www.susserver.com/ bekijken...

[YaPP]

Denk je ?
Als jij als thuisgebruiker 1 of 2 pc'tjes staan hebt, is toch makkelijk up to date te houden ?
Hou als webhost of bedrijf maar eens je computerpark met 1000 den pc's up to date ...

als je alleen al kijkt naar het aantal outlook express exploits die de laatste tijd gebruikelijk waren, vind ik dit toch een hele opluching.

Virussen proberen tegenwoordig steeds vaker van exploits (o.a. buffer overflows) gebruik te maken om zich te verspreiden.

[Sluuut]

Ik ben van mening dat je niets hardware matig moet oplossen met de reden omdat het softwarematig niet meer kan. Soort van laatste redmiddel.

Wie weet zit er straks ook wel een feature in voor software beveiliging, paladin heette dat? Ik ben even de naam kwijt, iets wat in de toekomst in hardware zou worden gebouwd en wat later met Windows softwarematig ook zou kunnen worden beheerd, waardoor illegale of gekopieërde software niet meer mogelijk zou zijn.

[mindcrash]

Wie weet zit er straks ook wel een feature in voor software beveiliging, paladin heette dat?

codenaam Palladium aka. NGSCB (Next Generation Secure Computing Base)

Ik ben even de naam kwijt, iets wat in de toekomst in hardware zou worden gebouwd en wat later met Windows softwarematig ook zou kunnen worden beheerd, waardoor illegale of gekopieërde software niet meer mogelijk zou zijn.

Daar is nog niks over bekend. In theorie is het mogelijk, maar in de praktijk zal dat waarschijnlijk wel meevallen.

Als Microsoft echt dom is dan forceren ze NGSCB i.p.v. de consument de vrijheid geven of een bepaald programma wel of niet in de Nexus zal gaan draaien. Consumenten zijn wat dat betreft niet echt helemaal gek en zullen waarschijnlijk massaal overstappen alternatieve besturingssystemen (Linux) / computers (Apple). En dat is iets wat Microsoft dus zichzelf absoluut niet kan permitteren tegen de tijd dat Longhorn in de winkel ligt, gezien de huidige ontwikkelingen in de ict.

Hier kun je overigens lezen wat Microsoft precies van plan is met deze technologie.

[Mars Warrior]

Iets in hardware oplossen met de reden dat het softwarematig niet meer kan heeft volgens mij niets te maken met de page protection van moderne processoren.

In een eerdere reactie heb ik al eens aangegeven dat page protection op bijv. een VAX of Alpha processor de gewoonste zaak van de wereld is en heel veel fouten af kan vangen: Zo is binnen VMS de eerste pagina in je programma een NO-ACCESS page: hierdoor worden NULL pointers heel eenvoudig gedetecteerd.
Verder wordt op deze manier ook heel eenvoudig stack-overflow (en dus de dynamische uitbreiding van de stack) gedetecteerd door het OS: Die krijgt een NO-ACCESS exception, breid de stack uit, en hoppa, het programma loopt rustig verder. Niks geen gecheck in software: gewoon de hardware zijn werk laten doen...
Daarnaast bepaald zo'n page protection of een page R/W is, data of code bevat en vanaf welk level (kernel, user). Als je per ongeluk of expres "foute" dingen doet krijg je gewoon een AccessViolation exception die je in je programma kunt afvangen, net als elke andere exception.

Dat dit EINDELIJK ook in Windows XP of beter gezegd op een PC mogelijk wordt is toe te juichen, zowel vanuit een ontwikkel standpunt bezien als vanuit beveiliging/virussen

[tech-no-logical]

dit lijkt in hardware op wat de propolice gcc-extension in software doet. omdat (afaik) de overhead van propolice erg klein is, zie ik niet direct wat er aan dit systeem beter is dan aan een systeem waarbij binaries met propolice gecompileerd zijn (zoals bijvoorbeeld OpenBSD, waar propolice tegenwoordig standaard is).

[coolmos]

Het is dus een lapmiddel voor slecht geschreven software.

Niet dat dit een slechte zet is van AMD, maar waarom moet een hardware oplossing de fouten van Microsoft ondervangen ?

[Anoniem: 84469]

Het foutloze programma is een utopie.

[SG]

De trend is juist bij hogere orde talen om memory safe te kunnen progen zoals Java en C# het memory gebeuren wordt onderhuids geregeld en pionters worden gemeden zoals bij C/C++.
Nu wordt dit dus ook al op hardware level gedaan ipv op ontwikkelingtool niveau.

Dit houd in snelle time to market

5mnd code tijd waarvan 50% debuggen en dan 4mnd beta testen tegen 3mnd coden 25% debuggen en 2mnd beta testen en veel minder bug's

Als overdreven voorbeeld

[YaPP]

Het is dus een lapmiddel voor slecht geschreven software.

neen.

Het probleem zit niet in de software, maar in de manier waarop de PC-architectuur (dus ook jouw CPU) werkt. We hebben het hier over een architectuur die 20 jaar oud is, en de tijd/eisen is ondertussen enorm veranderd

De CPU doet niets anders dan data verplaatsen, berekeningen uitvoeren, en in dat zelfde geheugen ook pointers ophalen, en op die plekken bytes uitvoeren als code. Het doel van een exploit is kortweg, buffers overschreiden zodat er ook een pointer aangepast word. (en die dus laten verwijzen naar jouw data, dat vervolgens als asm-code wordt uitgevoerd)

Als je op het niveau van C (en een beetje C++) programmeerd zit je dermate dicht op de CPU te werken, dat je ook op buffer groottes moet letten e.d.

[Anoniem: 95902]

@jGS

wij hebben op ons bedrijf honderden computers
en die zijn allemaal met 1 klik upto date
We hebben programma's die ALLE computers op ons netwerk in 1 keer update zodra die computer aangaat, zodra er een nieuwe patch is hoeven we die alleen maar in het juiste mapje te slepen, en klaar is kees

Ik ben het eens met Nico de Vries

thuisgebruikers hebben hun software vaak niet up to date, en voor hun is het een uitkomst

[YaPP]

We hebben programma's die ALLE computers op ons netwerk in 1 keer update zodra die computer aangaat, zodra er een nieuwe patch is hoeven we die alleen maar in het juiste mapje te slepen, en klaar is kees

Ik zal proberen netjes te blijven, maar om heel eerlijk te zijn vind ik dit zeer kortzichtig.

Patches zijn een plijster op de wond, en deze aanpak van AMD is mogelijk een genezing voor het echte probleem. Iets heel anders dus.

Het is best interessant om te weten hoe exploits werken, en dan kijk je misschien anders tegen deze zaken aan.

[EXCalibur_EeK]

ben wel benieuwd hoe je dat doet.

Gebruik je RIS/SUS?

[Anoniem: 47200]

Dit zal inderdaad wel een grote voorsprong voor AMD op gaan leveren. Zeker voor de professionele markt, hier is namelijk het punt beveiliging veel belangrijker. Nu is het natuurlijk de vraag of Intel in zijn (volgens mij) gister aangekondigde 64-bit processor hetzelfde zal doen. Maar het is in ieder geval een tijdelijke voorsprong voor AMD.

Dit is echter alleen maar goed, laat die gasten van Intel maar eens flink zweten om lekker voor ons snellere CPU's te onwikkelen. Concurrentie is namelik alleen maar goed voor ons consumenten.

[Anoniem: 28043]

lezen, intel heeft al een proc op de profesionele markt met deze feature.

[Anoniem: 73850]

lezen, intel heeft al een proc op de profesionele markt met deze feature.

Alleen de Itanium inderdaad. De Xeon heeft dit dus blijkbaar niet ingebakken. Aangezien de Xeon (volgens mij) véél meer wordt gebruikt dan de Itanium in servers en dergelijke, is het dus zeker wel een nadeel voor Intel dat ze deze feature niet in hun CPU's hebben.

Maar zoals iedereen wel weet heeft Intel veel features in hun CPU's mee gebakken wat ze later aan kunnen schakelen. Zou dit niet ook het geval zijn met deze feature? (vraag me nml af waar die analisten dat op baseren, dat Intel het niet heeft mee gebakken)

[Olaf van der Spek]

Zou dit niet ook het geval zijn met deze feature?

Nee, want er is ook OS support nodig voor deze feature. Tenzij de feature wel gedocumenteerd is en MS er al support voor heeft, kan Intel deze dus niet even aanzetten.

[Anoniem: 99722]

dat zal intel vast wel leuk vinden dat amd een voorsprong krijgt

[Pietervs]

dat zal intel vast wel leuk vinden dat amd een voorsprong krijgt
Ik denk dat ze bij Intel nog niet hun handjes in de lucht gooien en beginnen te gillen als kleine meisjes.

Reden hiervoor is dat deze feature wordt aangezet in XP. De 64-bitters worden dan wel ingezet in professionele omgevingen, maar dan toch vooral in servers en zware werkstations.
Wat draait er op servers? Geen XP. Wat draait er op zware werkstations? Misschien wel XP, maar gezien de "zwaarte" van die werkstations zullen ze over het algemeen toch beter beheerd worden dan het gemiddelde werkstationnetje bij een klein bedrijf. Dus de patches tegen buffer overflows zullen wel geinstalleerd zijn, net zoals een goede virusscanner.

edit:

neemt niet weg dat ik het wel een goede stap vind, van zowel AMD als Microsoft!

[procyon]

De 64 Bits processor van AMD is ook bedoeld voor thuisgebruik, dus het gaat hier niet alleen om zware werkstations. (Athlon 64)
In het artikel wordt ook gezegd dat deze maatregel oa bescherming bied voor de Blaster en Code Red aanvallen.