MotorOS: Ein Rust-basiertes Betriebssystem für x64-VMs

Einführung in Motūrus OS

• Das Motūrus-Projekt entwickelt MotūrusOS, ein einfaches, schnelles und sicheres Betriebssystem für die Cloud.
• Motūrus OS ist ein neues Betriebssystem, das auf Workloads in virtuellen Maschinen abzielt und für Webserver, Serverless und Edge-Caching genutzt werden kann.

Warum Motūrus OS?

• Derzeit laufen die meisten virtualisierten Produktions-Workloads unter Linux.
• Linux verfügt zwar über viele fortgeschrittene Funktionen, bringt aber auch einige Komplexitäten mit sich, die für virtualisierte Workloads nicht ideal sind:
  • Linux ist für Bare Metal optimiert und daher bei der Nutzung innerhalb einer VM ineffizient.
  • Linux ist schwierig zu verwenden.
  • Linux war historisch gesehen sehr unsicher.
• Ein neues Betriebssystem mit Fokus auf virtualisierte Workloads kann deutlich einfacher und sicherer als Linux gebaut werden und Linux bei Leistung oder Effizienz übertreffen oder zumindest erreichen.

Was ist Motūrus OS?

• Motūrus OS ist ein Microkernel-basiertes Betriebssystem, das in Rust entwickelt wurde und ausschließlich auf virtualisierte Workloads ausgerichtet ist.
• Es unterstützt derzeit x64-KVM-basierte virtuelle Maschinen und kann in Qemu oder Cloud Hypervisor ausgeführt werden.
• Rust ist die Kernsprache von Motūrus OS; nicht nur die Implementierung, sondern auch das ABI wird in Rust bereitgestellt.

Funktionen, die bereits arbeiten

• Die meisten Subsysteme laufen derzeit noch im POC/MVP-Modus, aber Aufgaben wie ein Webserver lassen sich bereits ausführen.
• Im Einzelnen funktionieren derzeit folgende Features:
  • Boot über MBR (Qemu) oder PVH (Cloud Hypervisor) in etwa 200 ms.
  • himem-Microkernel.
  • Scheduling: einfaches Multiprozessor-Round-Robin (SMP), das Kernel-Scheduling ist kooperativ.
  • Speicherverwaltung: derzeit nur 4K-Seiten, Stacks sind geschützt, Page Faults im Userspace werden korrekt behandelt.
  • I/O-Subsystem (im Userspace): VirtIO-BLK- und VirtIO-NET-Treiber, zwei einfache Dateisysteme, smoltcp-basiertes Networking (nur TCP unterstützt).
  • Userspace: mehrere Prozesse, Präemption, Threads, TLS, der Großteil der Rust-Standardbibliothek wurde portiert.
  • Eine einfache Unix-artige Shell ist vorhanden.

Funktionen, die noch nicht arbeiten

• Die meisten Teile sind noch nicht bereit für den produktiven Einsatz.
• Es gab noch kein Sicherheitsaudit.
• Im sys-io (Userspace-I/O-Subsystem) kann man leicht auf einen "not implemented"-Panic stoßen.
• Konkret funktionieren die folgenden Dinge noch nicht:
  • Dateisysteme: Der Großteil der Rust-std::fs-API wurde als POC implementiert, muss aber mit asynchronem I/O neu implementiert werden.
  • Networking: std::net::TcpStream ist größtenteils implementiert, andere Protokolle fehlen jedoch noch.
  • Ökosystem jenseits des Rust-Standards: Einige Crates lassen sich mit kleineren Anpassungen kompilieren und verwenden, Crates mit Abhängigkeit von asynchronen Runtimes wie Tokio lassen sich derzeit nicht kompilieren.

Wie kann man Motūrus OS bauen/ausführen?

• Siehe Dokument docs/build.md.

Danksagung

• Großer Dank an Philipp Oppermann, der die Blogserie über das Schreiben eines OS in Rust verfasst hat. Sie hat viele Menschen dazu inspiriert, in diesem Bereich zu experimentieren.

Meinung von GN⁺

• Innovativer Ansatz: Motūrus OS ist ein neues, auf virtualisierte Umgebungen spezialisiertes Betriebssystem, das die Komplexität und Ineffizienz von Linux lösen will.
• Einsatz von Rust: Rust ist eine Sprache mit starkem Fokus auf Speichersicherheit und Performance und dürfte zur Sicherheit und Effizienz von Motūrus OS beitragen.
• Beitrag für die Entwickler-Community: Das Projekt kann Entwicklern mit Interesse an Betriebssystementwicklung helfen, neue Möglichkeiten zu erkunden und bestehende Grenzen zu überwinden.

[ing03201]

Ich lese den Blog writing an os in rust auch, aber da tut sich ja schon jetzt etwas!
Scheint ein guter Artikel zu sein.

[GN⁺]

Hacker-News-Kommentare

• Meinung des Projektentwicklers/Autors:

  • Dank für das Interesse und die Diskussion über das Projekt.
  • Es gibt Bedenken hinsichtlich der langfristigen Überlebensfähigkeit und Unterstützung sowie der Compiler- und Binärkompatibilität.
  • Ohne Community kann das Projekt nicht erfolgreich sein, aber er glaubt, dass die potenziellen Vorteile eines Projekts wie Motor OS letztlich zu einem neuen, breit genutzten Betriebssystem führen werden.
  • Er weist auf Probleme von Linux innerhalb (und manchmal außerhalb) virtueller Maschinen hin und darauf, dass sich Linux-Entwickler nicht ausreichend darauf konzentrieren, diese zu lösen.
  • Er kann die Sorge über Compiler-Instabilität und Binärkompatibilität nicht nachvollziehen und erwähnt, dass sich aktuelle Linux-Kernel mit verschiedenen GCC- oder LLVM-Toolchains kompilieren lassen und auch ältere Binärdateien problemlos laufen.
  • Er erklärt, dass er bereit ist, weitere Fragen zu beantworten.

• Erklärung des "Rust-first"-Ansatzes:

  • "Rust-first" bedeutet, dass nicht nur der Microkernel und die Treiber in Rust implementiert sind, sondern dass derzeit auch User-Space-Programme nur in Rust geschrieben werden können.
  • Technisch ist es möglich, durch Reverse Engineering der Rust-basierten ABI und der bereitgestellten Rust-Toolchain Apps für Motor OS in anderen Sprachen wie C zu schreiben, aber das erfordert einen gewissen Arbeitsaufwand.
  • Es wird erklärt, dass gewöhnliche Rust-Programme die Standard-Rust-Bibliothek verwenden und sich ohne FFI kompilieren und ausführen lassen.

• Verwunderung darüber, warum ein kleiner Kernel auf moderner Hardware 200 ms benötigt:

  • Die Initialisierung von Metadaten für Speicherseiten, das Mounten des Dateisystems und das Starten des init-Prozesses seien notwendig, aber all das sollte seiner Ansicht nach in wenigen Mikrosekunden geschehen.
  • Es wird die Frage aufgeworfen, ob der Host Zeit benötigt, um Ressourcen vorzubereiten, etwa ob es in QEMU und KVM langsame Stellen gibt.

• Meinung, dass man gern einen Async-first-Kernel sehen würde, der in Rust geschrieben ist:

  • Es wird gefragt, ob ein Async-first-Kernel besonders schwierig ist oder keinen besonderen Wert bietet, oder ob man es einfach nur nicht versucht.
  • Es wird erwähnt, dass dies möglich sei, wenn man Phil Oppermanns OS-Serie in Rust folgt, aber dass neuere Rust-basierte Betriebssysteme das offenbar nicht versuchen.

• Meinung, die an frühere Aussagen von Linus Torvalds über Linux-Konkurrenz erinnert:

  • Es wird daran erinnert, dass Torvalds auf die Frage, ob er Konkurrenz fürchte, geantwortet habe, dass er gerne Gerätetreiber schreibe und Konkurrenz erst fürchte, wenn ein junger, leidenschaftlicher Mensch auftauche, der das ebenfalls gerne tue.

• Meinung, die Projekte wie Motor OS interessant findet und hofft, dass die Entwicklung fortgesetzt wird:

  • Es wird ausgedrückt, dass so viele Projekte wie Motor OS gescheitert seien, dass es schwer sei, noch begeistert zu sein.
  • Es wird erwähnt, dass es sehr schwierig sei, Linux für bestimmte Einsatzzwecke wie die Cloud zu ersetzen.

• Meinung, dass Docker, NixOS und "Serverless" wegen der Komplexität von Linux existieren:

  • Es wird erklärt, dass Docker und NixOS wegen Problemen der Paketverwaltung im User Space existieren, während Serverless daher komme, dass Unternehmen Rechenleistung entsprechend der Nachfrage bezahlen möchten.

• Meinung, die anfangs eine skeptische Haltung gegenüber neuer Technologie hatte, dann aber nach erneutem Nachdenken die durch das Entfernen unnötiger Schichten erreichbaren Effizienz- und Sicherheitsgewinne attraktiv findet:

  • Es wird eine gesunde Herangehensweise an neue Technologien beschrieben, und es wird anerkannt, dass die Effizienz- und Sicherheitsverbesserungen attraktiv sind.

• Meinung, dass Motor OS eher mit Docker usw. zu konkurrieren scheint:

  • Es wird darauf hingewiesen, dass Motor OS eher direkter mit Technologien wie Docker konkurriert als unmittelbar mit Linux.
  • Es wird der Wunsch geäußert, im Abschnitt "Warum?" zu behandeln, warum man sich für Motor OS statt für Docker usw. entscheiden sollte.

• Meinung, dass es nicht schwierig ist, ein neues Betriebssystem zu beginnen, aber sehr schwierig, es in den nächsten 50 Jahren zu unterstützen:

  • Es wird betont, dass das Schreiben eines neuen Betriebssystems nicht schwierig sei, seine langfristige Unterstützung jedoch äußerst schwierig.

[ahwjdekf]

Der Abschnitt „Nicht funktionierende Features“ ist wirklich ein starkes Stück. Ein Spielzeugprojekt.