Munal OS - WASM सैंडबॉक्सिंग के साथ ग्राफिक्स-आधारित प्रयोगात्मक ऑपरेटिंग सिस्टम

• Rust में पूरी तरह इम्प्लीमेंट किया गया एक ग्राफिक्स-आधारित प्रयोगात्मक ऑपरेटिंग सिस्टम, जो unikernel डिज़ाइन और WASM-आधारित सैंडबॉक्सिंग सुरक्षा मॉडल का उपयोग करता है
• EFI बाइनरी में kernel, WASM engine और सभी apps एम्बेडेड हैं, जिससे मिनिमल संरचना और एक अनोखा system call interface मिलता है
• VirtIO-आधारित drivers के जरिए QEMU में चलता है, और input, network तथा GPU प्रबंधन interrupts के बिना polling तरीके से इम्प्लीमेंट किया गया है
• ग्लोबल event loop और cooperative scheduling के जरिए सरल ऑपरेशन संरचना और app-विशिष्ट resource monitoring की सुविधा देता है
• अपना UI toolkit Uitk और built-in apps (web browser, text editor, Python terminal) प्रदान करता है, और कई भाषाओं में WASM apps विकसित किए जा सकते हैं

---

Munal OS क्या है

• Munal OS, Rust में पूरी तरह विकसित एक प्रयोगात्मक ऑपरेटिंग सिस्टम है, जिसे unikernel-आधारित architecture और WASM sandboxing को मिलाकर नई OS डिज़ाइन संभावनाओं को परखने के लिए बनाया गया प्रोजेक्ट है
• इसका लक्ष्य जटिलता कम करना, केवल आवश्यक तत्व अपनाना, और आधुनिक tools के साथ एक सरल सिस्टम संरचना हासिल करना है

मुख्य विशेषताएँ

• फुल ग्राफिकल environment और HD resolution सपोर्ट, mouse और keyboard interface सहित
• sandbox तरीके से app execution, जिससे user applications को kernel memory तक पहुंच से रोका जाता है
• network drivers और अपना TCP stack built-in
• customizable UI toolkit (Uitk) शामिल, जिसमें विभिन्न widgets, flexible layout और text rendering सपोर्ट है
• built-in apps: web browser (DNS, HTTPS, basic HTML support), text editor, Python terminal

Architecture

• EFI binary-आधारित संरचना

  • bootloader के बिना EFI binary के रूप में चलता है, जिसमें kernel/WASM engine/apps एक ही file में एम्बेडेड हैं
  • UEFI boot services को बहुत जल्दी बंद कर दिया जाता है, और system clock के अलावा उनका अतिरिक्त उपयोग नहीं होता

• Address space management

  • virtual address space का उपयोग नहीं, UEFI द्वारा छोड़े गए identity-mapped addresses को वैसे ही उपयोग किया जाता है
  • page tables में कोई बदलाव नहीं। kernel memory की प्रत्यक्ष सुरक्षा WASM sandboxing से पूरी की जाती है

• Drivers और hardware support

  • PS/2 या VGA के बजाय, VirtIO 1.1 specification का उपयोग करने वाले PCI drivers सीधे इम्प्लीमेंट किए गए हैं
    • keyboard, mouse, network, GPU के लिए drivers उपलब्ध
  • interrupts का उपयोग नहीं, सभी drivers polling तरीके से डिज़ाइन किए गए हैं
  • QEMU के अलावा वास्तविक hardware पर चलाने का समर्थन नहीं, आगे अतिरिक्त विकास की आवश्यकता

• Event loop और scheduling

  • multicore/interrupt support नहीं, पूरा सिस्टम एक single global event loop में रैखिक रूप से चलता है
    • हर loop में network/input drivers को poll किया जाता है, desktop UI और apps चलाए जाते हैं, और GPU framebuffer अपडेट होता है
  • performance analysis आसान, हर loop cycle का समय मापा जा सकता है
  • apps को खुद CPU छोड़ना पड़ता है, लंबी चलने वाली tasks को स्पष्ट रूप से yield करना होता है
  • cooperative scheduling पर आधारित, लेकिन Wasmi engine की fuel limit feature के जरिए खराब apps को forcefully terminate करने का समर्थन संभव है (अभी इम्प्लीमेंट नहीं)

Application execution structure

• [Wasmi WASM engine] built-in है, जो app execution के दौरान पूर्ण sandboxing और kernel isolation देता है
• kernel स्तर पर system call API उपलब्ध है, जिससे apps mouse/key events पढ़ सकते हैं, TCP sockets उपयोग कर सकते हैं, framebuffer पर आउटपुट दे सकते हैं
• apps के rendering results को OS desktop पर compose करके दिखाता है
• Rust के अलावा अन्य भाषाओं में भी apps बनाए जा सकते हैं, बस WASM build सपोर्ट होना चाहिए
• WASI compatibility आंशिक रूप से समर्थित है। यह पूर्ण अनुरूपता नहीं देता, केवल मुख्य external dependencies के उपयोग के लिए न्यूनतम इम्प्लीमेंटेशन शामिल है
• app-विशिष्ट dedicated log stream (stdout जैसा) उपलब्ध है, जिसे desktop के ‘audit’ view में resource usage के साथ देखा जा सकता है

UI toolkit (uitk)

• Munal OS और WASM apps दोनों में उपयोग होने वाला इसका अपना immediate-mode UI kit
• basic widgets (button, progress bar, text edit, scroll canvas) और triangle rasterizer प्रदान करता है
• global stylesheet आधारित एकसमान styling, साथ ही individual elements के लिए override सपोर्ट
• efficient caching system के जरिए अनावश्यक re-rendering को रोकता है
  • हर क्षेत्र को “tiles” में बांटा जाता है, और Rust mutability rules पर आधारित change-detection algorithm का उपयोग होता है

Build और runtime environment

• Rust Nightly 2025-06-01 और QEMU 10.0.0 या उससे ऊपर पर build और run किया जा सकता है

मुख्य संदर्भ सामग्री और credits

• Philipp Oppermann के Rust OS tutorial और OSDev Wiki दस्तावेज़
• Wasmi, smoltcp, Rustls, RustPython जैसे प्रमुख open source प्रोजेक्ट्स का उपयोग
• विभिन्न open source fonts, icons और wallpaper resources का उपयोग

Munal OS का महत्व और फायदे

• single EFI binary संरचना और नवोन्मेषी sandboxing के संयोजन से पारंपरिक OS डिज़ाइन प्रतिमानों पर पुनर्विचार
• QEMU environment के लिए optimized और अनोखी polling-आधारित driver संरचना, जिससे वास्तविक system hardware पर निर्भरता कम होती है
• system resource management में पारदर्शिता, और सरल संरचना से मिलने वाला सीखने व प्रयोग का बड़ा मूल्य
• भाषा या environment की पाबंदी के बिना WASM app ecosystem के विस्तार की बड़ी संभावना

[GN⁺]

Hacker News की राय

• हर iteration में network और input drivers को poll करना, desktop interface draw करना, हर active WASM application को एक step चलाना, फिर GPU framebuffer को flush करना—यह संरचना मुझे काफ़ी दिलचस्प लगी। यह Wasmi में कैसे implement किया गया है, यह जानने के लिए मैंने code ढूँढा GitHub code link. मैं यह बताना चाहता हूँ कि नए Wasmi(v0.45+) में resume होने वाले function calls को इस तरह बढ़ाया गया है कि fuel खत्म होने पर yield किया जा सके Wasmi docs link. आप पहले से fuel metering इस्तेमाल कर रहे हैं, इसलिए execution step में यह ज़्यादा efficient तरीका हो सकता है। इसका उपयोग उदाहरण Wasmi Wast runner example में देखा जा सकता है

  • एक बार फिर Wasmi बनाने के लिए धन्यवाद। Wasmi में fuel खत्म होने पर yield करने की सुविधा की खबर सचमुच बहुत दिलचस्प है। पुराने docs में मुझे ऐसा feature नहीं मिला था, और अगर यह तब होता, तो शायद WASM apps के design की दिशा अलग होती
  • मैं OP नहीं हूँ, लेकिन मुझे ठीक से समझ नहीं आ रहा कि यह feature मददगार क्यों है। क्या इसका मतलब यह है कि function से coroutine बनाकर उसे शुरू करें, और अगर execution के दौरान memory कम पड़ने से fail हो जाए, तो extra memory देकर उस coroutine को फिर resume किया जा सकता है? अगर ऐसा है, तो यह पहले के behavior से अलग कैसे है? क्या WASM में try/catch नहीं है? अगर failed state में malloc को explicitly फिर से retry करना पड़े, तो इससे वास्तव में क्या फ़र्क पड़ता है, यह मुझे साफ़ नहीं लग रहा
  • मुझे यह देखकर उत्साह हो रहा है कि Wasmi GUI apps चलाने लायक तेज़ है। मैं portable और highly transferable GUI apps बनाने के लिए एक app runtime बना रहा हूँ। performance और implementation simplicity के balance के लिए मैंने wasm चुना है, और मेरी उम्मीद है कि practically एक छोटी team, या शायद एक व्यक्ति, runtime को जल्दी खड़ा कर सके। यह तथ्य कि Wasmi जैसा optimized interpreter-based wasm runtime GUI apps भी बिना मुश्किल चला सकता है, मुझे काफ़ी संभावनाएँ दिखाता है

• चूँकि इसकी संरचना VirtIO पर निर्भर है, इसलिए Munal OS अभी असली hardware पर नहीं चलता—यह बात कही गई। अगर इसे real hardware पर चलाना हो, तो सीधे drivers जोड़ने के बजाय Linux को bootloader की तरह इस्तेमाल करके minimal hypervisor में OS चलाने की strategy भी एक मज़ेदार approach हो सकती है। ऐसा करने पर "VirtIO ही platform है" वाला concept बना रह सकता है। app execution के लिए WASM और platform के लिए VirtIO चुनने वाली यह पहचान काफ़ी शानदार है। लेकिन security के नज़रिए से MMU का इस्तेमाल ज़रूरी होगा। design के हिसाब से virtual memory तक जाना अनिवार्य नहीं है, लेकिन protection bits के लिए page tables और TLB management जैसी extra complexity आ जाएगी, जिससे simplicity कुछ कमज़ोर पड़ती है

  • आख़िरी बार जब मैंने hackintosh पर कोशिश की थी, तब Linux को bootloader और minimal hypervisor की तरह इस्तेमाल करके कुछ ऐसा ही चलाया था, और नतीजा ठीक-ठाक था। कमी यह थी कि Linux ने जो resolution और settings तय कर दीं, वही fixed रहीं, क्योंकि असली GPU events नहीं थे, इसलिए flexibility सीमित थी। अगर यह OS सचमुच OS न होकर UEFI executable की तरह चल सके, तो शायद सिर्फ UEFI video drivers से भी graphics संभव हो, लेकिन क्या इस तरह OS-जैसी functionality के साथ इसे करना संभव है, इस बारे में मुझे यक़ीन नहीं है

• मुझे लगता है कि इससे भी बड़ा नुकसान यह नहीं है कि repeat loop ज़्यादा देर CPU पर कब्ज़ा नहीं कर सकता और long-running work को ज़रूर explicitly yield करना होगा, बल्कि यह है कि जितने ज़्यादा apps खोलेंगे, हर app उतना धीमा होगा। मैंने खुद 10 से ज़्यादा apps शायद ही कभी खोले हों, लेकिन 30 tabs तक खोलने के अनुभव से कह सकता हूँ कि अगर हर एक process हो, तो performance drop साफ़ दिखेगा। अगर hardware काफ़ी तेज़ हो तो समस्या नहीं होगी, लेकिन उदाहरण के लिए video rendering जैसी भारी processing 1 second से 30 seconds तक धीमी हो सकती है—यह बहुत बड़ा अंतर है। फिर भी, पूरे OS को इस तरह implement करना अपने-आप में बहुत clever, शानदार और रोमांचक कोशिश है

  • अगर apps अपना काम समय पर पूरा कर दें, तो उन्हें बिल्कुल भी धीमा होने की ज़रूरत नहीं है। वे चलती हैं, खत्म करती हैं, और फिर अगले frame का इंतज़ार करती हैं। जब resources कम पड़ते हैं और wait time 0 से नीचे चला जाता है, तभी सब कुछ समग्र रूप से धीमा पड़ता है, लेकिन यह किसी complex fair scheduler की तुलना में कम elegant तरीका है। हर program में यह संरचना है कि frame तैयार होते ही वह explicitly yield कर दे, इसलिए जिन apps के पास करने के लिए कुछ नहीं है, वे लगभग समय नहीं लेतीं

• cooperative scheduling के अलावा Spectre attacks से बचाव भी मुश्किल दिखता है, और virtual memory के बिना efficiency मिलेगी या नहीं, इस पर भी संदेह है। उदाहरण के लिए, WASM में memory.grow handle करते समय अगर दूसरी app memory रास्ते में आ जाए, तो पूरी चीज़ memmove करनी पड़ सकती है—क्या यह सच में संभव है? फिर भी, यह सचमुच बहुत प्रभावशाली project है

  • अगर Spectre attack vector है, तो ठीक-ठीक कौन-सा threat model माना गया है? मौजूदा संरचना में तो सभी apps सीधे kernel में compile होती हैं, और web browser भी JavaScript execute नहीं करता, इसलिए untrusted code के आने का रास्ता ही नहीं दिखता
  • कृपया थोड़ा विस्तार से समझाइए

• जब wasm components पूरी तरह वास्तविकता बनेंगे, तब ऐसी कोशिशें कैसे बदलेंगी, यह जानने की उत्सुकता है। मुझे unikernel design बहुत पसंद है, और Munal OS का feature set भी प्रभावशाली है। मैं चाहता हूँ कि wasm का उपयोग सिर्फ एक बड़े single app के लिए नहीं, बल्कि कई छोटे processes और sub-environments को host करने के लिए भी हो। wasi preview3 में sync/async coexistence की संभावना जल्द खुलने वाली है, और ऐसा होने पर wasm में एक general-purpose runtime के लिए लगभग सारे तत्व आ जाएँगे। फिर भी अफ़सोस है कि host object bridging अभी भी JS पर बहुत केंद्रित है, लेकिन wasm components का वादा—standardization, lightweight होना, sandboxing, और language composability—सिर्फ एक portable format नहीं, बल्कि एक वास्तविक runtime capability के रूप में दुनिया में दिखे, यही उम्मीद है। नीचे दिया गया talk भी देखें What is a Component (and Why)

  • क्या इस विषय पर बात करते समय आप शायद इस वीडियो YouTube link का ज़िक्र करना चाह रहे थे?
  • मैंने SDL3 support वाला और embedded V8 के साथ scripting करने योग्य एक Rust app बनाना शुरू किया है blog intro. लेकिन मैं गंभीरता से यह सोच रहा हूँ कि इसे fork करके wasmtime या wasmi embed कर दूँ, ताकि किसी भी language से scripting संभव हो सके। compiler भी साथ embed किया जा सकता है, ताकि सिर्फ files देकर तुरंत scripting हो सके। वजह यह है कि wasmtime और wasmi दूसरे scripting engines की तुलना में तेज़ हैं comparison data. हालाँकि असुविधा यह है कि पूरा code environment सेट करना पड़ता है, इसलिए script के रूप में entry barrier कमज़ोर हो जाता है। फिर भी, idea इतना शानदार है कि इसे कम-से-कम एक बार आज़माने का मन है

• “The Birth and Death of Javascript” Pycon 2014 talk में मैंने वह हिस्सा देखा था जहाँ asm.js (आज के wasm का पूर्वज) से OS sandbox implement करने वाले भविष्य की बात की गई थी। यह project के design core से मिलता-जुलता लगा, इसलिए मैं जानना चाहता हूँ कि क्या इसका प्रभाव पड़ा था talk link

  • मुझे तो लगता है कि शायद Microsoft के research OS Midori से ज़्यादा प्रभाव आया होगा Midori intro

• यह देखकर हैरानी हुई कि इस OS में अपना web browser भी built-in है web browser source. demo video में इसे Hacker News render करते हुए भी देखा जा सकता है

  • web browser में JS, CSS वगैरह features के विस्फोट से पहले, ऐसे छोटे browser बहुत कम dependencies के साथ web देख सकते थे। लेकिन अब अफ़सोस यह है कि वे ज़्यादातर web को meaningful तरीके से दिखा ही नहीं पाते। मुझे लगता है कि content-centric web और app-centric web को थोड़ा और साफ़ तौर पर अलग करना चाहिए। content web के लिए बहुत simple HTTP client और HTML parser ही काफ़ी है, और web apps के लिए इस OS की तरह wasm-based model और कुछ सीमित hardware APIs ही पर्याप्त हैं। हाँ, UDP support ज़रूर चाहिए

• यह बहुत चौंकाने वाला है, और साथ ही यह सवाल भी उठता है कि क्या ऐसी संरचना OS का भविष्य बन सकती है। readme खुद भी काफ़ी दिलचस्प है। यह जानने की उत्सुकता है कि wasmi के बजाय wasmtime क्यों नहीं चुना गया। मैं भी VM में इस OS को खुद चलाकर देखना चाहता हूँ, और अपनी GUI library को Munal पर port करने की इच्छा भी है

  • wasmtime को no_std mode में build करना बहुत झंझट वाला था, इसलिए आखिरकार wasmi चुना—ऐसा अनुभव साझा किया गया
  • आधुनिक OS architecture के भविष्य की बात में SPECTRE और MELTDOWN के घुस आने पर एक मज़ाक जोड़ा गया
  • app isolation को virtualization से करने के लिहाज़ से, Qubes OS में हम पहले से ऐसा मिलता-जुलता भविष्य देख रहे हैं। वहाँ app isolation काफ़ी मज़बूती से किया जाता है

• Xerox PARC के समय से लगातार "userspace को bytecode में बदलने" की कोशिशें होती रही हैं, और बाज़ार में वास्तव में सफल उदाहरण शायद सिर्फ IBM i, ChromeOS, और Android ही हैं। फिर भी, यह project शानदार है और मैं चाहता हूँ कि यह सफल हो

  • WebAssembly वाले हर thread में आपका पुरानी bytecode VMs की बात दोहराना अब एक pattern जैसा लगने लगा है। हर बार लगभग वही tone और वही evaluation दोहराई जाती है, लेकिन developer community में तरह-तरह के experiments और नए approaches आना स्वाभाविक है। मैं basic pattern recognition से आगे जाकर कुछ ज़्यादा specific राय सुनना चाहूँगा
  • इस concept के फ़ायदे इतने स्पष्ट हैं कि जब तक यह ठीक से standard के रूप में स्थापित नहीं हो जाता, तब तक नए experiments बार-बार होते रहेंगे। wasm इस मामले में JVM वगैरह से साफ़ अलग है, क्योंकि वह सच में उसी लक्ष्य की ओर बढ़ रहा है
  • ChromeOS तो बस एक browser है, इसलिए वह संयोग से V8 इस्तेमाल करता है, और Android शायद कुछ भी इस्तेमाल करता तो भी सफल हो जाता। उन दोनों OS की सफलता का कारण technology नहीं, बल्कि कीमत थी

• client OS का design अपने-आप में आश्चर्यजनक है। मुझे लगता है कि ऐसी संरचना server पर भी तुरंत practical हो सकती है। अगर kernel बहुत छोटा रखा जाए और सिर्फ चलने वाला एक single app छोड़ा जाए, तो अनावश्यक security boundaries कम की जा सकती हैं। उदाहरण के लिए, key/value store इस तरह की संरचना के लिए उपयुक्त हो सकता है। मेरी जिज्ञासा यह है कि क्या इस IO model में network performance अच्छी मिलती है, और WASM hosting के दौरान अनावश्यक memory copies कम करने के लिए कोई खास technique लागू की जा सकती है?