M
Wieso glauben viele, man würde nur durch die Nutzung von Assembler die absolute Kontrolle haben? In EXE-Dateien ist ja auch nichts anderes als nativer Code enthalten. Du hast ja selbst bei 8085-Prozessoren die Möglichkeit, ein übergeordnetes Betriebssystem zu schreiben, das in der Lage ist, den normalen Programmfluss zu unterbrechen (Mit Interrupts eben). Dort könnte man allerdings ohne Probleme diese aufgerufene Systemroutine mit eigenem Code überschreiben.
Auf heutigen Systemen ist das aber nicht mehr möglich, da dank virtuellem Speicher der Zugriff auf Speicher anderer Prozesse oder des Kernels nicht möglich ist. Eine Manipulation der Register bringt nur den eigenen Prozess "in Gefahr", da das Betriebssystem für jeden Thread die Register gesichert hat und vor dem Beginn der Ausführung wiederherstellt.
Außerdem sind bestimmte Opcodes innerhalb eines unprivilegierten Prozesses ebenfalls nicht ausführbar, da sie das gesamte System beeinflussen könnten. (Zum Beispiel IN und OUT zur direkten Ausgabe auf einem Hardwareport). Der Prozessor übergibt in dem Fall die Kontrolle an das Betriebssystem, welches den entsprechenden Prozess beendet.
Wenn man ein Programm(Treiber) im Kernel Mode ausführt, gelten diese Beschränkungen nicht, weil dort kaum Maßnahmen zur gegenseitigen Kontrolle vorgesehen sind. Was man dort anstellt, wirkt sich also aufs gesamte System aus. Grobes Missverhalten kann unter Umständen erkannt werden, worauf das System mit einem Blauen Bildschirm reagiert, es kann aber auch einfach zum Einfrieren oder sonstigen Abstrusitäten führen.
Bei frühen Multithreading-Implementierungen war das System übrigens nicht in der Lage, einen laufenden Prozess zu unterbrechen, sondern er musste explizit die Kontrolle zurückgeben. Das mag aus Sicht des Prozesses sicherer sein, da er selbst bestimmen kann, wann er anderen Prozessen die Ausführung gestattet, wenn er einen kleinen Teil seiner Arbeit beendet hat, aber er kann damit natürlich auch das System blockieren oder die Systemleistung negativ beeinträchtigen.
