मान लीजिए कि मैं एक बहुत छोटे देशी निचले कर्नेल के आधार पर एक ऑपरेटिंग सिस्टम बनाना चाहता हूं जो एक प्रबंधित कोड दुभाषिया / रनटाइम के रूप में कार्य करता है और एक गैर-देशी मशीन भाषा (जावा बाइटकोड, सीआईएल, आदि) के लिए संकलित एक बड़ा ऊपरी कर्नेल। समान ऑपरेटिंग सिस्टम के उदाहरण विलक्षणता और कॉस्मॉस होंगे ।
विशुद्ध रूप से देशी समाधान के विपरीत इस तरह की बुनियादी सुविधाओं के साथ एक ओएस लिखने में क्या नुकसान और विकास चुनौतियां मौजूद हैं?
जवाबों:
भाषा के आधार पर, विकास की कई चुनौतियाँ हो सकती हैं:
पॉइंटर्स: यदि किसी भाषा में पॉइंटर्स नहीं हैं, तो अपेक्षाकृत आसान कार्य करना एक चुनौती होगी। उदाहरण के लिए, आप स्क्रीन पर मुद्रण के लिए वीजीए मेमोरी में लिखने के लिए पॉइंटर्स का उपयोग कर सकते हैं। हालाँकि, एक प्रबंधित भाषा में, आपको ऐसा करने के लिए कुछ प्रकार के "प्लग" (C / C ++ से) की आवश्यकता होगी।
असेंबली: एक OS को हमेशा कुछ असेंबली की आवश्यकता होती है। C / C ++ के विपरीत C #, Java आदि भाषाएँ इसके साथ इतनी अच्छी तरह से काम नहीं करती हैं। C या C ++ में आप इनलाइन असेंबली भी कर सकते हैं जो बहुत से कार्यों के लिए बहुत उपयोगी है। ऐसे कई मामले हैं जहाँ इसकी आवश्यकता है (उदाहरण x86 में): एक GDT लोड करना, एक IDT लोड करना, पेजिंग सक्षम करना, IRQ सेट करना, आदि।
नियंत्रण: यदि आप कॉस्मॉस जैसी किसी चीज़ का उपयोग कर रहे हैं, तो आपको पूर्ण नियंत्रण नहीं है। कॉस्मॉस एक माइक्रो-कर्नेल है और अनिवार्य रूप से "बूटस्ट्रैप" आपका "कर्नेल" है। यदि आप वास्तव में चाहते हैं, तो आप स्क्रैच से कॉस्मॉस जैसी चीज को लागू कर सकते हैं, हालांकि, इसमें लंबा समय लग सकता है।
ओवरहेड: प्रबंधित भाषाओं के साथ, सी या यहां तक कि सी ++ की तुलना में ओवरहेड का एक बहुत कुछ है। कॉस्मॉस जैसी चीजों को बहुत सी चीजों को लागू करने की आवश्यकता होती है, इससे पहले कि एक सी # हैलो वर्ल्ड कर्नेल भी चलाया जा सकता है। सी में, आप जाने के लिए तैयार हैं, कोई वास्तविक सेटअप की आवश्यकता नहीं है। C ++ में, कुछ चीजें हैं जिन्हें C ++ की कुछ विशेषताओं का उपयोग करने के लिए लागू करने की आवश्यकता है।
संरचनाएं: C / C ++ में ऐसी संरचनाएं होती हैं जो कई प्रबंधित भाषाओं में नहीं होती हैं, और इसलिए, आपको किसी संरचना की तरह कुछ होने के कुछ तरीके लागू करने की आवश्यकता होगी। उदाहरण के लिए, यदि आप C / C ++ में IDT (इंटरप्ट डिस्क्रिप्टर टेबल) लोड करना चाहते हैं, तो आप एक स्ट्रक्चर (पैक्ड विशेषता के साथ) बना सकते हैं, और इसे x86 ASM इंस्ट्रक्शन लिफ़्ट का उपयोग करके लोड कर सकते हैं । एक प्रबंधित भाषा में, यह करना बहुत कठिन है ...
प्रबंधित भाषाओं, सिंटैक्स-वार, आसान हैं, हालांकि, कई ओएस से संबंधित चीजों के लिए कई बार बहुत अच्छी तरह से अनुकूल नहीं हैं। इसका मतलब यह नहीं है कि उनका उपयोग नहीं किया जा सकता है, हालांकि, C / C ++ जैसी किसी चीज की अक्सर सिफारिश की जाती है।
मैंने यह दावा किया है कि एक प्रतियोगी ( एक प्रतिस्पर्धी माइक्रोकर्नल तकनीक पर काम करने वाले शोधकर्ता द्वारा ) यह बहुत कम ही जाना जाता है कि प्रबंधित कोड के माध्यम से एक्स्टेंसिबल सिस्टम की सुरक्षा का मूल्यांकन कैसे किया जाए।
समस्या यह है कि एक सुरक्षा छेद का कारण हो सकने वाले कीड़े के प्रकार सुरक्षा शोधकर्ताओं की तुलना में बहुत भिन्न होते हैं। एक पारंपरिक माइक्रो कर्नेल में सभी ड्राइवर और कर्नेल के अन्य उप-हिस्से अलग-अलग एड्रेस स्पेस में चलाकर एक दूसरे से अलग किए जाते हैं। एक माइक्रोकर्नल में, जहां आइसोलेशन टाइप चेकिंग कोड के माध्यम से कार्यान्वित किया जाता है, आप हर बार जब आप उप-सेवा का उपयोग करने की आवश्यकता होती है, तो पता स्थान बदलने से बहुत अधिक ओवरहेड से बचते हैं, लेकिन ट्रेडऑफ़ यह है कि अब अलगाव तंत्र का मूल्यांकन करना अधिक कठिन है।
प्रबंधित भाषा में लिखा गया कर्नेल का कोई विशेष भाग (डिवाइस ड्रायवर कहलाता है) सुरक्षित है यदि और केवल टाइप चेकर का कहना है कि ड्राइवर सुरक्षित है और टाइप चेकर में कोई बग नहीं है। तो प्रकार चेकर कर्नेल कोर का हिस्सा है। व्यवहार में ऐसा लगता है कि टाइप चेकर्स पारंपरिक माइक्रो कर्नेल कोर की तुलना में काफी बड़े और अधिक जटिल हैं। इसका मतलब है कि हमले की सतह संभावित रूप से बड़ी है।
मुझे नहीं पता कि पारंपरिक माइक्रो-कर्नेल आइसोलेशन तकनीक या प्रबंधित-कोड आधारित आइसोलेशन तकनीक वास्तव में कम या ज्यादा विश्वसनीय हैं। यहां बूटस्ट्रैपिंग की समस्या है: जब तक प्रबंधित-कोड अलगाव तकनीकों का व्यापक रूप से उपयोग नहीं किया जाता है, तब तक हम यह नहीं जान पाएंगे कि वे कितनी बार असुरक्षित हैं। लेकिन यह जाने बिना कि वे कितने असुरक्षित हैं, सुरक्षा परिस्थितियों के लिहाज से उन्हें उन परिस्थितियों में तैनात करना मुश्किल है।