Das No Execution Features des Athlon 64

[reunion]

"Über die Neuerungen der AMD64-Prozessoren ist in den letzten Monaten vor und nach dem Launch viel berichtet worden; sei es nun Cool'N'Quiet, der integrierte Memory Controller oder auch die derzeit meist noch brachliegenden 64-Bit-Erweiterungen. Ein Feature, welches ursprünglich aus der 64-Bit-Welt stammt und mit dem SP2 für Windows XP auch in der 32-Bit-Welt Verwendung finden wird, wurde bislang allerdings kaum erwähnt. Die Rede ist vom No-Execution-Bit, kurz NX.
NX ist ein Sicherheitsfeature, welches an einem fundamentalen Problem von Programmen ansetzt. Ist ein Programm erst einmal geladen, kann man bei einem Blick in die verwendeten Arbeitsspeicherbereiche nicht mehr feststellen, ob es sich bei einem bestimmten Block nun um Programmcode oder zum Programmablauf gehörende Daten handelt. Diese Verwaltung wird einzig und allein dem Programm und dem Betriebssystem überlassen. Genau an dieser Stelle setzen etliche Würmer und Viren an, die derzeit im Internet kursieren und Buffer-Overflows ausnutzen.

Bei einem Buffer-Overflow wird Programmcode in einen Speicherbereich eines Programms geladen, welcher eigentlich für Daten reserviert ist. Durch einen Programmierfehler kann es nun vorkommen, dass ein Programm beim Lesen von Code aus dem Arbeitsspeicher nicht nach dem eigentlichen Codeblock aufhört, sondern auch darüber hinaus liest. Befinden sich nun echte Daten in folgenden Block, wird das Programm üblicherweise nur abstürzen. Befindet sich aber schädlicher Code im Datenblock, so wird dieser nach dem Programmcode eingelesen und wie dieser ausgeführt. Auf diese Art und Weise hat sich beispielsweise der Blaster-Wurm durch einen Fehler im RPC-Stack ganz von alleine weiterverbreitet, sobald man ohne Firewall ans Internet angeschlossen ist.
An genau dieser Stelle setzt nun das NX-Feature an. Es bietet die Möglichkeit, einen Speicherbereich durch Setzen des No-Execution-Bits ausnahmslos für Daten zu verwenden. Ein Wurm oder Virus kann sich weiterhin in den Datenbereich kopieren. Kommt es zum Buffer-Overflow, wird wie bisher Programmcode aus einem Datenbereich eingelesen. Dies wird nun allerdings vom Prozessor erkannt; dieser gibt eine Exception zurück. Darauf wird das Programm höchstwahrscheinlich abstürzen. Allerdings geschieht der Absturz, ohne dass vorher noch der schädliche Code ausgeführt werden konnte. Das System bleibt also vom Wurm oder Virus verschont.

Wie bereits erwähnt hat Microsoft eine Möglichkeit gefunden, dieses Feature, welches alle x86-64-Bit-Prozessoren (auch der Itanium) beherrschen, auch für den 32-Bit-Betrieb nutzbar zu machen. Beim Itanium ist dies aufgrund der recht gemächlichen 32-Bit-Ausführungsgeschwindigkeit eher uninteressant. Bei den AMD64-CPUs hingegen, welche derzeit ja sowieso meist noch mit 32-Bit-Software betrieben werden, ist dieses Feature hingegen sehr willkommen. Natürlich muss Software entsprechend programmiert werden, um NX-Bits setzen zu können. Mit dem SP2 für Windows XP will Microsoft alle Kernkomponenten neu kompilieren, so dass diese NX unterstützen. Da fast 100% aller derzeit verbreiteten Viren und Würmer Sicherheitslücken von Microsoft-Produkten ausnutzen, wird ihnen damit ein Riegel vorgeschoben."

http://www.k-hardware.de/artikel.php?s=&artikel_id=2574

mfg
reu

[zeckensack]

Wenn ich mich nicht sehr täusche, dann wird seit dem 286er den Speichersegmentdeskriptoren ein "access rights"-Feld beigelegt, das aus den drei Bits "read", "write" und "execute" besteht.

Irgendwie fehlt mir jetzt das neue, an dieser Neuheit :kratz2:

[CrazyIvan]

Klingt gut, bin gespannt wies bewerkstelligt wird und würde mich freuen, wenns denn funktioniert.

Das Problem bei nem Buffer Overflow ist doch eigentlich genau das, dass der Inhalt der Speicherzelle überschrieben wird. Da nützt doch auch ein vorher gesetztes Flag oder was auch immer nix. Oder sollte man das Ganze globaler sehen?
Bitte um Erklärung durch die Experdden ;D

[Benedikt]

Hört sich interessant an. Gibt's das jetzt unter WinXP SP2 nur beim A64 oder auch bei anderen IA32-Prozessoren?

MFG,
BW

[zeckensack]

Original geschrieben von Benedikt
Hört sich interessant an. Gibt's das jetzt unter WinXP SP2 nur beim A64 oder auch bei anderen IA32-Prozessoren?

MFG,
BW IMO gibt's das mit allen x86-Prozessoren, die in den letzten zehn Jahren hergestellt wurden. Man muss es eben nur nutzen, und das tut Microsoft augenscheinlich bisher nicht.

Nochmal zum Mitdenken:
Die virtuelle Speicherverwaltung wird vom Prozessor in Symbiose mit dem OS erledigt.

1)Paging:
Der Prozessor erzeugt eine Exception, sobald auf einen Speicherbereich zugegriffen wird, der nicht im physikalischen RAM liegt. Diese Exception unterbricht den gerade laufenden Prozess, und gibt die Kontrolle an einen Exception Handler weiter (OS-Komponente). Dieser EH sorgt nun dafür, dass der Speicherbereich von der Festplatte geladen, und im physikalischen RAM geparkt wird. Danach wird die Kontrolle an den Prozess zurückgegeben. Dieser merkt von der Exception rein garnichts, und kann nun die Speicheranfrage ausführen und weiterarbeiten.

2)Speicherschutz:
Jeder Prozess hat seinen privaten virtuellen Adressraum, und 'sieht' den Speicher indirekt über Segment-Deskriptoren (http://www.sandpile.org/ia32/sreg.htm). Diese Deskriptoren steuern die Umwandlung von virtuellen Adressen in physikalische Adressen. Beim Verlassen der hinterlegten Bereiche ("base" und "limit") wird wieder eine Exception erzeugt, die idR das Programm beendet (der beliebte "General protection fault - access violation", bzw auf deutsch "Allgemeiner Schutzfehler - Zugriffsverletzung").
Auf die Deskriptoren selbst kann nur im Kernel-Ring zugegriffen werden. Dadurch sind sie vor jeglichen Attacken durch User-Prozesse bombensicher geschützt.

Wie man hinter dem Link sehen kann, gibt's da auch das bereits erwähnte "access rights"-Feld, was eben für jedes Segment selektiv Lesezugriff, Schreibzugriff und Ausführung (als Code) erlaubt, oder eben verbietet. Wird gegen diese Regeln verstossen, gibt's wieder eine Exception.

Der langen Rede kurzer Sinn:
Die HW-Unterstützung für diesen 'neuen' Schutz gibt's schon seit Ewigkeiten. Sie muss nur vom OS genutzt werden.

[Demirug]

Zecki, es könnte sein das ich mich täusche aber ist das Problem beim Protected Mode nicht folgendes.

Man kann für die Segemente die Rechte ausführen, lesen, schreiben recht genau vergeben. Um allerdings ein Flaches Speichermodel zu bekommen ist es erforderlich das man 3 Segmente benutzt die alle auf die gleiche Pages verweisen. Dadurch kann man über das Stacksegemnt (welche ja Lesen und schreibrechte hat) den Wert in einer Page verändern. Das Codesegement hat auf die gleiche Page Ebenfalls zugriff und darf den Code in der Page zwar nicht ändern aber ausführen.

Das neue an den x86-64 CPUs von AMD scheint nun zu sein das man das Ausführungsrecht pro Page vergeben kann. Das witzige dabei ist das die Win32 API dieses Recht schon immer als Page Recht kennt man es aber bei den x86 CPUs automatisch mit den Leserecht zusammen bekommen hat. Der neue SP scheint dies nun für die neuen AMD CPUs zu ändern. Das könnte allerdings dazu führen das einige Applikationen nicht mehr laufen und deshalb kann man wohl festlegen welche Apps es nutzen sollen und welche nicht.

[Alertstatus Red]

So viel ich weiss, auch mit eine flache lineare arbeitsmodell gibt doch ein bereich des speicher der als PAGES Desckriptoren welche die zugriffe regelt, aber leider beim x86 CPU kann man nicht eine seite (page) nur als read-execute oder read-data stellen wie dagegen auf alfa CPU, sparc u.s.w. die möglich ist. Mann könnte dies auf segment-eben das tun, aber der verwaltung ist einer kompliziert als mit eine Flat memory modell. Also eine solche feature wie das NX bit ist sehr wilkommen, fragt sich man aber warum intel das versaumt hat mit eine schutz auf pages ebene zu implementieren .... :asshole:


cya :) :bäh: :D