Microsoft mottet Palladium (NGSCB) zugunsten von NX ein
- Ersteller Nero24
- Erstellt am
★ Themenstarter ★
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Bei den Begriffen TCPA, TCG, Palladium und NGCSB zucken "freiheitsliebenden" Internetuser in der Regel zusammen wie verschreckte Katzen in einer Gewitternacht. Zwei Jahre ist es nun schon her, dass die Industrie mit dem Sicherheitskonzept <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1047204391">TCPA</a> an die Öffentlichkeit ging. Später wurde aus TCPA die Nachfolger-Organisation <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1049990849">TCG</a>. Alle "Features", Hintergrunde, Bedenken und Risiken entnehmt bitte den Links und Folgelinks, um diese Meldung nicht unnötig aufblähen zu müssen.
Das Gegenstück zu TCPA softwareseitig sollte das Palladium-Konzept in Microsofts Windows XP Nachfolger Longhorn werden. Während TCPA nur die passive Hardware beschreibt, war es Aufgabe von Palladium, das Sicherheitskonzept aktiv umzusetzen. Das reichte von Trusted Areas lokal wie auch im Web, von verifizierten Serials beim Programmstart bis hin zu Inhalten, die nur auf ausgewiesenen Rechnern bzw. für ausgewiesene User nutzbar sein sollten. Vor anderthalb Jahren hat Microsoft Palladium in NGSCB (Next-Generation secure Computing Base for Windows) <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1043749888">umbenannt</a>. So weit, so gut/schlecht.
Nun jedoch weiß das US-Online-Magazin <a href="http://www.crn.com/sections/BreakingNews/dailyarchives.asp?ArticleID=49936" TARGET="b">CRN</a> interessantes zu berichten. Demzufolge habe Microsoft das Palladium-Konzept derzeit auf Eis gelegt. Stattdessen wolle man sich voll und ganz auf das <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1077715275">NX-Features</a> (Data-Execution-Prevention) konzentrieren, welches derzeit von AMDs K8-Prozessoren unterstützt wird und von künftigen Intel-CPUs wohl unterstützt werden wird. NX verhindert das Ausführen von Daten als Programmcode, eine Sicherheitslücke, die derzeit allzu oft von Viren und Würmern verwendet wird, um schadhaften Code auf einem fremden Rechner auszuführen. Ein Punkt, wo auch Palladium ansetzen sollte. Da AMD dies nun jedoch in Hardware realisiert hat und von der Software nur noch unterstützt zu werden braucht, ist dies für MS natürlich ein wesentlich einfacherer Weg. Bereits Service Pack 2 von Windows XP wird NX unterstützen! Alles über die Funktionsweise von NX gibt's <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1073646170">hier</a>.
Was aus Palladium wird, ist derzeit nicht wirklich klar. CRN zitiert Mario Juarez, Product Manager von Microsofts Security and Technology Business Unit, mit den Worten, dass Palladium vor zwei Jahren in einer Phase der Entwicklung vorgestellt wurde, als noch gar nicht klar war, wie die technische Umsetzung vonstatten gehen solle. Ferner sei das Projekt derzeit eingemottet, da die Entwickler sich weigerten, ihre Programme neu zu schreiben, um die NGSCB-APIs zu nutzen. So ist es möglich, dass Longhorn komplett ohne Palladium kommen wird! CRN:<ul><i>After a year of tackling the Windows security nightmare, Microsoft has killed its Next-Generation Secure Computing Base (NGSCB) project and later this year plans to detail a revised security plan for Longhorn, the next major version of Windows, company executives said.</i></ul>Fahrplanmäßig dagegen soll die Unterstützung für Intels <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1050941891">LaGrande</a> Sicherheitstechnologie fortgesetzt werden...
THX rkinet für den Hinweis
Das Gegenstück zu TCPA softwareseitig sollte das Palladium-Konzept in Microsofts Windows XP Nachfolger Longhorn werden. Während TCPA nur die passive Hardware beschreibt, war es Aufgabe von Palladium, das Sicherheitskonzept aktiv umzusetzen. Das reichte von Trusted Areas lokal wie auch im Web, von verifizierten Serials beim Programmstart bis hin zu Inhalten, die nur auf ausgewiesenen Rechnern bzw. für ausgewiesene User nutzbar sein sollten. Vor anderthalb Jahren hat Microsoft Palladium in NGSCB (Next-Generation secure Computing Base for Windows) <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1043749888">umbenannt</a>. So weit, so gut/schlecht.
Nun jedoch weiß das US-Online-Magazin <a href="http://www.crn.com/sections/BreakingNews/dailyarchives.asp?ArticleID=49936" TARGET="b">CRN</a> interessantes zu berichten. Demzufolge habe Microsoft das Palladium-Konzept derzeit auf Eis gelegt. Stattdessen wolle man sich voll und ganz auf das <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1077715275">NX-Features</a> (Data-Execution-Prevention) konzentrieren, welches derzeit von AMDs K8-Prozessoren unterstützt wird und von künftigen Intel-CPUs wohl unterstützt werden wird. NX verhindert das Ausführen von Daten als Programmcode, eine Sicherheitslücke, die derzeit allzu oft von Viren und Würmern verwendet wird, um schadhaften Code auf einem fremden Rechner auszuführen. Ein Punkt, wo auch Palladium ansetzen sollte. Da AMD dies nun jedoch in Hardware realisiert hat und von der Software nur noch unterstützt zu werden braucht, ist dies für MS natürlich ein wesentlich einfacherer Weg. Bereits Service Pack 2 von Windows XP wird NX unterstützen! Alles über die Funktionsweise von NX gibt's <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1073646170">hier</a>.
Was aus Palladium wird, ist derzeit nicht wirklich klar. CRN zitiert Mario Juarez, Product Manager von Microsofts Security and Technology Business Unit, mit den Worten, dass Palladium vor zwei Jahren in einer Phase der Entwicklung vorgestellt wurde, als noch gar nicht klar war, wie die technische Umsetzung vonstatten gehen solle. Ferner sei das Projekt derzeit eingemottet, da die Entwickler sich weigerten, ihre Programme neu zu schreiben, um die NGSCB-APIs zu nutzen. So ist es möglich, dass Longhorn komplett ohne Palladium kommen wird! CRN:<ul><i>After a year of tackling the Windows security nightmare, Microsoft has killed its Next-Generation Secure Computing Base (NGSCB) project and later this year plans to detail a revised security plan for Longhorn, the next major version of Windows, company executives said.</i></ul>Fahrplanmäßig dagegen soll die Unterstützung für Intels <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1050941891">LaGrande</a> Sicherheitstechnologie fortgesetzt werden...
THX rkinet für den Hinweis
Bahlermann
Vice Admiral Special
Ich dachte immer ein buffer overflow
wäre wenn der für einen Wert gedachte speicher überfüllt wird,
und so der folgende originalcode durch schädlichen code ersetzt ist der ausgeführt wird.
★ Themenstarter ★
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Ja, das stimmt ja auchOriginal geschrieben von Bahlermann
Ich dachte immer ein buffer overflow
wäre wenn der für einen Wert gedachte speicher überfüllt wird,
und so der folgende originalcode durch schädlichen code ersetzt ist der ausgeführt wird.
So steht's auch in dem Text den zu zitierst; nur anders formuliert 
Der für den Wert (Daten!) gedachte Speicherbereich wird überfüllt und überschreibt einen Speicherbereich dahinter. Wenn es sich bei dem "Dahinter" um Code handelt und man den Bereich, mit dem überfüllt wird, so geschickt wählt, dass es sich dabei um Code handelt, der ausführbar ist und das Programm nicht nur einfach abstürzen lässt, dann hat man durch den Overflow eigenen Programmcode in den Speicher geschmuggelt. Und was das heissen kann, wissen wir ja von diversen Viren und Würmern 
Bahlermann
Vice Admiral Special
Und woran erkennt jetzt die CPU das der falsche code nicht der richtige ist?
Wen NX nur verhinder 200 anstatt 10 zeichen für einen String zu benutzen ist das ja nur etwas um schlampiger programieren zu können. Wie möchte MS das eigentlich in ihrer Software vernünftig hinbbekommen
als könnige des Buffer Overflow
Wen NX nur verhinder 200 anstatt 10 zeichen für einen String zu benutzen ist das ja nur etwas um schlampiger programieren zu können. Wie möchte MS das eigentlich in ihrer Software vernünftig hinbbekommen
als könnige des Buffer Overflow
★ Themenstarter ★
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.058
- Renomée
- 10.440
Das muss die CPU nicht erkennen! Die CPU verhindert nur, dass Daten in einen Bereich geschrieben wird, der für Code reserviert ist, was bisher nicht der Fall ist. Wird versucht, Code mit Daten zu überschreiben, bricht das System die Programmausführung mit einer entsprechenden Fehlermeldung ab.
rkinet
Grand Admiral Special
Original geschrieben von Bahlermann
Und woran erkennt jetzt die CPU das der falsche code nicht der richtige ist?
Wen NX nur verhinder 200 anstatt 10 zeichen für einen String zu benutzen ist das ja nur etwas um schlampiger programieren zu können. Wie möchte MS das eigentlich in ihrer Software vernünftig hinbbekommen
Es werden wohl nur größere, zusammenhängende Blöcke definiert, was einem Compiler nicht schwer fallen sollte.
Übrigens, auch LINUX hat hier Einfallstore, es also ein algemeines Problem.
Lui-Kim-Su
Grand Admiral Special
Riecht verdammt nach anfang April
DANKE, AMD DANKE! Das "du" uns vor TCPA, TCG, Palladium und NGCSB bewarst 
Soweit ich weiß wird bei NX keine Userdaten ins I-Net gesendet oder?! Und somit hat uns AMD dank eine kleine Erfindung vorerst vor dem Weg zum Gläsernenbürger bewahrt und gleich zeitig die Sicherheit erhöht.
Und das ist wieder ein grund mehr AMD zu kaufen... 8)
EDIT:
OK, evt. sind die Jubelscheie noch verfrüht...
Soweit ich weiß wird bei NX keine Userdaten ins I-Net gesendet oder?! Und somit hat uns AMD dank eine kleine Erfindung vorerst vor dem Weg zum Gläsernenbürger bewahrt und gleich zeitig die Sicherheit erhöht.
Und das ist wieder ein grund mehr AMD zu kaufen...
8)EDIT:
OK, evt. sind die Jubelscheie noch verfrüht...
Da ist der Artikel bei Heise aber etwas anders:
http://www.heise.de/newsticker/meldung/47139
http://www.heise.de/newsticker/meldung/47139
Ich hab MS ja in letzter Zeit bestimmt nur selten gelobt (bzw. garnicht), aber wenn das stimmt -
Andererseits hat MS das auch angerührt...
Zur Technik: Das Problem ist, dass Daten und Code in einem 4Gb Speicherbereich liegen.
Wenn Funktionen aufgerufen werden wird die Rücksprungadresse normalerweise (immer) im Stack gespeichert. Wenn ich nun weis wie ich die Rücksprungadresse ändern kann hab ich schon 3/4 vom Hack fertig. Als nächstes muss man wissen wo die Daten genau liegen und fertig ist der Hack.
Praktisch ginge das zb. so: Ein Angreifer sendet ein TCP/IP Paket an einen Rechner. Das Paket wird irgendwo gespeichert. Dann sendet der Angreifer ein 2. Paket hinterher, das einen Pufferüberlauf auslößt und die Rücksprungadresse dahin verbiegt, wo das 1. Paket im Speicher liegt (kann man natürlich auch beides in einem Paket realisiseren).
So wird das 1. Paket ausgeführt, obwohl das eigentlich nur Daten enthalten sollte bzw. vom Programm selbst nur als Daten behandelt werden sollte.
NX sichert nun selektierbare Bereiche (Pages) gegen Ausführung ab, so dass der Sprung zum Code im 1. Paket mit einem Fehler endet und das Programm beendet wird (anstatt Fehlerhaften Code auszuführen und so womöglich weitere Rechner zu infizieren).
Der Blaster hätte zb. mit NX garkeine Chance gehabt.
Die i386-Architektur bietet eigentlich selbst Maßnahmen soetwas sehr wirkungsvoll zu verhindern (fast noch eleganter als NX), aber da es Windows NT früher auch für PPC und MIPS gab (die die Sache eher wie NX implementiert haben) hat man es bei i386 nicht genutzt.
Andererseits hat MS das auch angerührt...
Zur Technik: Das Problem ist, dass Daten und Code in einem 4Gb Speicherbereich liegen.
Wenn Funktionen aufgerufen werden wird die Rücksprungadresse normalerweise (immer) im Stack gespeichert. Wenn ich nun weis wie ich die Rücksprungadresse ändern kann hab ich schon 3/4 vom Hack fertig. Als nächstes muss man wissen wo die Daten genau liegen und fertig ist der Hack.
Praktisch ginge das zb. so: Ein Angreifer sendet ein TCP/IP Paket an einen Rechner. Das Paket wird irgendwo gespeichert. Dann sendet der Angreifer ein 2. Paket hinterher, das einen Pufferüberlauf auslößt und die Rücksprungadresse dahin verbiegt, wo das 1. Paket im Speicher liegt (kann man natürlich auch beides in einem Paket realisiseren).
So wird das 1. Paket ausgeführt, obwohl das eigentlich nur Daten enthalten sollte bzw. vom Programm selbst nur als Daten behandelt werden sollte.
NX sichert nun selektierbare Bereiche (Pages) gegen Ausführung ab, so dass der Sprung zum Code im 1. Paket mit einem Fehler endet und das Programm beendet wird (anstatt Fehlerhaften Code auszuführen und so womöglich weitere Rechner zu infizieren).
Der Blaster hätte zb. mit NX garkeine Chance gehabt.
Die i386-Architektur bietet eigentlich selbst Maßnahmen soetwas sehr wirkungsvoll zu verhindern (fast noch eleganter als NX), aber da es Windows NT früher auch für PPC und MIPS gab (die die Sache eher wie NX implementiert haben) hat man es bei i386 nicht genutzt.
rkinet
Grand Admiral Special
heise verweist aber auch auf den 'NX-Bit' Artikel.
Problem bei Palldium ist, daß eben Grundsatzfragen im Design der PCs betroffen sind. Wenn in Firmen nach Hardwarewechsel das Backup vom Desktop nicht mehr läuft, oder nicht mehr über Harddisk-Images viele Dutzend PCs ihre Software erhalten können, geht das eben nicht.
Ohn Unterstützung im 'Profilager' wäre dann Palladium eh eine Totgeburt.
Fruchtnektar
Admiral Special
Der König ist tot. Es lebe der König.
Es ist doch eine 88 oder?
Es ist doch eine 88 oder?
StrgAltEntf
Admiral Special
Den Champagner jetzt schon aufzumachen, wäre zwar sicher noch etwas verfrüht, aber das klingt schon nicht schlecht .
Wäre schon witzig: Die Faulheit der Software-Entwickler (okay, und ganz nebenbei auch die NX-Technologie
) verhindert die Unterjochung der Anwender (überspitzt formuliert ). Die Faulheit ist eine Tugend, die man nicht unterschätzen sollte
(Gleichzeitig ist sie aber eine Plage, die unter anderem dafür sorgt, dass sich viele niemals von MS lösen werden)
Außerdem ist es wie gesagt etwas früh zum feiern: MS und andere Interessenten wie z.B. die Rechteindustrie werden sich andere Mittel und Wege überlegen, den Anwendern die Kontrolle über deren Rechner streitig zu machen und sie mit netten "Features" wie DRM&Co zu beglücken. Und wie im Originalartikel schon steht: Microsoft wird von sich hören lassen, wenn sie selber erstmal wissen, wie's weitergeht.
Mich gewinnt Microsoft so oder so nicht zurück
Wäre schon witzig: Die Faulheit der Software-Entwickler (okay, und ganz nebenbei auch die NX-Technologie
) verhindert die Unterjochung der Anwender (überspitzt formuliert ). Die Faulheit ist eine Tugend, die man nicht unterschätzen sollte (Gleichzeitig ist sie aber eine Plage, die unter anderem dafür sorgt, dass sich viele niemals von MS lösen werden
)Außerdem ist es wie gesagt etwas früh zum feiern: MS und andere Interessenten wie z.B. die Rechteindustrie werden sich andere Mittel und Wege überlegen, den Anwendern die Kontrolle über deren Rechner streitig zu machen und sie mit netten "Features" wie DRM&Co zu beglücken. Und wie im Originalartikel schon steht: Microsoft wird von sich hören lassen, wenn sie selber erstmal wissen, wie's weitergeht.
Mich gewinnt Microsoft so oder so nicht zurück
X-Dimension
Grand Admiral Special
Also das halte ich für ein Gerücht!
Denn -> http://www.computerbase.de/news/software/multimedia/2004/mai/microsoft_musik_ablaufdatum/
XD
Denn -> http://www.computerbase.de/news/software/multimedia/2004/mai/microsoft_musik_ablaufdatum/
XD
Wir sind hier nicht bei Linux
Je nach Programm wären sicherlich auch ein paar kleine Änderungen nötig, aber das liegt weniger an den Änderungen als am Programmierstiel.
Na jetzt hol ich doch mal weiter aus:
Inzwischen hat sich das Modell für Programme (auf ziemlich vielen Plattformen) durchgesetzt:
Das Programm liegt in einem virtuellen (bei x86 4GB großem) Speicherbereich.
In diesem Speicherbereich liegen verteilt sowohl Daten, Code als auch der Stack. Bei Linux werden hier zb. auch shared libs in den Adressraum eingeblendet.
Das geht mittels Paging. Der Adressraum ist wie gesagt virtuell, hat also erstmal nix mit dem Ram zu tun.
Dieser Adressraum ist in Pages unterteilt. Eine Page ist erstmal nix weiter als ein Ausschnitt von diesem Adressraum, sagen wir Offset xyz bis Offset xyz+abc.
Den Pages kann man Eigenschaften zuordnen. Zb. kann man die Page auf einen Bereich im physikalischen Ram zeigen lassen. Wenn die Page im Adressraum bei 1MB anfängt, im physikalischen Ram bei 120MB begint und 4MB größ ist wird der Ausschnitt 1MB bis 5MB vom virtuellen Adressraum auf den physikalischen Speicher 120MB bis 124MB gemappt.
Damit kann man zb. Anwendungen kreuz und quer im Ram verteilen, Speicheranforderungen realisieren usw. (im normalen Betrieb sind nie die ganzen 4GB gemappt, ein großteil vom Adressraum bleibt da unbenutzt).
Speicheranforderungen könnten zb. so ablaufen - das Prog sagt dem OS es will 20MB Speicher haben, und das OS sagt darauf dem Prog, dass es die 20MB an Position xyz im Adressraum gemappt hat.
Durch den Aufbau von Progs (.EXE, ELF, A.OUT etc.) liegen die Daten immer getrennt vom Code, und im Adressraum auch in einer anderen Page. NX setzt nun da an, und man kann einzelne Pages als nicht ausführbar markieren. Die Daten befinden sich dann im Adressraum, aber können eben nicht ausgeführt werden. So kann ein Programm explizit deklarieren, ob sich an der Stelle Code oder Daten befinden. Ein Virus der sich einschleicht wird ja erstmal immer als Daten deklariert, und nur durch einen Programmfehler auch wirklich ausgeführt - mit NX geht das nicht.
Paging ist eine Möglichkeit der Speicherverwaltung. Es gibt dank x86 aber noch eine 2. Möglichkeit - die Segmentierung.
Die Segmentierung liegt eine Ebene höher als Paging. Ein Segment ist ein kompletter virtueller Adressraum (bei x86 mit 16MB oder 4GB, die letztendliche Größe kann man aber selbst in diesem Rahmen festlegen).
In diesen einzelnen Segmenten ist Paging möglich. x86 kennt ziemlich viele Segmentattribute, so gibt es Segmente in denen nur Code liegen kann, Segmente in denen nur Daten liegen können, und ein sehr einfaches Rechtemanagement (das ist alles direkt in der CPU implementiert).
Die Segmentierung ist ein integraler Bestandteil von x86, man kann die also nicht umgehen. Aber man kann sie unwirksam machen. x86 Assembler kennt 2 verschiedene Nutzungsmöglichkeiten für Offsets - in Sprunganweisungen zeigt ein Offset auf Code, in irgend einem anderen Befehl auf Daten. Also MOV AX,[0x3] (2 bytes vom Offset 3 in Register AX lesen) und JMP 0x3 (zum Offset 3 springen und den Code dort ausführen) sind erstmal so ziemlich das Selbe.
Jetzt stellt sich eine Frage: Wo ist zwischen den Offsets der Unterschied?
Ich hab ja gesagt die Segmentierung sei integral, man kann sie also nicht umgehen. Oben fehlen die Segmentangaben, vollständig müsste es nämlich heißen MOV AX, [DS:0x3] und JMP [CS:0x3] (jetzt haben wir Segment:Offset).
Jetzt wird der Unterschied deutlich, x86 erlaubt es nämlich die Segmente einfach wegzulassen (-> kleinerer Code) und dafür die Standart-Segmente (CS -> Code Segment, DS -> Daten Segment) zu nutzen.
Also wenn kein Segment gegeben ist wird bei einem Code-Offset immer das CS-Segment, und bei einem Date-Offset immer das DS-Segment angenommen.
Bei aktuellen OSs bedient man sich nun einem kleinen Trick (obwohl es unsauberer Hack besser trifft). CS und DS sind zwar unterschiedliche Segmente, können aber trotzdem auf genau den selben Speicher zeigen. Das wird manchmal sogar "nötig" (es ließe sich doch vermeiden), weil x86 eben ein kleines Rechte-Management für Segmente hat - so kann man in Code Segmenten nur Code ausführen, und bei Daten-Segmenten nur lesen/schreiben (und das ist auch noch steuerbar, nur lesen ist zb. auch möglich).
Also wenn wir Code und Daten in einen 4GB Adressraum packen wollen wird das auf den ersten Blick sogar nötig, dass CS und DS auf den selben Speicher zeigen (obwohl es ja trotzdem 2 verschiedene Segmente sind).
Dadurch, dass wir keine Segmente angeben müssen wird das jetzt alles schön einfach. MOV AX, [0x3] ließt die Daten vom Offset 3, und JMP 0x3 führt den Code dort aus. Und da eben die Segmente auf den selben Speicher (bzw. die selben Pages) zeigen (nur mit verschiedenen Rechten) liegt bei DS:0x3 auch genau das selbe wie bei CS:0x3 (das selbe gilt übrigens auch für das Stack-Segment SS, in dem nur der Stack liegt - das ist ansonsten auch ein normales Daten-Segment).
Andere Architekturen bieten diese Segmentierung nicht (bzw. nicht in dem Maße), so dass man die zur kompatiblität bei x86 einfach weg"optimiert".
Aber was wäre wenn nun CS und DS nicht auf den selben Speicherbereich zeigen?
Vorteil: Da die Daten nicht als Code sichtbar sind kann das Programm auch keinen Daten mehr ausführen. Also wie mit NX. Bei CS:0x3 liegt jetzt was völlig anderes als bei DS:0x3.
Nachteile:
- Selbstmodifizierender Code wäre nicht mehr so einfach realisierbar (aber sowas unsauberes nimmt zum Glück seit langem keiner mehr und es gibt auch noch CPU-bedingte Dinge die sowas verhindern).
- Das Programm darf nicht davon ausgehen, dass CS und DS auf den selben Speicher zeigen.
Eigentlich fallen die Nachteile nicht ins Gewicht. In den Ausführbaren Dateien (also .EXE, ELF, A.OUT usw.) wird strikt zwischen Code, Daten und Stack unterschieden. Die werden momentan aber eben alle in einen Adressraum geladen (und dahin ist die Unterscheidung).
Es wäre eben die Frage wieviele Programme annehmen CS und DS zeigen auf den selben Speicherbereich. Ich kann mir nicht wirklich vorstellen wo man sowas brauchen könnte, aber Ausnahmen gibts immer.
Dann wäre natürlich der Aufwand zur Verwaltung der Segmente ein bisschen größer, aber das dürfte performance-mäßig nicht ins Gewicht fallen.
Bleibt nur noch die Kompatiblität zu anderen Architekturen. Der virtuelle "flat" Adressraum ("flat" -> keinerlei Segmentierung oder sowas) hat sich weit verbreitet und ist inzwischen eigentlich durchgehend standart.
Den gäbe es mit der Änderung nicht mehr in dem Sinne. Aber die geänderten Programme würden natürlich auch laufen wenn CS und DS wieder auf den selben Speicher zeigen. Das Betriebssystem müsste für die einzelnen Programme vor dem Start die Segmente festlegen, so braucht sich das Programm dann auch nicht mit der Segmentierung rumzuschlagen - wenn CS, DS und SS gestzt sind müssen die (für das Programm) nicht mehr geändert werden, so wie es heute schon der Fall ist.
Puh, jetzt hab ich ja doch wieder so einen Schinken geschrieben![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Je nach Programm wären sicherlich auch ein paar kleine Änderungen nötig, aber das liegt weniger an den Änderungen als am Programmierstiel.
Na jetzt hol ich doch mal weiter aus:
Inzwischen hat sich das Modell für Programme (auf ziemlich vielen Plattformen) durchgesetzt:
Das Programm liegt in einem virtuellen (bei x86 4GB großem) Speicherbereich.
In diesem Speicherbereich liegen verteilt sowohl Daten, Code als auch der Stack. Bei Linux werden hier zb. auch shared libs in den Adressraum eingeblendet.
Das geht mittels Paging. Der Adressraum ist wie gesagt virtuell, hat also erstmal nix mit dem Ram zu tun.
Dieser Adressraum ist in Pages unterteilt. Eine Page ist erstmal nix weiter als ein Ausschnitt von diesem Adressraum, sagen wir Offset xyz bis Offset xyz+abc.
Den Pages kann man Eigenschaften zuordnen. Zb. kann man die Page auf einen Bereich im physikalischen Ram zeigen lassen. Wenn die Page im Adressraum bei 1MB anfängt, im physikalischen Ram bei 120MB begint und 4MB größ ist wird der Ausschnitt 1MB bis 5MB vom virtuellen Adressraum auf den physikalischen Speicher 120MB bis 124MB gemappt.
Damit kann man zb. Anwendungen kreuz und quer im Ram verteilen, Speicheranforderungen realisieren usw. (im normalen Betrieb sind nie die ganzen 4GB gemappt, ein großteil vom Adressraum bleibt da unbenutzt).
Speicheranforderungen könnten zb. so ablaufen - das Prog sagt dem OS es will 20MB Speicher haben, und das OS sagt darauf dem Prog, dass es die 20MB an Position xyz im Adressraum gemappt hat.
Durch den Aufbau von Progs (.EXE, ELF, A.OUT etc.) liegen die Daten immer getrennt vom Code, und im Adressraum auch in einer anderen Page. NX setzt nun da an, und man kann einzelne Pages als nicht ausführbar markieren. Die Daten befinden sich dann im Adressraum, aber können eben nicht ausgeführt werden. So kann ein Programm explizit deklarieren, ob sich an der Stelle Code oder Daten befinden. Ein Virus der sich einschleicht wird ja erstmal immer als Daten deklariert, und nur durch einen Programmfehler auch wirklich ausgeführt - mit NX geht das nicht.
Paging ist eine Möglichkeit der Speicherverwaltung. Es gibt dank x86 aber noch eine 2. Möglichkeit - die Segmentierung.
Die Segmentierung liegt eine Ebene höher als Paging. Ein Segment ist ein kompletter virtueller Adressraum (bei x86 mit 16MB oder 4GB, die letztendliche Größe kann man aber selbst in diesem Rahmen festlegen).
In diesen einzelnen Segmenten ist Paging möglich. x86 kennt ziemlich viele Segmentattribute, so gibt es Segmente in denen nur Code liegen kann, Segmente in denen nur Daten liegen können, und ein sehr einfaches Rechtemanagement (das ist alles direkt in der CPU implementiert).
Die Segmentierung ist ein integraler Bestandteil von x86, man kann die also nicht umgehen. Aber man kann sie unwirksam machen. x86 Assembler kennt 2 verschiedene Nutzungsmöglichkeiten für Offsets - in Sprunganweisungen zeigt ein Offset auf Code, in irgend einem anderen Befehl auf Daten. Also MOV AX,[0x3] (2 bytes vom Offset 3 in Register AX lesen) und JMP 0x3 (zum Offset 3 springen und den Code dort ausführen) sind erstmal so ziemlich das Selbe.
Jetzt stellt sich eine Frage: Wo ist zwischen den Offsets der Unterschied?
Ich hab ja gesagt die Segmentierung sei integral, man kann sie also nicht umgehen. Oben fehlen die Segmentangaben, vollständig müsste es nämlich heißen MOV AX, [DS:0x3] und JMP [CS:0x3] (jetzt haben wir Segment:Offset).
Jetzt wird der Unterschied deutlich, x86 erlaubt es nämlich die Segmente einfach wegzulassen (-> kleinerer Code) und dafür die Standart-Segmente (CS -> Code Segment, DS -> Daten Segment) zu nutzen.
Also wenn kein Segment gegeben ist wird bei einem Code-Offset immer das CS-Segment, und bei einem Date-Offset immer das DS-Segment angenommen.
Bei aktuellen OSs bedient man sich nun einem kleinen Trick (obwohl es unsauberer Hack besser trifft). CS und DS sind zwar unterschiedliche Segmente, können aber trotzdem auf genau den selben Speicher zeigen. Das wird manchmal sogar "nötig" (es ließe sich doch vermeiden), weil x86 eben ein kleines Rechte-Management für Segmente hat - so kann man in Code Segmenten nur Code ausführen, und bei Daten-Segmenten nur lesen/schreiben (und das ist auch noch steuerbar, nur lesen ist zb. auch möglich).
Also wenn wir Code und Daten in einen 4GB Adressraum packen wollen wird das auf den ersten Blick sogar nötig, dass CS und DS auf den selben Speicher zeigen (obwohl es ja trotzdem 2 verschiedene Segmente sind).
Dadurch, dass wir keine Segmente angeben müssen wird das jetzt alles schön einfach. MOV AX, [0x3] ließt die Daten vom Offset 3, und JMP 0x3 führt den Code dort aus. Und da eben die Segmente auf den selben Speicher (bzw. die selben Pages) zeigen (nur mit verschiedenen Rechten) liegt bei DS:0x3 auch genau das selbe wie bei CS:0x3 (das selbe gilt übrigens auch für das Stack-Segment SS, in dem nur der Stack liegt - das ist ansonsten auch ein normales Daten-Segment).
Andere Architekturen bieten diese Segmentierung nicht (bzw. nicht in dem Maße), so dass man die zur kompatiblität bei x86 einfach weg"optimiert".
Aber was wäre wenn nun CS und DS nicht auf den selben Speicherbereich zeigen?
Vorteil: Da die Daten nicht als Code sichtbar sind kann das Programm auch keinen Daten mehr ausführen. Also wie mit NX. Bei CS:0x3 liegt jetzt was völlig anderes als bei DS:0x3.
Nachteile:
- Selbstmodifizierender Code wäre nicht mehr so einfach realisierbar (aber sowas unsauberes nimmt zum Glück seit langem keiner mehr und es gibt auch noch CPU-bedingte Dinge die sowas verhindern).
- Das Programm darf nicht davon ausgehen, dass CS und DS auf den selben Speicher zeigen.
Eigentlich fallen die Nachteile nicht ins Gewicht. In den Ausführbaren Dateien (also .EXE, ELF, A.OUT usw.) wird strikt zwischen Code, Daten und Stack unterschieden. Die werden momentan aber eben alle in einen Adressraum geladen (und dahin ist die Unterscheidung).
Es wäre eben die Frage wieviele Programme annehmen CS und DS zeigen auf den selben Speicherbereich. Ich kann mir nicht wirklich vorstellen wo man sowas brauchen könnte, aber Ausnahmen gibts immer.
Dann wäre natürlich der Aufwand zur Verwaltung der Segmente ein bisschen größer, aber das dürfte performance-mäßig nicht ins Gewicht fallen.
Bleibt nur noch die Kompatiblität zu anderen Architekturen. Der virtuelle "flat" Adressraum ("flat" -> keinerlei Segmentierung oder sowas) hat sich weit verbreitet und ist inzwischen eigentlich durchgehend standart.
Den gäbe es mit der Änderung nicht mehr in dem Sinne. Aber die geänderten Programme würden natürlich auch laufen wenn CS und DS wieder auf den selben Speicher zeigen. Das Betriebssystem müsste für die einzelnen Programme vor dem Start die Segmente festlegen, so braucht sich das Programm dann auch nicht mit der Segmentierung rumzuschlagen - wenn CS, DS und SS gestzt sind müssen die (für das Programm) nicht mehr geändert werden, so wie es heute schon der Fall ist.
Puh, jetzt hab ich ja doch wieder so einen Schinken geschrieben
PuckPoltergeist
Grand Admiral Special
AMD64 kennt keine Segmentierung mehr, und damit hat sich das Thema schon erledigt.
Es macht keinen Sinn sowohl Segmentierung als auch Paging zu unterstützen, da beide Techniken am Ende das selbe realisieren. Paging ist von der Handhabung her einfacher (zumindest bei x86) und es wird auf wirklich jeder Hardwareplattform unterstützt. Somit sollte die Wahl ja eigentlich klar sein.
Ja, die Frage ist wieso AMD64 keine Segmentierung mehr kennt -> eben weil sie nicht genutzt wurde.
Mit NX ist es ja auch garkein Problem, da bietet Paging ähnliches wie Segmentierung (mal von der strikteren Trennung zwischen Daten und Code abgesehen) - aber der 32bit PM kennt sowas eben net
Es wäre wirklich nur die kleine Tatsache, dass Progs nicht mehr annehmen CS und DS zeige auf den selben Speicher. Es wäre dann ja nicht schlimm wenn sie das trotzdem täten, aber man könnte dann sofort auch für den 32bit PM etwas NX-artiges implementieren.
Mit NX ist es ja auch garkein Problem, da bietet Paging ähnliches wie Segmentierung (mal von der strikteren Trennung zwischen Daten und Code abgesehen) - aber der 32bit PM kennt sowas eben net
Es wäre wirklich nur die kleine Tatsache, dass Progs nicht mehr annehmen CS und DS zeige auf den selben Speicher. Es wäre dann ja nicht schlimm wenn sie das trotzdem täten, aber man könnte dann sofort auch für den 32bit PM etwas NX-artiges implementieren.
PuckPoltergeist
Grand Admiral Special
Du weißt schon, dass für sowas elementar Änderungen am OS notwendig sind? Speicherschutz (mal jetzt ganz allgemein bezeichnet) erfordert die Unterstützung durch die Hardware, was dann wiederum vom OS genutzt werden muss. Es macht einfach keinen Sinn, die Segmentierung wieder auszugraben.
Ähnliche Themen
