- Maestro ist ein Projekt, das ein leichtgewichtiges Unix-artiges Betriebssystem in Rust neu entwickeln will, das zugleich so Linux-kompatibel ist, dass es sich für den Alltagsgebrauch eignet
- Es begann 2018 als Schulprojekt und wurde anfangs in C implementiert, wechselte aber wegen Problemen bei der Pflege der Codebasis und wegen der Sicherheitsanforderungen der Kernel-Entwicklung zu Rust
- Derzeit handelt es sich um einen monolithischen Kernel für x86 32-Bit; von 437 Linux-Systemaufrufen sind 135 in gewissem Umfang implementiert, also etwa 31 %
- Parallel dazu werden das Boot-System und der Daemon-Manager Solfège, Systemwerkzeuge sowie der Paketmanager blimp entwickelt; außerdem funktionieren musl, bash und einige GNU coreutils
- Das Projekt befindet sich noch in einem sehr frühen Stadium und ist instabil; getestet wird vor allem mit QEMU, VMWare und VirtualBox, daher ist es sicherer, es nicht auf Rechnern mit wichtigen Daten zu installieren
Ziele und Ausgangspunkt von Maestro
- Maestro ist ein von Grund auf in Rust geschriebenes Unix-artiges Betriebssystem
- Ziel ist es, ein leichtgewichtiges System zu schaffen, das ausreichend Linux-kompatibel ist, um sich im Alltag verwenden zu lassen
- Es wurde gestartet, um eine Umgebung zu schaffen, in der man das System von A bis Z selbst verstehen und nach den eigenen Vorstellungen anpassen kann
Warum der Wechsel von C zu Rust?
- Der erste Commit wurde am 22. Dezember 2018 um 03:18 erstellt, und das Projekt begann als Schulaufgabe
- Die erste Implementierung wurde etwa anderthalb Jahre lang in C entwickelt, doch es wurde schwierig, die Codebasis sauber zu halten
- Vorteile des Neustarts mit Rust
- Das Projekt konnte auf Basis der aus früheren Fehlern gewonnenen Erkenntnisse von Grund auf neu entworfen werden
- Es eröffnete Raum für neue Ansätze, statt einfach nur einen Linux-ähnlichen Kernel in C neu zu schreiben
- Dank des Typsystems von Rust kann der Compiler einen Teil der Verantwortung für Speichersicherheit übernehmen, statt allein der Programmierer
Wo Rust bei der Kernel-Entwicklung Vorteile brachte
- Das Debugging in der Kernel-Entwicklung ist deutlich schwieriger als bei normalen Anwendungen
- Dokumentation ist schwer zu finden, und schon BIOS-Implementierungen selbst können fehlerhaft sein
- Beim Booten kann der Kernel auf den gesamten Speicher zugreifen und dadurch auch versehentlich an falsche Stellen wie den eigenen Code schreiben
- Werkzeuge wie valgrind lassen sich nicht zur Verfolgung von Speicherlecks einsetzen
- gdb kann mit QEMU und VMWare verwendet werden, aber das Verhalten des Kernels kann je nach Emulator oder virtueller Maschine unterschiedlich ausfallen
- Manche Umgebungen wie VirtualBox unterstützen kein gdb; auch die gdb-Unterstützung in QEMU und VMWare ist teilweise unvollständig, und gelegentlich stürzt gdb ab
- Um solche Probleme zu verringern, ist eine speichersichere Sprache auch für die Kernel-Entwicklung vorteilhaft
- Rust half dabei, mehrere Sicherheitsmechanismen in den Kernel einzubauen, und wird im Projekt als eine der besten Entscheidungen bewertet
Aktueller Implementierungsstand
- Maestro ist derzeit ein monolithischer Kernel und unterstützt nur die x86-32-Bit-Architektur
- Implementierungsstand zum Zeitpunkt des Schreibens
- Von 437 Linux-Systemaufrufen sind 135 in gewissem Umfang implementiert
- Implementierungsgrad der Systemaufrufe: {p:31}
- Über alle Repositories hinweg gibt es 615 Dateien und 48.800 Zeilen Code
- Die Zeilenzahl wurde mit dem Befehl
clocermittelt
- OS-Komponenten außerhalb des Kernels
- Solfège: ein in gewisser Weise systemd ähnliches, aber leichteres Boot-System und Daemon-Management
- maestro-utils: eine Sammlung von Systemwerkzeug-Befehlen
- blimp: Paketmanager
- Weitere Komponenten sind auf GitHub veröffentlicht
- Drittsoftware, deren Funktion bestätigt wurde
- musl C-Standardbibliothek
-
bash
- einige GNU-coreutils-Befehle wie
ls,cat,mkdir,rm,rmdir,uname,whoami - Das originale neofetch kennt Maestro nicht, daher wird eine gepatchte Version von neofetch benötigt
- einige GNU-coreutils-Befehle wie
Wie man es selbst testen kann und welche Einschränkungen es gibt
- Das OS befindet sich noch in einem sehr frühen Stadium und ist sehr instabil
- Von einer Installation auf Rechnern mit wichtigen Daten wird abgeraten
- Bisher wurde vor allem mit QEMU, VMWare und VirtualBox getestet
- Es gibt zwei Installationswege
- Download einer vorgefertigten komprimierten
.iso-Datei - ISO selbst bauen
- Download einer vorgefertigten komprimierten
- Das ISO enthält ein Installationsprogramm für das OS und kann in QEMU, VMWare, VirtualBox usw. ausgeführt werden
- Für das Ausführen des ISO wird ausreichend RAM benötigt; 1 GB genügen
- Der Grund ist, dass zu installierende Pakete im RAM des initramfs und nicht auf der Festplatte gespeichert werden
- Das OS kann derzeit USB-Sticks oder CD-ROMs nicht direkt lesen und ist daher auf den Bootloader angewiesen
Themen des Artikels
- Ziel ist es nicht, ein Tutorial zum Bau eines OS zu schreiben
- Als grundlegende Ressourcen zum OS-Bau werden osdev.org und Philipp Oppermann’s blog empfohlen
- Künftig sollen fortgeschrittenere Themen, Problemlösungsprozesse und die interne Funktionsweise von Computer, Betriebssystem und Internet behandelt werden
Weitere Entwicklungsrichtung
- Priorität haben die Bereinigung der Codebasis und die Leistungsoptimierung
- Da das Projekt als Schulprojekt begann, wurden teils Abkürzungen gewählt, um Termine einzuhalten; die angesammelten technischen Schulden müssen nun abgebaut werden
- Auch einige Speicherlecks müssen behoben werden, und Performance-Optimierung könnte Thema eigener Artikel werden
- Das nächste große Ziel ist, den Paketmanager vollständig auf dem OS lauffähig zu machen
- Dafür wird Netzwerkunterstützung benötigt, an der derzeit gearbeitet wird
- Außerdem wird Unterstützung für Shared Libraries benötigt
- Shared Libraries müssen Dateien direkt in den Speicher mappen, doch die aktuelle Implementierung des
mmap-Systemaufrufs im Kernel unterstützt das noch nicht
- Danach lassen sich Programme wie gcc/g++, clang, rustc, make, Git und Vim leichter installieren und testen
- Langfristig ist das Ziel ein Workflow, in dem der Kernel direkt auf Maestro entwickelt wird
Entwicklungsprozess zur Erhöhung des Reifegrads des Kernels
- Die Entwicklung verläuft so, dass Programme auf dem Kernel ausgeführt werden; wenn etwas nicht funktioniert, wird der verursachende Systemaufruf gesucht und implementiert oder korrigiert
- Ein Programm auf dem Kernel ausführen
- Falls es nicht funktioniert, anhand der Ausgabe der Systemaufrufe den ersten problematischen Systemaufruf finden
- Falls dieser Systemaufruf nicht implementiert ist oder einen Bug enthält, ihn implementieren oder korrigieren
- Das Programm erneut ausführen
- Je mehr Programme auf dem Kernel korrekt laufen, desto stabiler und ausgereifter wird er
1 Kommentare
Hacker-News-Meinungen
Vielen Dank für die Unterstützung; das bedeutet mir viel, weil ich sehr viel Arbeit in dieses Projekt gesteckt habe.
Die Website scheint im Moment ziemlich langsam oder offline zu sein; es gibt mehr Traffic als erwartet, und ich vermute auch einen DoS-Angriff.
Ich bin gerade bei der Arbeit und kann mich nicht sofort darum kümmern, aber wenn ich zu Hause bin, werde ich versuchen, sie wieder besser zum Laufen zu bringen.
2010, als es Rust noch nicht gab, habe ich kurz nach dem Uniabschluss ein bisschen an einem Unix-artigen Hobby-OS in C herumgebastelt; das hat wirklich Spaß gemacht.
Ich beneide dich darum, dass du die Zeit finden konntest, so weit zu kommen.
Die Navigationsleiste nimmt etwa 33 % des Bildschirms ein und lässt sich nicht entfernen.
Ich verstehe nicht, warum Leute so etwas fixieren und damit wertvollen Leseraum wegnehmen. Wenn man will, kann man in etwa 300 ms nach ganz oben scrollen.
Ein kleines, tolles Projekt. Es ist erstaunlich, dass es so weit bootet, obwohl nicht einmal ein Drittel der Systemaufrufe von Linux implementiert ist.
Allerdings sind die fehlenden Dinge vermutlich die komplexeren. Die TTY-Schicht zum Beispiel wirkt derzeit noch ziemlich rudimentär, und sie richtig umzusetzen dürfte viel Arbeit sein.
Deshalb fällt es schwer zu erwarten, dass Maestro innerhalb der nächsten drei Jahre Linux-Anwendungen ausführen wird. Das gilt selbst dann, wenn man die Tausenden von Treibern in Linux gar nicht berücksichtigt.
Auf reifen Plattformen sammelt sich Logik an, um viele Szenarien zu unterstützen, und deshalb braucht die Mehrheit nicht den Großteil des gesamten Systems.
Das ist ähnlich wie der Satz: „Niemand nutzt mehr als 10 % von Excel, aber die 10 %, die jeder nutzt, sind unterschiedlich.“
Wenn man nur 30 % der Excel-Funktionen implementiert, könnte man wahrscheinlich eine Engine bauen, die 99 % aller Tabellenkalkulationen da draußen öffnet. Wenn man allerdings vollständige Dokumentkompatibilität möchte, ist es bis dahin noch ein weiter Weg.
Manche Systemaufrufe werden nur in bestimmten Codepfaden aufgerufen oder sind neue Aufrufe, die nur nötig sind, wenn man auf einen neueren Kernel zielt.
Es gibt viele Systemaufrufe, und einige davon sind ziemlich obskur. Eine vollständig offene Ersatzimplementierung müsste am Ende wohl die meisten unterstützen, aber ein Drittel ist ein guter Anfang.
[1] Ich wollte die VM auf Bare Metal laufen lassen oder als VM booten, und abgesehen von etwa
init=/path/to/the/vmschien dies der Weg mit dem geringsten Aufwand dorthin zu sein. Aber dieser Ansatz gibt mir nicht das, was ich eigentlich will: Hardwaretreiber und den TCP-Stack innerhalb der VM-Sprache zu haben.Ich denke nicht, dass es Steam, LibreOffice und Firefox ausführen muss, um nützlich zu werden. Viele Komponenten einer typischen Server- oder Microservices-Architektur tun relativ einfache Dinge, und ein sicherer, einfacher Kernel könnte dafür ziemlich große Vorteile bringen.
Es gibt auch Kerla, einen monolithischen Kernel in Rust, der Linux-ABI-Kompatibilität zum Ziel hatte. Allerdings scheint er seit einigen Jahren inaktiv zu sein.
[1] https://news.ycombinator.com/item?id=28986229
Es ist als Mikrokernel entworfen und dürfte wahrscheinlich etwas ausgereifter sein. Da es unter der MIT-Lizenz steht, scheint auch Code-Sharing möglich zu sein.
Es wäre interessant, Security-/Penetration-Testing/Fuzzing zu betreiben, um zu sehen, „ob ein fähiger Hacker allein schon deshalb etwas finden kann, weil es in Rust geschrieben ist“.
Ich bin mir zu 100 % sicher, dass Fuzzing-Tests oder Penetration-Tests viele Probleme zutage fördern würden. Ich hatte bisher einfach noch keine Zeit, mich darum zu kümmern.
Das scheint etwas zu sein, das im inzwischen eingestellten Projekt Kerla bereits versucht wurde.
Klingt nach einem interessanten Projekt. Die Nachteile von C und die Schwierigkeiten der OS-Entwicklung sehe ich allerdings vor allem beim Debugging.
Durch den Wechsel zu Rust dürften bestimmte Arten von Speicherfehlern verschwunden sein, aber ist das Debugging immer noch schmerzhaft? Oder ist es im Vergleich zu früher weniger geworden und damit erträglich?
Debugging ist immer noch schmerzhaft, aber deutlich weniger als früher.
Zum Beispiel ist es nicht sehr wahrscheinlich, dass man vergisst, einen Mutex zu benutzen, weil der Compiler einen Fehler meldet.
Trotzdem ist es kein Allheilmittel, und Probleme wie Deadlocks gibt es weiterhin. Besonders dann, wenn Interrupts dazukommen.
Wenn man zum Beispiel einen Mutex sperrt und dann ein Interrupt auftritt, bleibt der Code, der diesen Mutex gesperrt hat, bis zum Ende des Interrupts angehalten. Wenn der Interrupt-Handler dann versucht, denselben Mutex zu sperren, entsteht ein Deadlock, und das Typsystem kann bei solchen Problemen nicht helfen.
Die Lösung besteht darin, die Interrupt-Verarbeitung zu deaktivieren, solange der Mutex gesperrt ist, aber der Compiler kann das nicht erzwingen.
Etwas off-topic, aber mir gefällt Gource, das der Autor im Beitragsvideo verwendet hat.
Ich hatte es vorher noch nie gesehen, hatte aber vor ein paar Jahren die Idee, etwas Ähnliches zu bauen. Offenbar gibt es doch keine völlig neuen Ideen.
Besonders zu Lernzwecken finde ich es wirklich gut, einen Kernel selbst zu bauen. Ich würde gern wissen, welche Ressourcen verwendet wurden, um den Kernel und das OS insgesamt zu verstehen.
Ich bin überrascht, dass Theseus OS nicht erwähnt wurde. Es ist ein in Arbeit befindliches OS, das von Grund auf in Rust geschrieben wird und die Speichersicherheitsgarantien des Rust-Compilers nutzt, um vieles automatisch bereitzustellen, was man bei einem klassischen OS vorsichtig verdrahten müsste.
Zum Beispiel ist es trotz einer Struktur mit einer einzigen Privilegstufe und einem einzigen Adressraum sicher. Alle Teile des OS sind hot-pluggable.
Der Nachteil ist, dass nativer Code vollständig in Rust geschrieben sein muss, aber letztes Jahr wurde eine WASM-Runtime implementiert. Ein Thread dazu von vor drei Jahren:
https://news.ycombinator.com/item?id=25741729
Ich hätte nicht gedacht, dass es jemanden gibt, der verrückt genug ist, sich das Projekt ft_penguin vorzunehmen. Ich bin mir nicht sicher, ob der Name noch stimmt, aber ehrlich: wirklich gut gemacht.
Als ich vor sieben Jahren an der Schule war, hielt ich es für eines der Projekte mit der schlechtesten Belohnung im Verhältnis zur nötigen Zeit.
Ich frage mich, ob du anfangs mit einem Freund zusammen angefangen hast und wie es vor der Neufassung in Rust war. Auch, ob du gleichzeitig noch andere Projekte gemacht hast.
Beim Blick in den Code kamen schöne Erinnerungen hoch, und jetzt bekomme ich Lust, meinen DevOps-Job aufzugeben und wieder Embedded oder andere Low-Level-Arbeit zu machen.