Munal OS - Sistem operasi eksperimental berbasis grafis dengan sandboxing WASM

• Sistem operasi eksperimental berbasis grafis yang sepenuhnya diimplementasikan dengan Rust, menggunakan desain unikernel dan model keamanan sandboxing berbasis WASM
• Kernel, mesin WASM, dan semua aplikasi tertanam di dalam biner EFI sehingga menyediakan struktur yang diminimalkan dan antarmuka system call yang unik
• Berjalan di QEMU melalui driver berbasis VirtIO, dengan pengelolaan input, jaringan, dan GPU yang diimplementasikan dengan metode polling tanpa interupsi
• Mendukung struktur operasi yang disederhanakan dan pemantauan sumber daya per aplikasi melalui event loop global dan penjadwalan kooperatif
• Menyediakan UI toolkit Uitk sendiri serta aplikasi bawaan (peramban web, editor teks, terminal Python), dan memungkinkan pengembangan aplikasi WASM dalam berbagai bahasa

---

Apa itu Munal OS

• Munal OS adalah sistem operasi eksperimental yang dikembangkan sepenuhnya dengan Rust, sebuah proyek yang dibuat untuk mengeksplorasi desain OS baru dengan menggabungkan arsitektur berbasis unikernel dan sandboxing WASM
• Tujuannya adalah mewujudkan struktur sistem yang disederhanakan dengan alat modern, dengan mengurangi kompleksitas dan hanya menerapkan elemen-elemen esensial

Fitur utama

• Mendukung lingkungan grafis penuh dan resolusi HD, serta dilengkapi antarmuka mouse dan keyboard
• Menjalankan aplikasi dalam mode sandbox, memblokir akses aplikasi pengguna ke memori kernel
• Memiliki driver jaringan dan stack TCP sendiri bawaan
• Menyertakan UI toolkit yang dapat dikustomisasi (Uitk), dengan berbagai widget, layout fleksibel, dan dukungan rendering teks
• Aplikasi bawaan: peramban web (mendukung DNS, HTTPS, HTML dasar), editor teks, terminal Python

Arsitektur

• Struktur berbasis biner EFI

  • Berjalan dalam bentuk biner EFI tanpa bootloader, dengan kernel/mesin WASM/aplikasi tertanam dalam satu file
  • Layanan boot UEFI dihentikan secepat mungkin dan tidak dimanfaatkan lebih lanjut selain untuk jam sistem

• Manajemen ruang alamat

  • Tidak menggunakan ruang alamat virtual, melainkan langsung memakai alamat identity-mapped yang ditinggalkan UEFI
  • Tidak ada perubahan page table. Perlindungan langsung memori kernel dilengkapi melalui sandboxing WASM

• Driver dan dukungan perangkat keras

  • Alih-alih PS/2 atau VGA, Munal OS mengimplementasikan langsung driver PCI yang memanfaatkan spesifikasi VirtIO 1.1
    • Menyediakan driver untuk keyboard, mouse, jaringan, dan GPU
  • Tidak menggunakan interupsi, semua driver dirancang dengan metode polling
  • Menjalankan pada perangkat keras fisik selain QEMU belum didukung dan memerlukan pengembangan tambahan di masa depan

• Event loop dan penjadwalan

  • Tidak mendukung multicore/interupsi, seluruh operasi dieksekusi secara linear dalam satu event loop global
    • Pada setiap loop dilakukan polling driver jaringan/input, eksekusi UI desktop dan aplikasi, serta pembaruan framebuffer GPU
  • Mudah untuk analisis performa, karena waktu dapat diukur pada setiap siklus loop
  • Aplikasi harus melepaskan penggunaan CPU secara langsung, dan pekerjaan jangka panjang harus secara eksplisit melakukan yield
  • Berbasis penjadwalan kooperatif, tetapi penghentian paksa aplikasi yang bermasalah dimungkinkan melalui fitur fuel limit di mesin Wasmi (belum diimplementasikan)

Struktur eksekusi aplikasi

• Menyertakan [Wasmi WASM engine], yang saat menjalankan aplikasi memberikan sandboxing penuh dan pemisahan dari kernel
• Menyediakan API system call di tingkat kernel, sehingga aplikasi dapat mengambil event mouse/keyboard, menggunakan socket TCP, menulis ke framebuffer, dan sebagainya
• Hasil rendering aplikasi dikomposisikan oleh OS lalu ditampilkan di desktop
• Aplikasi juga dapat dibuat dengan bahasa selain Rust, selama mendukung build WASM maka tidak ada batasan penggunaan
• Kompatibilitas WASI didukung sebagian. Tidak sepenuhnya patuh, hanya mencakup implementasi minimum untuk memanfaatkan dependensi eksternal utama
• Tersedia stream log khusus per aplikasi (mirip stdout), yang dapat dilihat bersama penggunaan sumber daya di tampilan 'audit' pada desktop

UI toolkit (uitk)

• UI kit immediate-mode buatan sendiri yang digunakan baik oleh Munal OS maupun aplikasi WASM
• Menyediakan widget dasar (tombol, progress bar, text edit, scroll canvas) serta rasterizer segitiga
• Styling terpadu berbasis stylesheet global, dengan dukungan override per elemen
• Sistem caching yang efisien untuk mencegah re-rendering yang tidak perlu
  • Membagi tiap area menjadi “tile”, dengan algoritme deteksi perubahan berbasis aturan mutability Rust

Lingkungan build dan eksekusi

• Dapat di-build dan dijalankan pada Rust Nightly 2025-06-01 dan QEMU 10.0.0 atau lebih baru

Referensi utama dan kredit

• Tutorial Rust OS dari Philipp Oppermann dan dokumentasi OSDev Wiki
• Memanfaatkan berbagai open source utama seperti Wasmi, smoltcp, Rustls, RustPython, dan lainnya
• Menggunakan berbagai font, ikon, dan materi wallpaper open source

Makna dan keunggulan Munal OS

• Menggabungkan struktur biner EFI tunggal dan sandboxing yang inovatif untuk meninjau kembali paradigma desain OS yang ada
• Dioptimalkan untuk lingkungan QEMU dengan struktur driver berbasis polling yang unik, sehingga meminimalkan ketergantungan pada perangkat keras sistem nyata
• Menawarkan transparansi pengelolaan sumber daya sistem, dengan nilai pembelajaran dan eksperimen yang tinggi dari struktur yang sederhana
• Memiliki potensi besar untuk memperluas ekosistem aplikasi WASM tanpa batasan bahasa maupun lingkungan

[GN⁺]

Opini Hacker News

• Menarik melihat strukturnya: di setiap iterasi, sistem melakukan polling jaringan dan driver input, menggambar antarmuka desktop, menjalankan satu langkah untuk tiap aplikasi WASM yang aktif, lalu melakukan flush ke framebuffer GPU. Saya penasaran bagaimana ini diimplementasikan dengan Wasmi, jadi saya mencari kodenya tautan kode GitHub. Saya juga ingin memberi tahu bahwa di Wasmi terbaru (v0.45+), dukungan pemanggilan fungsi yang bisa dilanjutkan telah diperluas sehingga bisa melakukan yield saat fuel habis tautan dokumentasi Wasmi. Karena sudah memakai fuel metering, ini bisa menjadi cara yang lebih efisien pada tahap eksekusi. Contoh penggunaannya bisa dilihat di contoh runner Wasmi Wast

  • Sekali lagi terima kasih sudah membuat Wasmi. Kabar tentang fitur yield saat fuel Wasmi habis benar-benar menarik. Saya dulu sempat kecewa karena tidak menemukan fitur seperti ini di dokumentasi lama; kalau saja sudah ada, arah desain aplikasi WASM saya mungkin akan berbeda
  • Saya bukan OP, tapi saya kurang paham kenapa fitur ini membantu. Apakah maksudnya Anda bisa membuat coroutine dari sebuah fungsi, menjalankannya, lalu kalau gagal di tengah jalan karena kehabisan memori, Anda bisa memberi memori tambahan dan me-resume coroutine itu? Kalau begitu, apa bedanya dengan perilaku yang sudah ada? Apakah WASM juga tidak punya try/catch? Kalau pada akhirnya harus secara eksplisit mencoba malloc lagi setelah gagal, saya bingung apa keuntungan nyatanya
  • Saya senang melihat Wasmi cukup cepat untuk menjalankan aplikasi GUI. Saya sedang mengembangkan app runtime untuk membuat aplikasi GUI yang portabel dan mudah dipindahkan. Saya memilih wasm demi keseimbangan antara performa dan kesederhanaan implementasi, dan saya berharap runtime seperti itu bisa dibangun dengan cepat oleh tim kecil, atau bahkan satu orang. Fakta bahwa runtime wasm berbasis interpreter yang dioptimalkan seperti Wasmi bisa menjalankan aplikasi GUI tanpa masalah memberi saya banyak harapan

• Karena bergantung pada VirtIO, disebutkan bahwa Munal OS masih belum bisa berjalan di perangkat keras nyata. Jika ingin dijalankan di perangkat keras nyata, menurut saya pendekatan yang menarik adalah memakai Linux sebagai bootloader dan menjalankan OS ini di atas hypervisor minimal, alih-alih menambahkan driver sendiri. Dengan begitu, konsep “VirtIO adalah platform” bisa tetap dipertahankan. Memilih WASM untuk menjalankan aplikasi dan VirtIO untuk platform membuat identitasnya terasa konsisten. Namun dari sudut pandang keamanan, penggunaan MMU tetap diperlukan. Secara desain mungkin tidak harus sampai memperkenalkan memori virtual, tetapi untuk memakai bit proteksi tetap muncul kompleksitas tambahan seperti page table dan pengelolaan TLB, sehingga kesederhanaannya sedikit berkurang

  • Pada percobaan Hackintosh terakhir saya, saya sempat menjalankannya dengan cara serupa, memakai Linux sebagai bootloader sekaligus hypervisor minimal, dan hasilnya cukup baik. Kekurangannya, tanpa event GPU nyata, semuanya jadi terkunci pada resolusi dan pengaturan yang dipilih Linux, sehingga kebebasannya terbatas. Kalau OS ini bisa bekerja sebagai executable UEFI alih-alih OS “sungguhan”, mungkin grafisnya bisa ditangani hanya dengan driver video UEFI, tetapi saya tidak yakin apakah itu masih bisa dicoba sambil tetap memiliki fitur yang layak disebut OS

• Menurut saya, kelemahan yang lebih besar daripada fakta bahwa loop iterasi tidak boleh terlalu lama memonopoli CPU dan pekerjaan panjang harus secara eksplisit melakukan yield, adalah bahwa semakin banyak aplikasi yang dibuka, semakin lambat pemrosesan tiap aplikasi. Saya sendiri hampir tidak pernah membuka lebih dari 10 aplikasi sekaligus, tetapi berdasarkan pengalaman pernah membuka 30 tab, kalau masing-masing adalah proses terpisah, penurunan performanya akan sangat terasa. Kalau hardwarenya cukup cepat mungkin tidak masalah, tetapi untuk pekerjaan berat seperti render video misalnya, waktu bisa melambat dari 1 detik menjadi 30 detik, dan itu akan sangat terasa. Meski begitu, fakta bahwa seluruh OS dibuat seperti ini tetap sangat cerdas, luar biasa, dan mengasyikkan

  • Selama aplikasi menyelesaikan pekerjaannya tepat waktu, tidak ada alasan harus menjadi lambat. Jalankan, selesai, lalu tunggu frame berikutnya. Kalau sumber daya kurang dan waktu tunggu turun ke 0 atau kurang, semuanya memang jadi melambat, tetapi ini sekadar pendekatan yang kurang elegan dibanding scheduler adil yang kompleks. Tiap program dibuat untuk secara eksplisit melakukan yield setelah frame-nya siap, jadi aplikasi yang tidak punya pekerjaan hampir tidak memakai waktu

• Selain cooperative scheduling, pertahanan terhadap serangan Spectre juga tampak sulit, dan saya ragu efisiensinya bisa bagus tanpa memori virtual. Misalnya saat menangani memory.grow di WASM, kalau memori aplikasi lain menghalangi, mungkin bisa muncul situasi di mana seluruh blok harus di-memmove; saya penasaran apakah itu benar-benar memungkinkan. Meski begitu, ini tetap proyek yang sangat mengesankan

  • Kalau Spectre dianggap sebagai vektor serangan, pertanyaannya adalah: model ancaman seperti apa yang diasumsikan? Dalam struktur saat ini, semua aplikasi dikompilasi langsung ke kernel dan browser web pun tidak menjalankan JavaScript, jadi tampaknya tidak ada jalur masuk untuk kode yang tidak tepercaya
  • Mohon penjelasan lebih rinci

• Saya penasaran bagaimana eksperimen seperti ini akan berubah ketika komponen wasm benar-benar terwujud. Saya sangat menghargai desain unikernel, dan Munal OS juga mengesankan karena punya banyak fungsi. Saya berharap wasm tidak hanya dipakai untuk satu aplikasi besar, tetapi juga untuk menampung banyak proses kecil dan sub-lingkungan. Di wasi preview3, kemungkinan koeksistensi sinkron/asinkron tampaknya akan segera terbuka, dan pada titik itu wasm akan memiliki semua elemen runtime serbaguna. Saya masih menyayangkan kenyataan bahwa bridging host object masih terlalu terpusat pada JS, tetapi saya berharap janji komponen wasm—standar, ringan, sandbox, dan komposisi lintas bahasa—bisa benar-benar terlihat di dunia nyata sebagai kemampuan runtime, bukan sekadar format distribusi tunggal. Lihat juga talk berikut What is a Component (and Why)

  • Waktu membahas topik ini, apakah yang Anda maksud sebenarnya video ini tautan YouTube?
  • Saya mulai membuat aplikasi Rust yang mendukung SDL3 dan menyematkan V8 untuk scripting perkenalan blog. Tapi yang benar-benar saya pertimbangkan adalah mem-fork ini dan menyematkan wasmtime atau wasmi agar scripting bisa dilakukan dengan bahasa apa pun. Saya bahkan bisa menyematkan kompiler juga, jadi cukup memberi file dan langsung bisa discrpting. Ini karena wasmtime dan wasmi lebih cepat daripada engine scripting lain data perbandingan. Hanya saja yang merepotkan adalah seluruh environment kode harus disiapkan dulu, jadi keunggulan masuk sebagai “script” jadi agak lemah. Meski begitu, idenya sendiri terlalu keren untuk tidak dicoba setidaknya sekali

• Saya pernah melihat bagian dalam talk PyCon 2014 “The Birth and Death of Javascript” yang memperkenalkan masa depan di mana sandbox OS dibangun dengan asm.js (pendahulu wasm saat ini), dan rasanya sangat mirip dengan inti desain proyek ini, jadi saya penasaran apakah itu menjadi pengaruh tautan talk

  • Saya justru merasa kemungkinan pengaruh yang lebih besar datang dari Midori, OS riset milik Microsoft pengenalan Midori

• Saya terkejut karena OS ini bahkan menyertakan browser web sendiri sumber browser web. Di video demo juga terlihat browser itu merender Hacker News

  • Sebelum browser web dibanjiri fitur seperti JS dan CSS, browser sekecil ini masih bisa dipakai melihat web dengan dependensi minimal, tetapi sekarang justru sebagian besar web tidak lagi bisa dilihat secara bermakna. Menurut saya, web yang berfokus pada konten dan web yang berfokus pada aplikasi perlu dipisahkan lebih jelas. Web konten hanya butuh klien HTTP yang sangat sederhana dan parser HTML, sedangkan web app, seperti OS ini, cukup dengan basis wasm plus segelintir API hardware. Hanya saja, dukungan UDP wajib ada

• Saya merasa takjub, sekaligus bertanya-tanya apakah struktur seperti ini bisa menjadi masa depan OS. README-nya sendiri juga sangat menarik. Saya penasaran kenapa memilih wasmi alih-alih wasmtime. Saya juga ingin mencoba OS ini sendiri di VM, dan tergoda untuk mem-porting library GUI saya ke Munal

  • Saya berbagi pengalaman bahwa membangun wasmtime dalam mode no_std terlalu merepotkan, jadi akhirnya saya memilih wasmi
  • Menambahkan lelucon bahwa setiap pembicaraan tentang masa depan struktur OS modern selalu disusupi SPECTRE dan MELTDOWN
  • Menyebut bahwa masa depan serupa sebenarnya sudah dialami di Qubes OS, dalam arti isolasi aplikasi dilakukan lewat virtualisasi. Di sana isolasi aplikasinya benar-benar kuat

• Sejak era Xerox PARC, upaya untuk “mengubah userspace menjadi bytecode” terus berulang, dan menurut saya contoh yang benar-benar sukses di pasar hanya IBM i, ChromeOS, dan Android. Meski begitu, proyek ini keren dan saya harap berhasil

  • Rasanya setiap thread tentang WebAssembly selalu ada orang yang mengulang cerita tentang VM bytecode lama, dan sekarang itu sudah terasa seperti pola. Penilaian dengan nada yang sama terus diulang, padahal di komunitas pengembang sangat wajar kalau muncul banyak eksperimen dan pendekatan baru. Saya ingin mendengar pendapat yang lebih rinci, bukan sekadar pengenalan pola yang mendasar
  • Konsep seperti ini memang punya kelebihan yang sangat jelas, jadi sampai benar-benar mapan sebagai standar, percobaan baru akan terus bermunculan. Dalam hal itu wasm jelas sangat berbeda dari JVM dan sejenisnya, karena memang itulah yang dituju
  • ChromeOS kebetulan memakai V8 hanya karena pada dasarnya ia adalah browser, dan saya rasa Android akan tetap sukses memakai apa pun. Faktor keberhasilan kedua OS itu bukan teknologinya, melainkan harganya

• Desain OS kliennya sendiri sudah mengejutkan. Struktur seperti ini juga tampak langsung praktis untuk server. Kalau kernel dibuat sangat kecil dan hanya menyisakan satu aplikasi yang berjalan, batas keamanan yang tidak perlu bisa dikurangi. Misalnya key/value store akan cocok untuk struktur seperti ini. Yang saya penasaran, apakah model IO seperti ini bisa memberi performa jaringan yang baik, dan apakah ada teknik khusus yang bisa dipakai saat meng-host WASM untuk mengurangi penyalinan memori yang tidak perlu