32 Bit Prescott: Yamhill mit NX-Feature ?
- Ersteller rkinet
- Erstellt am
rkinet
Grand Admiral Special
http://download.microsoft.com/downl...-b64d-64e791b3c9ae/WinXPSP2_Documentation.doc einfach per 'NX' Dokument absuchen)
NX = Memory protection technologies
Auszug aus der Docu zu Windows XP SP2:
The 32-bit version of Windows currently leverages the “no-execute page protections” processor feature as defined by Advanced Micro Devices (AMD). This processor feature requires that the processor run in Physical Address Extension (PAE) mode .
Although the only processor families with Windows-compatible hardware support for execution protection that are currently shipping are the AMD K8 and the Intel Itanium processor families, it is expected that future 32-bit and 64-bit processors will provide execution protection. Microsoft is preparing for and encouraging this trend by supporting execution protection in its Windows operating systems.
Einen zukünftigen NX fähigen 32 Bit Prozessor von AMD erscheint unrealistisch. OK, der Paris basiert auf einem abgespeckten x64 Design, aber ob MS dafür den Aufwand betreibt.
Der zukünftige NX-fähige 32 Bit Proz. dürfte daher der Prescott sein (d.h. Gruppe P4, Xeon & Celeron), wobei 'nur' der PAE-Mode etwas aufgebohrt wird.
Der Itanium hat sowas ja schon.
Aufgebohrter PAE bedeutet aber gleichzeit auch Zugriff auf zusätzlichen Speicher jenseits der 4 GB-Grenze.
Das könnte dann das geheimnisvolle YAMHILL sein, 36-40 Bit PAE incl. NX (hat ja schon der Itanium).
NX = Memory protection technologies
Auszug aus der Docu zu Windows XP SP2:
The 32-bit version of Windows currently leverages the “no-execute page protections” processor feature as defined by Advanced Micro Devices (AMD). This processor feature requires that the processor run in Physical Address Extension (PAE) mode .
Although the only processor families with Windows-compatible hardware support for execution protection that are currently shipping are the AMD K8 and the Intel Itanium processor families, it is expected that future 32-bit and 64-bit processors will provide execution protection. Microsoft is preparing for and encouraging this trend by supporting execution protection in its Windows operating systems.
Einen zukünftigen NX fähigen 32 Bit Prozessor von AMD erscheint unrealistisch. OK, der Paris basiert auf einem abgespeckten x64 Design, aber ob MS dafür den Aufwand betreibt.
Der zukünftige NX-fähige 32 Bit Proz. dürfte daher der Prescott sein (d.h. Gruppe P4, Xeon & Celeron), wobei 'nur' der PAE-Mode etwas aufgebohrt wird.
Der Itanium hat sowas ja schon.
Aufgebohrter PAE bedeutet aber gleichzeit auch Zugriff auf zusätzlichen Speicher jenseits der 4 GB-Grenze.
Das könnte dann das geheimnisvolle YAMHILL sein, 36-40 Bit PAE incl. NX (hat ja schon der Itanium).
Nichtausführbare Segmente bietet sogar schon der 386er an - da stimmt wohl was mit der Beschreibung net. Oder bezieht sich das nur auf PAE (da weis ich net wie's läuft).
PAE ist recht uninteressant, da es sehr langsam ist.
Registered
Vice Admiral Special
- Mitglied seit
- 12.07.2002
- Beiträge
- 757
- Renomée
- 7
Ob es in Yamhill enthalten ist, weiß ich nicht. Es ist aber in der AMD64 Entwicklung enthalten und deshalb wird es wohl auch in Yamhill enthalten sein
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ich denke mal, es steht für No eXecute. Mein Auto trägt diese Abkürzung auch im Namen, obwohl es öfters ausgeführt wird *gg*.
Es ist gut, daß dieses Feature auf x86 Einzug hält - wo es schon soviele Features gibt. Wieder ein Feature-Flag mehr. Kritisch wird es, wenn ein Feature-Flag "x86 compatible" auftaucht.
Gruß,
DB
rkinet
Grand Admiral Special
Original geschrieben von Dresdenboy
Ich denke mal, es steht für No eXecute.
Es ist gut, daß dieses Feature auf x86 Einzug hält - wo es schon soviele Features gibt. Wieder ein Feature-Flag mehr. Kritisch wird es, wenn ein Feature-Flag "x86 compatible" auftaucht.
Gruß,
DB
NX, richtig No execution Bereiche im Speicher. Der Stack wird damit ab SP2 von MS gegen ausführbaren Code gesichert. Der MSBlaster (O-Ton MS) hätte so keine Chance beim Athlon 64 gehabt.
MS führt namentlich den Itanium und den Athlon 64 auf, sowie ein Hinweis auf zukünftige 32/64 Produkte.
Im 32 Bit-Windows wird NX in der 'Lite Version' für den Stack genutzt, im 64-Bit Modes ist alles nochmals ausgefeilter. Auch sind unter 32 Bit weiterhin nur 4 GB Adressraum von Windows direkt nutzbar, trotz PAE.
Beim Prescott, hab dies schon einmal spekuliert, könnte ein OS-Kern-Task 36-40 Bit PAE nutzen, während 'normale' Programme und weite Bereiche des Windows OS im 32 Bit-Raum bleiben. Hat übrigens Ähnlichkeit mit dem Lonhorn-Konzept.
Da Intel NX bereits beim Itanium nutzt und Sicherheit ein topaktuelles Thema ist, wäre ein Verzicht bei Intel eigentlich nicht nachvollziehbar. Gesteuert wird das Feature im PAE-Modus, so die MS-Docu.
@rkinet
Die Mutanten und Freaks hast du schon erfolgreich angelockt, das ist gut so!
Das Thema Sicherheit/Infrastruktur und Privatheit habe ich mit einem anderem Aspekt auch schon angesprochen
Katalysator für TCPA: Würmer und Stromausfall
Ein anderer Aspekt wurde hier im Forum ebenso angesprochen.
Opteron/Athlon64 und TCPA
und
3DCenter hat da eine eigene Sparte
TCPA/TCG & Palladium
Wo ist deine Message? Was ist das wirklich bemerkenswerte daran (Der Yamhill ist doch nur ein netter Aufhänger, gell? )
1. Die Plattformübergreifende Kooperation?
2. Der Schleichende Übergang?
3. Der Einfluss von MS?
4. Ziehen alle am gleiche Strang?
5. Haben wir eine Chance gegen die heimliche unheimliche Allianz zu bestehen?
6. Ist Linux wirklich der Ausweg?
7. Sehen wir zu schwarz?
8. Ist Datenschutz eine veraltetes Thema von Ökofundamentalisten?
9. Was für andere Möglichkeiten bestehen denn noch Computersysteme Wasserdicht zu bekommen?
10. Ist Computersicherheit eine Illusion?
11. Warum ist die Welt rund?
12. Was schreibe ich denn hier?
MFG Bokill
Die Mutanten und Freaks hast du schon erfolgreich angelockt, das ist gut so!
Das Thema Sicherheit/Infrastruktur und Privatheit habe ich mit einem anderem Aspekt auch schon angesprochen
Katalysator für TCPA: Würmer und Stromausfall
Ein anderer Aspekt wurde hier im Forum ebenso angesprochen.
Opteron/Athlon64 und TCPA
und
3DCenter hat da eine eigene Sparte
TCPA/TCG & Palladium
Wo ist deine Message? Was ist das wirklich bemerkenswerte daran (Der Yamhill ist doch nur ein netter Aufhänger, gell? )
1. Die Plattformübergreifende Kooperation?
2. Der Schleichende Übergang?
3. Der Einfluss von MS?
4. Ziehen alle am gleiche Strang?
5. Haben wir eine Chance gegen die heimliche unheimliche Allianz zu bestehen?
6. Ist Linux wirklich der Ausweg?
7. Sehen wir zu schwarz?
8. Ist Datenschutz eine veraltetes Thema von Ökofundamentalisten?
9. Was für andere Möglichkeiten bestehen denn noch Computersysteme Wasserdicht zu bekommen?
10. Ist Computersicherheit eine Illusion?
11. Warum ist die Welt rund?
12. Was schreibe ich denn hier?
MFG Bokill
Zuletzt bearbeitet:
rkinet
Grand Admiral Special
Mal auf dem Teppich bleiben.
Theorie und Praxis:
- Ein Großteil der Sicherheitsprobleme entstehen nicht weil geniale Programmierer das letzte Schlupfloch eines OS ausnutzen, sondern weil 'olle Kammellen' an beknnten OS-Lücken aus Bequemlichkeit, auch im Profiumfeld, monatelang nicht geschlossen werden (s. Blaster).
- TCPA/TCG & Palladium haben natürlich im Prinzip mit dem NX-Feature zu tun, sind aber doch weitaus umfangreicher. Übrigens zeigen die Anmerkungen von MS zu NX, daß noch viel vorhandene Software erst einmal auf ein Niveau gehoben werden muß, bis TCPA/TCG & Palladium überhaupt technisch einsetzbar wäre
Zu Yamhill:
Hierbei geht es um eine elemtare Angelegenheit für AMD. Baut Intel eine inkompatible 64 Bit EW in seine nächsten CPU's, hätte AMD große Probleme.
Baut Intel 'nur' NX ein, wird in großem Umfang alle Software entsprechend angepaßt. Damit wird aber (unbeabsichtigt ?) bereits das Fundament gelegt, daß diese problemlos mit einem OS mit erweitertem Adressbereich (s. MS Docu) funktioniert.
Arbeiten Firmen wg. NX an ihrer Software, bietet es sich an auch gleich die x86-64 Variante mit zu compilieren.
Daher ermöglicht dieses Feature indirekt einen Boost für AMD64.
Theorie und Praxis:
- Ein Großteil der Sicherheitsprobleme entstehen nicht weil geniale Programmierer das letzte Schlupfloch eines OS ausnutzen, sondern weil 'olle Kammellen' an beknnten OS-Lücken aus Bequemlichkeit, auch im Profiumfeld, monatelang nicht geschlossen werden (s. Blaster).
- TCPA/TCG & Palladium haben natürlich im Prinzip mit dem NX-Feature zu tun, sind aber doch weitaus umfangreicher. Übrigens zeigen die Anmerkungen von MS zu NX, daß noch viel vorhandene Software erst einmal auf ein Niveau gehoben werden muß, bis TCPA/TCG & Palladium überhaupt technisch einsetzbar wäre
Zu Yamhill:
Hierbei geht es um eine elemtare Angelegenheit für AMD. Baut Intel eine inkompatible 64 Bit EW in seine nächsten CPU's, hätte AMD große Probleme.
Baut Intel 'nur' NX ein, wird in großem Umfang alle Software entsprechend angepaßt. Damit wird aber (unbeabsichtigt ?) bereits das Fundament gelegt, daß diese problemlos mit einem OS mit erweitertem Adressbereich (s. MS Docu) funktioniert.
Arbeiten Firmen wg. NX an ihrer Software, bietet es sich an auch gleich die x86-64 Variante mit zu compilieren.
Daher ermöglicht dieses Feature indirekt einen Boost für AMD64.
rkinet
Grand Admiral Special
AMD, Intel put antivirus tech into chips
http://marketwatch-cnet.com.com/2100-7355_3-5137832.html?type=pt&part=marketwatch-cnet&tag=feed&subj=news
Zitat:
A number of damaging worms from last year relied on buffer overflows .
Around 50 percent of the Windows security updates from Microsoft in the last two years may have been rendered unnecessary if the technology existed then, according to an analysis by AMD and Microsoft.
Nachtrag:
Ob 32 Bit bei Prescott oder doch x86-64 (http://www.theregister.co.uk/content/28/34777.html Dell 'suspects' Yamhill is on the way ) wird wohl in den nächsten Wochen offengelegt
http://marketwatch-cnet.com.com/2100-7355_3-5137832.html?type=pt&part=marketwatch-cnet&tag=feed&subj=news
Zitat:
A number of damaging worms from last year relied on buffer overflows .
Around 50 percent of the Windows security updates from Microsoft in the last two years may have been rendered unnecessary if the technology existed then, according to an analysis by AMD and Microsoft.
Nachtrag:
Ob 32 Bit bei Prescott oder doch x86-64 (http://www.theregister.co.uk/content/28/34777.html Dell 'suspects' Yamhill is on the way ) wird wohl in den nächsten Wochen offengelegt
rkinet
Grand Admiral Special
PuckPoltergeist
Grand Admiral Special
Aber nur in Verbindung mit der Speichersegmentierung (welche ja auch deutlich mehr als 4GB Speicher zulassen würde). Diese wird aber weder von Windows noch von Linux genutzt (naja doch irgendwo schon, aber nur im absolut notwendigen Maß). Ergo ist dieses Feature für heutige Betriebssysteme auch nicht nutzbar.
Also soweit ich das sehe bekommt ein Programm 2 Segmente, ein Codesegment und ein Datensegment.
Die beiden Segmente liegen aufeinander, so hat das Programm 4gb auf die es zugreifen kann wie es ihm Spaß macht.
Wenn man nun einfach die Segmente nicht übereinander legen würde, sondern so, dass die sich nicht überlappen hätte das Programm ein Codesegment (CS), wo der statische Code drinnen ist - hier kann nix geändert werden.
Dann gäbe es noch ein Datensegment (DS), wo das Programm alle Daten hinschreiben kann. Und zu guter letzt könnte man ein extra Stack Segment machen (SS), wo sich nur der Stack befindet.
Dank Klassen usw. brauchen wir aber ein Code segment mit Schreibzugriff, es würde aber schon reichen wenn wir alles so lassen wie es momentan ist (CS und DS zeigen auf verschiedene Segmente, aber adressieren den selben Speicherbereich (einmal Readonly und Auführbar, einmal Readwrite und nicht ausführbar)) aber noch ein extra Stack Segment reinsetzen.
Ein Programm müsste sich dann nicht mit Segmenten rumschlagen (CS, DS und SS ändern sich niemals) aber wir hätten trotzdem einen abgekoppelten Stack. Und wenn die 4gb Stack vollgeschrieben sind gibts ne Exception und das wars. Aber der Programmcode oder die Programmdaten werden nicht überschrieben.
Die beiden Segmente liegen aufeinander, so hat das Programm 4gb auf die es zugreifen kann wie es ihm Spaß macht.
Wenn man nun einfach die Segmente nicht übereinander legen würde, sondern so, dass die sich nicht überlappen hätte das Programm ein Codesegment (CS), wo der statische Code drinnen ist - hier kann nix geändert werden.
Dann gäbe es noch ein Datensegment (DS), wo das Programm alle Daten hinschreiben kann. Und zu guter letzt könnte man ein extra Stack Segment machen (SS), wo sich nur der Stack befindet.
Dank Klassen usw. brauchen wir aber ein Code segment mit Schreibzugriff, es würde aber schon reichen wenn wir alles so lassen wie es momentan ist (CS und DS zeigen auf verschiedene Segmente, aber adressieren den selben Speicherbereich (einmal Readonly und Auführbar, einmal Readwrite und nicht ausführbar)) aber noch ein extra Stack Segment reinsetzen.
Ein Programm müsste sich dann nicht mit Segmenten rumschlagen (CS, DS und SS ändern sich niemals) aber wir hätten trotzdem einen abgekoppelten Stack. Und wenn die 4gb Stack vollgeschrieben sind gibts ne Exception und das wars. Aber der Programmcode oder die Programmdaten werden nicht überschrieben.
So sicher ist dies noch nicht, dass der Prescott AMD64 versteht... solange Intel keine offizielle Mitteilung macht, bleiben dies nur Gerüchte und Spekulationen.
Strategische Überlegungen64Bit; IBM SUN AMD Intel jedoch gewisse Überlegungen sind da schon bestechend
XBit- Labs hatte da mal eine sehr geniale Analyse/Spekulation (Ist in dem Thread oben drin) .
Die Andeutungen von Dell sind da immer noch deutlich wage und luftig.
MFG Bokill
Strategische Überlegungen64Bit; IBM SUN AMD Intel jedoch gewisse Überlegungen sind da schon bestechend
XBit- Labs hatte da mal eine sehr geniale Analyse/Spekulation (Ist in dem Thread oben drin) .
Die Andeutungen von Dell sind da immer noch deutlich wage und luftig.
MFG Bokill
rkinet
Grand Admiral Special
Ist natürlich Spekulation.
Aber 'marketwatch-cnet' muß irgendwoher Informationen haben, um Intel & Prescott zu verknüpfen. SSE3 hat definitiv nichts damit zu tun, die heutige IA32 Architektur ebenso nicht,
Ein 'nur NX'-Feature hätte Intel längst veröffentlicht und marketingtechnisch ausgeschlacht. Und in seine Compiler eingebaut.
Bem:
Habe den technischen Hintergrund für das Verfahren nicht ganz durchschaut, speziell weshalb heutige IA32-Möglichkeiten nicht ausreichen.
Da MS aber ausdrücklich von Itanium & AMD64 spricht ist hier wohl ein typisches 64 Bit (ursrünglich IA64?) -Feature von AMD in x86-64 mit eingearbeitet worden, sodaß dies auch für 32 Bit-OS und Anwendungen nutzbar wird.
Wieder wohl aber ein Zeichen, daß AMD viel Hirnschmalz in x86-64 gesteckt hat, um ein einfaches, aber doch auch trickreiches Aufbrechen der IA32 zu ermöglichen. Und auch Schwächen des Konzeptes auszubügeln.
Nachtrag:
Intel-Ingenieur haben mit ja schon seit Jahren im Rahmen der Patentwiedergabe von x86-64 detailierte Einblicke in dessen Möglichkeiten. Als 'Compilerbauer' und 'Code-Analytiker' kennen die natürlich auch genau, wie und wo x86-64 Programme beschleunigt.
Wo hier noch spekuliert wird, hat Intel mit Sicherheit schon genaue Aufstellungen, was ein (x86-64 ) 64 Bit DivX, DirextX, Win64 oder 64 Bit Treiber für Grafikkarten mal bringen wird. Die müssen nicht täglich abwarten, was die realen Benchmarks der Öffentlichkeit aufzeigen. Nachdem der Opteron/A64 nicht floppte, dürften bei Intel die Alarmglocken schon seit Monaten läuten lassen. Die einzige Frage ist, wie die Geschäftsleitung Intel auf dieses Vorwissen reagiert hat.
Aber 'marketwatch-cnet' muß irgendwoher Informationen haben, um Intel & Prescott zu verknüpfen. SSE3 hat definitiv nichts damit zu tun, die heutige IA32 Architektur ebenso nicht,
Ein 'nur NX'-Feature hätte Intel längst veröffentlicht und marketingtechnisch ausgeschlacht. Und in seine Compiler eingebaut.
Bem:
Habe den technischen Hintergrund für das Verfahren nicht ganz durchschaut, speziell weshalb heutige IA32-Möglichkeiten nicht ausreichen.
Da MS aber ausdrücklich von Itanium & AMD64 spricht ist hier wohl ein typisches 64 Bit (ursrünglich IA64?) -Feature von AMD in x86-64 mit eingearbeitet worden, sodaß dies auch für 32 Bit-OS und Anwendungen nutzbar wird.
Wieder wohl aber ein Zeichen, daß AMD viel Hirnschmalz in x86-64 gesteckt hat, um ein einfaches, aber doch auch trickreiches Aufbrechen der IA32 zu ermöglichen. Und auch Schwächen des Konzeptes auszubügeln.
Nachtrag:
Intel-Ingenieur haben mit ja schon seit Jahren im Rahmen der Patentwiedergabe von x86-64 detailierte Einblicke in dessen Möglichkeiten. Als 'Compilerbauer' und 'Code-Analytiker' kennen die natürlich auch genau, wie und wo x86-64 Programme beschleunigt.
Wo hier noch spekuliert wird, hat Intel mit Sicherheit schon genaue Aufstellungen, was ein (x86-64 ) 64 Bit DivX, DirextX, Win64 oder 64 Bit Treiber für Grafikkarten mal bringen wird. Die müssen nicht täglich abwarten, was die realen Benchmarks der Öffentlichkeit aufzeigen. Nachdem der Opteron/A64 nicht floppte, dürften bei Intel die Alarmglocken schon seit Monaten läuten lassen. Die einzige Frage ist, wie die Geschäftsleitung Intel auf dieses Vorwissen reagiert hat.
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
@rkinet
> Ein 'nur NX'-Feature hätte Intel längst veröffentlicht und marketingtechnisch ausgeschlacht. Und in seine Compiler eingebaut.
NX benötigt keine Compilerunterstüzung.
> Habe den technischen Hintergrund für das Verfahren nicht ganz durchschaut,
Der Hintergrund des der Buffer-Overflow Exploits liegt daran, dass Speicherbereiche die eigenlich nur Daten enthalten (Stack, Heap) dazu misbraucht werden um Ausfürbaren Code dort abzulegen und auszufürhen.
Die technischen Möglichkeiten von IA 32 würden für eine saubere Trennung von Code und Daten ausreichen, wenn das Betriebssystem korrekt von Segmentierung gebrauch machen würde. Das tut aber weder Linux noch NT. Grund: Beide Betriebssysteme legen ein flaches Speichermodell zu Grunde -- das ist für OS und Anwendungen viel leichter handhabbar. Ein flaches Speichermodell heist in dem Fall das die Segmentregister auf den gleichen Speicherbereich zeigen (bzw gleich Null enthalten). IMO ist der Segment-Quatsch einer der schlimmsten x86 Designfehler.
So nun zum Problem: Beim klassischen IA32 Paging können Speicherseiten als Lesbar und oder Schreibbar markiert werden. Wenn eine Seite lesbar ist darf die CPU auch Code der sich dort befindet ausführen. D.h es gibt keine Unterscheidung zwischen "lesbaren Daten" und "ausführbarem Code".
Das NX-Feature rüstet nur diese Unterscheidbarkeit nach indem (phsikalische) Speicherseiten, welche Daten enthalten, als "Not executable" gekennzeichnet werden. Wenn die CPU auf eine Speicherseite zugreift um davon Daten in den L1-Instruction Cache zu lesen wird das entsprechende NX-Bit in der Übersetzungstabelle überprüft. Ist NX gesetzt gibt es eine Access Violation Exception, anderfals werden die Daten (wie bisher) in den L1-I Cache übertragen. Von dort aus gelangen die Daten als Instructions in den Execution-Core.
Da die NX Bits in den Memory-Translation-Tabellen stehen ist es ausschlieslich Aufgabe des OS zu entscheiden für welche Speicherbereiche das NX Bit gesetzt wird.
> speziell weshalb heutige IA32-Möglichkeiten nicht ausreichen.
Das liegt einfach daran, das es keine Redundanzen (=Freie Bits) in den Datenstrukturen gibt die man für normales IA32 Paging braucht. D.h. Es bleibt keine Stelle übrig in der man das NX Bit speichern könnte. Bei PAE-Paging gibt es diese Möglichkeit.
BTW. So eine Technologie ist bei weitem nichts neues. Einige RISC CPUs kennen sowas schon lange, dort heist das ganze dann EOR (Execute OR Read). D.h eine Speicherseite kann entweder Code enthalten und executable sein oder Daten die lesbar sind.
> Da MS aber ausdrücklich von Itanium & AMD64 spricht ist hier wohl ein typisches 64 Bit (ursrünglich IA64?) -Feature von AMD in x86-64 mit eingearbeitet worden, sodaß dies auch für 32 Bit-OS und Anwendungen nutzbar wird.
IA64 und AMD64 nutzt im Long Mode immer PAE-Paging. Darum bietet es sich an dieses Feature in PAE-Paging Mode zu integrieren anstelle eines gänzlich neuen Paging-Modes.
NX hat nichts mit 32/64 Bit zu tun, sondern alleine mit der Virtual Memory Implementierung der CPU (=>PAE-Paging). Da seit langem alle Intel CPUs PAE können ist es zu erwarten, dass Intel dieses Feature schnell in seinen 32Bit CPUs nachgerüstet.
> - TCPA/TCG & Palladium haben natürlich im Prinzip mit dem NX-Feature zu tun
Ersetze "im Prinzip" durch "nichts", dann stimmt's
> [Yamhil] Baut Intel eine inkompatible 64 Bit EW in seine nächsten CPU's, hätte AMD große Probleme.
Inzwischen unwahrscheinlich da MS keine weitere Windows Platform schaffen/pflegen will.
> Baut Intel 'nur' NX ein, wird in großem Umfang alle Software entsprechend angepaßt.
Es wird wenig SW geben die man anpassen muss -- im Moment fallen mir nur nur JIT-Compiler und SW mit dynamischer Codegenerierung ein.
> Damit wird aber (unbeabsichtigt ?) bereits das Fundament gelegt, daß diese problemlos mit einem OS mit erweitertem Adressbereich (s. MS Docu) funktioniert.
Wieso? PAE wird doch schon lange unterstützt.
> Arbeiten Firmen wg. NX an ihrer Software, bietet es sich an auch gleich die x86-64 Variante mit zu compilieren.
Für x86-64 brauchst du aber ein 64 Bit Windows!
Mehr Infos zu zu NX auf AMD64: Chapter 5: "Page Translation and Protection" in "AMD64 Architecture Programmer’s Manual Volume 2: System Programming".
> Ein 'nur NX'-Feature hätte Intel längst veröffentlicht und marketingtechnisch ausgeschlacht. Und in seine Compiler eingebaut.
NX benötigt keine Compilerunterstüzung.
> Habe den technischen Hintergrund für das Verfahren nicht ganz durchschaut,
Der Hintergrund des der Buffer-Overflow Exploits liegt daran, dass Speicherbereiche die eigenlich nur Daten enthalten (Stack, Heap) dazu misbraucht werden um Ausfürbaren Code dort abzulegen und auszufürhen.
Die technischen Möglichkeiten von IA 32 würden für eine saubere Trennung von Code und Daten ausreichen, wenn das Betriebssystem korrekt von Segmentierung gebrauch machen würde. Das tut aber weder Linux noch NT. Grund: Beide Betriebssysteme legen ein flaches Speichermodell zu Grunde -- das ist für OS und Anwendungen viel leichter handhabbar. Ein flaches Speichermodell heist in dem Fall das die Segmentregister auf den gleichen Speicherbereich zeigen (bzw gleich Null enthalten). IMO ist der Segment-Quatsch einer der schlimmsten x86 Designfehler.
So nun zum Problem: Beim klassischen IA32 Paging können Speicherseiten als Lesbar und oder Schreibbar markiert werden. Wenn eine Seite lesbar ist darf die CPU auch Code der sich dort befindet ausführen. D.h es gibt keine Unterscheidung zwischen "lesbaren Daten" und "ausführbarem Code".
Das NX-Feature rüstet nur diese Unterscheidbarkeit nach indem (phsikalische) Speicherseiten, welche Daten enthalten, als "Not executable" gekennzeichnet werden. Wenn die CPU auf eine Speicherseite zugreift um davon Daten in den L1-Instruction Cache zu lesen wird das entsprechende NX-Bit in der Übersetzungstabelle überprüft. Ist NX gesetzt gibt es eine Access Violation Exception, anderfals werden die Daten (wie bisher) in den L1-I Cache übertragen. Von dort aus gelangen die Daten als Instructions in den Execution-Core.
Da die NX Bits in den Memory-Translation-Tabellen stehen ist es ausschlieslich Aufgabe des OS zu entscheiden für welche Speicherbereiche das NX Bit gesetzt wird.
> speziell weshalb heutige IA32-Möglichkeiten nicht ausreichen.
Das liegt einfach daran, das es keine Redundanzen (=Freie Bits) in den Datenstrukturen gibt die man für normales IA32 Paging braucht. D.h. Es bleibt keine Stelle übrig in der man das NX Bit speichern könnte. Bei PAE-Paging gibt es diese Möglichkeit.
BTW. So eine Technologie ist bei weitem nichts neues. Einige RISC CPUs kennen sowas schon lange, dort heist das ganze dann EOR (Execute OR Read). D.h eine Speicherseite kann entweder Code enthalten und executable sein oder Daten die lesbar sind.
> Da MS aber ausdrücklich von Itanium & AMD64 spricht ist hier wohl ein typisches 64 Bit (ursrünglich IA64?) -Feature von AMD in x86-64 mit eingearbeitet worden, sodaß dies auch für 32 Bit-OS und Anwendungen nutzbar wird.
IA64 und AMD64 nutzt im Long Mode immer PAE-Paging. Darum bietet es sich an dieses Feature in PAE-Paging Mode zu integrieren anstelle eines gänzlich neuen Paging-Modes.
NX hat nichts mit 32/64 Bit zu tun, sondern alleine mit der Virtual Memory Implementierung der CPU (=>PAE-Paging). Da seit langem alle Intel CPUs PAE können ist es zu erwarten, dass Intel dieses Feature schnell in seinen 32Bit CPUs nachgerüstet.
> - TCPA/TCG & Palladium haben natürlich im Prinzip mit dem NX-Feature zu tun
Ersetze "im Prinzip" durch "nichts", dann stimmt's
> [Yamhil] Baut Intel eine inkompatible 64 Bit EW in seine nächsten CPU's, hätte AMD große Probleme.
Inzwischen unwahrscheinlich da MS keine weitere Windows Platform schaffen/pflegen will.
> Baut Intel 'nur' NX ein, wird in großem Umfang alle Software entsprechend angepaßt.
Es wird wenig SW geben die man anpassen muss -- im Moment fallen mir nur nur JIT-Compiler und SW mit dynamischer Codegenerierung ein.
> Damit wird aber (unbeabsichtigt ?) bereits das Fundament gelegt, daß diese problemlos mit einem OS mit erweitertem Adressbereich (s. MS Docu) funktioniert.
Wieso? PAE wird doch schon lange unterstützt.
> Arbeiten Firmen wg. NX an ihrer Software, bietet es sich an auch gleich die x86-64 Variante mit zu compilieren.
Für x86-64 brauchst du aber ein 64 Bit Windows!Mehr Infos zu zu NX auf AMD64: Chapter 5: "Page Translation and Protection" in "AMD64 Architecture Programmer’s Manual Volume 2: System Programming".
?Die Programme merken wie schon gesagt von NX rein garnix. Da wird beim Paging was geändert (was ja nur das Betriebssystem verwaltet) und auf einmal gibts eben Bereiche, in denen Code ausgeführt werden kann und welche wo genau das nicht geht.
... genau so, wie es eigentlich bisher auch möglich gewesen wäre
Ich hab nur einige Bedenken, ob auch alle Programme damit zurrecht kommen, oder nicht hier oder da mal ein Programmierer etwas zu bösartig rumgehackt hat und das dann nicht mehr funktioniert.
Ähnliche Themen
