जिक्रोन हाइलाइट: vDSO (आभासी गतिशील साझा वस्तु)

जिक्रोन? यह क्या है

अगस्त 2016 में, Google की किसी भी आधिकारिक घोषणा के बिना, नए ऑपरेटिंग सिस्टम के स्रोतों की खोज की गई थी फ्यूशिया। यह ओएस जिरकोन नामक एक माइक्रोकर्नेल पर आधारित है, जो बदले में एलके (लिटिल कर्नेल) पर आधारित है।

फुकिया लिनक्स नहीं है

लेख में क्या चर्चा की जाएगी?

जिक्रोन में vDSO सिस्टम कॉल (syscalls) तक पहुंचने का एकमात्र साधन है।

क्या हमारे कोड से सीधे प्रोसेसर निर्देश SYSENTER / SYSCALL को कॉल करना असंभव है? नहीं, ये प्रोसेसर निर्देश सिस्टम ABI का हिस्सा नहीं हैं। उपयोगकर्ता कोड को इन निर्देशों का सीधे पालन करने से मना किया गया है।

जो लोग इस तरह के एक वास्तुशिल्प कदम के बारे में अधिक जानकारी जानना चाहते हैं, मैं आपको बिल्ली के लिए आमंत्रित करता हूं।

जिरकोन vDSO (वर्चुअल डायनामिक शेयर्ड ऑब्जेक्ट)

संक्षिप्त vDSO का अर्थ v irtual D ynamic S hared O bject है:

• डायनेमिक शेयर्ड ऑब्जेक्ट एक शब्द है जिसका उपयोग ELF प्रारूप (.so फ़ाइलों) के लिए साझा पुस्तकालयों को संदर्भित करने के लिए किया जाता है।
• यह ऑब्जेक्ट वर्चुअल है क्योंकि यह फ़ाइल सिस्टम पर मौजूदा अलग फ़ाइल से लोड नहीं होता है। VDSO छवि सीधे कर्नेल द्वारा प्रदान की जाती है।

कर्नेल समर्थन

उपयोगकर्ता-मोड अनुप्रयोगों के लिए एकमात्र नियंत्रित ABI के रूप में vDSO के लिए समर्थन दो तरीकों से लागू किया गया है:

1. वर्चुअल मेमोरी ऑब्जेक्ट ( VMO, वर्चुअल मेमोरी ऑब्जेक्ट ) को प्रोजेक्ट करना।
   
   जब zx_vmar_map vDSO के लिए ZX_VM_PERM_EXECUTE (और ZX_VM_PERM_EXECUTE अनुरोध किया जाता है), कर्नेल को ऑफसेट और आकार के निष्पादन योग्य vDSO खंड से सख्ती से मेल खाने की आवश्यकता होती है। यह (सहित) प्रक्रिया मेमोरी में केवल एक वीडीएसओ प्रक्षेपण की गारंटी देता है। प्रक्रिया में vDSO के पहले सफल प्रक्षेपण के बाद, इसे अब हटाया नहीं जा सकता है। और प्रक्रिया मेमोरी में vDSO को फिर से प्रोजेक्ट करने का प्रयास, VDSO के लिए अनुमानित VMO को हटाने का प्रयास करता है और गलत ऑफसेट और / या आकार के साथ ZX_ERR_ACCESS_DENIED त्रुटि के साथ विफल ZX_ERR_ACCESS_DENIED ।
   Vdso कोड के ऑफसेट और आकार को ELF फ़ाइल से संकलन चरण में निकाला जाता है और फिर ऊपर की जाँच करने के लिए कर्नेल कोड में उपयोग किया जाता है। पहले सफल vDSO प्रक्षेपण के बाद, ओएस कर्नेल चेकों को गति देने के लिए लक्ष्य प्रक्रिया के लिए पते को याद करता है।

   
   

2. सिस्टम कॉल फ़ंक्शंस के लिए रिटर्न एड्रेस की जाँच करें।
   
   जब उपयोगकर्ता-मोड कोड कर्नेल को कॉल करता है, तो एक निम्न-स्तरीय सिस्टम कॉल नंबर रजिस्टर में प्रेषित होता है। निम्न-स्तरीय सिस्टम कॉल vDSO और जिरकोन कोर के बीच आंतरिक (निजी) इंटरफ़ेस हैं। कुछ (अधिकांश) सीधे सार्वजनिक एबीआई के सिस्टम कॉल के अनुरूप हैं, जबकि अन्य नहीं करते हैं।
   VDSO कोड में प्रत्येक निम्न-स्तरीय सिस्टम कॉल के लिए, कोड में एक निश्चित सेट है जो यह कॉल करता है। VDSO के लिए स्रोत कोड आंतरिक वर्णों को परिभाषित करता है जो ऐसे प्रत्येक स्थान की पहचान करते हैं। संकलन के समय, इन स्थानों को vDSO प्रतीक तालिका से पुनर्प्राप्त किया जाता है और कर्नेल कोड उत्पन्न करने के लिए उपयोग किया जाता है जो प्रत्येक निम्न-स्तरीय सिस्टम कॉल के लिए कोड पते की वैधता की भविष्यवाणी को निर्धारित करता है। ये विधेय आपको VDSO कोड सेगमेंट की शुरुआत से ऑफसेट को देखते हुए, वैधता के लिए कॉलिंग कोड को जल्दी से जांचने की अनुमति देते हैं।
   यदि यह विधेय द्वारा निर्धारित किया जाता है कि कॉलिंग कोड को सिस्टम कॉल करने की अनुमति नहीं है, तो एक सिंथेटिक अपवाद फेंक दिया जाता है, जैसे कि कॉलिंग कोड ने एक नॉनटेक्स्ट या विशेषाधिकार प्राप्त निर्देश को निष्पादित करने का प्रयास किया।

   
   

एक नई प्रक्रिया बनाते समय vDSO

एक नई बनाई गई प्रक्रिया के पहले धागे का निष्पादन शुरू करने के लिए, zx_process_start सिस्टम कॉल का उपयोग किया जाता है । इस सिस्टम कॉल का अंतिम पैरामीटर (प्रलेखन में arg2 देखें) निर्मित प्रक्रिया के पहले धागे के लिए तर्क देता है। स्वीकृत समझौते के अनुसार, प्रोग्राम लोडर vDSO को नई प्रक्रिया के पते स्थान (सिस्टम द्वारा चयनित एक यादृच्छिक स्थान) पर मैप करता है और बनाई गई प्रक्रिया के पहले धागे में arg2 तर्क के साथ मैपिंग के आधार पते को स्थानांतरित करता है। यह पता ईएलएफ फ़ाइल का हेडर एड्रेस है, जिस पर सिस्टम कॉल करने के लिए आवश्यक नामित कार्य पाए जा सकते हैं।

मेमोरी कार्ड (लेआउट) vDSO

vDSO एक नियमित ईएफएल साझा पुस्तकालय है जिसे किसी भी अन्य की तरह माना जा सकता है। लेकिन vDSO के लिए, पूरे ईएलएफ प्रारूप का एक छोटा सबसेट जानबूझकर चुना जाता है। इसके कई फायदे हैं:

• प्रक्रिया में इस तरह के ईएलएफ की मैपिंग सरल है और इसमें कोई भी जटिल सीमा मामले शामिल नहीं हैं जिन्हें ईएलएफ कार्यक्रमों को पूरी तरह से समर्थन देने की आवश्यकता होती है।
• वीडीएसओ का उपयोग करने के लिए पूरी तरह से कार्यात्मक गतिशील ईएलएफ बंधन की आवश्यकता नहीं होती है। विशेष रूप से, vDSO में गतिशील स्थानांतरण नहीं हैं। किसी ELF फ़ाइल का PT_LOAD सेगमेंट केवल आवश्यक कार्रवाई है।
• वीडीएसओ कोड स्टेटलेस और रीइंटरेंट है। यह विशेष रूप से प्रोसेसर रजिस्टरों और स्टैक के साथ काम करता है। यह न्यूनतम प्रतिबंधों के साथ कई प्रकार के संदर्भों में उपयोग के लिए उपयुक्त बनाता है, जो अनिवार्य एबीआई ऑपरेटिंग सिस्टम का अनुपालन करता है। यह विश्वसनीयता और सुरक्षा के लिए कोड विश्लेषण और सत्यापन को भी सरल बनाता है।

सभी vDSO मेमोरी को दो लगातार खंडों द्वारा दर्शाया गया है, जिनमें से प्रत्येक में पूरे पृष्ठ संरेखित हैं:

1. पहला खंड केवल पढ़ने के लिए है और इसमें ईएलएफ हेडर के साथ-साथ निरंतर डेटा भी शामिल है।
2. दूसरा खंड निष्पादन योग्य है और इसमें vDSO कोड है।

संपूर्ण vDSO छवि में केवल इन दो खंडों के पृष्ठ हैं। ईएलएफ हेडर से निकाले गए केवल दो मानों को वीडीएसओ मेमोरी प्रदर्शित करना आवश्यक है: प्रत्येक सेगमेंट में पृष्ठों की संख्या।

ओएस बूट समय निरंतर डेटा

कुछ सिस्टम कॉल केवल रिटर्न मान हैं जो स्थिर हैं (मान रनटाइम पर अनुरोध किए जाने चाहिए और उपयोगकर्ता-मोड कोड में संकलित नहीं किए जा सकते हैं)। इन मानों को या तो संकलन समय पर कर्नेल में तय किया जाता है, या बूट समय (बूट पैरामीटर और हार्डवेयर पैरामीटर) पर कर्नेल द्वारा निर्धारित किया जाता है। उदाहरण के लिए: zx_system_get_version () , zx_system_get_num_cpus () और zx_ticks_per_second () । उदाहरण के लिए, अंतिम फ़ंक्शन का रिटर्न मान कर्नेल कमांड लाइन पैरामीटर से प्रभावित होता है।

चूँकि ये मान स्थिर होते हैं, इसलिए OS कर्नेल पर वास्तविक सिस्टम कॉल के लिए भुगतान करने का कोई मतलब नहीं है। इसके बजाय, उनका कार्यान्वयन सरल C ++ फ़ंक्शन है जो vDSO निरंतर खंड से पढ़े गए डेटा को लौटाता है। संकलन के दौरान कैप्चर किए गए मान (जैसे सिस्टम के संस्करण स्ट्रिंग) को केवल vDSO में संकलित किया जाता है।

बूट समय पर निर्धारित मानों के लिए, कर्नेल को वीडीएसओ की सामग्री को संशोधित करना चाहिए। यह शुरुआती-निष्पादन योग्य कोड का उपयोग करके किया जाता है जो कर्नेल से पहले उपयोगकर्ता प्रक्रिया शुरू करने से पहले VMO vDSO बनाता है (और इसे VMO विवरणक पास करता है)। संकलन के दौरान, vDSO छवि ( vdso_constants ) से ऑफसेट ELF फ़ाइल से निकाले जाते हैं और फिर कर्नेल में एम्बेड किए जाते हैं। बूट समय पर, कर्नेल अस्थायी रूप से सही मानों (मौजूदा सिस्टम स्टार्टअप के लिए) के साथ संरचना को प्रारंभिक करने के लिए अपने स्वयं के पता स्थान में vdso_constants फैले पृष्ठों को प्रदर्शित करता है।

यह सब सिरदर्द क्यों?

सबसे महत्वपूर्ण कारणों में से एक सुरक्षा है। यही है, अगर कोई हमलावर मनमाना (शेल-) कोड निष्पादित करता है, तो उसे सिस्टम फ़ंक्शन को कॉल करने के लिए vDSO फ़ंक्शन का उपयोग करना होगा। पहली बाधा बनाई गई प्रत्येक प्रक्रिया के लिए vDSO बूट पते के पूर्वोक्त यादृच्छिककरण होगी। और चूंकि ओएस कर्नेल vDSO के VMO (वर्चुअल मेमोरी ऑब्जेक्ट) के लिए जिम्मेदार है, यह एक विशिष्ट प्रक्रिया के लिए पूरी तरह से अलग vDSO को मैप करने का विकल्प चुन सकता है, जिससे खतरनाक (और किसी विशेष प्रक्रिया के लिए आवश्यक नहीं) सिस्टम कॉल। उदाहरण के लिए: आप ड्राइवरों को बच्चे की प्रक्रियाओं को रोकने या MMIO क्षेत्रों को संभालने से रोक सकते हैं। यह हमले की सतह को कम करने के लिए एक महान उपकरण है।

नोट: वर्तमान में, कई vDSO के लिए समर्थन सक्रिय रूप से विकसित किया जा रहा है। पहले से ही एक अवधारणा से कार्यान्वयन और सरल परीक्षण हैं, लेकिन कार्यान्वयन की विश्वसनीयता में सुधार करने और निर्धारित करने के लिए और अधिक काम करने की आवश्यकता है कि कौन से विकल्प उपलब्ध हैं। वर्तमान अवधारणा vDSO छवि विकल्प प्रदान करती है जो केवल पूर्ण vDSO सिस्टम कॉल इंटरफ़ेस का एक सबसेट निर्यात करती है।