Thema: Process Emulation

[osDeveloper93]

Hallo,

ich will in meinem Betriebssystem einen Process Emulator einbauen.

Was ich mir darunter vorstelle ist, dass die Processe/Programme nicht mehr direkt als Maschinencode in den Arbeitsspeicher "gemappt" werden,
sondern das ein Interpreter (oder so was ähnliches) "dazwischen geschaltet" wird.
Dadurch kann der User keine befehle wie lgdt benutzen, sondern nur die befehle die ich erlaube (mov, add, ...).

Ich weiß dass es schwierig ist,
jedoch frage ich mich ob sowas sinnvoll ist?

Arbeitsspeicherschutz gibt es ja halbwegs schon (zB. Paging).
Jedoch keinen Schutz vor unerlaubten Befehlen (soweit es mir bekannt ist).

Also die Fragen:

• Ist sowas sinnvoll?
• Wird mein Betriebssystem dadurch langsamer (Das es ein bisschen langsamer wird weiß ich selbst, jedoch kann es zB. eine kurze zeit einfrieren)?
• Kann man meine Idee noch verbessern?

Ich hoffe ihr habt verstanden was ich meine.

Mit freundlichen Grüßen
osDeveloper93

[kevin]

Ganz so dilettantisch ist Intel dann doch nicht rangegangen.

lgdt und ähnliches ist nur in Ring 0 erlaubt, in Ring 3 gibt es einen GPF.

[osDeveloper93]

Das ist gut.

Dann brauch ich dieses Ding nicht mehr.

Wo kann man es herausfinden, was erlaubt ist und was nicht (Ring 3)?

[MNemo]

AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions

• Kapitel 3 listet die Allzweck Instuktionen auf, die überall erlaubt sind
• Kapitel 4 listet die System-Instructions auf die nur in RING 0 ausgeführt werden dürfen.

[DaCodaaa]

Ein Prozess Emulator hat aber trotzdem noch einen Vorteil:

man kann Programme von anderen Systemem mit ein bisschen trixerei auch auf seinem eigenen Betriebssystem einfacher zum laufen bringen, oder sehe ich das falsch?

Gruss DaCodaaa

[Cjreek]

Ein Prozess Emulator hat aber trotzdem noch einen Vorteil:

man kann Programme von anderen Systemem mit ein bisschen trixerei auch auf seinem eigenen Betriebssystem einfacher zum laufen bringen, oder sehe ich das falsch?

Gruss DaCodaaa

Ich glaube du siehst das falsch. Hauptproblem ist ja dass jedes OS seine eigene API hat. Und daran ändert so ein Emulator auch nichts.

[osDeveloper93]

Stimmt,

jedoch wenn das Betriebssystem mehrere Architekturen unterstützt, kann sowas von Vorteil sein.
Auch wenn man sowas auch anders machen kann.

[kevin]

Naja, wenn ich Programme einer anderen Plattform laufen lassen will, dann portiere ich "einfach" qemu. Da arbeiten nämlich schon ein paar Leute ein paar Jahre lang dran, das mit halbwegs akzeptabler Geschwindigkeit hinzubekommen.

[osDeveloper93]

Stimmt,

aber QEMU ist ein externes Programm.
Und ich finde dass es schon ein unterschied ist wenn das Betriebssystem sowas anbietet, als das du dir es manuel besorgen musst.
Außerdem emuliert QEMU doch ein ganzes PC ohne Betriebssystem.

[stultus]

Wenn du Programme für andere OS laufen lassen willst, schau dir an wie WINE (http://winehq.org/) das macht.

Wenn du auch Architekturgrenzen überwenden oder Befehle sperren willst, wäre ne Art JIT-Compiler eher der passende Weg - ist aber noch deutlich mehr Entwicklungsaufwand, und erfordert natürlich auch Bibliotheken um irgendwas zu machen

In beiden Fällen wäre eine Integration innen Kernel aber eher doof - bringt dir keinerlei Vorteile (jedenfalls keine die ich mir denken kann), nur mehr Risiken was Abstürze und Sicherheit anbelangt. Und auch wenns ne Anwendung ist, kanns ja ein Teil des Betriebssystems sein

[osDeveloper93]

Ins Kern soll es ja garnicht.
Es soll ein Modul sein.