Was sind mögliche Fallstricke, wenn ein minimaler Kernel verwalteten Code ausführt?

Angenommen, ich möchte ein Betriebssystem erstellen, das auf einem sehr kleinen nativen unteren Kernel basiert, der als Interpreter / Laufzeit für verwalteten Code fungiert, und auf einem größeren oberen Kernel, der in einer nicht-nativen Maschinensprache (Java-Bytecode, CIL usw.) kompiliert wurde. Beispiele für ähnliche Betriebssysteme wären Singularity und Cosmos .

Welche Fallstricke und Entwicklungsherausforderungen bestehen beim Schreiben eines Betriebssystems mit einer solchen Infrastruktur im Gegensatz zu einer rein nativen Lösung?

Abhängig von der Sprache kann es viele Entwicklungsherausforderungen geben:

1. Zeiger: Wenn eine Sprache keine Zeiger hat, ist es eine Herausforderung, relativ einfache Aufgaben zu erledigen. Beispielsweise können Sie Zeiger verwenden, um in den VGA-Speicher zu schreiben und auf dem Bildschirm zu drucken. In einer verwalteten Sprache benötigen Sie jedoch eine Art "Plug" (von C / C ++), um dasselbe zu tun.

2. Versammlung:Assemblierung Ein Betriebssystem benötigt immer eine Assemblierung. Sprachen wie C #, Java usw. funktionieren damit nicht so gut wie C / C ++. In C oder C ++ können Sie auch eine Inline-Assembly verwenden, die für viele Aufgaben sehr, sehr nützlich ist. Es gibt VIELE Fälle, in denen dies erforderlich ist (Beispiele in x86): Laden eines GDT, Laden eines IDT, Aktivieren von Paging, Einrichten von IRQs usw.

3. Kontrolle: Wenn Sie so etwas wie Cosmos verwenden, haben Sie nicht die volle Kontrolle. Cosmos ist ein Mikrokernel und "bootstrappt" im Wesentlichen Ihren "Kernel". Sie können so etwas wie Cosmos von Grund auf neu implementieren, wenn Sie es wirklich wollten. Dies kann jedoch sehr lange dauern.

4. Overhead: Bei verwalteten Sprachen ist der Overhead im Vergleich zu C oder sogar C ++ sehr hoch. Dinge wie Cosmos müssen viele Dinge implementieren, bevor selbst ein C # hello world-Kernel ausgeführt werden kann. In C können Sie loslegen, es ist kein richtiges Setup erforderlich. In C ++ müssen nur einige wenige Dinge implementiert werden, um einige der Funktionen von C ++ nutzen zu können.

5. Strukturen: In C / C ++ gibt es Strukturen, über die viele verwaltete Sprachen nicht verfügen. Daher müssten Sie eine Art Struktur implementieren. Wenn Sie beispielsweise eine IDT (Interrupt Descriptor Table) in C / C ++ laden möchten, können Sie eine Struktur (mit einem gepackten Attribut) erstellen und diese mit dem x86-ASM-Befehl lidt laden . In einer verwalteten Sprache ist dies viel schwieriger zu tun ...

Syntaxmäßig verwaltete Sprachen sind jedoch einfacher, da viele Dinge, die mit dem Betriebssystem zusammenhängen, oftmals nicht sehr gut geeignet sind. Das bedeutet nicht, dass sie nicht verwendet werden können, jedoch werden häufig C / C ++ empfohlen.

Ich habe gehört, dass (von einem Forscher, der an einem konkurrierenden Mikrokernel-Verfahren arbeitet ) behauptet wurde, dass nur sehr wenig darüber bekannt ist, wie die Sicherheit von Systemen bewertet werden kann, die durch verwalteten Code erweiterbar sind.

Das Problem ist, dass die Arten von Fehlern, die eine Sicherheitslücke verursachen könnten, sich stark von den Sicherheitsforschern unterscheiden, an die sie gewöhnt sind. In einem herkömmlichen Mikrokernel werden alle Treiber und andere Unterteile des Kernels voneinander isoliert, indem sie in verschiedenen Adressräumen ausgeführt werden. In einem Mikrokernel, in dem die Isolation durch verwalteten Code mit Typprüfung implementiert wird, vermeiden Sie den enormen Overhead beim Wechseln des Adressraums jedes Mal, wenn Sie einen Unterdienst verwenden müssen. Der Kompromiss besteht jedoch darin, dass die Bewertung des Isolationsmechanismus jetzt schwieriger ist.

Jeder bestimmte Teil des Kernels (z. B. ein Gerätetreiber), der in der verwalteten Sprache geschrieben ist, ist nur dann sicher, wenn die Typprüfung angibt, dass der Treiber sicher ist und die Typprüfung keine Fehler aufweist. Die Typprüfung ist also Teil des Kernels. In der Praxis scheinen die Typprüfer erheblich größer und komplizierter zu sein als herkömmliche Mikrokernkerne. Das bedeutet, dass die Angriffsfläche möglicherweise größer ist.

Ich weiß nicht, ob herkömmliche Mikrokernel-Isolationstechniken oder auf verwaltetem Code basierende Isolationstechniken wirklich mehr oder weniger zuverlässig sind. Hier liegt ein Bootstrapping-Problem vor: Solange keine Isolationstechniken für verwalteten Code weit verbreitet sind, wissen wir nicht, wie oft sie unsicher sind. Ohne zu wissen, wie unsicher sie sind, ist es jedoch schwierig, sie in sicherheitskritischen Situationen bereitzustellen.