image

No-Execute functie in nieuwe processoren stelt niet veel voor

vrijdag 29 juli 2005, 13:01 door Redactie, 7 reacties

De "no-execute" functie die in de nieuwste processoren aanwezig is en aanvallen van hackers moet afslaan, is niet het wondermiddel dat veel gebruikers denken dat het is. Via No eXecute, dat door Intel eXecute Disable en AMD Enhanced Virus Protection genoemd wordt, worden bepaalde gedeeltes van het geheugen afgeschermd, zodat instructies van de processor daar niet uitgevoerd kunnen worden. Hierdoor moet voorkomen worden dat wormen functies via het geheugen uitvoeren.

Zowel AMD als Intel geven toe dat de technologie de computer niet onkwetsbaar maakt, en dat malware nog steeds toe kan slaan. De technologie zorgt er echter voor dat de gevolgen beperkt blijven. De media hype rond No eXecute heeft er volgens onderzoeker David Maynor toe geleid dat de technologie als een wondermiddel wordt afgeschilderd dat toekomstige MS Blaster wormen kan voorkomen, terwijl dit niet zo is.

"NX stopt niet alle aanvallen die misbruik van een buffer overflow maken, de meest gebruikte manier om een systeem over te nemen. Ik kan nog steeds code op een machine met NX uitvoeren, het is alleen iets lastiger" zegt Maynor, die het eerder een snelheidsdrempel voor aanvallers vindt dan een echt stopteken.

Reacties (7)
29-07-2005, 13:21 door Anoniem
Hoe is het geheugenbeheer nu eigenlijk ?

Is het niet mogelijk om het geheugen te scheiden in een deel alleen voor
applicaties en een deel alleen voor data. Deze twee virtueel gescheiden
geheugen gebieden kunnen natuurlijk dynamisch groeien en krimpen en
uiteraard ten koste van elkaar. Swappen naar hdd moet natuurlijk ook
mogelijk blijven.

En dat de applicaties ook achter elkaar in het voor applicaties bestemde
geheugen liggen, zeg maar geen fragmentatie en als dit gebeurt dat het
OS de boel weer netjes archiveert. Ik denk wel dat op deze manier dat je
alleen nog maar software kan schrijven volgens het virtuele machine
principe.

Dan kun je een globaal code en data bit gebruiken, het nx bit zeg maar.
En vervolgens gebruik je voor iedere applicatie ook nog een keer eigen
afscherming en ook voor iedere data gedeelte per applicatie.


Gebeurt dit al ? Of moet de IA32 en IA64 architectuur op de helling ?

Is het niet mogelijk om de MMU tjes nog verder uit te breiden en dat het
hele concept van programma draaien herzien moet worden door gebruik te
maken van gespecialiseerde eenheden in de processor. Net zoiets als
CELL bedoeld is voor dsp berekeningen.
29-07-2005, 14:57 door Anoniem
newsflash: Er is geen wondermiddel
29-07-2005, 15:33 door Anoniem
Tuurlijk wel,
Alleen moeten we een andere architectuur gebruiken.
Oftewel hoe ver wil je gaan.
In de visie van de huidige generatie is dat niet mogelijk en dus klopt jou
antwoord vanuit dat perspectief.
29-07-2005, 15:38 door Anoniem
Door Anoniem
Hoe is het geheugenbeheer nu eigenlijk ?

Is het niet mogelijk om het geheugen te scheiden in een deel alleen voor
applicaties en een deel alleen voor data. Deze twee virtueel gescheiden
geheugen gebieden kunnen natuurlijk dynamisch groeien en krimpen en
uiteraard ten koste van elkaar. Swappen naar hdd moet natuurlijk ook
mogelijk blijven.

En dat de applicaties ook achter elkaar in het voor applicaties bestemde
geheugen liggen, zeg maar geen fragmentatie en als dit gebeurt dat het
OS de boel weer netjes archiveert. Ik denk wel dat op deze manier dat je
alleen nog maar software kan schrijven volgens het virtuele machine
principe.

Dan kun je een globaal code en data bit gebruiken, het nx bit zeg maar.
En vervolgens gebruik je voor iedere applicatie ook nog een keer eigen
afscherming en ook voor iedere data gedeelte per applicatie.


Gebeurt dit al ? Of moet de IA32 en IA64 architectuur op de helling ?

Is het niet mogelijk om de MMU tjes nog verder uit te breiden en dat het
hele concept van programma draaien herzien moet worden door gebruik te
maken van gespecialiseerde eenheden in de processor. Net zoiets als
CELL bedoeld is voor dsp berekeningen.


dsp berekeningen is niet helemaal een goede uitspraak sorry.

Ik bedoel meer gewoon dat je voor bepaalde berekeningen een
gespecialiseerde eenheid kunt gebruiken. voor booleaanse en simpele
rekenkundige acties een standaard alu. Voor Fp berekeningen je floating
point unit. Een mmu voor geheugen beheer. Is de mmu niet uit te breiden
met een extra functies ? Puur bedoeld voor afscherming. Ik denk dan wel
dat je alle opcodes moet herzien dus zal ia32 of ia64 nooit een oplossing
kunnen bieden.
29-07-2005, 19:12 door Anoniem
Door Anoniem
....
Ik bedoel meer gewoon dat je voor bepaalde berekeningen een
gespecialiseerde eenheid kunt gebruiken. voor booleaanse en
simpele
rekenkundige acties een standaard alu. Voor Fp berekeningen
je floating
point unit. Een mmu voor geheugen beheer. Is de mmu niet uit
te breiden
met een extra functies ? Puur bedoeld voor afscherming. Ik
denk dan wel
dat je alle opcodes moet herzien dus zal ia32 of ia64 nooit
een oplossing
kunnen bieden.
Ja, maar een mmu kan niet zien of een byte code of data is,
dat wordt dus aangegeven met het NX.
30-07-2005, 12:48 door Anoniem
Door Anoniem
Door Anoniem
....
Ik bedoel meer gewoon dat je voor bepaalde berekeningen een
gespecialiseerde eenheid kunt gebruiken. voor booleaanse en
simpele
rekenkundige acties een standaard alu. Voor Fp berekeningen
je floating
point unit. Een mmu voor geheugen beheer. Is de mmu niet uit
te breiden
met een extra functies ? Puur bedoeld voor afscherming. Ik
denk dan wel
dat je alle opcodes moet herzien dus zal ia32 of ia64 nooit
een oplossing
kunnen bieden.
Ja, maar een mmu kan niet zien of een byte code of data is,
dat wordt dus aangegeven met het NX.

Ik weet het niet hoor, als ik intern in de chip nu met 72 bits werk
(even niet aan ecc bits denken).
Dan heb ik 64 bit mogelijkheden en 8 bits om aan te geven wat
de 8 bytes aan data voorstellen, code of data of stack of tabel,
desnoods rauwe data als muziek of video dan weer algorithmes.
Ieder met eigen beperkingen en mogelijkheden.
Maar dan kom ik op mijn eigen
antwoord terug, dan moeten we af van de ia32 en ia64
architectuur en dat is helaas een utopie op korte termijn.
Het systeem zoals we nu hebben ondergaat een evolutie maar
moet altijd compatibel blijven. Je ziet bijvoorbeeld verwoedde
pogingen van intel om de legacy hardware te dumpen. Microsoft
doet steeds een kleine poging om hun besturingssysteem te
verbeteren en oude legacy problemen te verhelpen.
Toch had bijvoorbeeld lang terug al een hoop 16 bit problemen
kunnen verkomen door een virtual machine in het echte 32 bits
windows in te bouwen. Dan kun je veel meer controleren omdat
je gebruik maakt van emulatie. de hardware is al enkele jaren
snel genoeg. Op die manier kun je ook compatibiliteit in bouwen.
We moeten meer en meer naar virtual machines toe en dat kan
alleen als er een hele andere filosofie van programmeren
aangeleerd gaat worden.
01-08-2005, 08:22 door Anoniem
Het grootste probleem ligt volgens mij in het Object Oriented Programmng
model, waarbij bij het instantieren van een class met code en data deze
samen bij elkaar op de heap worden geplaatst. Compilers van software
zouden moeten worden aangepast dat de objecten van geinstantieerde
classes moeten splitsen in data en code blokken, waarbij de datablokken
worden voorzien van de NX bit.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.