Asterinas - नया Linux-संगत kernel प्रोजेक्ट

 (lwn.net)
8 पॉइंट द्वारा GN⁺ 2025-06-23 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Rust में लिखा गया Linux ABI-संगत kernel, जो “framekernel” आर्किटेक्चर अपनाकर monolithic और microkernel के फायदे जोड़ने का लक्ष्य रखता है
  • सभी unsafe code को सीमित libraries के भीतर encapsulate करके, बाकी kernel services को safe Rust abstractions के साथ विकसित करने के लिए डिज़ाइन किया गया है, ताकि memory safety और सरल shared memory संरचना दोनों हासिल की जा सकें
  • RedLeaf, Tock, Rust for Linux जैसे मौजूदा Rust OS से फर्क यह है कि इसमें hardware isolation support, general-purpose लक्ष्य, Linux-संगत ABI, और user space में कई भाषाओं का execution शामिल है
  • TCB (trusted computing base) को न्यूनतम करने और formal verification (Verus के उपयोग से) को आगे बढ़ाने पर ज़ोर, साथ ही Intel TDX जैसे trusted execution environment hardware का support, और OSTD/OSDK जैसे OS development frameworks भी अलग से उपलब्ध
  • अभी शुरुआती development stage में है; x86/RISC-V support और 206 system calls लागू किए गए हैं, Docker/container/cloud environments पर फोकस है, लेकिन X11/Xfce जैसे desktop विस्तार पर भी काम चल रहा है

What's Asterinas?

  • Asterinas, Rust में विकसित एक नया Linux ABI-संगत kernel प्रोजेक्ट है
  • “framekernel” आर्किटेक्चर का मतलब है कि unsafe Rust code (memory-unsafe हिस्से) को framework libraries तक सीमित रखकर safe API में wrap किया जाए, और बाकी सभी kernel services को safe Rust में विकसित किया जाए
  • यह monolithic kernel की सरल/उच्च-प्रदर्शन संरचना और microkernel की न्यूनतम TCB (trusted computing base) / सुरक्षा—दोनों को एक साथ हासिल करने की कोशिश करता है
  • kernel के अंदर services एक ही address space में अलग-अलग चलती हैं, और हर service केवल वही resources इस्तेमाल कर सकती है जो core library द्वारा उसे दिए गए हों

framekernel आर्किटेक्चर की व्याख्या

  • framekernel की अवधारणा पहली बार "Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation" पेपर में प्रस्तावित की गई थी
  • monolithic kernel वह संरचना है जिसमें सारा code एक ही kernel-mode address space में होता है, जबकि microkernel केवल न्यूनतम TCB को kernel space देता है और अधिकांश कार्य user-mode services को सौंपता है
  • framekernel, Rust की 'unsafe' क्षमता की ज़रूरत वाले code को library के रूप में encapsulate करता है, और बाकी kernel services को memory-safe Rust abstractions के साथ विकसित करता है
  • हर service kernel address space के भीतर चलती है, लेकिन उसे केवल वही resources access करने की अनुमति होती है जो library स्पष्ट रूप से उपलब्ध कराती है
  • TCB को छोटा रखने से formal verification (गणितीय प्रमाण) करना अधिक व्यावहारिक हो जाता है, और इससे पूरे system की विश्वसनीयता और स्थिरता बढ़ सकती है
  • यह shared memory आधारित (monolithic kernel जैसा high performance) होने के साथ-साथ internal privilege separation/security (microkernel का लाभ) को जोड़ने वाला approach है

मौजूदा Rust OS और framekernel से तुलना

  • RedLeaf: Rust-आधारित microkernel, hardware isolation का उपयोग नहीं करता
  • Asterinas: general-purpose OS, hardware isolation का उपयोग, Linux ABI compatibility, और कई भाषाओं वाले user space execution का support
  • Tock: embedded SoC target, core (unsafe allowed) और capsule (safe code) विभाजन संरचना, hardware isolation support नहीं
  • Rust for Linux प्रोजेक्ट का उद्देश्य भी kernel interfaces को safe abstractions में wrap करके kernel drivers को Rust में सुरक्षित रूप से लिखना सक्षम बनाना है

formal verification और सुरक्षा

  • TCB को घटाने का मुख्य उद्देश्य यह है कि formal verification को व्यावहारिक रूप से संभव बनाया जा सके
  • Asterinas, seL4 की तरह छोटा और verifiable TCB, Linux ABI compatibility, और shared memory संरचना—इन तीनों को साथ लेकर चलने वाला एक अनोखा प्रयास है
  • security audit विशेषज्ञ कंपनी CertiK के साथ मिलकर Verus-आधारित formal verification का काम किया जा रहा है
    • CertiK की security assessment report में प्रोजेक्ट के audit points और मिले issues सार्वजनिक किए गए हैं

libraries और development tools

  • kernel के अलावा OSTD (Rust OS framework) और OSDK (Cargo-आधारित development tool) भी प्रदान किए जाते हैं
  • OSTD के मुख्य लक्ष्य:
    • OS development में entry barrier कम करना और innovation की नींव बनाना
    • Rust operating systems की memory safety मजबूत करना और low-level API abstraction देना
    • अलग-अलग Rust OS projects के बीच code reuse को बढ़ावा देना
    • user mode में नए code का test संभव बनाना (development productivity में वृद्धि)
  • OSD और OSTD-आधारित kernels के लिए Linux-compatible होना ज़रूरी नहीं है, और ये x86 hardware control, virtual memory, multiprocessing (SMP), timer आदि के लिए high-level memory-safe APIs देते हैं
  • Intel sponsor के रूप में शामिल है, खासकर Trust Domain Extensions (TDX) और virtual machine isolation से जुड़ी तकनीकों के कारण

development status और प्रमुख sponsors

  • 2024 की शुरुआत में open source (MPL license) के रूप में पहली बार जारी, वर्तमान में 45 contributors; मुख्य contributors में चीन के SUSTech, Peking University, Fudan University के PhD छात्र और Ant Group शामिल हैं
  • x86, RISC-V support, और Linux system calls में 206 लागू (कुल 368 में से)
  • अभी apps चलाने में सक्षम नहीं, शुरुआती distribution development और container (Docker) support लक्ष्य हैं, साथ ही Nix-आधारित distribution जैसी कोशिशें भी हो रही हैं
  • Linux kernel module loading का support नहीं है और इसे स्थायी रूप से जोड़ने की कोई योजना नहीं है

आगे की योजना

  • और अधिक CPU architectures तथा hardware support का विस्तार, और cloud environments में वास्तविक उपयोगिता को short-term priority बनाया गया है
  • Linux virtio devices का support पूरा हो चुका है, और चीनी cloud market (Alibaba Cloud, Aliyun) को प्रमुख target माना गया है
  • सुरक्षित और छोटा TCB, Intel trusted computing features support, और containers के लिए host OS बनाना इसका मुख्य लक्ष्य है
  • Rust for Linux से उद्देश्य कुछ हद तक मिलता-जुलता है, लेकिन Rust for Linux जहाँ मौजूदा kernel के भीतर drivers को Rust में लाने तक सीमित है, वहीं Asterinas पूरे kernel की नई design और TCB minimization की ओर बढ़ता है
  • फिलहाल X11, Xfce support जैसी कई दिशाओं में प्रयोग चल रहे हैं, और OSTD में भी सामान्य OS developers का ध्यान खींचने की क्षमता है

Rust for Linux से अंतर

  • Rust for Linux: मौजूदा Linux kernel में केवल safe Rust drivers जोड़ता है; पूरा kernel अब भी C-आधारित है
  • Asterinas: नया kernel शुरुआत से Rust में लागू, unsafe को सख्ती से सीमित करता है, formal verification को आगे बढ़ाता है, और cloud/container environments पर केंद्रित है

समग्र निष्कर्ष और आगे की संभावना

  • Asterinas memory safety, formal verification, और cloud environments में practical usability के स्तर पर एक नवोन्मेषी approach आज़मा रहा है
  • अभी वास्तविक उपयोग के उदाहरण या व्यापक community validation नहीं है, लेकिन OS research, cloud, और security क्षेत्रों में रुचि मिल रही है
  • OSTD framework जैसी चीज़ों में भविष्य के Rust OS development ecosystem में उपयोग की संभावना है

Asterinas से जुड़े LWN comments के मुख्य बिंदुओं का सार

  • Singularity OS और language-based security boundary पर बहस
    • Asterinas का framekernel, Microsoft के Singularity OS जैसा है, लेकिन Rust के borrow checker का उपयोग करके memory safety बढ़ाने की कोशिश करता है
    • system को भाषा-स्तर (जैसे Rust, Java, WASM/JS) की security boundary से सुरक्षित करने के approach पर एक ओर यह आलोचना है कि "पूर्ण भरोसा संभव नहीं, इसलिए व्यवहार में hardware/OS-level sandbox के साथ ही इस्तेमाल होता है", जबकि दूसरी ओर यह राय है कि "fault prevention और formal verification में इसके फायदे हैं"
    • WASM, JS, Java आदि की security पर बहस के बावजूद, वास्तविक सेवाओं में केवल language sandbox पर भरोसा नहीं किया जाता; आम तौर पर hardware या OS sandbox साथ में उपयोग किया जाता है
  • operating system development trends और geopolitical background
    • हाल के वर्षों में कई नए OS projects उभरे हैं, और OS innovation का माहौल फैल रहा है
    • चीन, अमेरिका की technology sanctions और supply chain risk के जवाब में Linux के विकल्प वाले OS development को तेज़ कर रहा है
    • US sanctions, GPL और open source की global governance पर बहस, और चीन/यूरोप आदि देशों द्वारा स्वतंत्र technology ecosystem बनाने की राजनीतिक चर्चा तेज़ रही
    • Linux fork को बनाए रखने बनाम बिल्कुल नया kernel विकसित करने की कठिनाई, community knowledge/know-how पर निर्भरता, और language barriers भी चर्चा के विषय रहे
  • Linux compatibility / system call count पर बहस
    • "Linux system call count से compatibility को मापना उचित नहीं"—ऐसी राय बड़ी संख्या में सामने आई
    • एक single system call (ioctl आदि) में कई detailed APIs छिपे हो सकते हैं, इसलिए वास्तविक compatibility के लिए kernel test suites और असली apps का चलना ज़्यादा महत्वपूर्ण है
    • Linux के शुरुआती विकास इतिहास का उदाहरण भी दिया गया, जहाँ POSIX compatibility के लिए syscall एक-एक करके लागू किए गए; यह भी राय आई कि 99% प्रमुख syscalls का support होने पर काफी software चल सकता है
  • license और Rust ecosystem
    • Asterinas द्वारा MPL चुनने पर चर्चा: सकारात्मक राय यह कि Rust के crate ecosystem और modular licensing के साथ MPL अच्छी तरह फिट बैठता है
    • यह भी दृष्टिकोण सामने आया कि GPL हमेशा सर्वोत्तम नहीं होता, और corporate sponsorship होने पर MPL जैसी business-friendly license चुनी जा सकती है
  • project dependencies / security
    • Rust-आधारित OS में बहुत सारे external crates के उपयोग की सुरक्षा पर सवाल उठे, और cargo deny/vet जैसे tools के जरिए supply chain security और audit automation की ज़रूरत बताई गई
    • केवल lockfile से dependency surface समझना मुश्किल होता है; Rust ecosystem की transitive dependencies, OS-specific dependencies जैसी जटिलताओं का भी उल्लेख हुआ
  • technical inspiration / similar architectures
    • यह भी बताया गया कि framekernel की अवधारणा 1990s के University of Washington के SPIN OS architecture से मिलती-जुलती है
    • SPIN में भी strong modularity और compiler-आधारित interface/access control पर ज़ोर था
  • committer composition पर विवाद
    • 45 contributors में से कई commits कुछ ही PhD छात्रों के केंद्र में होने की बात कही गई
    • इस गलतफहमी की ओर इशारा किया गया कि PhD student-led contributions का committer के रूप में मूल्य कम होता है; साथ ही यह राय भी थी कि research-driven innovation project के रूप में इसकी अहमियत है
  • politics/history बहस और off-topic इशारे
    • OS discussion अमेरिका, यूरोप और चीन की geopolitics/politics/history तक फैल गई, जिस पर editors ने कई बार "off-topic" चेतावनी दी
    • कुछ users ने ज़ोर दिया कि open source/FOSS ecosystem भी geopolitical माहौल में बदलाव से प्रभावित हो सकता है
  • अन्य
    • WASM security पर academic papers साझा किए गए
    • kernel development status को लेकर सकारात्मक और आलोचनात्मक—दोनों तरह की प्रतिक्रियाएँ दिखीं

संबंधित पढ़ाई

2 टिप्पणियां

 
eususu 2025-06-24

ऐसी कोशिशें वाकई बहुत अच्छी लगती हैं.
लगता है कि शायद जल्द ही ऐसा kernel आएगा जो crash न हो.
 
GN⁺ 2025-06-23
Hacker News की राय

  • यह एक दिलचस्प approach लगती है, और मैं इसकी सफलता की उम्मीद करता हूँ। लेकिन अब भी कुछ संदेह बाकी हैं। 90s के आखिर या 2000s की शुरुआत में Linus ने एक TV interview में competitors के बारे में जो कहा था, वह अभी भी याद है। Linus ने कुछ इस तरह कहा था: "कोई भी drivers लिखना पसंद नहीं करता, इसलिए जब तक कोई युवा और भूखा शानदार driver engineer सामने नहीं आता, तब तक हम सुरक्षित हैं।" उस समय भी उन्हें यह समझ थी कि driver interface को unstable रखना एक defensive strategy है। 25 साल बाद आज kernels का virtualized hardware पर चलना बहुत आम है, लेकिन अब भी ऐसे व्यावहारिक और usable operating systems बहुत कम हैं जो real hardware के साथ abstraction को सफलतापूर्वक संभाल सकें

    • "driver interface को unstable रखना एक defensive strategy है" वाली बात पर, आगे चलकर यह संभव लग सकता है कि कोई युवा और भूखा systems researcher या AI आए, और AI agent C में लिखे Linux drivers को सुरक्षित Rust-आधारित Asterinas drivers में translate कर दे। एक और व्यावहारिक approach यह है कि Linux kernel को किसी isolation environment के अंदर डालकर reuse किया जाए। उदाहरण के लिए HongMeng kernel, User-Mode Linux का उपयोग करके drivers को reuse करता है। Asterinas भी इसी तरह की strategy अपना सकता है। संदर्भ: https://www.usenix.org/conference/osdi24/presentation/chen-haibo

    • मुझे संदेह है कि Linus सच में कोई "moat" चाहता था या उसने इसे जानबूझकर ऐसा बनाया था। वह कोई tech startup founder नहीं था, मूल रूप से बस एक kernel hacker था, और उसकी आजीविका की बुनियाद पहले ही बन चुकी थी। kernel के अंदर driver interface की instability को जानबूझकर competition रोकने की strategy मानना कुछ ज़्यादा projection लगता है

    • पहले भी SPIN OS(Modula 3), JX OS(Java), House OS(Haskell), Verve जैसे उदाहरण रहे हैं। इन सबने type-safe और memory-safe भाषाओं का उपयोग करके kernel functionality बनाई थी। आम तौर पर उनका ढाँचा ऐसा था कि जोखिम को checked function calls के पीछे छिपाया गया, और कुछ ने VM का उपयोग भी किया। performance या adoption की समस्याओं को छोड़ दें, तो मुख्य कमजोरियाँ abstraction में gaps, unsafe code bypass, compiler/JIT के कारण safety model का टूटना, और सामान्य hardware faults (जैसे spacecraft में cosmic rays) थीं। फिर भी वे unsafe language kernels/apps की तुलना में कहीं अधिक सुरक्षित हैं। यहाँ से आगे बढ़ना हो तो unsafe code का static analysis, यह सुनिश्चित करना कि सभी unsafe functions type-memory-safe interfaces का पालन करें, integration के समय abstraction-safety-preserving compiler, और प्रति-component certified compiler भी इस्तेमाल किए जा सकते हैं। ज़्यादातर productivity tools पहले से मौजूद हैं; बस एक चीज़ बाकी है: 'पूरी तरह सुरक्षित abstracted compilation', जिस पर अभी research चल रही है, और manual inspection भी संभव है

    • व्यावहारिक रूप से usable operating systems बहुत कम होने की एक वजह है। hardware की दुनिया में interface 'standards' बहुत हैं, लेकिन असली hardware शायद ही कभी standards के मुताबिक ठीक से काम करता है। जब तक drivers को तरह-तरह की quirks और न सुधारी जा सकने वाली defects (errata) को संभालने वाला code लिखने के लिए समय न दिया जाए, तब तक वास्तविक physical hardware पर performance और support हासिल करना वास्तव में बहुत कठिन है

    • दूसरी ओर, वास्तव में मैं जो Linux इस्तेमाल करता हूँ उसका 98% virtualized environment में चलता है। desktop/laptop पर मैं fullscreen Virtualbox चलाता हूँ, Windows drivers सिर्फ तभी इस्तेमाल करता हूँ जब सच में ज़रूरत हो, और Mac पर Docker.app द्वारा managed headless VM चलता है। कंपनी के सभी production workloads AWS VM पर हैं। घर पर मेरा एकमात्र Linux hardware भी home server है, और जल्द ही उसे eBay से खरीदे गए Mac mini VM से बदलने की योजना है। अगर Linux-compatible लेकिन अधिक secure और लगभग समान performance वाला कोई kernel आता है, तो आजकल drivers कम होने पर भी alternative चुनना आसान लगता है

  • मैंने सुना है कि हाल के microkernels ने IPC performance issues को काफ़ी सुधारा है। असल में कितना सुधार हुआ है यह ठीक से याद नहीं, लेकिन लगता है कि Mach ने industry को बड़ा trauma दिया था। project site को देखें तो structure कुछ ऐसा दिखता है कि सिर्फ Framework (privileged mode) ही Rust unsafe का उपयोग कर सकता है, जबकि Services (unprivileged) केवल safe Rust का उपयोग करते हैं। यह थोड़ा अजीब लगता है—अगर unprivileged code unsafe हो तो वह unprivileged होने पर भी खतरनाक नहीं होगा? उल्टा, वह unsafe code जिसे वास्तव में verification चाहिए, उसे ही बिना सीमा privileged side में लिखने दिया गया है? और license देखें तो Asterinas मुख्य रूप से Mozilla Public License(MPL) 2.0 का उपयोग करता है, जबकि कुछ components अधिक permissive license में हैं। न GPL, न BSD—बीच का कुछ लगता है

    • "अगर unprivileged भी unsafe हो तो वह खतरनाक है, और जिन हिस्सों को सबसे अधिक verification चाहिए उन्हें privileged में केंद्रित करना अजीब है"—इस सवाल को framekernel context में समझना चाहिए। पूरा Rust-based framekernel kernel space में चलता है, लेकिन तार्किक रूप से दो हिस्सों में बँटा है: privileged OS framework और unprivileged OS services। privileged हिस्से में safe + unsafe Rust kernel code दोनों आते हैं, जबकि unprivileged हिस्से में केवल safe Rust kernel code होता है। यह policy पूरी तरह kernel code पर लागू होती है। framekernels में user programs की भाषा पर कोई पाबंदी नहीं है

    • मेरी जानकारी में हाल के microkernels ने ज़्यादातर IPC performance को नाटकीय रूप से बेहतर बनाया है। उदाहरण के लिए seL4 ने IPC को बहुत आक्रामक रूप से optimize किया है, और उसका IPC Linux के सामान्य syscall से भी कहीं तेज़ है। काफी संभव है कि अधिकांश programs seL4 पर उल्टा अधिक तेज़ चलें। वास्तविक performance comparison data देखना दिलचस्प होगा

    • यह सही है कि नए microkernels ने IPC issue सुधारे हैं। दरअसल, अधिक बुनियादी समस्या यह है कि आधुनिक hardware पर monolithic kernel के syscall भी बहुत धीमे हैं। इसी वजह से io_uring या virtio जैसे interfaces अच्छी performance देते हैं: वे system और app (या hypervisor और guest) के बीच requests और responses को queue के रूप में संभालते हैं, जिससे address space switches से बचा जा सके। आगे के operating systems में, चाहे उनकी structure कोई भी हो, 'queueing'-based syscall mechanism ज़रूरी होगा। और अगर यह approach अपनाई जाए, तो OS को monolithic/microkernel/किसी और architecture में बाँटने से performance में बड़ा फर्क नहीं पड़ेगा

    • Framekernel में privileged/unprivileged का विभाजन kernel/userspace वाला अर्थ नहीं रखता। पूरा OS kernel privilege level पर चलता है। बस तार्किक रूप से इसे core library code (unsafe उपयोग की अनुमति, privileged) और बाकी kernel component code (libraries का उपयोग, unsafe का सीधा उपयोग नहीं, unprivileged) में बाँटा गया है। संभवतः इसे linter जैसे static checks से enforce किया जाता है। terminology के overlapping उपयोग के कारण यह structure भ्रमित कर सकता है

    • unprivileged tasks भी kernel core के समान memory space में चलते हैं, इसलिए runtime पर unsafe behavior को रोकने का कोई तरीका नहीं है। अगर runtime में सचमुच privilege अलग करना हो, तो microkernel architecture चाहिए। यहाँ privileges को runtime की बजाय static तरीके से लागू किया गया है, यानी unsafe code को प्रतिबंधित करके

  • मुझे जिज्ञासा है कि kernel को एक छोटे unsafe core और बड़े safe modules में बाँटने का विचार कितना नया है। इसमें microkernel का hardware overhead नहीं है, monolithic की safety problems से बचाव है, और system language के safe/unsafe distinction का अच्छा उपयोग दिखता है—इसलिए यह project काफ़ी दिलचस्प और आशाजनक लगता है

  • इससे Drew DeVault की Rust in Linux review याद आती है। HN discussion भी जुड़ सकती है https://news.ycombinator.com/item?id=41404733

  • यह सचमुच एक शानदार प्रयास लगता है, और यह भी प्रभावशाली है कि author इस thread में मौजूद है। जानना चाहूँगा कि यह किस स्तर तक usable है; चाहूँगा कि किसी सीमित environment में ही सही, एक server image बनाकर इसे आज़माया जाए

    • Asterinas अभी अपेक्षाकृत नया kernel है, इसलिए general-purpose उपयोग के लिए इसमें अभी काफ़ी polishing की ज़रूरत है। लेकिन अगर लक्ष्य वास्तव में efficient और reliable production service operation है, तो वह gap इतना बड़ा नहीं है, और 1 साल के भीतर उस लक्ष्य तक पहुँचना संभव लग सकता है। अभी Linux namespaces, cgroups जैसे core features लागू किए जा रहे हैं, और Asterinas-आधारित पहला distribution भी बन रहा है। शुरुआती लक्ष्य Confidential VMs के guest OS के रूप में Asterinas का उपयोग करना है, और memory safety तथा छोटे TCB के कारण security के लिहाज़ से इसमें Linux की तुलना में स्पष्ट बढ़त है

  • यह देखकर तसल्ली होती है कि microkernel IPC के धीमे होने को उसकी कम लोकप्रियता की वजह बताने में तकनीकी रूप से बेहद सक्षम लोग भी adoption के असली कारणों और उस प्रक्रिया को कभी-कभी गलत समझ लेते हैं

    • अगर ऐसा है, तो सबके लिए उपयोगी होगा कि ठीक-ठीक बताया जाए कि किस बिंदु पर गलत व्याख्या हो रही है

  • license MPL है; व्यक्तिगत रूप से मुझे लगता है कि इससे बेहतर licenses (जैसे GPLv3) भी हैं

    • documentation में सीधे समझाया गया है कि MPL क्यों चुना गया। यह मेरी पसंदीदा choice नहीं है, लेकिन वजह समझ में आती है

  • मुझे यह वाकई अच्छी idea लगती है। बहुत सा software पहले से बना हुआ है, और अगर कोई alternative foundation हो तो purely technical कारणों से परे भी बड़े फायदे और विकल्प मिल सकते हैं। kFreeBSD, GNU/Hurd याद आते हैं

  • सोच रहा हूँ कि ऐसे kernels को क्या कहा जाना चाहिए। *nux?