मैंने एक लेख लिखने का फैसला किया, और यदि संभव हो, तो बेयर बोन एक्स 86 डिवाइस और ऑपरेटिंग सिस्टम के संगठन दोनों के स्वतंत्र अनुसंधान के अपने अनुभव को साझा करने के लिए लेखों की एक श्रृंखला। फिलहाल, मेरी हैक को ऑपरेटिंग सिस्टम भी नहीं कहा जा सकता है - यह एक छोटा कर्नेल है जो मल्टीबूट (GRUB) से बूट हो सकता है, वास्तविक और वर्चुअल मेमोरी को प्रबंधित कर सकता है, और एक प्रोसेसर पर मल्टीटास्किंग मोड में कई बेकार कार्य भी कर सकता है।

विकास के दौरान, मैंने अपने आप को एक नया लिनक्स लिखने का लक्ष्य निर्धारित नहीं किया (हालांकि, मैं मानता हूं, मैंने इसके बारे में 5 साल पहले सपना देखा था) या किसी को प्रभावित करना, इसलिए मैं आपसे विशेष रूप से प्रभावित नहीं होने के लिए कहता हूं। जो मैं वास्तव में करना चाहता था वह यह पता लगाना था कि i386 वास्तुकला सबसे बुनियादी स्तर पर कैसे काम करती है, और वास्तव में ऑपरेटिंग सिस्टम कैसे अपना जादू करते हैं, और हाइप रस्ट को खोदते हैं।

अपने नोट्स में मैं न केवल स्रोत ग्रंथों (उन्हें गिटलैब पर पाया जा सकता है) और नंगे सिद्धांत (इसे कई संसाधनों पर पाया जा सकता है) को साझा करने की कोशिश करूंगा, लेकिन वह रास्ता भी जो मैं बिना सोचे-समझे जवाब खोजने के लिए गया था। विशेष रूप से, इस लेख में मैं एक कर्नेल फ़ाइल बनाने, इसे लोड करने और इसे इनिशियलाइज़ करने के बारे में बात करूँगा।

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

साहित्य और स्रोत

बेशक , मुझे यह सबसे अच्छा ओएसडीवी संसाधन से मिला, विकी से और मंच से दोनों। दूसरे, मैं अपने ब्लॉग के साथ फिलिप ओपरमैन का नाम लूंगा - जंग और लोहे के गुच्छा के बारे में बहुत सारी जानकारी।

कुछ बिंदु लिनक्स कर्नेल में जासूसी करते हैं, मिनिक्स विशेष साहित्य की मदद के बिना नहीं है, जैसे कि तेनबाम की पुस्तक " ऑपरेटिंग सिस्टम " । डिजाइन और कार्यान्वयन, "रॉबर्ट लव पुस्तक" लिनक्स कर्नेल। विकास प्रक्रिया का विवरण । " X86 आर्किटेक्चर के संगठन के बारे में कठिन प्रश्नों को " Intel 64 और IA-32 आर्किटेक्चर सॉफ्टवेयर डेवलपर के मैनुअल वॉल्यूम 3 (3A, 3B, 3C और 3D): सिस्टम प्रोग्रामिंग गाइड " का उपयोग करके हल किया गया था। बायनेरिज़ के प्रारूप की समझ में, लेआउट ld, llvm, nm, nasm, मेक के लिए मार्गदर्शक हैं।
युपीडी। अद्भुत Redox OS सिस्टम की याद दिलाने के लिए CoreTeamTech का धन्यवाद। मैं इसके स्रोत से बाहर नहीं निकला। दुर्भाग्य से, आधिकारिक GitLab सिस्टम रूसी आईपी से उपलब्ध नहीं है, इसलिए आप GitHub को देख सकते हैं।

एक और प्रस्तावना

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

उपकरण

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

कई कारणों से जंग को चुना गया। सबसे पहले, इसकी बढ़ती लोकप्रियता और सुखद दर्शन। दूसरे, उनकी क्षमता निम्न स्तर के साथ काम करने की लेकिन "पैर में खुद को गोली मारने" की कम संभावना के साथ। तीसरा, जावा और मावेन के प्रेमी के रूप में, मैं सिस्टम और निर्भरता प्रबंधन के निर्माण के लिए बहुत आदी हूं, और कार्गो पहले से ही टूलचिन भाषा में बनाया गया है। चौथा, मुझे बस कुछ नया चाहिए था, सी की तरह नहीं।

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

Qemu का उपयोग लॉन्च करने के लिए किया गया था - मुझे इसकी गति, इंटरैक्टिव मोड और GDB हुक करने की क्षमता पसंद है। बूट करने के लिए और तुरंत सभी हार्डवेयर जानकारी है - बेशक GRUB (हैडर को व्यवस्थित करना आसान है, इसलिए इसे लें)।

लिंकिंग और लेआउट

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

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

32-बिट वातावरण में पेजिंग का उपयोग करने वाले ऑपरेटिंग सिस्टम के लिए, प्रत्येक कार्य में 4 जीबी का पता लगाने योग्य मेमोरी स्पेस होता है, भले ही आपके पास 128 एमबी रैम स्थापित हो। यह सिर्फ स्मृति के पेजिंग संगठन के कारण होता है; मुख्य मेमोरी में पृष्ठों की अनुपस्थिति तदनुसार नियंत्रित की जाती है।

हालांकि, वास्तव में, एप्लिकेशन आमतौर पर 4 जीबी से थोड़ा कम उपलब्ध होते हैं। ऐसा इसलिए है क्योंकि ओएस को इंटरप्ट, सिस्टम कॉल को संभालना चाहिए, जिसका अर्थ है कि कम से कम उनके हैंडलर को इस एड्रेस स्पेस में होना चाहिए। हमें इस सवाल का सामना करना पड़ रहा है: इन 4 जीबी में वास्तव में कर्नेल पते कहां रखे जाने चाहिए ताकि प्रोग्राम सही तरीके से काम कर सकें?

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

इस अवधारणा को हायर-हाफ कर्नेल कहा जाता है (यहाँ मैं आपको संबंधित जानकारी चाहते हैं, तो आपको osdev.org पर संदर्भित करता है)। स्मृति का कौन सा टुकड़ा चुनना है यह आपके भूख पर निर्भर करता है। 512 एमबी किसी के लिए पर्याप्त है, लेकिन मैंने खुद को 1 जीबी हड़पने का फैसला किया है, इसलिए मेरा कर्नेल 3 जीबी + 1 एमबी पर स्थित है (1 एमबी को कम-उच्च मेमोरी सीमा का पालन करने की आवश्यकता है, GRUB हमें 1 एमबी के बाद भौतिक मेमोरी में लोड करता है) ।
हमारी निष्पादन योग्य फ़ाइल में प्रवेश बिंदु निर्दिष्ट करना भी हमारे लिए महत्वपूर्ण है। मेरे निष्पादन योग्य के लिए, यह कोडांतरक में लिखा गया _ लोडर फ़ंक्शन होगा, जिसे मैं अगले खंड में अधिक विस्तार से बताऊंगा।

लिंक करने के लिए आपको और क्या जानने की आवश्यकता है? डेटा सेक्शन (.rodata, .data), uninitialized चर (.bs, सामान्य) कैसे स्थित होंगे, और यह भी याद रखें कि GRUB को बाइनरी के पहले 8 KB में मल्टीबूट हेडर के स्थान की आवश्यकता होती है।

तो अब हम एक लिंकर स्क्रिप्ट लिख सकते हैं!

ENTRY(_loader) OUTPUT_FORMAT(elf32-i386) SECTIONS { . = 0xC0100000; .text ALIGN(4K) : AT(ADDR(.text) - 0xC0000000) { *(.multiboot1) *(.multiboot2) *(.text) } .rodata ALIGN(4K) : AT(ADDR(.rodata) - 0xC0000000) { *(.rodata*) } .data ALIGN (4K) : AT(ADDR(.data) - 0xC0000000) { *(.data) } .bss : AT(ADDR(.bss) - 0xC0000000) { _sbss = .; *(COMMON) *(.bss) _ebss = .; } } 

GRUB के बाद डाउनलोड करें

जैसा कि ऊपर उल्लेख किया गया है, मल्टीबूट विनिर्देश को हेडर को बूट छवि के पहले 8 KB में होना चाहिए। पूर्ण विनिर्देश यहां देखा जा सकता है , लेकिन मैं केवल ब्याज के विवरण पर ध्यान केंद्रित करूंगा।

• 32 बिट संरेखण (4 बाइट्स) का सम्मान किया जाना चाहिए
• एक जादू नंबर 0x1BADB002 होना चाहिए
• मल्टीबूटर को यह बताने के लिए आवश्यक है कि हमें कौन सी जानकारी प्राप्त करनी है और कैसे मॉड्यूल रखना है (मेरे मामले में, मैं चाहता हूं कि कर्नेल मॉड्यूल को 4 केबी पृष्ठ पर संरेखित किया जाए, और समय और प्रयास बचाने के लिए मेमोरी कार्ड भी प्राप्त करें)
• एक चेकसम प्रदान करें (चेकसम + मैजिक नंबर + झंडे को शून्य देना चाहिए)

 MB1_MODULEALIGN equ 1<<0 MB1_MEMINFO equ 1<<1 MB1_FLAGS equ MB1_MODULEALIGN | MB1_MEMINFO MB1_MAGIC equ 0x1BADB002 MB1_CHECKSUM equ -(MB1_MAGIC + MB1_FLAGS) section .multiboot1 align 4 dd MB1_MAGIC dd MB1_FLAGS dd MB1_CHECKSUM 

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

• EAX रजिस्टर में जादू नंबर 0x2BADB002 होता है, जो कहता है कि डाउनलोड सफल रहा
• EBX रजिस्टर में लोडिंग के परिणामों के बारे में जानकारी के साथ संरचना का भौतिक पता है (हम इसके बारे में बहुत बाद में बात करेंगे)
• प्रोसेसर संरक्षित मोड में है, पेज मेमोरी को बंद कर दिया गया है, सेगमेंट रजिस्टर और स्टैक एक अपरिभाषित (हमारे लिए) स्थिति में हैं, GRUB ने उन्हें अपनी जरूरतों के लिए इस्तेमाल किया और जल्द से जल्द इसे फिर से परिभाषित करना होगा।

पहली चीज जो हमें करने की आवश्यकता है, वह पेजिंग को सक्षम करने, स्टैक को ट्यून करने और अंत में उच्च-स्तरीय रस्ट कोड पर नियंत्रण स्थानांतरित करने के लिए है।
मैं स्मृति के पेज संगठन, पेज डायरेक्टरी और पेज टेबल पर विस्तार से नहीं लिखूंगा, क्योंकि इस ( उनमें से एक ) के बारे में उत्कृष्ट लेख लिखे गए हैं। मुख्य बात जो मैं साझा करना चाहता हूं वह यह है कि पृष्ठ खंड नहीं हैं! कृपया मेरी गलती न दोहराएं और GDTR में पेज टेबल एड्रेस लोड न करें! पृष्ठ तालिका के लिए CR3 है! कार्य की सादगी (केवल एक पृष्ठ तालिका के लिए) के लिए पृष्ठ का विभिन्न आर्किटेक्चर में एक अलग आकार हो सकता है, मैंने पीएसई को शामिल करने के कारण 4 एमबी का आकार चुना।

इसलिए, हम वर्चुअल पेज मेमोरी को सक्षम करना चाहते हैं। ऐसा करने के लिए, हमें एक पृष्ठ तालिका, और उसके भौतिक पते की आवश्यकता है, जिसे CR3 में लोड किया गया है। उसी समय, हमारी बाइनरी फ़ाइल 3 जीबी की ऑफसेट के साथ वर्चुअल एड्रेस स्पेस में काम करने के लिए जुड़ी हुई थी। इसका मतलब है कि सभी चर पते और लेबल में 3 जीबी की ऑफसेट है। पृष्ठ तालिका सिर्फ एक सरणी है जिसमें पृष्ठ पते में इसका वास्तविक पता होता है, जो पृष्ठ आकार से जुड़ा होता है, साथ ही पहुंच और स्थिति झंडे भी होते हैं। चूंकि मैं 4 एमबी पृष्ठों का उपयोग करता हूं, मुझे 1024 प्रविष्टियों के साथ केवल एक पीडी पृष्ठ तालिका चाहिए:

 section .data align 0x1000 BootPageDirectory: dd 0x00000083 times (KERNEL_PAGE_NUMBER - 1) dd 0 dd 0x00000083 times (1024 - KERNEL_PAGE_NUMBER - 1) dd 0 

टेबल में क्या है?

1. बहुत पहले पृष्ठ को कोड के वर्तमान खंड (0-4 एमबी भौतिक मेमोरी) की ओर ले जाना चाहिए, क्योंकि प्रोसेसर में सभी पते भौतिक हैं और वर्चुअल में अनुवाद अभी तक नहीं किया गया है। इस पृष्ठ डिस्क्रिप्टर की अनुपस्थिति से तत्काल दुर्घटना हो जाएगी, क्योंकि प्रोसेसर पृष्ठों को चालू करने के बाद अगला निर्देश नहीं ले पाएगा। झंडे: बिट 0 - तालिका मौजूद है, बिट 1 - पृष्ठ लिखित है, बिट 7 - पृष्ठ आकार 4 एमबी। पृष्ठों को चालू करने के बाद, रिकॉर्ड रीसेट हो जाता है।
2. 3 जीबी तक छोड़ें - शून्य यह सुनिश्चित करता है कि पृष्ठ स्मृति में नहीं है
3. भौतिक स्मृति में 0 का संदर्भ देते हुए, 3 जीबी मार्क वर्चुअल मेमोरी में हमारा मूल है। पृष्ठों को चालू करने के बाद, हम यहां काम करेंगे। झंडे पहले रिकॉर्ड के समान हैं।
4. 4 जीबी तक छोड़ें।

इसलिए, हमने सारणी घोषित कर दी है और अब हम CR3 में इसके भौतिक पते को लोड करना चाहते हैं। लिंकिंग स्टेज पर 3 जीबी के एड्रेस ऑफसेट के बारे में मत भूलना। पते को लोड करने का प्रयास करना क्योंकि यह हमें 3 जीबी + चर ऑफसेट के वास्तविक पते पर भेज देगा और तत्काल दुर्घटना की ओर ले जाएगा। इसलिए, हम BootPageDirectory का पता लेते हैं और उसमें से 3 GB घटाते हैं, इसे CR3 में डालते हैं। हम CR4 रजिस्टर में PSE चालू करते हैं, CR0 रजिस्टर में पृष्ठों के साथ काम चालू करते हैं:

  mov ecx, (BootPageDirectory - KERNEL_VIRTUAL_BASE) mov cr3, ecx mov ecx, cr4 or ecx, 0x00000010 mov cr4, ecx mov ecx, cr0 or ecx, 0x80000000 mov cr0, ecx 

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

  lea ecx, [StartInHigherHalf] jmp ecx StartInHigherHalf: mov dword [BootPageDirectory], 0 invlpg [0] 

अब यह सब बहुत छोटा है: स्टैक को इनिशियलाइज़ करें, GRUB स्ट्रक्चर और असेंबलर पास करें!

  mov esp, stack+STACKSIZE push eax push ebx lea ecx, [BootPageDirectory] push ecx call kmain hlt section .bss align 32 stack: resb STACKSIZE 

कोड के इस टुकड़े के बारे में आपको क्या जानने की जरूरत है:

1. कॉल के सी-कन्वेंशन के अनुसार (यह रस्ट पर भी लागू होता है), चर रिवर्स ऑर्डर में स्टैक के माध्यम से फ़ंक्शन में स्थानांतरित किए जाते हैं। सभी चर x86 में 4 बाइट्स द्वारा संरेखित किए जाते हैं।
2. स्टैक अंत से बढ़ता है, इसलिए स्टैक के सूचक को स्टैक के अंत तक ले जाना चाहिए (पते पर STACKSIZE जोड़ें)। मैंने जो स्टैक आकार लिया वह 16 केबी का था, पर्याप्त होना चाहिए।
3. निम्नलिखित को कर्नेल में स्थानांतरित किया गया है: मल्टीबूट की जादुई संख्या, बूटलोडर संरचना का भौतिक पता (हमारे लिए एक मूल्यवान मेमोरी कार्ड है), पृष्ठ तालिका का आभासी पता (कहीं 3 जीबी स्थान में)

इसके अलावा, यह घोषित करना न भूलें कि kmain बाहरी है और _loader वैश्विक है।

आगे के कदम

निम्नलिखित नोटों में, मैं खंड रजिस्टर स्थापित करने के बारे में बात करूंगा, संक्षेप में एक वीजीए बफर के माध्यम से सूचना के उत्पादन पर जाऊंगा, आपको बताऊंगा कि मैंने कैसे व्यवधान, पृष्ठ प्रबंधन और सबसे प्यारी चीज के साथ काम किया - मल्टीटास्किंग - मैं मिठाई के लिए छोड़ दूँगा।

पूरा प्रोजेक्ट कोड GitLab पर उपलब्ध है ।

आपका ध्यान के लिए धन्यवाद!

UPD2: भाग 2
UPD2: भाग 3