Speicherschutz damals (i386) und heute?

20/03/2010 - 15:31 von k.martinen | Report spam
Hallo.

Ich hoffe das ich hier die richtige Gruppe hab. Ich suche nach einer
verstàndlichen Erklàrung der Unterschiede zum Topic. Denn ich bin
eigentlich der meinung das mit den heutigen Schnellen Prozessoren die
Techniken die damals schon im i386 Protected Mode existierten (z.b.
Datensegmente nicht ausführbar, Programmsegmente nicht beschreibbar)
viele Heute existierenden Probleme inexistent machen würden.

Nun hab ich in den 80'ern ein wenig Grundkenntnisse in 6502-Assembler an
einem COBOLD (von der Elrad/c't) mitbekommen und spàter nur wenig mit
x86-ASM zu tun gehabt. Leider nie beruflich. Aber ich habe viele in die
Tiefe gehende Literatur dazu gelesen. U.a. Tischers PC-Intern, Messmers
Hardware-Buch und vor allem von R.P. Nelson die Technische Referenz
80386/486 Handbuch für Programmierer.

So wie ich das aus dem Gelesenen Verstehe sind diese im Prozessor
eingebauten Schutzmechanismen irgendwann aus der Mode gekommen weil die
CPUs einfach noch zu langsam waren. D.h. es wurde dann der Effizienz
wegen keinen Gebrauch mehr gemacht dingen wie Getrennten
Speichersegmenten für Daten und Code (?), von den weiteren IOPL um OS,
Treiber und Userland zu trennen, den Descriptor-tabellen,
Task/Call/Interrupt-Gates u.a. Und ob die IO-Permission Bitmap noch
existiert ist mir auch nicht klar (und wodurch sie evtl. ersetzt wurde).

Es würde mir sicherlich zum Verstàndniss weiterhelfen wenn mir jemand der
sich darin auskennt mal schreiben könnte welche dieser CPU-Interna heute
noch genutzt werden oder wodurch sie ersetzt wurden und in welchen
Betriebsystemen wie Windows, Linux u.a.

Das DOS hier in weiten teilen raus fàllt ist schon klar (außer
Speichermanager u.à.) und OS/2 setzt m.e. zumindest noch einen großen
Teil dieser Funktionen ein.

Alternative wàre ein Link-Tip falls es eine Seite gibt die das etwas
detailierter erklàrt. Eine Assembler-für-dummies Seite suche ich
jedenfalls nicht. Es braucht aber nun auch keine Seite für Profis sein,
obwohl ich denke das ich sowas besser verstehen würde als die erstere.

Ich hoffe auf einen Freundlichen Poster der mir da auf die Sprünge helfen
kann.

Gruß
Kay
 

Lesen sie die antworten

#1 Stefan Reuther
20/03/2010 - 21:35 | Warnen spam
Tach,

k.martinen wrote:
(Wenn du mit Namen unterschreibst, kannst du den auch komplett ins
From-Feld eintragen :-)
Ich hoffe das ich hier die richtige Gruppe hab. Ich suche nach einer
verstàndlichen Erklàrung der Unterschiede zum Topic. Denn ich bin
eigentlich der meinung das mit den heutigen Schnellen Prozessoren die
Techniken die damals schon im i386 Protected Mode existierten (z.b.
Datensegmente nicht ausführbar, Programmsegmente nicht beschreibbar)
viele Heute existierenden Probleme inexistent machen würden.


[...]
So wie ich das aus dem Gelesenen Verstehe sind diese im Prozessor
eingebauten Schutzmechanismen irgendwann aus der Mode gekommen weil die
CPUs einfach noch zu langsam waren. D.h. es wurde dann der Effizienz
wegen keinen Gebrauch mehr gemacht dingen wie Getrennten
Speichersegmenten für Daten und Code (?)



Die Programmierer wollten Zeiger, mit denen man mehr als 64k am Stück
adressieren kann. Allerdings waren sie nicht gewillt, den Zusatzaufwand
mit den Segmentregistern zu treiben, was zum einen Code kostet, zum
anderen Zeit (die komplexen Rechteprüfungen gibt's nicht für lau).

Letztlich widerspricht das segmentierte Modell einfach den von anderen
Architekturen gewohnten Programmiermodellen. Ein dynamischer Lader geht
halt davon aus, eine Code-Adresse als Daten-Adresse uminterpretieren zu
können, um da die Adresse einer dynamisch geladenen Funktion nachzutragen.

Die Trennung zwischen Code- und Datensegment wird/wurde auch mal in
OpenBSD genutzt, um Speicherschutz durchzusetzen. Man mappt allen
ausführbaren Code an den Anfang des linearen Adressraums und definiert
ein entsprechend kurzes Code-Segment, das Datensegment ist dann größer
und enthàlt auch die Daten. Das klappt aber auch nicht immer.
Typischerweise besteht ein Adressraum heutzutage aus Code gefolgt von
Daten des Hauptprogramms, danach Code gefolgt von Daten von der ersten
DLL, danach Code gefolgt von Daten der zweiten DLL usw.

von den weiteren IOPL um OS, Treiber und Userland zu trennen,
den Descriptor-tabellen, Task/Call/Interrupt-Gates u.a.



Das wird schon noch genutzt, aber eben nur zur Trennung von
Betriebssystem und Userland.

Und ob die IO-Permission Bitmap noch existiert ist mir auch nicht
klar (und wodurch sie evtl. ersetzt wurde).



Die gibt es noch. Linux für i386 hat einen Systemaufruf (ioperm), mit
dem sich ein Programm Portzugriff freischalten kann.


Stefan

Ähnliche fragen