Munal OS - WASM sandboxing uygulanan grafik tabanlı deneysel işletim sistemi

• Tamamen Rust ile geliştirilmiş, unikernel tasarımı ve WASM tabanlı sandboxing güvenlik modeli kullanan grafik tabanlı deneysel bir işletim sistemi
• EFI binary içinde çekirdek, WASM engine ve tüm uygulamalar gömülü; bu sayede minimal bir yapı ve benzersiz bir sistem çağrısı arayüzü sunuyor
• VirtIO tabanlı sürücüler üzerinden QEMU’da çalışıyor; giriş, ağ ve GPU yönetimi interrupt olmadan polling yöntemiyle uygulanmış
• Küresel event loop ve cooperative scheduling ile sadeleştirilmiş bir çalışma yapısı ve uygulama bazlı kaynak izleme desteği sağlıyor
• Kendi UI toolkit’i Uitk ile birlikte yerleşik uygulamalar (web browser, text editor, Python terminal) sunuyor; çeşitli dillerle WASM uygulaması geliştirmek mümkün

---

Munal OS nedir

• Munal OS, Rust ile tamamen geliştirilmiş deneysel bir işletim sistemi olup, unikernel tabanlı mimari ile WASM sandboxing’i birleştirerek yeni bir OS tasarımını keşfetmek için oluşturulmuş bir proje
• Karmaşıklığı azaltıp yalnızca temel bileşenleri kullanarak, modern araçlarla sadeleştirilmiş bir sistem yapısı gerçekleştirmeyi hedefliyor

Başlıca özellikler

• Tam grafik ortamı ve HD çözünürlük desteği; fare ve klavye arayüzü içeriyor
• Sandbox yöntemiyle uygulama çalıştırma, kullanıcı uygulamalarının çekirdek belleğine erişimini engelliyor
• Ağ sürücüsü ve kendi TCP stack’i yerleşik olarak geliyor
• Özelleştirilebilir UI toolkit (Uitk) içeriyor; çeşitli widget’lar, esnek yerleşim ve metin render etme desteği sunuyor
• Varsayılan uygulamalar: web browser (DNS, HTTPS, temel HTML desteği), text editor, Python terminal

Mimari

• EFI binary tabanlı yapı

  • Bootloader olmadan EFI binary biçiminde çalışıyor; çekirdek/WASM engine/uygulamalar tek bir dosyaya gömülü
  • UEFI boot servisleri mümkün olan en kısa sürede sonlandırılıyor, sistem saati dışında ek bir kullanım yok

• Adres alanı yönetimi

  • Sanal adres alanı kullanılmıyor, UEFI’nin bıraktığı identity-mapped adresler doğrudan kullanılıyor
  • Page table değişikliği yok. Çekirdek belleğinin doğrudan korunması WASM sandboxing ile tamamlanıyor

• Sürücüler ve donanım desteği

  • PS/2 veya VGA yerine, VirtIO 1.1 spesifikasyonunu kullanan PCI sürücüleri doğrudan uygulanmış
    • Klavye, fare, ağ ve GPU için sürücüler sağlanıyor
  • Interrupt kullanılmıyor, tüm sürücüler polling yöntemiyle tasarlanmış
  • QEMU dışındaki gerçek donanım üzerinde çalışma desteklenmiyor; gelecekte ek geliştirme gerekiyor

• Event loop ve scheduling

  • Multicore/interrupt desteği yok, tüm çalışma tek bir küresel event loop içinde doğrusal olarak yürütülüyor
    • Her döngüde ağ/giriş sürücüleri polling ile kontrol ediliyor, masaüstü UI ve uygulamalar çalıştırılıyor, GPU framebuffer güncelleniyor
  • Performans analizi kolay, her döngü çevrimi için zaman ölçümü yapılabiliyor
  • Uygulamaların CPU kullanımını doğrudan bırakması gerekiyor, uzun süren işler için açıkça kontrolü devretmeleri gerekli
  • Cooperative scheduling tabanlı olsa da, Wasmi engine’in fuel limit özelliği ile hatalı uygulamaları zorla durdurma desteği mümkün (henüz uygulanmadı)

Uygulama çalıştırma yapısı

• [Wasmi WASM engine] yerleşik; uygulama çalıştırılırken tam sandboxing ve çekirdekten yalıtım sağlıyor
• Çekirdek düzeyinde system call API sunuyor; uygulamalar fare/tuş olaylarını sorgulayabiliyor, TCP socket kullanabiliyor, framebuffer’a çıktı verebiliyor
• Uygulamaların render çıktısı OS tarafından masaüstünde birleştirilerek gösteriliyor
• Rust dışındaki dillerle de uygulama geliştirilebiliyor, yalnızca WASM build desteği olması yeterli
• WASI uyumluluğu kısmi düzeyde. Tam uyumlu değil; temel harici bağımlılıkların kullanılabilmesi için minimum uygulama içeriyor
• Uygulama başına özel bir log stream’i (stdout benzeri) bulunuyor; masaüstündeki ‘denetim’ görünümünde kaynak kullanımıyla birlikte görülebiliyor

UI toolkit (uitk)

• Hem Munal OS hem de WASM uygulamalarında kullanılan kendi immediate-mode UI kiti
• Temel widget’lar (button, progress bar, text edit, scroll canvas) ve üçgen rasterizer sunuyor
• Küresel stylesheet tabanlı tutarlı stil uygulaması, her öğe için override desteği
• Verimli caching sistemi ile gereksiz yeniden render işlemlerini önlüyor
  • Her alanı “tile” olarak ayırıyor, Rust mutability kurallarına dayalı bir değişiklik algılama algoritması kullanıyor

Build ve çalışma ortamı

• Rust Nightly 2025-06-01 ve QEMU 10.0.0 veya üzeri sürümlerde build edilip çalıştırılabiliyor

Başlıca referanslar ve katkılar

• Philipp Oppermann’ın Rust OS eğitimleri ve OSDev Wiki dokümantasyonu
• Wasmi, smoltcp, Rustls, RustPython gibi önemli open source projeler kullanılıyor
• Çeşitli open source yazı tipleri, ikonlar ve duvar kâğıdı kaynakları kullanılmış

Munal OS’in önemi ve avantajları

• Tek EFI binary yapısı ile yenilikçi sandboxing yaklaşımını birleştirerek, mevcut OS tasarım paradigmasını yeniden düşünmeye zorluyor
• QEMU ortamına optimize edilmiş ve kendine özgü polling tabanlı sürücü yapısı sayesinde gerçek sistem donanımına bağımlılığı en aza indiriyor
• Sistem kaynak yönetiminde şeffaflık sunuyor; sade yapısı nedeniyle öğrenme ve deneysel kullanım değeri yüksek
• Dil veya ortam kısıtı olmadan WASM uygulama ekosistemini genişletme potansiyeli taşıyor

[GN⁺]

Hacker News yorumu

• Her yinelemede ağ ve giriş sürücülerini polling ile kontrol etmesi, masaüstü arayüzünü çizmesi, etkin her WASM uygulamasını bir adım çalıştırması ve ardından GPU framebuffer'ını flush etmesi ilgimi çekti. Bunu Wasmi ile nasıl yaptığını merak edip kodu inceledim GitHub kod bağlantısı. En güncel Wasmi'de (v0.45+) fuel bittiğinde yield edebilmek için resumable function call desteğinin genişletildiğini belirtmek isterim Wasmi dokümantasyon bağlantısı. Zaten fuel metering kullanıldığı için, yürütme adımında daha verimli bir yöntem olabilir. Nasıl kullanılacağını görmek için Wasmi Wast runner örneğine bakılabilir

  • Wasmi'yi bir kez daha yaptığınız için teşekkürler. Fuel bittiğinde yield edebilme özelliği gerçekten çok ilginç. Eski belgelerde böyle bir özellik bulamamıştım; eğer olsaydı, WASM uygulamalarını tasarlama yönüm farklı olurdu
  • OP değilim ama bunun neden faydalı olduğunu tam anlayamadım. Bunun anlamı, bir fonksiyonla coroutine oluşturup başlattıktan sonra çalışma sırasında bellek yetersizliğinden hata verirse ek bellek sağlayıp coroutine'i tekrar resume edebilmek mi? Öyleyse mevcut davranıştan farkı nedir? WASM'da try/catch de yok mu? Hata durumunda malloc'u açıkça tekrar denemek gerekiyorsa, bunun ne kazandırdığı bana çok net gelmediği için kafam karıştı
  • Wasmi'nin GUI uygulamaları çalıştırabilecek kadar hızlı olması heyecan verici. Ben de taşınabilirliği ve aktarılabilirliği yüksek GUI uygulamaları yapmak için bir uygulama runtime'ı geliştiriyorum. Performans ve uygulama sadeliği arasında denge kurmak için wasm'i seçtim; hatta birkaç kişilik ya da tek kişilik bir ekibin runtime'ı nispeten hızlıca kurabilmesini umuyorum. Wasmi gibi optimize edilmiş, yorumlayıcı tabanlı bir wasm runtime'ının GUI uygulamalarını da sorunsuz çalıştırabildiğini görmek bana büyük bir potansiyel hissettiriyor

• Yapının VirtIO'ya dayandığını, bu yüzden Munal OS'nin henüz gerçek donanımda çalışmadığını belirtiyor; eğer gerçek donanımda çalıştırmak istenirse doğrudan sürücü eklemek yerine Linux'u bootloader olarak kullanıp işletim sistemini minimal bir hypervisor içinde çalıştırmanın da ilginç bir yaklaşım olacağını düşünüyor. Böylece "VirtIO platformdur" fikri korunabilir. Uygulama çalıştırmada WASM, platformda VirtIO seçimiyle kimliğini koruması güzel. Ancak güvenlik açısından MMU kullanımı gerekir. Tasarım olarak sanal belleği tamamen benimsemek zorunda olmayabilirsiniz ama koruma bitlerini kullanmak için sayfa tabloları ve TLB yönetimi gibi ek karmaşıklıklar gelir; bu da sadeliği bir miktar zayıflatır

  • Son Hackintosh denememde Linux'u bootloader ve minimal hypervisor olarak kullanarak benzer bir şey yaptım ve oldukça iyi sonuç aldı. Dezavantajı, gerçek GPU olayları olmadığı için Linux'un belirlediği çözünürlük ve ayarlara bağlı kalmanız; bu da esnekliği azaltıyor. Eğer bu OS gerçek bir OS yerine bir UEFI çalıştırılabilir dosyası olarak işleyebilseydi, yalnızca UEFI video sürücüleriyle de grafik mümkün olabilirdi; ama gerçek anlamda OS benzeri özellikler taşırken bunun ne kadar uygulanabilir olduğundan emin değilim

• Yineleme döngüsünün CPU'yu uzun süre meşgul etmemesi ve uzun işleri mutlaka açıkça yield etmesi gerekmesinden daha büyük sorun bence şu: ne kadar çok uygulama açarsanız her birinin işleme hızı o kadar düşer. Ben şahsen 10'dan fazla uygulamayı pek açmadım ama 30 sekmeye kadar çıktığım oldu; eğer her biri birer süreçse performans düşüşü belirgin olurdu. Donanım yeterince hızlıysa sorun olmayabilir ama örneğin video render alma gibi ağır işlemler 1 saniye yerine 30 saniye sürebilir; fark çok hissedilir. Buna rağmen tüm OS'yi bu şekilde inşa etmiş olması başlı başına çok zeki, gerçekten etkileyici ve heyecan verici bir deneme

  • Uygulamalar işleri gerektiği sürede bitirebiliyorsa, aslında yavaşlamak zorunda değiller. Çalıştırılır, işini bitirir ve bir sonraki frame'i bekler. Kaynaklar yetmez ve bekleme süresi sıfırın altına düşerse genel bir yavaşlama olur ama bu, karmaşık ve adil bir scheduler yerine daha az zarif bir yöntemdir. Her program, frame'ini hazırlamayı bitirdiğinde açıkça yield eder; dolayısıyla yapacak işi olmayan uygulamalar neredeyse hiç zaman harcamaz

• İşbirlikçi zamanlamanın yanı sıra Spectre saldırılarına karşı savunmanın da zor göründüğünü ve sanal bellek olmadan verim alınmasının mümkün olup olmadığını sorguluyorum. Örneğin WASM'da memory.grow işlenirken başka bir uygulamanın belleğine çarparsa her şeyi memmove ile taşımak gerekebilir; bunun gerçekten uygulanabilir olup olmadığını merak ediyorum. Yine de gerçekten etkileyici bir proje

  • Eğer Spectre bir saldırı vektörü olarak görülüyorsa, burada tam olarak hangi tehdit modelinin varsayıldığını sormak isterim. Mevcut yapıda tüm uygulamalar doğrudan kernel'e derlenmiş durumda ve web tarayıcısı da JavaScript çalıştırmıyor; dolayısıyla güvenilmeyen kodun sisteme girebileceği bir yol varmış gibi görünmüyor
  • Daha detaylı açıklama rica ederim

• wasm component'ler hayata geçtiğinde bu tür denemelerin nasıl değişeceğini merak ediyorum. unikernel tasarımını takdir ediyorum ve Munal OS'nin zengin özellikleri de etkileyici. wasm'in yalnızca tek bir büyük uygulama için değil, çok sayıda küçük süreç ve alt ortam barındırmak için de kullanılmasını umuyorum. wasi preview3 ile senkron/asenkron bir arada kullanım yakında mümkün olacak gibi görünüyor; böylece wasm, genel amaçlı bir runtime'ın gereken parçalarını tamamlamış olacak. Hâlâ host object bridging'in büyük ölçüde JS merkezli kalması üzücü ama wasm component'lerin vaat ettiği şeylerin — standart, hafiflik, sandbox, diller arası birleşebilirlik — sadece tek bir dağıtım formatı olarak değil, gerçek bir runtime yeteneği olarak pratikte karşılık bulmasını umuyorum. Şu konuşmaya da bakılabilir What is a Component (and Why)

  • Bu konudan bahsederken acaba şu videoyu mu kastetmiştiniz YouTube bağlantısı
  • SDL3 destekleyen ve gömülü V8 ile script yazılabilen bir Rust uygulaması yapmaya başladım blog tanıtımı. Ama asıl ciddi olarak düşündüğüm şey, bunu fork edip wasmtime ya da wasmi gömerek herhangi bir dille script yazılabilir hale getirmek. Hatta derleyicileri de gömüp yalnızca bir dosya vererek doğrudan script çalıştırılabilen bir yapı kurulabilir. Çünkü wasmtime ve wasmi, diğer script motorlarından daha hızlı karşılaştırma verileri. Tek rahatsız edici tarafı, tüm kod ortamını kurmak gerektiği için script olmanın getirdiği giriş kolaylığının azalması. Yine de fikir çok havalı; bir ara denemek isterim

• “The Birth and Death of Javascript” Pycon 2014 konuşmasında asm.js'nin (bugünkü wasm'in öncülü) OS sandbox'ı oluşturmak için kullanılacağı bir gelecekten bahsediliyordu; bu fikir bu projenin tasarım çekirdeğine oldukça benziyor, acaba bir etkisi oldu mu diye merak ediyorum konuşma bağlantısı

  • Bana kalırsa daha çok Microsoft'un araştırma amaçlı OS'si Midori'den etkilenmiş olma ihtimali yüksek Midori tanıtımı

• Bu OS'nin kendi web tarayıcısını bile içermesi şaşırtıcı web tarayıcı kaynağı. Demo videosunda Hacker News'i render ettiğini de görebilirsiniz

  • Web tarayıcılarına JS, CSS vb. özellikler dolmadan önce böyle küçük tarayıcılarla minimum bağımlılıkla web görüntülenebiliyordu; ama bugün bu yüzden web'in büyük kısmını anlamlı biçimde görüntülemek neredeyse mümkün değil, bu da üzücü. İçerik odaklı web ile uygulama odaklı web'i daha net ayırmamız gerektiğini düşünüyorum. İçerik web'i için çok basit bir HTTP istemcisi ve HTML parser yeterli; web uygulamaları içinse, bu OS'deki gibi wasm tabanlı bir yapı ve az sayıda donanım API'si yeterli olabilir. Yalnız UDP desteği şart

• Çok etkileyici; acaba bu yapı işletim sistemlerinin geleceği olabilir mi diye düşündürüyor. README de oldukça ilginç. Wasmi yerine neden wasmtime seçilmediğini merak ediyorum. Bu OS'yi ben de bir VM içinde denemek isterim; hatta GUI kütüphanemi Munal'a port etme hevesim bile var

  • wasmtime'ı no_std modunda derlemek çok uğraştırıcı olduğu için sonunda wasmi'yi seçtiğime dair benzer bir deneyim paylaşabilirim
  • Modern OS yapılarının geleceği konuşulurken SPECTRE ve MELTDOWN'un araya girmesiyle ilgili espri yapıyor
  • Uygulama izolasyonunun sanallaştırmayla sağlanması açısından, Qubes OS'de benzer bir geleceği şimdiden yaşadığımızı da söyleyebilirim. Orada uygulama izolasyonu çok daha kesin biçimde sağlanıyor

• Xerox PARC döneminden bu yana "userspace'i bytecode'a dönüştürme" girişimleri hep tekrarlandı ve piyasada gerçekten başarılı sayılabilecek örneklerin IBM i, ChromeOS ve Android ile sınırlı olduğunu düşünüyorum. Yine de bu proje çok havalı; umarım başarılı olur

  • WebAssembly ile ilgili her başlıkta eski bytecode VM'lerden söz etmeniz artık bir kalıp gibi geliyor. Her seferinde aynı tonda benzer bir değerlendirme yapıyorsunuz; oysa geliştirici topluluklarında farklı denemeler ve yeni yaklaşımlar kaçınılmazdır. Temel örüntü tanımalarının ötesinde, daha ayrıntılı görüşlerinizi duymayı isterim
  • Bu kavramın avantajları çok açık olduğu için, sağlam bir standart haline gelene kadar yeni denemelerin tekrar tekrar ortaya çıkması kaçınılmaz. wasm de bunu gerçekten hedeflemesi bakımından JVM vb. yapılardan belirgin şekilde ayrılıyor
  • ChromeOS sadece bir tarayıcı olduğu için tesadüfen V8 kullanıyor, Android ise ne kullansa başarılı olurdu diye düşünüyorum. Bu iki OS'nin başarısının nedeni teknoloji değil, fiyattı

• İstemci OS tasarımı başlı başına şaşırtıcı. Böyle bir yapının sunucu tarafında da hemen pratik karşılığı olabilir gibi geliyor. Kernel'i çok küçük tutup çalışan tek uygulamayı bırakmak, gereksiz güvenlik sınırlarını azaltabilir. Örneğin bir key/value store bu yapıya iyi uyabilir. Merak ettiğim şey şu: bu IO modeliyle ağ performansı iyi oluyor mu, ayrıca WASM host ederken gereksiz bellek kopyalarını azaltmak için özel teknikler uygulanabilir mi?