Das NX Bit - AMDs Anti-Viren Feature im Detail
- Ersteller Nero24
- Erstellt am
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
<center><a href="http://www.planet3dnow.de/artikel/diverses/nx/"><img src="http://www.planet3dnow.de/artikel/diverses/nx/img/header.png" height="458" width="512" alt="Das NX Bit - AMDs Anti-Viren Feature im Detail" border="0"></a></center>
Momenten kreisen die Marketingabteilungen von AMD, Intel und Microsoft wie die Aasgeier um das NX-Bit (Transmeta kommt demnächst sicher auch dazu). Alle sagen das NX-Bit mache den Computer sicherer und würde vor Viren schützen, also höchste Zeit sich das mal etwas genauer anzusehen. Unser Forums-Guru mit Nickname "i_hasser" hat sich daher auf das Thema gestürzt.
Genauer werden wir uns auf das Wie und das Wieso stürzen - also wieso brauchen wir das NX-Bit und wie genau funktioniert es, und dabei wollen wir nicht nur ein bisschen an der Oberfläche kratzen. Wichtig sind in dem Zusammenhang auch Sicherheitslücken allgemein, also machen wir da keinen Bogen drumherum sondern fangen gleich damit an:<ul><li><a href="http://www.planet3dnow.de/artikel/diverses/nx/"><b>Das NX Bit - AMDs Anti-Viren Feature im Detail</b></a></li></ul>Viel Vergnügen beim Lesen...
Momenten kreisen die Marketingabteilungen von AMD, Intel und Microsoft wie die Aasgeier um das NX-Bit (Transmeta kommt demnächst sicher auch dazu). Alle sagen das NX-Bit mache den Computer sicherer und würde vor Viren schützen, also höchste Zeit sich das mal etwas genauer anzusehen. Unser Forums-Guru mit Nickname "i_hasser" hat sich daher auf das Thema gestürzt.
Genauer werden wir uns auf das Wie und das Wieso stürzen - also wieso brauchen wir das NX-Bit und wie genau funktioniert es, und dabei wollen wir nicht nur ein bisschen an der Oberfläche kratzen. Wichtig sind in dem Zusammenhang auch Sicherheitslücken allgemein, also machen wir da keinen Bogen drumherum sondern fangen gleich damit an:<ul><li><a href="http://www.planet3dnow.de/artikel/diverses/nx/"><b>Das NX Bit - AMDs Anti-Viren Feature im Detail</b></a></li></ul>Viel Vergnügen beim Lesen...
Ziemlich komplizierte Materie, aber recht gut erklärt, auch die Grafiken sind schön. Der Artikel ist sicher nicht nach dem Geschmack jedes P3D-Lesers, aber man muß ihn ja nicht lesen. Das ist genau wie mit den technischen Betrachtungen zu Grafikchips auf 3dcenter.de. Hebt auf jeden Fall das Niveau der Seite.
Übrigens, wie wäre es mit einer englischen Übersetzung (nur so eine Idee)?
Übrigens, wie wäre es mit einer englischen Übersetzung (nur so eine Idee)?
rkinet
Grand Admiral Special
Als (noch) Besitzer eines Atari ST mit Motorola 68000 CPU kann man die IA32-Möglichkeit am Stack zu manipulieren als Steinzeit-Technologie bezeichenen.
Beim 68000 - vorgestellt 1979 - hatte das Betriebssystem einen getrenntenn Stackpointer, den ein Virus nicht sehen konnte und auch nicht zielsicher den Stackinhalt verändern konnte.
Hier liegt ein schwerwiegender Designfehler bei IA32 vor.
Allerdings wäre der 'doppelte' Stackpinter (A7, A7') heute kein prefekter Schutz gegen alle Angriffe.
Das NX-Bit geht hier technisch genügend weit, um IA32 an dieser Stelle zu schützen. Außerdem ist das NX-Feature ein bewährtes Werkzeug aus der 64 Bit Welt, Zeit es in den Desktop zu integrieren.
Zum Artikel selbst - sehr gut !
Danke 
. Hab mir auch Mühe gegeben das verständlich zu machen 
.
Heute hat das Betriebssystem natürlich auch einen getrennten Stack, der Bug bringt auch nicht den Stack vom OS sondern den vom eigenen Programm durcheinander.
Was du meinst ist wohl ein Return Stack. In der CPU ist der inzwischen getrennt vom 'eigentlichen' Stack (also wenn wir ein Unterprogramm aufrufen speichert die CPU die Rückkehradresse nicht auf dem normalen Stack sondern in einem speziellen Bereich), nach außen hin (also für den Programmierer und den Virus) liegt die Rückkehradresse aber noch auf dem normalen Stack und wenn das Programm den eigenen Stack durcheinanderbringt muss die CPU der Kompatiblität wegen den Return Stack entsprechend verändern.
. Hab mir auch Mühe gegeben das verständlich zu machen . Heute hat das Betriebssystem natürlich auch einen getrennten Stack, der Bug bringt auch nicht den Stack vom OS sondern den vom eigenen Programm durcheinander.
Was du meinst ist wohl ein Return Stack. In der CPU ist der inzwischen getrennt vom 'eigentlichen' Stack (also wenn wir ein Unterprogramm aufrufen speichert die CPU die Rückkehradresse nicht auf dem normalen Stack sondern in einem speziellen Bereich), nach außen hin (also für den Programmierer und den Virus) liegt die Rückkehradresse aber noch auf dem normalen Stack und wenn das Programm den eigenen Stack durcheinanderbringt muss die CPU der Kompatiblität wegen den Return Stack entsprechend verändern.
Zuletzt bearbeitet:
rkinet
Grand Admiral Special
nein, der 68000 hat zwei unabhängige Stackpointer.
Wird eine Betriebssystemroutine aufgerufen wird A7' statt A7 (der Stackpointer) verwendet.
Ein normales Anwendungsprogramm hat keinen Zugriff auf A7' kann so nicht identifizieren, wo der Stackbereich des OS bzw. die gerade aktuelle Adresse liegt.
Bei IA32 wird per Software ein anderer Stackbereich definiert, Motorola arbeitete schon vor 25 Jahren in Hardware.
Aber Intel wollte IA32 ja nie groß einführen, war nur eine Notlösung weil eigentlich vorgesehene 'Itanium32' in den frühen 80er Jahren wegen Designmängeln eingestellt wurde.
Ähnlichkeiten mit späteren Ereignissen wären rein zufällig.
Nein, du hast das auch bei IA32 in Hardware realisiert.
Für jeden Task (entspricht jedem Programm) gibt es noch ein TSS, ein Task Segment (wofür das 2. S steht hab ich gerade vergessen).
Da steht für den Task drinnen welchen Wert die Register haben, unter anderem auch SS:SP (also der Stack, SS->Stack Segment, SP -> Stack Pointer also das Offset im Stack Segment (entspricht normalerweise dem Datensegment)).
Jedes Programm hat natürlich seinen eigenen Stack, und das wird per Harware realisiert.
Bei einem Task-Wechsel wird ja der Zustand (Registerwerte, Pagetable, etc.) für den entsprechenden Task wiederhergestellt, und dabei wird automatisch auch ein anderer Stack genutzt (die Werte werden beim Verlassen des Tasks alle im TSS gespeichert).
Das Problem von x86 (was du auch beim 68k haben dürftest) ist, dass lokale Variablen in Programmen über den Stack adressiert werden. Also wenn ein Programm 128 Bytes an lokalen Variablen braucht wird 128 vom SP abgezogen (der Stack wächst rückwärts, im Endeffekt wird der Stack also 128 Bytes größer) und dann wird per SP+[x] adressiert.
Dumm wird die Geschichte wenn man zB. ein lokales Array erzeugt. Also sagen wir
Code:
int a[10];Das ist ein Array mit 10 Elementen.
Die werden jetzt auch per SP+[x] adressiert. Das Array braucht 40 Byte (ein int ist 4 Byte groß, also brauchen 10 Ints 40 Byte).
Wenn der Progger nun sagen wir in der Art und Weise auf ein Array zugreift
Code:
int x;
int a[10];
// irgendwas für x berechnen
a[x]=3;wird die Adresse für a[x] der Form SP+0+x*4 berechnet (1 int -> 4 Byte, nach dem Array kommen keine lokalen Variablen mehr, daher +0 - x könnte per SP+40 adressiert werden). Wenn sich x im Bereich von 0 bis 9 bewegt ist alles ok - dumm wirds nur, wenn x größer wird. Bei a[10] könnte das zB. in einem Zugriff auf x selbst resultieren (wenn das nach a auf dem Stack liegt).
Bei a[11] könnte das in einem Zugriff auf die Rückkehradresse resultieren und da haben wir das Problem - die wird dann auf 3 gesetzt.
Nach der Funktion kehrt das Programm dann zur Adresse 3 zurück, was ziemlichen Müll ergeben sollte. Wenn der Hacker das gezielt manipulieren kann...
Das Problem kannst du nicht durch mehrere Stacks lösen, weil davon ja der Programmstack beeinflusst wird. An den Betriebssystemstack kommst du nur durch einen Fehler im Betriebssystem selbst ran.
Einzige Lösungsmöglichkeit davon wäre ein Return Stack. Also Rücksprungadressen etc. werden auf einem separaten Stack gespeichert. Das hat aber weder x86, noch (afaik) der 68k.
Zuletzt bearbeitet:
warper
Commodore Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 483
- Renomée
- 0
Interessanter Artikel, allerdings mit ein paar kleinen Fehlern:
weiss --> kommt von wissen, schreibt man mit zwei s
(wurde überall nur mit einem s geschrieben)
Seite 5, erster Absatz: ausgelößt, müsste eigentlich ausgelöst heissen.
Danke
weiss --> kommt von wissen, schreibt man mit zwei s
(wurde überall nur mit einem s geschrieben)
Seite 5, erster Absatz: ausgelößt, müsste eigentlich ausgelöst heissen.
Danke
Original geschrieben von warper
Interessanter Artikel, allerdings mit ein paar kleinen Fehlern:
weiss --> kommt von wissen, schreibt man mit zwei s
(wurde überall nur mit einem s geschrieben)
Seite 5, erster Absatz: ausgelößt, müsste eigentlich ausgelöst heissen.
Danke
Nach neuer Rechtschreibung 'weiß' (langer Vokal, kurzes aber scharfes s) und 'ausgelößt' weil das ö lang bzw. nicht kurz gesprochen wird.
Also das 2. (ausgelößt) ist richtig
.
warper
Commodore Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 483
- Renomée
- 0
Ja Sorry, in der Schweiz gibt es halt dieses Doppel-s nicht, wir schreiben die entsprechenden Worte halt immer mit ss
Aber ausgelöst kommt doch von auslösen. Da kann ich mir beim besten Willen nicht vorstellen, dass man das so schreibt.
Lösen schreibt man ja schliesslich auch nicht mit Doppel-s
Aber ausgelöst kommt doch von auslösen. Da kann ich mir beim besten Willen nicht vorstellen, dass man das so schreibt.
Lösen schreibt man ja schliesslich auch nicht mit Doppel-s
Original geschrieben von warper
Ja Sorry, in der Schweiz gibt es halt dieses Doppel-s nicht, wir schreiben die entsprechenden Worte halt immer mit ss
Aber ausgelöst kommt doch von auslösen. Da kann ich mir beim besten Willen nicht vorstellen, dass man das so schreibt.
Lösen schreibt man ja schliesslich auch nicht mit Doppel-s
Doch, die ß/ss Regelung ist eindeutig
. Bei ausgelö
Zum Glück muss ich das nicht können ![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
rkinet
Grand Admiral Special
Der 68k hat sowas tatsächlich nicht.
Nur, es gibt eben zwei unabhängige Stackpointer statt einem bei IA32 (vgl. http://www-md.e-technik.uni-rostock.de/lehre/tinf/80x86.pdf)
Bei IA32 nutzen die Viren aus, daß der Stack von Betriebssystemroutinen an gewissen Positionen oder wohl nach gewissen Codesequenzen zu finden ist.
Per Buffer Overflow wird der abnormal ausgeweitet und die Pseudo-Rücksprungadresse zum Virus wird von der CPU ausgeführt.
Bei 68k ist der OS-Stack getrennt vom User-Stack, wird aber von vielen OS-Routinen an unterschiedlicher Stelle genutzt.
Ein Virus muss erst einmal den Stack finden (es gibt im Hauptspeicher keine Kopie des A7') und wird dann mit wirrem Inhalt konfrontiert. Das einzige was geht, ist ein Totalabsturz beim 68K herbei zu führen, aber die Kontrolle über das OS erhält man so nicht.
Natürlich ist der 68k nicht mehr mehr für ein modernes OS so zu verwenden, aber die zwei Stackpointer sind ein wesentlich bessere Schutz, als es IA32 bieten kann.
Nein, IA32 Programme können definitiv nicht auf den Betriebssystemstack zugreifen!
Ich habs doch im Artikel so schön erklärt
Angenommen so sieht unser Stack aus:
Code:
####################
# RETURN Address 1 #
####################
# Lokale Daten 1 #
# #
####################
# RETURN Address 2 #
####################
# Lokale Daten 2 #
# #
####################Dann laufen gerade 2 Funktionen, und die eine hat die andere aufgerufen.
Endet die aktuelle Funktion wird die von unten gesehen nächste Return Adresse benutzt und dorthin gesprungen (RETURN Address 2).
Dumm ist nur, wenn Programmcode statt in den Lokalen Daten 2 die RETURN Addresse überschreibt.
Ein Buffer Overflow ist das desswegen, weil es nur eine Methode gibt wie man das erreichen kann - man greift entweder über das gültige obere Indiz eines Arrays hinaus darauf zu (Overflow) oder man benutzt ein negatives Indiz (Underflow).
Nochmal im Detail:
Code:
#######################
# RETURN Address 2 #
# Array a - Index 9 #
# Array a - Index 8 #
# Array a - Index 7 #
# Array a - Index 6 #
# Array a - Index 5 #
# Array a - Index 4 #
# Array a - Index 3 #
# Array a - Index 2 #
# Array a - Index 1 #
# Array a - Index 0 #
#######################Angenommen wir greifen auf das Indiz 10 zu (welches Real garnicht existiert) überschreiben wir damit die Return Address mit irgend einem Wert.
Beim Verlassen der Funktion wird dann die veränderte Return Address benutzt und wir landen im Nirvana.
Andersherum gibt es bei dem Index oft einen Überlauf, wenn wir zB. auf den 4 Milliardensten Index zugreifen macht das bei 4 Byte pro Element 16 GB... das passt nicht in 32 Bit, wesswegen wir immer im Bereich von 0 bis 4GB landen.
Nochmal: Bei x86 ist der OS Stack auch vom Programm Stack getrennt!
Sonst könnte ein Programm doch beliebig das OS beeinflussen, das geht aber auch mit Viren nicht. Wenn ein Virus per Buffer Overflow die Kontrolle über ein Programm übernimmt hat der auch nur die Rechte von diesem Programm, nicht mehr und nicht weniger.
Ich weis nicht wie ich dir das jetzt erklären soll ohne 1. alle anderen zu langweilen und 2. Multitasking beim x86er auseinanderzunehmen
. Das OS hat seinen eigenen Stack nur für sich. So ist es nunmal.Am einfachsten ließe sich die Rücksprungadresse so verändern:
Code:
CALL ABC
ABC:
POP AX
PUSH 123
RETDas RET würde vom Stack die 123 lesen und dahin springen. So müsste es aber der Programmierer gewollt haben, dass die Routine ins Nirvana springt.
So sieht ein TSS (hab nachgeguckt - Task State Segment) aus:
Das wird alles geladen wenn die CPU einen bestimmten Task ausführt und gespeichert wenn die CPU den Task verlässt (Multitasking ist großteils schon in der CPU implementiert).
Unter anderem benutzt eben auch jedes Programm ein anderen Stack, der per SS:SP adressiert wird (bzw. eben ESP).
PDBR ist die Adresse für die Page Table für den Task, entsprechend wird jeder Task auch mit einer eigenen Page Table ausgeführt (sonst würden sich die Programme ja untereinander sehen).
Das Betriebssystem müsste schon explizit wollen, dass ein Programm den OS Stack sieht. Und das will es sicher nicht weil das ein Sicherheitsrisiko hoch 20 wäre - eine gezielte Änderung und das komplette OS schmiert ab (wenn der Kernel einen Fehler verursacht ist Sense).
Ich hab dir jetzt 3mal gesagt, dass Programme nicht auf den OS Stack zugreifen können...
Code:
31 23 15 7 0
╔═══════════════Ï═══════════════╬═══════════════Ï═════════════╦═╗
║ I/O MAP BASE ║ 0 0 0 0 0 0 0 0 0 0 0 0 0 ║T║64
Ã───────────────┼───────────────Î───────────────┼─────────────ð─Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ LDT ║60
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ GS ║5C
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ FS ║58
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ DS ║54
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ SS ║50
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ CS ║4C
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ ES ║48
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║ EDI ║44
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ ESI ║40
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ EBP ║3C
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ ESP ║38
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ EBX ║34
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ EDX ║30
╠═══════════════Ï═══════════════Ï═══════════════Ï═══════════════╣
║ ECX ║2C
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ EAX ║28
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ EFLAGS ║24
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ INSTRUCTION POINTER (EIP) ║20
Ã───────────────┼───────────────┼───────────────┼───────────────Â
║ CR3 (PDPR) ║1C
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ SS2 ║18
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║ ESP2 ║14
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ SS1 ║10
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║ ESP1 ║0C
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ SS0 ║8
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║ ESP0 ║4
Ã───────────────┼───────────────Î───────────────┼───────────────Â
║0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0║ BACK LINK TO PREVIOUS TSS ║0
╚═══════════════Ï═══════════════╬═══════════════Ï═══════════════╝Das wird alles geladen wenn die CPU einen bestimmten Task ausführt und gespeichert wenn die CPU den Task verlässt (Multitasking ist großteils schon in der CPU implementiert).
Unter anderem benutzt eben auch jedes Programm ein anderen Stack, der per SS:SP adressiert wird (bzw. eben ESP).
PDBR ist die Adresse für die Page Table für den Task, entsprechend wird jeder Task auch mit einer eigenen Page Table ausgeführt (sonst würden sich die Programme ja untereinander sehen).
Das Betriebssystem müsste schon explizit wollen, dass ein Programm den OS Stack sieht. Und das will es sicher nicht weil das ein Sicherheitsrisiko hoch 20 wäre - eine gezielte Änderung und das komplette OS schmiert ab (wenn der Kernel einen Fehler verursacht ist Sense).
Ich hab dir jetzt 3mal gesagt, dass Programme nicht auf den OS Stack zugreifen können...
Zuletzt bearbeitet:
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
@intel_hasser & PuckPoltergeist:
Eure Diskussion, die eigentlich nicht mehr viel mit dem Artikel zu tun hat, hab ich hier her geschoben:
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=184791
Eure Diskussion, die eigentlich nicht mehr viel mit dem Artikel zu tun hat, hab ich hier her geschoben:
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=184791
@intel_hasser
In den Meldungen von 3dnowgalaxy vom Sonntag 10. Oktober ist`s verlinkt
http://www.3dnowgalaxy.de/nc.htm
MFG Bokill
In den Meldungen von 3dnowgalaxy vom Sonntag 10. Oktober ist`s verlinkt
http://www.3dnowgalaxy.de/nc.htm
MFG Bokill
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
Guckst Du auf http://www.hardocp.com/Original geschrieben von Bokill
@intel_hasser
In den Meldungen von 3dnowgalaxy vom Sonntag 10. Oktober ist`s verlinkt
http://www.3dnowgalaxy.de/nc.htm
MFG Bokill
Keine Sorge, wir haben schon unsere "Spamlisten"
mit anderen Hardwareseiten, die wir immer mit unseren neuen Artikel eindecken (genau wie die uns 
)
Wieso? *Grundvergessenhab*
Im Zuge der Internationalisierung (unter OpenSource Proggern läuft ja sowieso fast alles auf Englisch ab) werd ich den Artikel auch ins Englische übersetzen.
(Sofern die Redaktion damit einverstanden ist - PN genügt)
Im Zuge der Internationalisierung (unter OpenSource Proggern läuft ja sowieso fast alles auf Englisch ab
) werd ich den Artikel auch ins Englische übersetzen.(Sofern die Redaktion damit einverstanden ist
- PN genügt)rkinet
Grand Admiral Special
@intel_hasser, Danke für die ausführliche Information.
Aber zum Nachdenken:
Beim AtariST / GEM wurde der Stack für Rücksprungadressen und Parameter verwendet. Größere Felder wurden aber nicht per Stack übergeben, sondern nur die Adresse eines Speicherbereiches an das OS übergeben, die mit zu bearbeitenden daten gefüllt waren.
Der Aufruf des OS erfolgte erfolgte ähnlich zu IA32 durch einen Interrupt.
Der Interrupt schaltete dann auch das Adresregister um, sodaß das OS alleine zur Verfügun hatte.
Der 'alte' Stack' wurde nur ausgewertet und verändert, hatte aber für die Rücksprungadressen des OS keinerlei Auswirkung.
Ein Anwendungsprogramm konnte nur sich selbst 'abschießen' oder eben wahllos den Speicher mit Daten zumüllen.
Nur, irgendwelche Manipulationen waren nicht möglich, wobei das OS ja noch dazu im ROM fest verankert war.
Aber auch ein Apple Mac mit OS im RAM hatte ein recht gut abgeschirmtes OS.
Die Technologie, Daten auf den Stack zu legen, ist wohl IA32 typisch. Beim 68k standen ja 32 Bit Register (7 frei verfügbar) zur Adressierung beliebiger Speicherbereiche zur Verfügung und der Stack war nur für Rücksprungadressen und Parameter in Verwendung. Aber eine Manipulation des OS-Stacks war nicht möglich, da ein Anwenderprogramm nicht die gerade vom OS benutzte Rücksprungadresse in Erfahrung bringen konnte.
Detailwissen zum 68020/30/40 habe ich nicht mehr, aber hier dürften dann moderne Schutzmechanismen umgesetzt worden sein.
Das NX-Bit arbeitet viel besser wie das Schutzsystem des 68k, aber im Vergleich zum puren IA32 war das 68k Design schon fortschrittlicher ausgelegt.
Es ist nur erstaunlich, daß soviele Jahre ohne CPUs ohne wirkungsvollen Hardwareschutz verkauft wurden.
Erinnert an die 50/60er Jahre, als Autos ohne Sicherheitsgurt und Sicherheitszelle verkauft wurden.
Das ist aber jetzt in weiten Bereichen mit NX-Bit vorbei.
--------------------
NX-Bit / Celeron J in Japan im Laden
http://www.theinquirer.net/?article=18998
Intel stellt in den nächsten Monaten auch zügig weitere Produkte 'AMD-kompatibel' incl. Pentium-M um.
Aber Weihnachten 2004 dürfte schon deutlich im Zeichen vom NX-Bit / SP2 stehen
Aber zum Nachdenken:
Beim AtariST / GEM wurde der Stack für Rücksprungadressen und Parameter verwendet. Größere Felder wurden aber nicht per Stack übergeben, sondern nur die Adresse eines Speicherbereiches an das OS übergeben, die mit zu bearbeitenden daten gefüllt waren.
Der Aufruf des OS erfolgte erfolgte ähnlich zu IA32 durch einen Interrupt.
Der Interrupt schaltete dann auch das Adresregister um, sodaß das OS alleine zur Verfügun hatte.
Der 'alte' Stack' wurde nur ausgewertet und verändert, hatte aber für die Rücksprungadressen des OS keinerlei Auswirkung.
Ein Anwendungsprogramm konnte nur sich selbst 'abschießen' oder eben wahllos den Speicher mit Daten zumüllen.
Nur, irgendwelche Manipulationen waren nicht möglich, wobei das OS ja noch dazu im ROM fest verankert war.
Aber auch ein Apple Mac mit OS im RAM hatte ein recht gut abgeschirmtes OS.
Die Technologie, Daten auf den Stack zu legen, ist wohl IA32 typisch. Beim 68k standen ja 32 Bit Register (7 frei verfügbar) zur Adressierung beliebiger Speicherbereiche zur Verfügung und der Stack war nur für Rücksprungadressen und Parameter in Verwendung. Aber eine Manipulation des OS-Stacks war nicht möglich, da ein Anwenderprogramm nicht die gerade vom OS benutzte Rücksprungadresse in Erfahrung bringen konnte.
Detailwissen zum 68020/30/40 habe ich nicht mehr, aber hier dürften dann moderne Schutzmechanismen umgesetzt worden sein.
Das NX-Bit arbeitet viel besser wie das Schutzsystem des 68k, aber im Vergleich zum puren IA32 war das 68k Design schon fortschrittlicher ausgelegt.
Es ist nur erstaunlich, daß soviele Jahre ohne CPUs ohne wirkungsvollen Hardwareschutz verkauft wurden.
Erinnert an die 50/60er Jahre, als Autos ohne Sicherheitsgurt und Sicherheitszelle verkauft wurden.
Das ist aber jetzt in weiten Bereichen mit NX-Bit vorbei.
--------------------
NX-Bit / Celeron J in Japan im Laden
http://www.theinquirer.net/?article=18998
Intel stellt in den nächsten Monaten auch zügig weitere Produkte 'AMD-kompatibel' incl. Pentium-M um.
Aber Weihnachten 2004 dürfte schon deutlich im Zeichen vom NX-Bit / SP2 stehen
Zuletzt bearbeitet:
Ähnliche Themen
