Diskussion:NX-Bit

Turion

Hat AMD Turion dieses Feature?

Jo, hab ihn eingefügt.

Softwareunterstützung

Die Software und Betriebssysteme die dieses Feature unterstützen sollte man genauer aufführen. --marti 03:26, 28. Jan. 2007 (CET)

Wozu? Das hat doch nichts mit der Funktionsweise von diesem zu tun. Software, die dieses nutzt ist auch nicht besser als die das nicht nutzen.....siehe Hintertürchen. --79.199.58.240 03:22, 2. Jun. 2008 (CEST)

Jedoch ist im Artikel nur von Windows die Rede... Jedoch unterstützen Mac OS X und Linux diese Funktion auch seit geraumer Zeit ?! -- 80.134.189.191 20:50, 18. Mär. 2010 (CET)

Weblinks

Lassen sich für dieses Thema keine Weblinks finden, die WP:Web entsprechen? Vom Feinsten finde ich den Beitrag von Planet 3DNow! jedenfalls Aufgrund der mangelnden Ausführlichkeit zur angesprochenen Schuldfrage (wenn schon, denn schon), Werbe-Popups und der verwendeten Sprache nicht. Ich schlage vor, den durch folgende

• von AMD (englisch)
• und Linux-Magazin

zu ersetzen und dem Heise-Artikel einen besseren Namen zu geben. Für das "XD bit white paper" von Intel muß man sich leider einloggen, daher ist das als Link auch nicht geeignet. --Trac3R 01:30, 21. Sep. 2008 (CEST)

Mach es selbst.

Dieser Abschnitt kann archiviert werden. --Trac3R 11:00, 21. Sep. 2008 (CEST)

Fehler

"Wenn dabei ein Sprung innerhalb des Segmentes ausgelöst wird" - sollte wohl innerhalb der Page heißen, hab das mal korrigiert. Das NX Bit findet sich im Page Deskriptor, nicht in den Segmentdeskriptoren, und arbeitet entsprechend auf Pagebasis. Die Segmente selber liefert schon seit dem 386er die Möglichkeit Codeausführung zu verhindern. Das geht soweit, dass ein Segment entweder ein Datensegment ist, oder ein Codesegment - aber nicht beides (Codesegmente können nicht verändert werden). Bei aktuellen OS die keine Segmentierung benutzen sind alle "normalen" Segmente 4GB groß und fangen bei 0 an, damit umgeht man effektiv die Segmentierung.

Hab damals übrigens den P3D Artikel geschrieben... wenigstens sind da keine Fehler drinnen ;). --84.57.133.0 13:31, 10. Dez. 2008 (CET)

"Vor Integeroverflows, Programmabstürzen und DoS-Attacken schützt das NX-Bit allerdings nicht." Was soll das denn bedeuten? Es schützt auch nicht vor Spam oder vor Grippe... -- Impic 22:00, 3. Jun 2005 (CEST)

Seh ich auch so. Die "DoS-Attacken" beziehen sich sogar nichtmal auf ein lokales Computersystem. Und der Programmabsturz wird ja eben gerade ausgelöst, um das restliche System zu schützen. Ich hab den Satz mal gelöscht. --Maexs 19:21, 24. Okt. 2009 (CEST)

Funktionsweise

Inwiefern soll durch das NX-Bit das Von-Neumann-Prinzip ("teilweise") gebrochen werden? Daten und Programm-Code sind ja nachwievor in der selben physikalischen Einheit abgespeichert. Ein ledigliches zusätzliches Sicherheitsmerkmal kann doch das VN-Prinzip nicht brechen, oder? --Maexs 21:39, 21. Dez. 2009 (CET)

Hmmm....ich finde die Formulierung auch fragwürdig, wenn an das in Relation zum Hintertürchen für eineBuffer Overflow trotz NX Bit sieht. --79.199.61.109 20:18, 8. Jun. 2010 (CEST)

Naja, es sind Daten und Code eben räumlich getrennt im Arbeitsspeicher, man kann es nicht mehr nach Belieben mixen. Ob das nun über ein eigenes Adressbit geschieht (wie bei "echten" Harward-Architekturen) oder eben über ein Flag in der zugehörigen Seitentabelle, die den Inhalt und die Zugriffsrechte einer Speicherseite beschreibt, ist da eher Nebensache. Natürlich gibt es wegen des NX-Bits plötzlich keine getrennten Busse für Befehle und Daten, wie es eine Harvard-Architektur verlangen würde, das ist klar. --00:14, 9. Jun. 2010 (CEST)

CPU-Liste kürzen?

Da mir kein Hersteller bekannt ist, der NX-Support in neueren CPUs wieder entfernt hat, würde es doch reichen, jeweils die erste CPU einer CPU-Familie zu nennen. Das würde die CPU-Liste deutlich verkleinern und übersichtlicher machen. Was meint ihr? --RokerHRO (Diskussion) 14:10, 27. Aug. 2013 (CEST)

Ja, das ist eine gute Idee. -- Gerd Fahrenhorst (Diskussion) 18:10, 27. Aug. 2013 (CEST)

Erledigt. --RokerHRO (Diskussion) 17:24, 30. Aug. 2013 (CEST)

Nachteile?

Im BIOS gibt es in der Regel die Option, dieses NX-Bit zu deaktivieren. Welche Vorteile hat dies, bzw. welche Nachteile des NX Bit werden damit vermieden? Führt die Nutzung von NX-Bit zu zusätzlicher Latenz? (nicht signierter Beitrag von 78.54.174.152 (Diskussion) 22:58, 23. Sep. 2015 (CEST))

Execute disable bit mit Uefi modus

Ich verwende einen Intel Core X Serie Processor der 9 Generation.

Ich bemerke einen aktiven Leistung aufbau und Latenzstabilität beim deaktivieren.

Ich es richtig, das im Uefi Modus Execute Disable Bit auch deaktiviert werden kann da diese Option als Legacy Modus betrachtet wird? Ohne ein Sicherheitsrisiko einzugehen? (nicht signierter Beitrag von 2A02:1210:3A3E:400:CC1B:78C6:8A01:B192 (Diskussion) 20:22, 2. Feb. 2022 (CET))

Wikipedia ist kein Forum. Und nein, das ist nicht richtig: das NX-Bit bietet einen Sicherheitsgewinn, der nicht unwesentlich ist. Diese Funktion zu deaktivieren ist keine gute Idee...

‣Andreas•⚖ 20:44, 2. Feb. 2022 (CET)

32-Bit-x86 "IA-32"

Unter 32-Bit-Betriebssystemen war es nicht so einfach, PAE und damit das NX-Bit bzw. XD-Bit zu aktivieren, weil meist Treiber nicht gut mit PAE zurecht kamen. Die gesamte Software hätte also erst "PAE-aware" gemacht werden müssen, warum gerade auch Windows anfangs immer ohne PAE-Aktivierung daherkam: damit das System nicht instabil wurde.

Auch unter Linux gab es diese Bedenken anfangs, da Linux jedoch ein komplett quell-offenes System ist, war die Sache nicht so schwierig wie unter Windows: Linux wurde einfach durch einen Compiler, der PAE-aware war, neu übersetzt, und alles lief. Siehe dazu z.B. x86 NX support auf LWN.net, Zitat: Linus's main concern about the patch would appear to be how many old applications it might break. The reply from Arjan van de Ven is that pretty much everything "just works." The no-execute permission is not applied unless the code is specially marked in the image file, and gcc apparently does a good job of not setting that flag when it would break things.

Für Windows findet sich haufenweise was dazu im Netz, wer suchet der findet. Für OS/2 wurde das genau gleich diskutiert, und auch hier sind die Treiber das Problem, siehe z.B. die Diskussion mit dem Titel Hybrid "64-Bit" eComStation im OS2 World Community Forum. In diesem Zusammenhang: erst eComStation 1.2 konnte die "vollen" 4 GB, die bei reinem 32-Bit-x86 ohne PAE möglich sind, wirklich nutzen (siehe z.B. eComStation auf www.operating-system.org). Für OS/2 4.52, das letzte "offizielle" von IBM, waren 4 GB zu viel (siehe z.B. hier). eComStation und ArcaOS nutzen, wie auch Windows, die max. 4 GB abzüglich der für die Geräte abgezwackten Bereiche, womit auf jedem System unterschiedlich viel RAM verfügbar ist (siehe z.B. hier). In Essenz ist es aber bei Windows 2000 und XP dasselbe Problem wie auf OS/2.

Was hat das mit dem NX-Bit zu tun? Nun, wenn 32-Bit-Windows das NX-Bit unterstützt, dann nutzt das nix, wenn PAE so große Probleme macht, dass dann beides nicht aktiviert werden kann.

Ist das ganze wirklich so interessant? Keine Ahnung. Anregungen, Überarbeitungen, Kürzungen u.d.gl. sind (begründet!, diskutiert) immer willkommen. ‣Andreas•⚖ 00:29, 6. Apr. 2024 (CEST)