Änderungen an der Funktionalität durch Microsoft Windows XP Service Pack 2

Es handelt sich bei diesem Dokument um Teil 3 von "Änderungen an der Funktionalität durch Microsoft Windows XP Service Pack 2". Dieser Teil enthält detaillierte Informationen zu den in Windows XP Service Pack 2 enthaltenen Speicherschutztechnologien.

Dieses Dokument gilt für Microsoft® Windows® XP Service Pack 2 (SP2) für die 32-Bit-Versionen von Windows XP Professional und Windows XP Home Edition. Es werden nicht alle im Service Pack enthaltenen Änderungen beschrieben. Vielmehr werden diejenigen Änderungen hervorgehoben, die sich am stärksten auf die Verwendung von Windows XP SP2 auswirken. Zudem werden Referenzen für möglicherweise verfügbare zusätzliche Informationen bereitgestellt.

Datenausführungsverhinderung

Wozu dient die Datenausführungsverhinderung?

Bei der Datenausführungsverhinderung (Data Execution Prevention, DEP) handelt es sich um einen Satz von Hardware- und Softwaretechnologien, durch die zusätzliche Speicherüberprüfungen ausgeführt werden und somit zum Schutz vor bösartigen Codeexploits beigetragen wird. In Windows XP SP2 wird die Datenausführungsverhinderung durch Hardware und Software erzwungen.

Durch Hardware erzwungene Datenausführungsverhinderung

Die durch Hardware erzwungene Datenausführungsverhinderung kennzeichnet in einem Prozess alle Speicherbereiche als nicht ausführbar, wenn der Bereich nicht explizit ausführbaren Code enthält. Bei bestimmten Angriffen wird versucht, Code aus nicht ausführbaren Speicherbereichen einzufügen und auszuführen. Die Datenausführungsverhinderung hilft beim Verhindern dieser Angriffe, indem sie abgefangen und eine Ausnahme ausgelöst wird.

Bei der durch Hardware erzwungene Datenausführungsverhinderung werden Speicherbereiche mit einem Attribut gekennzeichnet, das angibt, dass aus diesem Speicherbereich kein Code ausgeführt werden sollte. Die Datenausführungsverhinderung gilt pro virtuelle Speicherseite und ändert normalerweise ein Bit im Seitentabelleneintrag (Page Table Entry, PTE), um die Speicherseite zu kennzeichnen.

Die eigentliche Hardwareimplementierung der Datenausführungsverhinderung und die Kennzeichnung der virtuellen Speicherseite unterscheiden sich je nach Prozessorarchitektur. Prozessoren, die durch Hardware erzwungene Datenausführungsverhinderung unterstützen, können jedoch eine Ausnahme auslösen, wenn Code von einer mit dem entsprechenden Attributsatz gekennzeichneten Seite ausgeführt wird.

Sowohl Advanced Micro Devices™ (AMD) als auch die Intel® Corporation haben Windows-kompatible Architekturen definiert und ausgeliefert, die mit der Datenausführungsverhinderung kompatibel sind.

Ab Windows XP Service Pack 2 verwendet die 32-Bit-Version von Windows die von AMD definierte NX-Prozessorfunktion (No Execute) für den Seitenschutz oder die von Intel definierte Execute Disable Bit-Funktion. Um diese Prozessorfunktionen zu verwenden, muss der Prozessor im PAE-Modus (Physical Address Extension, Physikalische Adresserweiterung) ausgeführt werden. Die 64-Bit-Versionen von Windows XP verwenden die NX-Prozessorfunktion für 64-Bit-Erweiterungen und für bestimmte Werte des Feldes für die Zugriffsrechte für den Seitentabelleneintrag bei IPF-Prozessoren.

Wir hoffen, dass alle künftigen 32-Bit- und 64-Bit-Prozessoren Unterstützung für die durch Hardware erzwungene Datenausführungsverhinderung bereitstellen werden. Microsoft arbeitet weiterhin mit Prozessoranbietern zusammen, um die Übernahme und Entwicklung von DEP-Technologien zu fördern.

Durch Software erzwungene Datenausführungsverhinderung

In Windows XP SP2 wurde ein zusätzlicher Satz von Datenausführungsverhinderungs-Sicherheitsüberprüfungen hinzugefügt. Diese Überprüfungen werden als durch Software erzwungene Datenausführungsverhinderung bezeichnet und sollen die Ausnutzung von Ausnahmebehandlungsmechanismen in Windows mindern. Die durch Software erzwungene Datenausführungsverhinderung kann auf jedem Prozessor ausgeführt werden, der Windows XP SP2 ausführen kann. Standardmäßig schützt die durch Software erzwungene Datenausführungsverhinderung nur begrenzte Systembinärdateien, unabhängig von den durch Hardware erzwungenen DEP-Funktionen des Prozessors.

Für wen ist diese Funktion gedacht?

Anwendungs- und Treiberentwickler sollten die Datenausführungsverhinderung und die Anforderungen für auf einer unterstützenden Plattform ausgeführte Software kennen. Anwendungen, die Just-In-Time-Codegenerierung (JIT) oder Speicher aus dem Standardprozessstapel oder -heap ausführen, sollten die Anforderungen für die Datenausführungsverhinderung genau beachten.

Treiberentwickler sollten den PAE-Modus auf Plattformen kennen, auf denen durch Hardware erzwungene Datenausführungsverhinderung unterstützt wird. Der PAE-Modus auf Systemen unter Windows XP Service Pack 2 wurde geändert, um die Treiberkompatibilität zu verbessern.

Welche neue Funktionalität wurde in Windows XP Service Pack 2 für diese Funktion hinzugefügt?

Datenausführungsverhinderung in 32-Bit-Versionen von Windows und Anwendungen

Detaillierte Beschreibung

Durch Hardware erzwungene DatenausführungsverhinderungP

Bis auf wenige Unterschiede entspricht das allgemeine Verhalten der Datenausführungsverhinderung in Windows dem der 32-Bit- und 64-Bit-Versionen von Windows. Aus Gründen der Einheitlichkeit für Anwendungs- und Treiberentwickler wurde das Speicherschutzmodell (einschließlich der Datenausführungsverhinderung) für die 32-Bit- und 64-Bit-Versionen von Windows gleich konzipiert.

Anwendungsentwickler sollten das Verhalten der Datenausführungsverhinderung im Benutzermodus kennen. Eine DEP-Ausnahme im Benutzermodus führt auf Windows-Systemen zu STATUS_ACCESS_VIOLATION (0xc0000005). Der erste Parameter von ExceptionInformation in der Struktur von EXCEPTION_RECORD enthält den Typ der aufgetretenen Zugriffsverletzung. Der Wert 8 für ExceptionInformation[0] gibt an, dass eine Ausführungsverletzung aufgetreten ist.

In den meisten Prozessen ist die Ausnahme STATUS_ACCESS_VIOLATION eine nicht behandelte Ausnahme, die zur Beendigung des Prozesses führt.

Die Datenausführungsverhinderung wird auch auf Treiber im Kernelmodus angewendet. Die Datenausführungsverhinderung für Speicherbereiche im Kernelmodus kann nicht selektiv aktiviert oder deaktiviert werden. In 32-Bit-Versionen von Windows wird die Datenausführungsverhinderung standardmäßig auf den Stapel angewendet. Dies ist eine Abweichung gegenüber der Datenausführungsverhinderung im Kernelmodus in 64-Bit-Versionen von Windows, bei der die Datenausführungsverhinderung auf den Stapel, den ausgelagerten Pool und den Sitzungspool angewendet wird.

Gerätetreiber dürfen keinen Code aus dem Stapel ausführen, wenn die Datenausführungsverhinderung aktiviert ist. Eine DEP-Zugriffsverletzung im Kernelmodus führt zur Fehlerüberprüfung: 0xFC: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY.

Durch Software erzwungene Datenausführungsverhinderung

Die durch Software erzwungene Datenausführungsverhinderung führt zusätzliche Überprüfungen für Ausnahmebehandlungsmechanismen in Windows aus. Wenn die Abbilddateien des Programms mit SafeSEH (Safe Structured Exception Handling) erstellt wurden, stellt die durch Software erzwungene Datenausführungsverhinderung sicher, dass der Ausnahmehandler vor dem Erteilen einer Ausnahme in der Funktionstabelle in der Abbilddatei registriert wird.

Wenn die Abbilddateien des Programms nicht mit SafeSEH erstellt wurden, stellt die durch Software erzwungene Datenausführungsverhinderung vor dem Erteilen einer Ausnahme sicher, dass sich der Ausnahmehandler in einem als ausführbar gekennzeichneten Speicherbereich befindet.

Warum ist diese Änderung wichtig? Zur Minderung welcher Probleme trägt dies bei?

Der Hauptvorteil der Datenausführungsverhinderung besteht darin, dass sie zum Verhindern der Codeausführung über Datenseiten beiträgt, wie z. B. den Standardheap, verschiedene Stapel und Speicherpools. Im normalen Betrieb des Systems wird normalerweise kein Code aus dem Standardheap und -stapel ausgeführt. Die durch Hardware erzwungene Datenausführungsverhinderung erkennt von diesen Orten ausgeführten Code und löst bei der Ausführung eine Ausnahme aus. Wenn es sich um eine nicht behandelte Ausnahme handelt, wird der Prozess beendet. Die Ausführung von Code aus geschütztem Speicher im Kernelmodus führt zu einer Fehlerüberprüfung.

Obwohl das Beenden eines Prozesses oder das Verursachen eines Systemfehlers durch eine Fehlerüberprüfung nicht ideal scheint, trägt es dazu bei, die Ausführung von bösartigem Code zu verhindern. Das Verhindern der Ausführung von bösartigem Code auf dem System kann Schäden am System oder die Verbreitung von bösartigem Code verhindern, dessen schädliche Auswirkungen leicht die eines durch eine Fehlerüberprüfung beendeten Prozesses übersteigen können.

Die Datenausführungsverhinderung kann eine Reihe von Sicherheitsexploits mindern. Genauer gesagt kann die Datenausführungsverhinderung Exploits verhindern, bei denen ein Virus oder ein anderer Angriff zusätzlichen Code in einen Prozess einfügt und dann diesen eingefügten Code auszuführen versucht. Auf einem System mit Datenausführungsverhinderung würde die Ausführung des eingefügten Codes zu einer Ausnahme führen. Die durch Software erzwungene Datenausführungsverhinderung kann Exploits von Ausnahmebehandlungsmechanismen in Windows mindern.

Ein weiterer Vorteil der Datenausführungsverhinderung bezieht sich auf gute Entwicklung und bewährte Methoden für Anwendungs- und Treiberentwickler. Die Datenausführungsverhinderung zwingt Entwickler, das Ausführen von Code aus Datenseiten zu vermeiden, bei dem die Seiten nicht explizit als ausführbar gekennzeichnet sind.

Welche Funktionsweisen haben sich geändert?

Anwendungskompatibilität

Voraussichtlich wird das Verhalten mancher Anwendungen mit der Datenausführungsverhinderung inkompatibel sein. Bei Anwendungen, die dynamische Codegenerierung (z. B. Just-In-Time-Codegenerierung) ausführen und erstellten Code nicht explizit mit der Ausführungsberechtigung kennzeichnen, treten möglicherweise Kompatibilitätsprobleme mit der Datenausführungsverhinderung auf. Bei Anwendungen, die nicht mit SafeSEH erstellt wurden, müssen sich die Ausnahmehandler in ausführbaren Speicherbereichen befinden.

Anwendungen, die die Datenausführungsverhinderung verletzen, empfangen eine Ausnahme mit dem Statuscode STATUS_ACCESS_VIOLATION (0xC0000005). Wenn eine Anwendung ausführbaren Speicher erfordert, muss sie explizit dieses Attribut für den entsprechenden Speicher festlegen, indem sie PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE oder PAGE_EXECUTE_WRITECOPY im Speicherschutzargument der virtuellen* Arbeitsspeicherreservierungsfunktionen angibt. Heapzuweisungen, die die Funktionen malloc() und HeapAlloc() verwenden, sind nicht ausführbar.

Treiberkompatibilität

Bei Treiberkompatibilitätsproblemen mit der Datenausführungsverhinderung handelt es sich meist um durch den PAE-Modus verursachte Kompatibilitätsprobleme.

Hinweis   PAE ist nur auf Systemen mit Prozessoren erforderlich, die durch Hardware erzwungene Datenausführungsverhinderung unterstützen.

Die Datenausführungsverhinderung selbst kann Kompatibilitätsprobleme mit Treibern verursachen, die Codegenerierung ausführen oder mithilfe anderer Techniken ausführbaren Code in Echtzeit erstellen. Obwohl viele Treiber mit diesem Verhalten korrigiert wurden (da die Datenausführungsverhinderung für in 64-Bit-Versionen von Windows geladene Treiber immer aktiviert ist), gibt es keine Garantie, dass alle Treiber aktualisiert wurden. Diese Techniken werden jedoch von wenigen Treibern eingesetzt, und voraussichtlich wird durch die Datenausführungsverhinderung allein keine große Zahl von Treiberkompatibilitätsproblemen verursacht werden. 

Das Hauptaugenmerk bei der Treiberkompatibilität gilt dem Ausführen des PAE-Modus auf 32-Bit-Systemen. Der PAE-Modus ermöglicht Prozessoren das Adressieren von mehr als 4 GB an Speicher. Der Hauptunterschied zwischen der PAE-Speicherauslagerung und der Speicherauslagerung ohne PAE ist die zusätzliche Auslagerungsebene, die im PAE-Modus erforderlich ist (3 Ebenen anstelle von 2).

Manche Treiber werden bei Aktivierung des PAE-Modus möglicherweise nicht geladen, da unter Umständen das Gerät keine 64-Bit-Adressierung ausführen kann oder die Treiber annehmen, dass der PAE-Modus mehr als 4 GB RAM erfordert. Diese Treiber erwarten im PAE-Modus immer 64-Bit-Adressen und gehen davon aus, dass sie (oder das entsprechende Gerät) die Adresse nicht interpretieren können.

Andere Treiber werden möglicherweise im PAE-Modus geladen, verursachen jedoch eine Systeminstabilität, indem sie Seitentabelleneinträge des Systems direkt ändern. Diese Treiber erwarten 32-Bit-Seitentabelleneinträge, empfangen jedoch im PAE-Modus stattdessen 64-Bit-Seitentabelleneinträge.

Das größte Treiberkompatibilitätsproblem bei PAE betrifft DMA-Übertragungen (Direct Memory Access, Direkter Speicherzugriff) und die Zuordnung der Mapregister. Viele Geräte, die DMA unterstützen, normalerweise 32-Bit-Adapter, können keine physikalische 64-Bit-Adressierung ausführen. Bei Ausführung im 32-Bit-Modus kann das Gerät alle physikalischen Adressbereiche adressieren. Im PAE-Modus besteht die Möglichkeit, dass an einer physikalischen Adresse, die größer ist als 4 GB, Daten vorhanden sind. Damit Geräte mit diesen Einschränkungen in diesem Szenario funktionsfähig sind, bietet die Windows 2000 Server-Produktfamilie und höher Doppelpufferung für die DMA-Transaktion, indem sie eine durch ein Mapregister angegebene 32-Bit-Adresse bereitstellt. Das Gerät kann die DMA-Transaktion mit der 32-Bit-Adresse ausführen, und der Kernel kopiert den Speicher an die dem Treiber bereitgestellte 64-Bit-Adresse.

Wenn das System mit deaktiviertem PAE ausgeführt wird, ist es für Treiber für 32-Bit-Geräte nie erforderlich, die Mapregister durch echten Speicher zu unterstützen. Dies bedeutet, dass keine Doppelpufferung notwendig ist, da alle Geräte und Treiber im 32-Bit-Adressbereich enthalten sind. Aufgrund von Tests mit Treibern für 32-Bit-Geräte auf Computern mit 64-Bit-Prozessoren werden die meisten von Kunden getesteten DMA-fähigen Treiber unbegrenzte Mapregister erwarten.

Um Kompatibilitätsprobleme einzuschränken, enthält Windows XP Service Pack 2 Änderungen an der Hardwareabstraktionsschicht (Hardware Abstraction Layer, HAL), die das DMA-Verhalten von 32-Bit-Hardwareabstraktionsschichten nachahmen. Die geänderte Hardwareabstraktionsschicht gewährt unbegrenzte Mapregister, wenn das System im PAE-Modus ausgeführt wird. Außerdem ignoriert der Kernelspeicher-Manager alle physikalischen Adressen über 4 GB. Jedes System-RAM mit mehr als 4 GB könnte von Windows nicht adressiert werden und im System nicht verwendet werden. Durch das Begrenzen des Adressbereichs auf 4 GB sehen Geräte mit 32-Bit-DMA-Busmasterfunktionen Transaktionen mit einer Adresse oberhalb der 4-GB-Grenze nicht. Da diese Änderungen die Doppelpufferung der Transaktionen überflüssig machen, wird eine Reihe von Fehlern in manchen Treibern bei der richtigen Implementierung der Unterstützung für die Doppelpufferung vermieden.

Aufgrund dieser Änderungen an der Hardwareabstraktionsschicht und am Speicher-Manager werden minimale Auswirkungen auf die Gerätetreiberkompatibilität auf Systemen unter Windows XP Service Pack 2 mit aktivierter Datenausführungsverhinderung erwartet.

Systemkompatibilität

Ein letztes Problem mit der DEP-Kompatibilität geht von Systemen aus, auf denen der PAE-Modus aktiviert ist, obwohl sie nicht für mehr als 4 GB physikalisches RAM konzipiert sind. Microsoft hat bei Tests festgestellt, dass manche Systeme mit Prozessoren, die durch Hardware erzwungene Datenausführungsverhinderung unterstützen, nicht gestartet werden oder andere Stabilitätsprobleme aufweisen, wenn der Prozessor im PAE-Modus ausgeführt wird. 

Der PAE-Modus ist eine Voraussetzung für die Nutzung der NX-Prozessorfunktion. Daher sollten Systemdesigner und Firmwareentwickler wissen, dass das System möglicherweise im PAE-Modus ausgeführt wird, obwohl der Chipsatz und die Firmware des Systems nicht für die Unterstützung von mehr als 4 GB physikalischem RAM konzipiert sind.

Besonders relevant ist Systemfirmware, die Seitentabelleneinträge interpretiert, um vom Betriebssystem ausgeführte Anweisungen zu ermitteln. Seitentabelleneinträge werden auf eine Länge von 64 Bit erweitert, wenn der Prozessor im PAE-Modus ausgeführt wird. Systemdesigner und Firmwareentwickler sollten sich an die Prozessor- und Chipsatzanbieter wenden für weitere Informationen zum sicheren Ermitteln der vom Betriebssystem ausgeführten Anweisungen.

Systemdesigner, die mit AMD-Prozessoren arbeiten, finden weitere Informationen im "BIOS and Kernel Developer’s Guide for AMD Athlon™ 64 and AMD Opteron Processors". Dieses Whitepaper finden Sie auf der AMD Athlon™ 64-Website unter http://go.microsoft.com/fwlink/?LinkId=28165, indem Sie auf "BIOS and Kernel Developer’s Guide for AMD Athlon™ 64 and AMD Opteron Processors" klicken.

Intel veröffentlicht keine detaillierten Informationen zum System Management Mode (SMM). Systemdesigner, die mit Intel-Prozessoren arbeiten, sollten sich für weitere Informationen direkt an Intel wenden.

Weitere Informationen zur Windows-Unterstützung für den PAE-Modus finden Sie im Artikel zur physikalischen Adresserweiterung, zum PAE-Speicher und Windows auf der Microsoft-Website unter http://go.microsoft.com/fwlink/?LinkId=28166.

Wie werden diese Probleme behoben?

Anwendungen, die ausführbare Speicherbereiche erfordern, müssen beim Zuordnen von Speicher die Attribute PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE oder PAGE_EXECUTE_WRITECOPY verwenden. Außerdem können Anwendungen aus dem Standardprozessheap oder aus dem Stapel keine Aktionen ausführen. Die meisten Anwendungen, die mit der Datenausführungsverhinderung inkompatible Aktionen ausführen, müssen aktualisiert werden, damit sie kompatibel sind. Anwendungen müssen außerdem mit SafeSEH erstellt werden, oder es muss sichergestellt sein, dass sich ihre Ausnahmehandler in explizit als ausführbar gekennzeichnetem Speicher befinden.

Eine Anwendung kann die Anwendungsprogrammierschnittstelle (Application Programming Interface, API) VirtualAlloc() zum Zuordnen von ausführbarem Speicher mit den entsprechenden Speicherschutzoptionen verwenden. Es sollte mindestens die Speicherschutzoption PAGE_EXECUTE verwendet werden. Es wird empfohlen, dass die Anwendung nach dem Erstellen des ausführbaren Codes Speicherschutz festlegt, um den Schreibzugriff auf den zugeordneten Speicher nicht zuzulassen. Anwendungen können den Schreibzugriff auf zugeordneten Speicher mit der API VirtualProtect() nicht zulassen. Das Nichtzulassen des Schreibzugriffs stellt maximalen Schutz für ausführbare Bereiche des Prozessadressbereichs sicher.

Wenn ein bösartiger Prozess Code in einen ausführbaren Bereich einzufügen versucht, führt der Zugriff zur Schreibausnahme STATUS_ACCESS_VIOLATION. Die Anwendung sollte versuchen, die ausführbaren Bereiche ihres Adressbereichs so klein wie möglich zu halten. Dies würde die Angriffsfläche verkleinern, über die ausführbarer Speicher in den Prozessadressbereich eingefügt und ausgeführt werden könnte.

Außerdem können anspruchsvolle Anwendungen das Layout des virtuellen Speichers steuern und ausführbare Bereiche erstellen. Diese Anwendungen sollten versuchen, ausführbare Bereiche in einem niedrigeren Speicherbereich als in den nicht ausführbaren Bereichen zu suchen. Der Zweck des Suchens von ausführbaren Bereichen unterhalb nicht ausführbarer Bereiche besteht darin, einen Pufferüberlauf vor dem Überlaufen in den ausführbaren Speicher zu schützen.

Eine kleine Anzahl von ausführbaren Dateien und Bibliotheken enthält möglicherweise ausführbaren Code in einem Datenbereich der Abbilddatei. In manchen Fällen platzieren Anwendungen möglicherweise kleine Codesegmente (die häufig als Thunks bezeichnet werden) in den Datenabschnitten. Die Datenausführungsverhinderung kennzeichnet jedoch in den Speicher geladene Abschnitte der Abbilddatei als nicht ausführbar, wenn auf den Abschnitt nicht das Ausführbar-Attribut angewendet wurde.

Ausführbarer Code in Datenabschnitten sollte daher in einen Codeabschnitt migriert werden, oder der Datenabschnitt, der den ausführbaren Code enthält, sollte explizit als ausführbar gekennzeichnet werden. Das Ausführbar-Attribut, IMAGE_SCN_MEM_EXECUTE (0x20000000), sollte zum Feld Characteristics des entsprechenden Abschnittsheaders für ausführbaren Code enthaltende Abschnitte hinzugefügt werden.

Der mit Microsoft VisualStudio verteilte Microsoft-Linker kann das Ausführbar-Attribut mit der Linkeroption /SECTION zu einem Abschnitt hinzufügen. Die Linkeroption /SECTION hat das folgende Format:

/SECTION:Name,[E][R][W][S][D][K][L][P][X][,ALIGN=#]

Der Wert E gibt das Ausführbar-Attribut (0x20000000) an. Weitere Informationen zu /SECTION und zu anderen Microsoft-Linkeroptionen stehen auf der MSDN-Website unter http://go.microsoft.com/fwlink/?LinkId=28167 zur Verfügung.

Außerdem können mithilfe des Dienstprogramms Microsoft COFF Binary File Editor (Editbin.exe) die Abschnittsattribute eines vorhandenen Abbildes geändert werden. Das Dienstprogramm Editbin verfügt über die Option /SECTION mit folgendem Format:

/SECTION:Name[=newname][,[[!]{CDEIKOMPRSUW}][A{1248PTSX}]]

Die Werte E und C geben Code- bzw. Ausführbar-Attribute an. Weitere Informationen zum Dienstprogramm Editbin und zur Option /SECTION finden Sie auf der MSDN-Website unter http://go.microsoft.com/fwlink/?LinkId=28168.

Microsoft plant, Microsoft .NET Framework v1.0 und v1.1 zu aktualisieren, um die Datenausführungsverhinderung in Windows XP SP2 zu nutzen. Von Microsoft .NET Framework abhängige Anwendungen sind weiterhin normal funktionsfähig, profitieren jedoch nicht von der Datenausführungsverhinderung, falls diese aktiviert ist.

Microsoft ermutigt Anwendungsentwickler, die Microsoft .NET Framework weitervertreiben, auf Microsoft .NET Framework v1.0 Service Pack 3 oder v1.1 Service Pack 1 zu aktualisieren. Diese Versionen nutzen die Datenausführungsverhinderung, wenn sie zur Verfügung steht.

Welche Einstellungen wurden in Windows XP Service Pack 2 hinzugefügt oder geändert?

Systemweite Konfiguration der Datenausführungsverhinderung

Die Konfiguration der Datenausführungsverhinderung für das System wird über Optionen in Boot.ini gesteuert. Außerdem wurden Änderungen an System in der Systemsteuerung vorgenommen, damit Endbenutzer die Einstellungen für die Datenausführungsverhinderung leicht konfigurieren können, wenn sie als Administrator beim System angemeldet sind.

Windows unterstützt vier systemweite Konfigurationen für durch Hardware erzwungene und durch Software erzwungene Datenausführungsverhinderung.

Die durch Hardware erzwungene Datenausführungsverhinderung und die durch Software erzwungene Datenausführungsverhinderung werden auf die gleiche Weise konfiguriert. Wenn die systemweite Richtlinie für die Datenausführungsverhinderung auf Opt In festgelegt ist, sind die gleichen Windows-Kernbinärdateien und Anwendungen sowohl durch die durch Hardware erzwungene Datenausführungsverhinderung als auch durch die durch Software erzwungene Datenausführungsverhinderung geschützt. Wenn das System die durch Hardware erzwungene Datenausführungsverhinderung nicht verwenden kann, sind die Windows-Kernbinärdateien und Anwendungen nur durch die durch Software erzwungene Datenausführungsverhinderung geschützt.

Analog sind, wenn die systemweite Richtlinie für die Datenausführungsverhinderung auf Opt Out festgelegt ist, vom Schutz durch die Datenausführungsverhinderung ausgenommene Anwendungen sowohl von der durch Hardware erzwungenen Datenausführungsverhinderung als auch von der durch Software erzwungenen Datenausführungsverhinderung ausgenommen.

Die vier systemweiten Konfigurationen der Datenausführungsverhinderung werden durch Optionen in Boot.ini gesteuert. Folgende Einstellungen gelten für Boot.ini:

/noexecute=Richtlinienstufe

Dabei ist Richtlinienstufe definiert als AlwaysOn, AlwaysOff, OptIn oder OptOut.

Die Einstellung /noexecute in der Datei Boot.ini wird, sofern vorhanden, beim Installieren von Windows XP SP2 oder beim Verschieben eines Windows-Betriebssystemabbilds zwischen Computern mit und ohne Unterstützung für durch Hardware erzwungene Datenausführungsverhinderung nicht geändert.

Während der Installation von Windows XP SP2 ist die Richtlinienstufe OptIn standardmäßig aktiviert, wenn nicht in einer unbeaufsichtigten Installation eine andere Richtlinienstufe angegeben ist. Wenn die Einstellung /noexecute=Richtlinienstufe nicht im Starteintrag für eine Version von Windows mit Unterstützung für die Datenausführungsverhinderung vorhanden ist, entspricht das Verhalten dem Verhalten beim Einschluss der Option /noexecute=OptIn.

Als Administratoren angemeldete Endbenutzer können die Datenausführungsverhinderung zwischen den Richtlinien OptIn und OptOut manuell auf der Registerkarte Datenausführungsverhinderung im Dialogfeld Systemeigenschaften konfigurieren. Im folgenden Verfahren wird das manuelle Konfigurieren der Datenausführungsverhinderung auf dem Computer beschrieben.

IT-Experten können die systemweite Konfiguration der Datenausführungsverhinderung mit einer Reihe von Methoden steuern. Die Datei Boot.ini kann direkt mit Skriptmechanismen oder mit dem in Windows XP SP2 enthaltenen Tool Bootcfg.exe geändert werden.

Für unbeaufsichtigte Installationen von Windows XP SP2 können Sie mithilfe der Datei Unattend.txt eine bestimmte Konfiguration der Datenausführungsverhinderung im Vorhinein ausfüllen. Mit dem Eintrag OSLoadOptionsVar im Abschnitt [Data] der Datei Unattend.txt können Sie eine systemweite Konfiguration der Datenausführungsverhinderung angeben.

Konfiguration der Datenausführungsverhinderung auf Anwendungsbasis

Aus Gründen der Anwendungskompatibilität kann die Datenausführungsverhinderung, wenn sie auf die Richtlinienstufe OptOut festgelegt ist, für einzelne 32-Bit-Anwendungen selektiv deaktiviert werden.

Endbenutzer können auf der Registerkarte Datenausführungsverhinderung in Systemeigenschaften die Datenausführungsverhinderung selektiv für eine Anwendung deaktivieren.

Für IT-Experten ist in Windows XP Service Pack 2 eine neue Anwendungskompatibilitätskorrektur namens DisableNX enthalten. Die Anwendungskompatibilitätskorrektur DisableNX deaktiviert die Datenausführungsverhinderung für das Programm, auf das sie angewendet wird.

Die Anwendungskompatibilitätskorrektur DisableNX kann mithilfe des Application Compatibility Toolkit auf eine Anwendung angewendet werden. Weitere Informationen zur Windows-Anwendungskompatibilität finden Sie im Artikel zur Windows-Anwendungskompatibilität auf der Microsoft-Website unter http://go.microsoft.com/fwlink/?LinkId=23302.

Zum Seitenanfang

3 von 8