- Maestro adalah proyek untuk membuat ulang sistem operasi keluarga Unix yang ringan dengan Rust, tetapi tetap kompatibel dengan Linux hingga cukup untuk penggunaan sehari-hari
- Dimulai pada 2018 sebagai proyek sekolah dan awalnya diimplementasikan dalam bahasa C, tetapi beralih ke Rust karena masalah pengelolaan codebase dan tuntutan keamanan dalam pengembangan kernel
- Saat ini berupa kernel monolitik untuk x86 32-bit, dengan 135 dari 437 system call Linux telah diimplementasikan sampai tingkat tertentu, atau sekitar 31%
- Proyek ini juga membuat sistem boot dan manajer daemon Solfège, utilitas sistem, serta manajer paket blimp; musl, bash, dan sebagian GNU coreutils juga sudah berjalan
- Karena masih berada pada tahap sangat awal dan belum stabil, pengujian terutama berfokus pada QEMU, VMWare, dan VirtualBox; lebih aman untuk tidak memasangnya di mesin yang berisi data penting
Tujuan dan titik awal Maestro
- Maestro adalah sistem operasi keluarga Unix yang ditulis dari awal dengan Rust
- Tujuannya adalah membuat sistem yang ringan dan cukup kompatibel dengan Linux hingga bisa digunakan sehari-hari
- Proyek ini dimulai untuk menciptakan lingkungan tempat seseorang bisa memahami sistem secara langsung dari A sampai Z dan menyesuaikannya sesuai keinginan
Alasan beralih dari C ke Rust
- Commit pertama dibuat pada 22 Desember 2018 pukul 03:18, dan proyek ini bermula sebagai tugas sekolah
- Implementasi awal berlangsung sekitar satu setengah tahun dalam bahasa C, tetapi menjaga codebase tetap bersih menjadi sulit
- Keuntungan yang diperoleh saat memulai ulang dengan Rust
- Proyek dapat dirancang ulang dari awal berdasarkan pelajaran dari kesalahan sebelumnya
- Bisa mencoba sesuatu yang lebih baru daripada sekadar menulis ulang kernel mirip Linux dalam C
- Berkat sistem tipe Rust, sebagian tanggung jawab atas keamanan memori dapat ditangani oleh compiler, bukan programmer
Bagian yang membuat Rust menguntungkan dalam pengembangan kernel
- Debugging dalam pengembangan kernel jauh lebih sulit dibanding aplikasi biasa
- Dokumentasi sulit ditemukan, dan implementasi BIOS itu sendiri bisa memiliki cacat
- Saat booting, kernel dapat mengakses seluruh memori, sehingga bisa menulis ke lokasi yang salah seperti kodenya sendiri
- Alat seperti valgrind tidak dapat digunakan untuk melacak kebocoran memori
- gdb dapat digunakan bersama QEMU dan VMWare, tetapi perilaku kernel bisa berbeda tergantung emulator atau mesin virtual
- Ada lingkungan seperti VirtualBox yang tidak mendukung gdb, sementara dukungan gdb di QEMU dan VMWare juga tidak lengkap, dan gdb terkadang crash
- Untuk mengurangi masalah semacam ini, bahasa yang aman dari sisi memori juga menguntungkan dalam pengembangan kernel
- Rust membantu memasukkan berbagai pengaman ke dalam kernel, dan dinilai sebagai keputusan terbaik dalam proyek ini
Status implementasi saat ini
- Maestro saat ini adalah kernel monolitik dan hanya mendukung arsitektur x86 32-bit
- Status implementasi pada saat penulisan
- 135 dari 437 system call Linux telah diimplementasikan sampai tingkat tertentu
- Tingkat implementasi system call: {p:31}
- Secara total di seluruh repositori terdapat 615 file dan 48.800 baris kode
- Jumlah baris dihitung dengan perintah
cloc
- Komponen OS selain kernel
- Solfège: sistem boot dan manajer daemon yang agak mirip systemd, tetapi lebih ringan
- maestro-utils: kumpulan perintah utilitas sistem
- blimp: manajer paket
- Komponen lainnya tersedia secara publik di GitHub
- Perangkat lunak pihak ketiga yang telah dipastikan berjalan
- Library standar C musl
-
bash
- Sebagian perintah GNU coreutils seperti
ls,cat,mkdir,rm,rmdir,uname,whoami - Karena neofetch asli tidak mengenali Maestro, diperlukan versi neofetch yang sudah dipatch
- Sebagian perintah GNU coreutils seperti
Cara menguji sendiri dan batasannya
- OS ini masih berada pada tahap sangat awal dan sangat tidak stabil
- Tidak disarankan memasangnya di mesin yang berisi data penting
- Sejauh ini terutama diuji di QEMU, VMWare, dan VirtualBox
- Ada dua cara instalasi
- Mengunduh file
.isoterkompresi yang sudah dibangun sebelumnya - Membangun ISO sendiri
- Mengunduh file
- ISO menyertakan installer OS dan dapat dijalankan di QEMU, VMWare, VirtualBox, dan sejenisnya
- Menjalankan ISO membutuhkan RAM yang cukup, dan 1GB sudah cukup
- Ini karena paket yang akan diinstal disimpan di RAM initramfs, bukan di disk
- Saat ini OS belum dapat membaca USB stick atau CD-ROM secara langsung, sehingga bergantung pada bootloader
Topik yang akan dibahas dalam tulisan
- Tujuannya bukan menulis tutorial pembuatan OS
- Untuk materi dasar pembuatan OS, osdev.org dan blog Philipp Oppermann direkomendasikan
- Ke depannya, tulisan akan membahas topik yang lebih lanjut, proses pemecahan masalah, serta cara kerja internal komputer, sistem operasi, dan internet
Arah pengembangan berikutnya
- Prioritasnya adalah merapikan codebase dan mengoptimalkan performa
- Karena dimulai sebagai proyek sekolah, ada bagian yang mengambil jalan pintas demi memenuhi jadwal, dan utang teknis yang menumpuk harus dibayar
- Beberapa kebocoran memori juga perlu diperbaiki, dan optimasi performa bisa menjadi topik tulisan
- Target besar berikutnya adalah membuat manajer paket berjalan sepenuhnya di atas OS ini
- Diperlukan dukungan jaringan, yang saat ini sedang dikembangkan
- Diperlukan dukungan shared library
- Shared library harus memetakan file langsung ke memori, tetapi implementasi system call
mmappada kernel saat ini belum mendukung hal itu
- Setelah itu, program seperti gcc/g++, clang, rustc, make, Git, dan Vim dapat dipasang dan diuji dengan lebih mudah
- Pada akhirnya, targetnya adalah alur pengembangan kernel langsung di atas Maestro
Prosedur pengembangan untuk meningkatkan kematangan kernel
- Pengembangan dilakukan dengan menjalankan program di kernel; jika tidak berjalan, cari system call penyebabnya lalu implementasikan atau perbaiki
- Jalankan program di kernel
- Jika tidak berjalan, lihat output system call dan cari system call pertama yang menimbulkan masalah
- Jika system call tersebut belum diimplementasikan atau memiliki bug, implementasikan atau perbaiki
- Jalankan kembali program
- Semakin banyak program yang berjalan dengan benar di kernel, kernel menjadi semakin stabil dan matang
1 komentar
Komentar Hacker News
Terima kasih banyak atas dukungannya, ini sangat berarti karena saya sudah mencurahkan banyak usaha untuk proyek ini
Saat ini situs web tampaknya cukup lambat atau sedang down, sepertinya trafiknya lebih besar dari yang saya perkirakan dan saya juga curiga ada serangan DoS
Sekarang saya masih di tempat kerja jadi sulit untuk langsung fokus, tapi setelah sampai rumah saya akan mencoba memperbaikinya agar berjalan lebih baik
Pada 2010, saat Rust belum ada, saya sempat sedikit mengutak-atik hobby OS bergaya Unix dengan C tepat setelah lulus kuliah, dan itu sangat menyenangkan
Saya iri kamu sempat punya waktu untuk bisa sampai sejauh ini
Bilah navigasinya memakan sekitar 33% layar dan tidak bisa dihilangkan
Saya tidak paham kenapa orang membuat hal seperti itu tetap fixed dan mengambil ruang baca yang berharga. Kalau mau ke atas, tinggal scroll saja sekitar 300ms
Proyek kecil yang keren. Mengejutkan bahwa sistem ini bisa boot sejauh ini padahal belum mengimplementasikan bahkan sepertiga system call Linux
Hanya saja, kemungkinan yang belum ada justru bagian yang lebih rumit. Misalnya, lapisan TTY sekarang tampaknya masih cukup dasar, dan sepertinya akan butuh banyak kerja agar benar-benar matang
Jadi saya sulit berharap Maestro bisa menjalankan aplikasi Linux dalam 3 tahun ke depan. Bahkan tanpa mempertimbangkan ribuan driver yang dimiliki Linux
Platform yang matang menumpuk logika untuk mendukung banyak skenario, sehingga kebanyakan pengguna atau sistem tidak benar-benar membutuhkan sebagian besar keseluruhannya
Ini mirip dengan ungkapan, “tidak ada yang memakai lebih dari 10% Excel, tapi 10% yang dipakai tiap orang berbeda-beda”
Jika hanya mengimplementasikan 30% fungsi Excel pun, kita mungkin bisa membuat engine yang dapat membuka 99% spreadsheet di dunia. Hanya saja, kalau ingin kompatibilitas dokumen penuh, jalannya masih panjang
Beberapa system call mungkin hanya dipanggil pada jalur kode tertentu, atau merupakan panggilan baru yang hanya dibutuhkan saat menargetkan kernel yang lebih baru
Jumlah system call memang banyak, dan sebagian di antaranya cukup aneh. Untuk implementasi pengganti yang benar-benar terbuka, pada akhirnya memang harus mendukung sebagian besar dari itu, tapi sepertiga tetap merupakan awal yang bagus
[1] Saya ingin menjalankan VM di bare metal atau boot sebagai VM, dan selain hal seperti
init=/path/to/the/vm, ini tampak seperti cara dengan usaha paling kecil untuk sampai ke sana. Namun pendekatan itu tidak memberi saya hal yang benar-benar saya inginkan, yaitu meletakkan driver perangkat keras dan stack TCP di dalam bahasa VM tersebutMenurut saya, agar berguna tidak harus sampai bisa menjalankan Steam, LibreOffice, atau Firefox. Banyak komponen dalam arsitektur server umum atau microservice melakukan hal yang relatif sederhana, dan tampaknya bisa mendapat manfaat besar dari kernel yang aman dan sederhana
Ada juga Kerla, kernel tunggal berbasis Rust yang menargetkan kompatibilitas ABI Linux. Hanya saja tampaknya proyek itu sudah dorman selama beberapa tahun
[1] https://news.ycombinator.com/item?id=28986229
Desainnya microkernel, dan mungkin sedikit lebih matang. Karena berlisensi MIT, tampaknya ada peluang untuk berbagi kode
Hanya karena dibuat dengan Rust, akan menarik kalau dilakukan pengujian keamanan/penetrasi/fuzzing untuk melihat apakah peretas yang andal bisa tetap menemukan sesuatu
Saya 100% yakin kalau dilakukan fuzzing test atau penetration test, akan muncul banyak masalah. Hanya saja saya belum punya waktu luang untuk itu
Sepertinya ini hal yang sudah pernah dicoba dalam proyek Kerla yang sekarang sudah dihentikan
Terdengar seperti proyek yang menarik. Hanya saja saya rasa kekurangan memakai C dan sulitnya pengembangan OS sebagian besar ada di sisi debugging
Dengan beralih ke Rust, jenis kesalahan memori tertentu mungkin hilang, tetapi apakah debugging masih tetap menyakitkan? Atau apakah sudah cukup berkurang sehingga lebih tertahankan dibanding sebelumnya?
Debugging masih menyakitkan, tapi jauh lebih ringan daripada dulu
Misalnya, kemungkinan lupa memakai mutex tidak besar. Kompiler akan memberi tahu sebagai error
Tapi ini juga bukan solusi ajaib; masalah seperti deadlock tetap ada. Terutama saat interrupt ikut terlibat
Misalnya, jika sebuah mutex sudah dikunci lalu terjadi interrupt, kode yang memegang mutex itu berhenti sampai interrupt selesai. Namun jika kode penanganan interrupt mencoba mengunci mutex yang sama, akan terjadi deadlock, dan sistem tipe tidak bisa membantu soal masalah seperti ini
Solusinya adalah menonaktifkan penanganan interrupt selama mutex terkunci, tapi kompiler tidak bisa memaksakan hal itu
Sedikit menyimpang, tapi saya suka Gource yang dipakai penulis dalam video kontribusinya
Saya belum pernah melihatnya sebelumnya, dan beberapa tahun lalu saya sempat punya ide membuat sesuatu yang mirip. Ternyata memang tidak ada ide yang benar-benar baru
Terutama untuk tujuan belajar, saya sangat suka ide membuat kernel sendiri. Saya penasaran referensi apa yang dipakai untuk memahami kernel dan OS secara umum
Agak mengejutkan Theseus OS tidak disebut. Ini OS yang sedang dikembangkan dan dibuat dari nol dengan Rust, serta memanfaatkan jaminan keamanan memori dari kompiler Rust untuk secara otomatis menyediakan banyak hal yang pada OS biasa harus dirangkai dengan sangat hati-hati
Misalnya, ia aman meskipun memakai arsitektur tingkat hak akses tunggal dan ruang alamat tunggal. Semua bagian OS bisa di-hotplug
Kekurangannya, semua kode native harus Rust, tapi tahun lalu sudah diimplementasikan runtime WASM. Thread terkait dari 3 tahun lalu:
https://news.ycombinator.com/item?id=25741729
Saya tidak menyangka ada orang yang cukup nekat untuk mengerjakan proyek ft_penguin. Saya tidak tahu apakah namanya masih itu, tapi sejujurnya ini benar-benar keren
Saat masih di sekolah 7 tahun lalu, saya menganggap ini salah satu proyek dengan imbal hasil terburuk dibanding waktu yang dibutuhkan
Saya penasaran apakah awalnya kamu memulainya bersama teman, seperti apa sebelum ditulis ulang ke Rust, dan apakah kamu juga mengerjakan proyek lain pada saat yang sama
Saat melihat kodenya, saya jadi teringat betapa menyenangkannya ini, dan sekarang malah ingin berhenti dari pekerjaan DevOps lalu kembali ke embedded atau pekerjaan tingkat rendah lain yang memang dulu ingin saya jalani