Viele Anwender würden es begrüßen, wenn das Multitasking-Betriebssystem MagiC (vormals Mag!X) nicht ins RAM geladen werden müßte, sondern auch als ROM-Version verfügbar wäre. Ein Vorteil liegt auf der Hand: Es stünde mehr RAM für andere Anwendungen zur Verfügung. Ein zweiter Vorteil eines Betriebssystems auf ROM-Basis wird oft übersehen: Die Betriebssicherheit ist höher, da der Programmcode nicht durch fehlerhafte Software zerstört werden kann.

Der Leser wird mir nachsehen, daß ich nun keinen Trick vorstellen werde, wie man MagiC ins ROM befördert. Aber immerhin ist es mit Hilfe der PMMU des 68030-Prozessors möglich, den gesamten Programmcode von MagiC gegen Veränderungen zu schützen. Besitzer eines ST oder STE bleiben dabei allerdings außen vor, denn einen 68030 findet man nur in TT und Falcon. Andererseits spricht nichts dagegen, dem ST durch eine PAK/3 Erweiterungskarte ebenfalls zu diesem Prozessor zu verhelfen.

Multitasking ist eine feine Sache. Vor allen Dingen dann, wenn man einmal in einer Multitasking-Umgebung gearbeitet hat, wird man sie kaum noch missen wollen. Befinden sich mehrere Programme gleichzeitig im Speicher, vergrößert sich allerdings auch das Risiko von Abstürzen. Dies trifft zumindest dann zu, wenn unsauber programmierte oder fehlerhafte Software zum Einsatz kommt.
Programmfehler sind natürlich nie ganz auszuschließen und Fehler, die in einer Multitasking-Umgebung auftreten, wirken sich unter Umständen nicht nur auf ein einziges, sondern gleich auf mehrere Programme aus. Es gibt jedoch Mechanismen, mit denen sich parallel laufende Prozesse gegeneinander absichern lassen. MultiTOS geht hier mit gutem Beispiel voran, indem es die Fähigkeit des 68030-Prozessors ausnutzt, Zugriffe eines Prozesses auf den Code eines anderen Programms zu unterbinden (Memory Protection, Speicherschutz). Leider wird ein solcher Mechanismus von MagiC nicht unterstützt.
Mit relativ wenig Aufwand ist es aber möglich, zumindest den Programmcode von MagiC gegen Schreibzugriffe anderer Prozesse abzusichern. Sollte dann ein Programmfehler dazu führen, daß ein Schreibzugriff auf das Betriebssystem (in diesem Fall MagiC) durchgeführt wird, schlägt diese Operation fehl und der Verursacher wird mit einem Busfehler (zwei Bomben) bestraft. Die Wirkung ist dieselbe, als wenn sich MagiC im ROM befinden würde. Auch bei Schreibzugriffen auf ein ROM wird nämlich ein Busfehler ausgelöst.

Wie schaut ein Schreibschutz per PMMU in der Praxis aus? Der Grundgedanke bei der Verwendung einer PMMU (Paged Memory Management Unit) ist, daß der Hauptspeicher in mehrere Kacheln (Pages) unterteilt wird. Diese Speicherkacheln sind bei TT und Falcon 32 KByte groß. (Wird eine virtuelle Speicherverwaltung wie VRAM oder OUTSIDE verwendet, sind auch Pages von 8 oder 16 Kbyte möglich.) Jeder Kachel sind gewisse Attribute zugeordnet, beispielsweise eine Information darüber, ob der Inhalt dieser Seite beschrieben oder lediglich gelesen werden darf. Im Normalfall finden diese Attribute jedoch keine Anwendung und die PMMU liegt fast vollständig brach.
Das hier vorgestellte Programm MAGTOROM sorgt nun dafür, daß die Kacheln, die den Programmcode von MagiC beinhalten, gegen Schreibzugriffe abgesichert werden. Dazu werden lediglich die Deskriptor-Tabellen für die PMMU, mit deren Hilfe die Segmentierung des Speichers in Kacheln erfolgt, entsprechend erweitert und modifiziert.
Wichtig ist in diesem Zusammenhang natürlich, daß ausschließlich der Speicherbereich geschützt wird, der den MagiC-Programmcode enthält. Nun endet aber der Code von MagiC nicht zwangsweise genau am Ende einer solchen Kachel und so ist die Wahrscheinlichkeit hoch, daß sich in der letzten Kachel, die von MagiC beansprucht wird, zusätzlicher Code eines weiteren Programms befindet. Es wäre wünschenswert, wenn MagiC von sich aus dafür sorgen könnte, daß es auf dem letzten Byte einer Kachel endet. Und man höre und staune: MagiC ist auf diesen Eingriff vorbereitet. Neben dem Bootprogramm MAGXBOOT existiert noch ein zweiter Booter mit dem Namen MAGXBO32. Wird dieses Programm zum Starten von MagiC verwendet, wird der soeben geforderte Idealzustand hergestellt und der gesamte Programmcode von MagiC läßt sich wirkungsvoll über die PMMU schützen.
Detaillierte Informationen zur Programmierung der PMMU entnimmt man am besten der Fachliteratur [1] sowie älteren Ausgaben der ST Computer (Anfang 1991).

Der Assembler-Quelltext zu MAGTOROM wurde für den Easy Rider Assembler entwickelt, dürfte sich aber ohne größere Änderungen auch für andere Assembler eignen. Wichtig ist, daß der verwendete Assembler 68030 Code erzeugen kann.
MAGTOROM verweigert die Installation, wenn im cookie jar bereits ein PMMU-cookie angelegt wurde, die PMMU also schon von einem anderen Programm verwendet wird [2]. Dies ist unter MagiC normalerweise nur dann der Fall, wenn eine der virtuellen Speichermanager VRAM oder OUTSIDE installiert ist. Besitzer von OUTSIDE kommen auch ohne MAGTOROM in den Genuß eines schreibgeschützten MagiC-Systems: Wird OUTSIDE unter MagiC gestartet, richtet der Speichermanager nämlich von sich aus automatisch einen Schreibschutz ein, wie er hier vorgestellt wurde. MAGTOROM ist also in diesem Fall von vornherein überflüssig. Auch beim Einsatz von OUTSIDE sollte aus den bereits angesprochenen Gründen der Booter MAGXBO32 verwendet werden.
Bei MAGTOROM handelt es sich um ein recht kurzes Programm. Daran läßt sich gut erkennen, daß sich durch die Programmierung der PMMU mit recht wenig Aufwand interessante Ergebnisse erzielen lassen. Schädliche Nebenwirkungen sind bei der Verwendung von MAGTOROM nicht zu erwarten. Bis auf die Tatsache, daß der MagiC-Programmcode nicht mehr modifiziert werden kann, hinterläßt MAGTOROM keine Spuren. Daher kann man jedem MagiC-Anwender die Benutzung von MAGTOROM uneingeschränkt empfehlen.

US

Listings:
magtorom.s*

Literatur:
[1] Steve Williams, "68030 Assembly Language Reference", Addison-Wesley Publishing Company, Inc.
[2] Alexander Herzlinger, "Von Speichern und Keksen", ST Magazin 4/92

* Anm.: Es gibt mittlerweile aktuellere Versionen von magtorom: http://www.seimet.de/

Kontakt Artikel-Archiv