इस लेख में, हम पृष्ठ प्रस्तुत करते हैं, एक बहुत ही सामान्य मेमोरी प्रबंधन योजना जिसे हम अपने ओएस में भी लागू करते हैं। लेख बताता है कि मेमोरी अलगाव की आवश्यकता क्यों है, विभाजन कैसे काम करता है, वर्चुअल मेमोरी क्या है और पृष्ठ विखंडन समस्या को कैसे हल करते हैं। हम x86_64 आर्किटेक्चर में मल्टीलेवल पेज टेबल की योजना का भी पता लगाते हैं।

यह ब्लॉग GitHub पर पोस्ट किया गया है । यदि आपके पास कोई प्रश्न या समस्या है, तो वहां संबंधित अनुरोध खोलें।

स्मृति सुरक्षा

ऑपरेटिंग सिस्टम के मुख्य कार्यों में से एक कार्यक्रम को एक दूसरे से अलग करना है। उदाहरण के लिए, एक ब्राउज़र को एक पाठ संपादक के साथ हस्तक्षेप नहीं करना चाहिए। हार्डवेयर और ओएस कार्यान्वयन के आधार पर विभिन्न दृष्टिकोण हैं।

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

X86 पर, मेमोरी की सुरक्षा के लिए दो अलग-अलग तरीकों का समर्थन किया जाता है: विभाजन और पेजिंग ।

विभाजन

सेगमेंटेशन को 1978 में वापस लागू किया गया था, शुरुआत में पता योग्य मेमोरी की मात्रा बढ़ाने के लिए। उस समय, सीपीयू ने केवल 16-बिट पतों का समर्थन किया था, जिसने पता करने योग्य मेमोरी की मात्रा को 64 केबी तक सीमित कर दिया था। इस वॉल्यूम को बढ़ाने के लिए, अतिरिक्त सेगमेंट रजिस्टर पेश किए गए, जिनमें से प्रत्येक में एक ऑफसेट एड्रेस है। CPU स्वचालित रूप से प्रत्येक मेमोरी एक्सेस पर इस ऑफसेट को जोड़ता है, इस प्रकार 1 एमबी तक मेमोरी को संबोधित करता है।

CPU स्वचालित रूप से मेमोरी एक्सेस के प्रकार के आधार पर एक सेगमेंट रजिस्टर का चयन करता है: निर्देश प्राप्त करने के लिए CS कोड सेगमेंट रजिस्टर का उपयोग किया जाता है, और स्टैक ऑपरेशन (पुश / पॉप) के लिए SS स्टैक सेगमेंट रजिस्टर का उपयोग किया जाता है। अन्य निर्देश DS डेटा खंड रजिस्टर या वैकल्पिक ES खंड रजिस्टर का उपयोग करते हैं। बाद में, दो अतिरिक्त खंड रजिस्टर FS और GS को मुफ्त उपयोग के लिए जोड़ा गया था।

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

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

आभासी स्मृति

वर्चुअल मेमोरी का विचार एक भौतिक उपकरण से मेमोरी एड्रेस को अमूर्त करना है। स्टोरेज डिवाइस को सीधे एक्सेस करने के बजाय, सबसे पहले एक रूपांतरण चरण किया जाता है। विभाजन के मामले में, सक्रिय सेगमेंट का ऑफसेट पता अनुवाद चरण में जोड़ा जाता है। एक प्रोग्राम की कल्पना करें जो 0x1234000 ऑफसेट के साथ एक खंड में मेमोरी एड्रेस 0x1234000 तक 0x1111000 : वास्तव में, पता 0x2345000 जाता है।

दो प्रकार के पतों के बीच अंतर करने के लिए, रूपांतरण से पहले के पतों को आभासी कहा जाता है, और रूपांतरण के बाद के पतों को भौतिक कहा जाता है। उनके बीच एक महत्वपूर्ण अंतर है: भौतिक पते अद्वितीय हैं और हमेशा स्मृति में समान अद्वितीय स्थान का संदर्भ देते हैं। दूसरी ओर, आभासी पते अनुवाद कार्य पर निर्भर करते हैं। दो अलग-अलग आभासी पते एक ही भौतिक पते को अच्छी तरह से संदर्भित कर सकते हैं। इसके अलावा, समरूप आभासी पते रूपांतरण के बाद विभिन्न भौतिक पतों का उल्लेख कर सकते हैं।

इस संपत्ति के उपयोगी उपयोग का एक उदाहरण एक ही कार्यक्रम के दो बार समानांतर लॉन्च है:



यहां, एक ही कार्यक्रम दो बार चलता है, लेकिन विभिन्न रूपांतरण कार्यों के साथ। पहले उदाहरण में 100 सेगमेंट का एक खंड है, इसलिए इसके आभासी पते 0-150 भौतिक पते 100-250 में बदल जाते हैं। दूसरे उदाहरण में 300 की एक ऑफसेट है, जो वर्चुअल एड्रेस को 0-150 से भौतिक पते में 300-450 में बदल देता है। यह दोनों कार्यक्रमों को एक ही कोड को निष्पादित करने और एक दूसरे के साथ हस्तक्षेप किए बिना एक ही आभासी पते का उपयोग करने की अनुमति देता है।

एक और लाभ यह है कि अब कार्यक्रमों को भौतिक स्मृति पर मनमाने स्थानों पर रखा जा सकता है। इस प्रकार, ओएस प्रोग्राम को फिर से खोलने की आवश्यकता के बिना उपलब्ध मेमोरी की पूरी राशि का उपयोग करता है।

विखंडन

आभासी और भौतिक पते के बीच का अंतर विभाजन की एक वास्तविक उपलब्धि है। लेकिन एक समस्या है। कल्पना करें कि हम उस कार्यक्रम की तीसरी प्रति चलाना चाहते हैं जिसे हमने ऊपर देखा था:



यद्यपि भौतिक मेमोरी में पर्याप्त स्थान से अधिक है, लेकिन तीसरी प्रति कहीं भी फिट नहीं होती है। समस्या यह है कि उसे स्मृति के निरंतर टुकड़े की आवश्यकता है और हम अलग-अलग स्वतंत्र खंडों का उपयोग नहीं कर सकते।

विखंडन का मुकाबला करने का एक तरीका कार्यक्रम निष्पादन को रोकना है, स्मृति के उपयोग किए गए भागों को एक दूसरे के करीब ले जाएं, रूपांतरण को अपडेट करें, और फिर निष्पादन को फिर से शुरू करें:



अब तीसरा उदाहरण लॉन्च करने के लिए पर्याप्त जगह है।

इस डीफ़्रैग्मेन्टेशन का नुकसान बड़ी मात्रा में मेमोरी की प्रतिलिपि बनाने की आवश्यकता है, जो प्रदर्शन को कम करता है। इस प्रक्रिया को नियमित रूप से तब तक करना पड़ता है जब तक कि स्मृति बहुत अधिक विखंडित न हो जाए। प्रदर्शन अप्रत्याशित हो जाता है, कार्यक्रम किसी भी समय बंद हो जाते हैं और प्रतिक्रिया देना बंद कर सकते हैं।

अधिकांश प्रणालियों में विभाजन का उपयोग नहीं किए जाने के कारणों में से एक है। वास्तव में, यह x86 पर 64-बिट मोड में भी समर्थित नहीं है। विभाजन के बजाय, पृष्ठों का उपयोग किया जाता है जो विखंडन की समस्या को पूरी तरह से समाप्त करते हैं।

पृष्ठ स्मृति का संगठन

आभासी और भौतिक मेमोरी के स्थान को एक निश्चित आकार के छोटे ब्लॉक में विभाजित करने का विचार है। वर्चुअल मेमोरी ब्लॉक को पेज कहा जाता है, और फिजिकल एड्रेस स्पेस ब्लॉक को फ्रेम कहा जाता है। प्रत्येक पृष्ठ को व्यक्तिगत रूप से एक फ्रेम में मैप किया जाता है, जो आपको आसन्न भौतिक फ़्रेमों के बीच स्मृति के बड़े क्षेत्रों को विभाजित करने की अनुमति देता है।

लाभ स्पष्ट हो जाता है यदि आप एक खंडित स्मृति स्थान के साथ उदाहरण दोहराते हैं, लेकिन इस बार विभाजन के बजाय पृष्ठों का उपयोग कर रहे हैं:



इस उदाहरण में, पृष्ठ का आकार 50 बाइट्स है, अर्थात, स्मृति क्षेत्रों में से प्रत्येक को तीन पृष्ठों में विभाजित किया गया है। प्रत्येक पृष्ठ को एक अलग फ्रेम में मैप किया जाता है, इसलिए आभासी मेमोरी के एक आकस्मिक क्षेत्र को अलग-अलग भौतिक फ़्रेमों में मैप किया जा सकता है। यह आपको डीफ़्रैग्मेन्टेशन के बिना कार्यक्रम के तीसरे उदाहरण को चलाने की अनुमति देता है।

छिपा हुआ विखंडन

विभाजन की तुलना में, एक पेजिंग संगठन कई बड़े, चर-आकार वाले क्षेत्रों के बजाय कई छोटे निश्चित आकार के मेमोरी क्षेत्रों का उपयोग करता है। प्रत्येक फ्रेम का आकार एक जैसा होता है, इसलिए फ्रेम बहुत छोटा होने के कारण विखंडन संभव नहीं है।

लेकिन यह केवल एक उपस्थिति है । वास्तव में, विखंडन का एक छिपा हुआ रूप है, इस तथ्य के कारण तथाकथित आंतरिक विखंडन है कि प्रत्येक मेमोरी क्षेत्र बिल्कुल पृष्ठ आकार का एक बहु नहीं है। उपरोक्त उदाहरण में कल्पना करें, आकार 101 का एक कार्यक्रम: इसे अभी भी 50 के आकार के तीन पृष्ठों की आवश्यकता होगी, इसलिए यह आपकी ज़रूरत से अधिक 49 बाइट्स लेगा। स्पष्टता के लिए, विभाजन के कारण विखंडन को बाहरी विखंडन कहा जाता है ।

आंतरिक विखंडन में कुछ भी अच्छा नहीं है, लेकिन अक्सर यह बाहरी विखंडन की तुलना में कम बुराई है। अतिरिक्त मेमोरी अभी भी खपत होती है, लेकिन अब आपको इसे डीफ़्रैग्मेन्ट करने की आवश्यकता नहीं है, और विखंडन की मात्रा अनुमानित है (औसतन, प्रति मेमोरी क्षेत्र आधा पृष्ठ)।

पेज टेबल्स

हमने देखा कि लाखों संभावित पृष्ठों में से प्रत्येक को व्यक्तिगत रूप से एक फ्रेम में मैप किया गया है। यह पता अनुवाद जानकारी कहीं संग्रहीत करने की आवश्यकता है। सेगमेंट करते समय, प्रत्येक सक्रिय मेमोरी क्षेत्र के लिए अलग-अलग सेगमेंट रजिस्टर का उपयोग किया जाता है, जो पृष्ठों के मामले में असंभव है, क्योंकि रजिस्टरों की तुलना में उनमें से बहुत अधिक हैं। इसके बजाय, यह एक पृष्ठ तालिका नामक संरचना का उपयोग करता है।

उपरोक्त उदाहरण के लिए, टेबल इस तरह दिखाई देंगे:



जैसा कि आप देख सकते हैं, कार्यक्रम के प्रत्येक उदाहरण का अपना पेज टेबल है। वर्तमान सक्रिय तालिका के लिए एक संकेतक सीपीयू के एक विशेष रजिस्टर में संग्रहीत किया जाता है। x86 इसे CR3 कहा जाता है। कार्यक्रम के प्रत्येक उदाहरण को शुरू करने से पहले, ऑपरेटिंग सिस्टम को वहां सही पेज टेबल पर एक पॉइंटर लोड करना होगा।

जितनी बार मेमोरी एक्सेस की जाती है, सीपीयू रजिस्टर से टेबल पॉइंटर को पढ़ता है और टेबल में संबंधित फ्रेम को खोजता है। यह एक पूरी तरह से हार्डवेयर फ़ंक्शन है जो एक रनिंग प्रोग्राम के लिए पूरी तरह से पारदर्शी रूप से चलता है। प्रक्रिया को गति देने के लिए, कई प्रोसेसर आर्किटेक्चर के पास एक विशेष कैश है जो नवीनतम रूपांतरणों के परिणामों को याद करता है।

आर्किटेक्चर के आधार पर, पेज टेबल के फ्लैग फील्ड में अनुमतियों जैसी विशेषताओं को भी संग्रहीत किया जा सकता है। उपरोक्त उदाहरण में, r/w ध्वज पृष्ठ को पठनीय और लिखने योग्य बनाता है।

स्तरित पेज टेबल्स

सरल पृष्ठ तालिकाओं में बड़े पते के रिक्त स्थान के साथ एक समस्या है: स्मृति व्यर्थ है। उदाहरण के लिए, कार्यक्रम चार आभासी पेजों 0 , 1_000_000 , 1_000_050 और 1_000_100 का उपयोग करता है (हम अंकों के विभाजक के रूप में _ उपयोग करते हैं):



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

मेमोरी लॉस को कम करने के लिए, आप दो-स्तरीय संगठन का उपयोग कर सकते हैं। विचार यह है कि हम विभिन्न क्षेत्रों के लिए अलग-अलग तालिकाओं का उपयोग करते हैं। एक अतिरिक्त तालिका, जिसे द्वितीय-स्तरीय पृष्ठ तालिका कहा जाता है, पता क्षेत्रों और प्रथम-स्तरीय पृष्ठ तालिकाओं के बीच परिवर्तित होती है।

यह सबसे अच्छा उदाहरण द्वारा समझाया गया है। हम परिभाषित करते हैं कि प्रत्येक स्तर 1 पृष्ठ तालिका 10_000 आकार के क्षेत्र के लिए जिम्मेदार है। फिर उपरोक्त उदाहरण में निम्न तालिकाएँ मौजूद होंगी:



पेज 0 10_000 बाइट्स के पहले क्षेत्र में 10_000 , इसलिए यह दूसरे स्तर के पेज टेबल में पहले रिकॉर्ड का उपयोग करता है। यह प्रविष्टि पहले स्तर के T1 पृष्ठ तालिका की ओर इशारा करती है, जो यह निर्धारित करती है कि पृष्ठ 0 फ्रेम 0 को संदर्भित करता है।

पृष्ठ 1_000_000 , 1_000_050 और 1_000_100 के 100 वें बाइट क्षेत्र में 10_000 , इसलिए वे स्तर 2 पृष्ठ तालिका के 100 वें रिकॉर्ड का उपयोग करते हैं। यह रिकॉर्ड एक अन्य प्रथम स्तर तालिका T2 की ओर 10_000 करता है, जो तीन पृष्ठों को 100, 150 और 200 में तब्दील करता है। नोट यह कि प्रथम स्तर की तालिका में पृष्ठ पते में एक क्षेत्र ऑफसेट नहीं है, इसलिए, उदाहरण के लिए, पृष्ठ 1_000_050 का रिकॉर्ड केवल 50 ।

हमारे पास अभी भी दूसरे स्तर की तालिका में 100 खाली प्रविष्टियां हैं, लेकिन यह पिछले मिलियन की तुलना में बहुत कम है। बचत का कारण यह है कि आपको 10_000 और 1_000_000 बीच 10_000 मेमोरी वाले क्षेत्रों के लिए पहले स्तर के पेज टेबल बनाने की आवश्यकता नहीं है।

दो-स्तरीय तालिकाओं के सिद्धांत को तीन, चार या अधिक स्तरों तक बढ़ाया जा सकता है। सामान्य तौर पर, ऐसी प्रणाली को बहुस्तरीय या पदानुक्रमित पृष्ठ तालिका कहा जाता है।

पृष्ठ संगठन और बहु-स्तरीय तालिकाओं को जानते हुए, आप देख सकते हैं कि x86_64 आर्किटेक्चर में पृष्ठ संगठन कैसे लागू किया जाता है (हम मानते हैं कि प्रोसेसर 64-बिट मोड में काम करता है)।

पृष्ठ संगठन x86_64 पर

X86_64 आर्किटेक्चर 4 KB पृष्ठ आकार के साथ चार-स्तरीय तालिका का उपयोग करता है। स्तर के बावजूद, प्रत्येक पृष्ठ तालिका में 512 तत्व हैं। प्रत्येक रिकॉर्ड में 8 बाइट्स का आकार होता है, इसलिए तालिकाओं का आकार 512 × 8 बाइट्स = 4 KB है।



जैसा कि आप देख सकते हैं, प्रत्येक टेबल इंडेक्स में 9 बिट्स होते हैं, जो समझ में आता है, क्योंकि टेबल में 2 ^ 9 = 512 प्रविष्टियां हैं। नीचे के 12 बिट्स 4-किलोबाइट पेज ऑफ़सेट (2 ^ 12 बाइट्स = 4 KB) हैं। बिट्स 48 से 64 खारिज कर दिया जाता है, इसलिए x86_64 वास्तव में 64-बिट सिस्टम नहीं है, लेकिन केवल 48-बिट पते का समर्थन करता है। 5-स्तरीय पृष्ठ तालिका के माध्यम से पता आकार को 57 बिट तक विस्तारित करने की योजना है, लेकिन ऐसा प्रोसेसर अभी तक नहीं बनाया गया है।

हालाँकि 48 से 64 बिट्स को छोड़ दिया गया है, वे मनमाने मूल्यों पर सेट नहीं हो सकते हैं। इस सीमा में सभी बिट्स को अद्वितीय पते को संरक्षित करने और भविष्य के विस्तार की अनुमति देने के लिए बिट 47 की प्रतियां होनी चाहिए, उदाहरण के लिए, 5-स्तरीय पृष्ठ तालिका में। इसे साइन-एक्सटेंशन कहा जाता है, क्योंकि यह अतिरिक्त कोड में साइन एक्सटेंशन के समान है। यदि पता गलत तरीके से विस्तारित है, तो सीपीयू एक अपवाद फेंकता है।

रूपांतरण का उदाहरण

आइए एक उदाहरण देखें कि अनुवाद कैसे काम करता है:



स्तर 4 पृष्ठों की वर्तमान सक्रिय पृष्ठ तालिका का भौतिक पता, जो इस स्तर के पृष्ठों की जड़ तालिका है, CR3 में संग्रहीत है। प्रत्येक पृष्ठ तालिका प्रविष्टि तब अगले स्तर तालिका के भौतिक फ्रेम की ओर इशारा करती है। एक स्तर 1 तालिका प्रविष्टि प्रदर्शित फ्रेम को इंगित करती है। कृपया ध्यान दें कि पृष्ठ तालिकाओं में सभी पते भौतिक हैं और आभासी नहीं हैं, क्योंकि अन्यथा सीपीयू को इन पतों को बदलने की आवश्यकता होगी (जिससे अनंत पुनरावृत्ति हो सकती है)।

उपरोक्त पदानुक्रम दो पृष्ठों को (नीले रंग में) परिवर्तित करता है। सूचकांकों से, हम यह निष्कर्ष निकाल सकते हैं कि इन पृष्ठों के आभासी पते 0x803fe7f000 और 0x803FE00000 । आइए देखें कि क्या होता है जब कोई प्रोग्राम 0x803FE7F5CE पते पर मेमोरी पढ़ने की कोशिश करता है। सबसे पहले, पते को बाइनरी में बदलें और पेज टेबल इंडेक्स और पते के लिए ऑफसेट निर्धारित करें:



इन अनुक्रमों का उपयोग करते हुए, हम अब पृष्ठ तालिकाओं के पदानुक्रम के माध्यम से जा सकते हैं और संबंधित फ्रेम पा सकते हैं:

• CR3 से चौथे स्तर की तालिका का पता पढ़ें।
• चौथे स्तर का सूचकांक 1 है, इसलिए हम इस तालिका में सूचकांक 1 के साथ रिकॉर्ड को देखते हैं। वह कहती है कि एक स्तर 3 तालिका 16 KB पर संग्रहीत है।
• हम इस पते से तीसरे स्तर की तालिका लोड करते हैं और सूचकांक 0 के साथ रिकॉर्ड को देखते हैं, जो 24 केबी में दूसरे स्तर की तालिका की ओर इशारा करता है।
• दूसरे स्तर का सूचकांक 511 है, इसलिए हम पहले स्तर की तालिका के पते का पता लगाने के लिए इस पृष्ठ पर अंतिम रिकॉर्ड की तलाश कर रहे हैं।
• प्रथम स्तर की तालिका में सूचकांक 127 के साथ प्रविष्टि से, हमें अंत में पता चलता है कि पृष्ठ हेक्साडेसिमल प्रारूप में 12 KB फ्रेम या 0xc000 से मेल खाता है।
• अंतिम चरण भौतिक पते को प्राप्त करने के लिए फ़्रेम पते में एक ऑफसेट जोड़ना है: 0xc000 + 0x5ce = 0xc5ce।

पहले स्तर की तालिका में पृष्ठ के लिए, r ध्वज निर्दिष्ट किया गया है, अर्थात, केवल पढ़ने की अनुमति है। यदि हम वहां रिकॉर्ड करने का प्रयास करते हैं तो एक अपवाद को हार्डवेयर स्तर पर फेंक दिया जाएगा। उच्च-स्तरीय तालिकाओं की अनुमतियाँ निचले स्तरों तक विस्तारित होती हैं, इसलिए यदि हम तीसरे स्तर पर केवल-पढ़ने के लिए ध्वज सेट करते हैं, तो निचले स्तर का एक भी बाद का पृष्ठ लेखन योग्य नहीं होगा, भले ही वहाँ झंडे हों जो लिखने की अनुमति दें।

यद्यपि यह उदाहरण प्रत्येक तालिका के केवल एक उदाहरण का उपयोग करता है, आमतौर पर प्रत्येक पता स्थान में प्रत्येक स्तर के कई उदाहरण हैं। अधिकतम:

• चौथे स्तर की एक तालिका,
• तीसरे स्तर की 512 टेबल (चूंकि चौथे स्तर की तालिका में 512 रिकॉर्ड हैं),
• 512 * 512 दूसरे-स्तरीय टेबल (चूंकि तीसरे-स्तर के प्रत्येक टेबल में 512 प्रविष्टियां हैं), और
• पहले स्तर के 512 * 512 * 512 टेबल (दूसरे स्तर की प्रत्येक तालिका के लिए 512 रिकॉर्ड)।

पृष्ठ तालिका प्रारूप

X86_64 आर्किटेक्चर में, पेज टेबल अनिवार्य रूप से 512 प्रविष्टियों की सरणियाँ हैं। जंग सिंटैक्स में:

 #[repr(align(4096))] pub struct PageTable { entries: [PageTableEntry; 512], } 

जैसा कि repr विशेषता में दर्शाया गया है, तालिकाओं को पृष्ठ पर, अर्थात, 4 केबी सीमा पर संरेखित किया जाना चाहिए। यह आवश्यकता सुनिश्चित करती है कि तालिका हमेशा पूरे पृष्ठ को अच्छी तरह से भर दे, जिससे प्रविष्टियाँ बहुत कॉम्पैक्ट हो जाएँ।

प्रत्येक रिकॉर्ड का आकार 8 बाइट्स (64 बिट्स) और निम्न प्रारूप है:

बिट	नाम	मूल्य
0	वर्तमान	स्मृति में पृष्ठ
1	लिखने योग्य	रिकॉर्ड की अनुमति दी
2	उपयोगकर्ता सुलभ	यदि बिट सेट नहीं है, तो केवल कर्नेल के पास पृष्ठ तक पहुंच है
3	कैशिंग के माध्यम से लिखें	सीधे स्मृति में लिखें
4	कैश अक्षम करें	इस पृष्ठ के लिए कैश अक्षम करें
5	अभिगम	सीपीयू इस बिट को सेट करता है जब पेज उपयोग में होता है।
6	गंदा	सीपीयू इस बिट को पेज पर लिखते समय सेट करता है
7	विशाल पृष्ठ / अशक्त	पी 1 और पी 4 में शून्य बिट पी 3 में 1 केबी पेज, पी 2 में 2 एमबी पेज बनाता है
8	वैश्विक	पता स्थान स्विच करते समय पृष्ठ कैश से भरा नहीं है (सीआर 4 रजिस्टर का PGE बिट सेट होना चाहिए)
9-11	उपलब्ध	ओएस उन्हें स्वतंत्र रूप से उपयोग कर सकते हैं
12-51	भौतिक पता	पृष्ठ-फ़्रेम या निम्न पृष्ठ तालिका का ५२-बिट भौतिक पता
52-62	उपलब्ध	ओएस उन्हें स्वतंत्र रूप से उपयोग कर सकते हैं
63	कोई अमल नहीं	इस पृष्ठ पर कोड निष्पादन पर रोक (NXE बिट को EFER रजिस्टर में सेट किया जाना चाहिए)

हम देखते हैं कि केवल 12-51 बिट्स का उपयोग फ्रेम के भौतिक पते को संग्रहीत करने के लिए किया जाता है, और बाकी काम झंडे के रूप में किया जाता है या ऑपरेटिंग सिस्टम द्वारा स्वतंत्र रूप से उपयोग किया जा सकता है। यह संभव है क्योंकि हम हमेशा या तो 4096-बाइट-संरेखित पते पर, या तालिकाओं के एक गठबंधन पृष्ठ पर, या संबंधित फ्रेम की शुरुआत में इंगित करते हैं। इसका मतलब है कि बिट्स 0-11 हमेशा शून्य होते हैं, इसलिए उन्हें संग्रहीत नहीं किया जा सकता है, वे पते का उपयोग करने से पहले बस हार्डवेयर स्तर पर रीसेट हो जाते हैं। वही 52-63 के बिट्स पर लागू होता है, क्योंकि x86_64 आर्किटेक्चर केवल 52-बिट भौतिक पतों (और केवल 48-बिट वर्चुअल पतों) का समर्थन करता है।

आइए उपलब्ध झंडों पर एक नज़र डालें:

• present ध्वज प्रदर्शित पृष्ठों को गैर-प्रदर्शित वाले से अलग करता है। इसका उपयोग मुख्य स्मृति पूर्ण होने पर डिस्क को अस्थायी रूप से सहेजने के लिए पृष्ठों को करने के लिए किया जा सकता है। अगली बार जब पृष्ठ एक्सेस किया जाता है, तो एक विशेष पेजफॉल्ट अपवाद होता है, जिसमें ओएस डिस्क से पृष्ठ को स्वैप करके प्रतिक्रिया करता है - कार्यक्रम काम करना जारी रखता है।
• writable और no execute writable झंडे यह निर्धारित करते हैं कि पृष्ठ की सामग्री लेखन योग्य है या इसमें निष्पादन योग्य निर्देश हैं।
• पृष्ठ पर पढ़ने या लिखने पर प्रोसेसर द्वारा accessed और dirty झंडे स्वचालित रूप से सेट किए जाते हैं। ओएस इस जानकारी का उपयोग कर सकता है, उदाहरण के लिए, यदि यह पृष्ठों की अदला-बदली करता है या यह देखने के लिए जांचता है कि क्या पिछले पंपिंग से डिस्क में पेज की सामग्री बदल गई है।
• write through caching फ़्लैग के write through caching और disable cache फ़्लैग को disable cache करने से आप प्रत्येक पृष्ठ के लिए कैश को अलग-अलग प्रबंधित कर सकते हैं।
• user accessible ध्वज पृष्ठ को उपयोगकर्ता स्थान से कोड के लिए सुलभ बनाता है, अन्यथा यह केवल कर्नेल के लिए उपलब्ध है। इस फ़ंक्शन का उपयोग सिस्टम कॉल को गति देने के लिए किया जा सकता है, जबकि उपयोगकर्ता प्रोग्राम चल रहा है, तो कर्नेल के लिए पता मैपिंग को बनाए रखें। हालाँकि, स्पेक्टर भेद्यता इन पृष्ठों को उपयोगकर्ता स्थान के कार्यक्रमों द्वारा पढ़ा जा सकता है।
• global , (. TLB ) (address space switch). user accessible .
• huge page , 2 3 . 512 : 2 = 512 × 4 , 1 = 512 × 2 . .

X86_64 आर्किटेक्चर पृष्ठ तालिकाओं और उनके रिकॉर्ड के प्रारूप को परिभाषित करता है , इसलिए हमें इन संरचनाओं को स्वयं बनाने की आवश्यकता नहीं है।

सहयोगी अनुवाद बफर (TLB)

चार स्तरों के कारण, प्रत्येक पते के अनुवाद के लिए चार मेमोरी एक्सेस की आवश्यकता होती है। प्रदर्शन कारणों से, x86_64 तथाकथित साहचर्य अनुवाद बफर (TLB) में पिछले कुछ अनुवादों को कैश करता है। यदि आप अभी भी कैश में हैं, तो यह रूपांतरण को छोड़ देता है।

अन्य प्रोसेसर कैश के विपरीत, टीएलबी पूरी तरह से पारदर्शी नहीं है, पेज टेबल की सामग्री को बदलते समय रूपांतरणों को अपडेट या डिलीट नहीं करता है। इसका मतलब यह है कि जब भी यह पृष्ठ तालिका को संशोधित करता है, कर्नेल को टीएलबी को ही अपडेट करना चाहिए। ऐसा करने के लिए, एक विशेष सीपीयू निर्देश कहा जाता है invlpg(अमान्य पृष्ठ), जो टीएलबी से निर्दिष्ट पृष्ठ के अनुवाद को हटा देता है, ताकि अगली बार यह पृष्ठ तालिका से फिर से लोड हो जाए। TLB रजिस्टर रीलोड द्वारा पूरी तरह से साफ हो गया हैCR3वह पता स्थान स्विच की नकल करता है। दोनों विकल्प Rust में tlb मॉड्यूल के माध्यम से उपलब्ध हैं।

प्रत्येक पृष्ठ तालिका परिवर्तन के बाद टीएलबी को साफ करना याद रखना महत्वपूर्ण है, अन्यथा सीपीयू पुराने अनुवाद का उपयोग करना जारी रखेगा, जिससे अप्रत्याशित त्रुटियां हो सकती हैं जो डीबग करना बहुत कठिन हैं।

कार्यान्वयन

हमने एक बात का उल्लेख नहीं किया है: हमारा कोर पहले से ही पेज संगठन का समर्थन करता है । "रस्ट पर मिनिमल कर्नेल" लेख से बूटलोडर ने पहले से ही चार-स्तरीय पदानुक्रम स्थापित किया है जो हमारे कर्नेल के प्रत्येक पृष्ठ को एक भौतिक फ्रेम में मैप करता है, क्योंकि x86_64 पर 64-बिट मोड में पेज संगठन की आवश्यकता होती है।

इसका मतलब है कि हमारे मूल में सभी मेमोरी पते आभासी हैं। पते पर वीजीए बफर तक पहुंच 0xb8000केवल इसलिए काम की गई क्योंकि बूटलोडर पहचानकर्ता ने इस पृष्ठ को मेमोरी में अनुवाद किया, अर्थात, इसने वर्चुअल पेज 0xb8000को भौतिक फ्रेम में मैप किया 0xb8000।

पृष्ठ संगठन के लिए धन्यवाद, कर्नेल पहले से ही अपेक्षाकृत सुरक्षित है: अनुमेय स्मृति से परे हर एक्सेस पृष्ठ त्रुटि का कारण बनता है, और भौतिक मेमोरी को लिखने की अनुमति नहीं देता है। लोडर ने प्रत्येक पृष्ठ के लिए सही एक्सेस अनुमतियाँ भी निर्धारित की हैं: केवल कोड वाले पृष्ठ ही निष्पादन योग्य होंगे, और डेटा वाले केवल पृष्ठ ही लिखने के लिए उपलब्ध हैं

पृष्ठ त्रुटियां (पेजफॉल्ट)

आइए कर्नेल के बाहर मेमोरी एक्सेस करके पेजफॉल्ट को कॉल करने का प्रयास करें। सबसे पहले, एक त्रुटि हैंडलर बनाएं और सामान्य प्रकार की दोहरी त्रुटि के बजाय एक विशिष्ट अपवाद देखने के लिए इसे हमारे IDT में पंजीकृत करें:

 // in src/interrupts.rs lazy_static! { static ref IDT: InterruptDescriptorTable = { let mut idt = InterruptDescriptorTable::new(); […] idt.page_fault.set_handler_fn(page_fault_handler); // new idt }; } use x86_64::structures::idt::PageFaultErrorCode; extern "x86-interrupt" fn page_fault_handler( stack_frame: &mut ExceptionStackFrame, _error_code: PageFaultErrorCode, ) { use crate::hlt_loop; use x86_64::registers::control::Cr2; println!("EXCEPTION: PAGE FAULT"); println!("Accessed Address: {:?}", Cr2::read()); println!("{:#?}", stack_frame); hlt_loop(); } 

यदि पृष्ठ विफल रहता है, तो CPU स्वचालित रूप से केस सेट करता है CR2। इसमें पृष्ठ का वर्चुअल पता होता है जो विफलता का कारण बना। इस पते को पढ़ने और प्रदर्शित करने के लिए, फ़ंक्शन का उपयोग करें Cr2::read। आमतौर पर, प्रकार PageFaultErrorCodeत्रुटि के कारण मेमोरी एक्सेस के प्रकार के बारे में अधिक जानकारी देता है, लेकिन LLVM बग के कारण एक अमान्य त्रुटि कोड प्रसारित होता है , इसलिए हम इस जानकारी को अभी के लिए अनदेखा कर देंगे। जब तक हम पृष्ठ त्रुटि को हल नहीं करते, तब तक प्रोग्राम निष्पादन जारी नहीं रखा जा सकता है, इसलिए अंत में डालें hlt_loop।

अब हम कर्नेल के बाहर मेमोरी तक पहुँच प्राप्त करते हैं:

 // in src/main.rs #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start() -> ! { use blog_os::interrupts::PICS; println!("Hello World{}", "!"); // set up the IDT first, otherwise we would enter a boot loop instead of // invoking our page fault handler blog_os::gdt::init(); blog_os::interrupts::init_idt(); unsafe { PICS.lock().initialize() }; x86_64::instructions::interrupts::enable(); // new let ptr = 0xdeadbeaf as *mut u32; unsafe { *ptr = 42; } println!("It did not crash!"); blog_os::hlt_loop(); } 

शुरू करने के बाद, हम देखते हैं कि पृष्ठ त्रुटि हैंडलर कहा जाता है:



रजिस्टर में CR2वास्तव में वह पता होता है जिसे 0xdeadbeafहम एक्सेस करना चाहते थे।

वर्तमान अनुदेश सूचक है 0x20430a, इसलिए हम जानते हैं कि यह पता एक कोड पृष्ठ की ओर इशारा करता है। कोड पृष्ठ केवल-पढ़ने वाले लोडर द्वारा प्रदर्शित किए जाते हैं, इसलिए इस पते से पढ़ना काम करता है, और लिखने से त्रुटि होगी। सूचक 0xdeadbeafको इसमें बदलने का प्रयास करें 0x20430a:

 // Note: The actual address might be different for you. Use the address that // your page fault handler reports. let ptr = 0x20430a as *mut u32; // read from a code page -> works unsafe { let x = *ptr; } // write to a code page -> page fault unsafe { *ptr = 42; } 

यदि हम अंतिम पंक्ति पर टिप्पणी करते हैं, तो हम यह सुनिश्चित कर सकते हैं कि रीडिंग कार्य करता है, और लेखन पेजफॉल्ट त्रुटि का कारण बनता है।

पृष्ठ तालिकाओं तक पहुंच

अब कर्नेल के लिए पृष्ठ तालिकाओं पर एक नज़र डालें:

 // in src/main.rs #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start() -> ! { use x86_64::registers::control::Cr3; let (level_4_page_table, _) = Cr3::read(); println!("Level 4 page table at: {:?}", level_4_page_table.start_address()); […] } 

चौथे स्तर के पृष्ठों की वर्तमान सक्रिय तालिका रजिस्टर Cr3::readसे x86_64रिटर्न से समारोह CR3। एक युगल लौटता है PhysFrameऔर Cr3Flags। हम केवल पहले में रुचि रखते हैं।

शुरू करने के बाद, हम इस परिणाम को देखते हैं:

Level 4 page table at: PhysAddr(0x1000)

इस प्रकार, वर्तमान में, चौथे स्तर के पृष्ठों की सक्रिय तालिका पते पर भौतिक मेमोरी में संग्रहीत होती है 0x1000जैसा कि प्रकार द्वारा इंगित किया गया है PhysAddr। अब सवाल यह है कि इस तालिका को कर्नेल से कैसे एक्सेस किया जाए?

पेज संगठन के साथ, भौतिक मेमोरी तक सीधी पहुंच संभव नहीं है, अन्यथा प्रोग्राम आसानी से सुरक्षा को बायपास करने और अन्य कार्यक्रमों की मेमोरी तक पहुंच प्राप्त करने में सक्षम होंगे। इस प्रकार, पहुँच प्राप्त करने का एकमात्र तरीका कुछ आभासी पृष्ठ के माध्यम से है, जिसका भौतिक फ्रेम में अनुवाद किया गया है0x1000। यह एक विशिष्ट समस्या है क्योंकि कर्नेल को नियमित रूप से पृष्ठ तालिकाओं का उपयोग करना चाहिए, उदाहरण के लिए, जब एक नए धागे के लिए एक स्टैक आवंटित किया जाता है।

इस समस्या के समाधान को अगले लेख में विस्तार से वर्णित किया जाएगा। अभी के लिए, हम केवल यह कहते हैं कि लोडर एक विधि का उपयोग करता है जिसे पुनरावर्ती पृष्ठ सारणी कहते हैं । आभासी पता स्थान का अंतिम पृष्ठ है 0xffff_ffff_ffff_f000, हम इस तालिका में कुछ प्रविष्टियों को पढ़ने के लिए इसका उपयोग करते हैं:

 // in src/main.rs #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start() -> ! { let level_4_table_pointer = 0xffff_ffff_ffff_f000 as *const u64; for i in 0..10 { let entry = unsafe { *level_4_table_pointer.offset(i) }; println!("Entry {}: {:#x}", i, entry); } […] } 

हमने पिछले वर्चुअल पेज का पता एक पॉइंटर को कम कर दिया है u64। जैसा कि पिछले खंड में कहा गया है, प्रत्येक पृष्ठ तालिका प्रविष्टि आकार में 8 बाइट्स (64 बिट्स) है, और इसलिए u64बिल्कुल एक प्रविष्टि का प्रतिनिधित्व करती है। लूप का उपयोग करते हुए, forहम तालिका के पहले 10 रिकॉर्ड प्रदर्शित करते हैं। लूप के अंदर, हम पॉइंटर से सीधे पढ़ने और पॉइंटर offsetकी गणना करने के लिए एक असुरक्षित ब्लॉक का उपयोग करते हैं ।

शुरू करने के बाद हम निम्न परिणाम देखें:



प्रारूप के अनुसार ऊपर वर्णित है, मूल्य 0x2023रिकॉर्डिंग साधन होने झंडे 0 present, writable, accessedएक फ्रेम में और अनुवाद 0x2000। रिकॉर्ड 1 को फ्रेम में प्रसारित किया गया है 0x6e2000और इसमें समान झंडे, प्लस हैंdirty। प्रविष्टियां 2-9 गायब हैं, इसलिए इन वर्चुअल एड्रेस रेंज को किसी भी भौतिक पते पर मैप नहीं किया जाता है।

असुरक्षित संकेत के साथ प्रत्यक्ष रूप से कार्य करने के बजाय आप एक प्रकार का उपयोग कर सकते हैं PageTableकी x86_64:

 // in src/main.rs #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start() -> ! { use x86_64::structures::paging::PageTable; let level_4_table_ptr = 0xffff_ffff_ffff_f000 as *const PageTable; let level_4_table = unsafe {&*level_4_table_ptr}; for i in 0..10 { println!("Entry {}: {:?}", i, level_4_table[i]); } […] } 

यहां हम पॉइंटर को 0xffff_ffff_ffff_f000पहले एक पॉइंटर असाइन करते हैं , और फिर इसे रस्ट लिंक में परिवर्तित करते हैं। ऑपरेशन अभी भी असुरक्षित है, क्योंकि कंपाइलर को पता नहीं चल सकता है कि इस पते तक पहुंच वैध है। लेकिन रूपांतरण के बाद, हमारे पास एक सुरक्षित प्रकार है &PageTableजो इंडेक्सिंग संचालन की सुरक्षित, सत्यापित सीमाओं के माध्यम से व्यक्तिगत रिकॉर्ड तक पहुंच प्रदान करता है ।

x86_64भी तुरन्त निशानी नहीं लगाई देखने के लिए अलग-अलग रिकॉर्ड के लिए कुछ अमूर्त प्रदान करता है:



अगले कदम - 0 या पेज तालिका स्तर 3. करने के लिए लिखने 1 लिखने के लिए चिह्नों का अनुसरण करें लेकिन अब हम फिर से समस्या यह है कि उठता है 0x2000, और 0x6e5000कर रहे हैं भौतिक पते, इसलिए हम नहीं हम उनके लिए सीधी पहुँच प्राप्त कर सकते हैं। यह समस्या अगले लेख में हल की जाएगी।

सारांश

लेख स्मृति की रक्षा के दो तरीके प्रस्तुत करता है: विभाजन और पृष्ठ संगठन। पहली विधि चर-आकार के स्मृति क्षेत्रों का उपयोग करती है और बाहरी विखंडन से ग्रस्त होती है, दूसरा निश्चित आकार के पृष्ठों का उपयोग करता है और अभिगम अधिकारों पर अधिक नियंत्रण रखता है।

एक पृष्ठ संगठन एक या अधिक स्तरों की तालिकाओं में पृष्ठ अनुवाद जानकारी संग्रहीत करता है। X86_64 आर्किटेक्चर 4 KB के पृष्ठ आकार के साथ चार-स्तरीय तालिकाओं का उपयोग करता है। उपकरण स्वचालित रूप से पृष्ठ तालिकाओं को दरकिनार कर देता है और सहयोगी अनुवाद बफर (TLB) में रूपांतरण परिणामों को कैश करता है। पेज टेबल बदलते समय, इसे साफ करने के लिए मजबूर किया जाना चाहिए।

हमने पाया कि हमारा कोर पहले से ही पेज संगठन का समर्थन करता है, और मेमोरी में अनधिकृत पहुंच पेजफॉल्ट को छोड़ देता है। हमने वर्तमान में सक्रिय पृष्ठ तालिकाओं को एक्सेस करने का प्रयास किया, लेकिन केवल चौथे-स्तरीय तालिका तक पहुंचने में कामयाब रहे, क्योंकि पृष्ठ पते भौतिक पते संग्रहीत करते हैं, और हम उन्हें सीधे कर्नेल से एक्सेस नहीं कर सकते।

आगे क्या है?

निम्नलिखित लेख उन मूलभूत नींव पर आधारित है जो अब हमने सीखे हैं। पृष्ठ तालिका को कर्नेल से एक्सेस करने के लिए, एक उन्नत तकनीक जिसे पुनरावर्ती पृष्ठ तालिकाओं कहा जाता है, का उपयोग तालिका पदानुक्रम को पार करने और प्रोग्रामेटिक एड्रेस ट्रांसलेशन को लागू करने के लिए किया जाता है। लेख यह भी बताता है कि पेज टेबल में नए अनुवाद कैसे बनाएं।