Diskussion:NX-Bit

message: Die Software und Betriebssysteme die dieses Feature unterstützen sollte man genauer aufführen. --marti 03:26, 28. Jan. 2007 (CET)
replies: text: 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)
thread_title:  Softwareunterstützung 

message: "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)
replies: text: 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)
thread_title: Fehler

message: 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)
replies: text: 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)

text: 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)
thread_title: Funktionsweise

message: 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)
replies: text: Ja, das ist eine gute Idee. -- Gerd Fahrenhorst (Diskussion) 18:10, 27. Aug. 2013 (CEST)
replies: text:  Erledigt. --RokerHRO (Diskussion) 17:24, 30. Aug. 2013 (CEST)
thread_title:  CPU-Liste kürzen? 

message: 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)
thread_title: Nachteile?

message: 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? 
: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)
thread_title:  Execute disable bit mit Uefi modus 

message: 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)
thread_title:  32-Bit-x86 "IA-32"