सीपीयू के छल्ले सबसे स्पष्ट अंतर हैं
X86 संरक्षित मोड में, CPU हमेशा 4 रिंग में से एक में होता है। लिनक्स कर्नेल केवल 0 और 3 का उपयोग करता है:
- 0 कर्नेल के लिए
- उपयोगकर्ताओं के लिए 3
यह कर्नेल बनाम उपयोगकर्ताभूमि की सबसे कठिन और तेज़ परिभाषा है।
क्यों लिनक्स 1 और 2 के छल्ले का उपयोग नहीं करता है: सीपीयू विशेषाधिकार के छल्ले: क्यों 1 और 2 के छल्ले का उपयोग नहीं किया जाता है?
वर्तमान रिंग कैसे निर्धारित की जाती है?
वर्तमान रिंग को इसके संयोजन द्वारा चुना गया है:
वैश्विक डिस्क्रिप्टर तालिका: जीडीटी प्रविष्टियों की इन-मेमोरी टेबल और प्रत्येक प्रविष्टि में एक फ़ील्ड होता है Privlजो रिंग को एनकोड करता है।
LGDT इंस्ट्रक्शन वर्तमान डिस्क्रिप्टर टेबल पर पता सेट करता है।
इसे भी देखें: http://wiki.osdev.org/Global_Descriptor_Table
खंड सीएस, डीएस, आदि को पंजीकृत करता है, जो जीडीटी में एक प्रविष्टि के सूचकांक को इंगित करता है।
उदाहरण के लिए, CS = 0मतलब GDT की पहली प्रविष्टि वर्तमान में निष्पादन कोड के लिए सक्रिय है।
प्रत्येक अंगूठी क्या कर सकती है?
सीपीयू चिप को भौतिक रूप से बनाया गया है ताकि:
अंगूठी 0 कुछ भी कर सकती है
रिंग 3 कई निर्देश नहीं चला सकता है और कई रजिस्टरों को लिख सकता है, विशेष रूप से:
अपनी खुद की अंगूठी नहीं बदल सकते हैं! अन्यथा, यह खुद को अंगूठी 0 पर सेट कर सकता है और रिंग बेकार हो जाएगा।
दूसरे शब्दों में, वर्तमान खंड वर्णनकर्ता को संशोधित नहीं कर सकता है , जो वर्तमान रिंग को निर्धारित करता है।
पृष्ठ तालिकाओं को संशोधित नहीं कर सकते: x86 पेजिंग कैसे काम करता है?
दूसरे शब्दों में, सीआर 3 रजिस्टर को संशोधित नहीं किया जा सकता है, और पेजिंग स्वयं पेज तालिकाओं के संशोधन को रोकता है।
यह एक प्रक्रिया को सुरक्षा कारणों के लिए अन्य प्रक्रियाओं की स्मृति को देखने से रोकता है / प्रोग्रामिंग कारणों में आसानी।
बाधित हैंडलर पंजीकृत नहीं कर सकते। इन्हें स्मृति स्थानों पर लिखकर कॉन्फ़िगर किया जाता है, जिसे पेजिंग द्वारा भी रोका जाता है।
हैंडलर रिंग 0 में दौड़ते हैं, और सुरक्षा मॉडल को तोड़ देंगे।
दूसरे शब्दों में, LGDT और LIDT निर्देशों का उपयोग नहीं कर सकते।
IO जैसे निर्देश inऔर नहीं कर सकता out, और इस तरह मनमाने ढंग से हार्डवेयर एक्सेस है।
अन्यथा, उदाहरण के लिए, फ़ाइल अनुमति बेकार हो जाएगी यदि कोई भी प्रोग्राम डिस्क से सीधे पढ़ सकता है।
माइकल पेटी के लिए अधिक सटीक धन्यवाद : यह वास्तव में ओएस के लिए रिंग 3 पर आईओ के निर्देशों की अनुमति देने के लिए संभव है, यह वास्तव में टास्क सेक्शन द्वारा नियंत्रित किया जाता है ।
क्या संभव नहीं है रिंग 3 के लिए खुद को ऐसा करने की अनुमति देना अगर यह पहली जगह में नहीं था।
लिनक्स हमेशा इसे नापसंद करता है। इसे भी देखें: लिनक्स TSS के माध्यम से हार्डवेयर संदर्भ स्विच का उपयोग क्यों नहीं करता है?
रिंगों के बीच प्रोग्राम और ऑपरेटिंग सिस्टम कैसे संक्रमण करते हैं?
जब CPU चालू होता है, तो यह रिंग 0 में प्रारंभिक प्रोग्राम चलाना शुरू कर देता है (अच्छी तरह से, लेकिन यह एक अच्छा सन्निकटन है)। आप इस प्रारंभिक कार्यक्रम को कर्नेल होने के रूप में सोच सकते हैं (लेकिन यह आमतौर पर एक बूटलोडर है जो तब कर्नेल को अभी भी रिंग 0 में कहता है )।
जब कोई उपयोगकर्ता प्रक्रिया इसके लिए कर्नेल को कुछ करना चाहता है जैसे किसी फ़ाइल में लिखना, यह एक निर्देश का उपयोग करता है जो कि एक बाधा उत्पन्न करता है जैसे कि int 0x80याsyscall कर्नेल को संकेत देना। x86-64 लिनक्स syscall हैलो दुनिया उदाहरण:
.data
hello_world:
.ascii "hello world\n"
hello_world_len = . - hello_world
.text
.global _start
_start:
/* write */
mov $1, %rax
mov $1, %rdi
mov $hello_world, %rsi
mov $hello_world_len, %rdx
syscall
/* exit */
mov $60, %rax
mov $0, %rdi
syscall
संकलित करें और चलाएं:
as -o hello_world.o hello_world.S
ld -o hello_world.out hello_world.o
./hello_world.out
गिटहब ऊपर ।
जब ऐसा होता है, CPU एक कॉलबैक हैंडलर को कॉल करता है जिसे कर्नेल बूट समय पर पंजीकृत करता है। यहां एक ठोस नंगेपन का उदाहरण है जो एक हैंडलर को पंजीकृत करता है और इसका उपयोग करता है ।
यह हैंडलर रिंग 0 में चलता है, जो यह तय करता है कि कर्नेल इस क्रिया को करने देगा, एक्शन करेगा, और रिंग में यूजरलैंड प्रोग्राम को पुनः आरंभ करेगा 3. x86_64
जब execसिस्टम कॉल का उपयोग किया जाता है (या जब कर्नेल शुरू हो जाएगा/init ), कर्नेल नए यूजरलैंड प्रक्रिया के रजिस्टरों और मेमोरी को तैयार करता है, तो यह प्रवेश बिंदु पर कूदता है और सीपीयू को रिंग 3 में स्विच करता है
यदि प्रोग्राम कुछ शरारती करने की कोशिश करता है जैसे निषिद्ध रजिस्टर या मेमोरी एड्रेस (पेजिंग के कारण) को लिखने के लिए, सीपीयू रिंग 0 में कुछ कर्नेल कॉलबैक हैंडलर भी कहता है।
लेकिन चूंकि यूजरलैंड शरारती था, इसलिए कर्नेल इस बार प्रक्रिया को मार सकता है, या इसे सिग्नल के साथ चेतावनी दे सकता है।
जब कर्नेल बूट होता है, तो यह कुछ निश्चित आवृत्ति के साथ एक हार्डवेयर घड़ी सेटअप करता है, जो समय-समय पर व्यवधान उत्पन्न करता है।
यह हार्डवेयर क्लॉक रिंग 0 को चलाने वाले इंटरप्ट को जनरेट करता है, और इसे शेड्यूल करने की अनुमति देता है कि कौन सी यूजरलैंड उठती है।
इस तरह, शेड्यूलिंग तब भी हो सकती है, जब प्रक्रियाएं कोई सिस्टम कॉल नहीं कर रही हैं।
कई छल्ले होने की बात क्या है?
कर्नेल और यूजरलैंड को अलग करने के दो प्रमुख लाभ हैं:
- प्रोग्राम बनाना आसान है क्योंकि आप अधिक निश्चित हैं कि कोई दूसरे के साथ हस्तक्षेप नहीं करेगा। उदाहरण के लिए, एक उपयोगकर्ता प्रक्रिया को पेजिंग के कारण किसी अन्य प्रोग्राम की मेमोरी को ओवरराइट करने के बारे में चिंता करने की आवश्यकता नहीं है, और न ही किसी अन्य प्रक्रिया के लिए अमान्य स्थिति में हार्डवेयर डालने के बारे में।
- यह अधिक सुरक्षित है। उदाहरण के लिए फ़ाइल अनुमतियां और मेमोरी पृथक्करण एक हैकिंग ऐप को आपके बैंक डेटा को पढ़ने से रोक सकते हैं। यह, ज़ाहिर है, कि आप कर्नेल पर भरोसा करते हैं।
इसके साथ कैसे खेलें?
मैंने एक नंगे धातु सेटअप का निर्माण किया है जो रिंगों में सीधे हेरफेर करने का एक अच्छा तरीका होना चाहिए: https://github.com/cirosantilli/x86-bare-metal-examples
मेरे पास दुर्भाग्य से एक उपयोगकर्ता के उदाहरण को बनाने के लिए धैर्य नहीं था, लेकिन मैं सेटअप पेजिंग के रूप में दूर तक गया था, इसलिए उपयोगकर्ताभूमि को व्यवहार्य होना चाहिए। मुझे एक पुल अनुरोध देखना अच्छा लगेगा।
वैकल्पिक रूप से, लिनक्स कर्नेल मॉड्यूल रिंग 0 में चलते हैं, इसलिए आप उनका उपयोग विशेषाधिकार प्राप्त संचालन को आज़माने के लिए कर सकते हैं, उदाहरण के लिए नियंत्रण रजिस्टर पढ़ें: नियंत्रण रजिस्टर को कैसे एक्सेस करें cr0, cr2, cr3 एक प्रोग्राम से? विभाजन की गलती हो रही है
यहाँ एक सुविधाजनक QEMU + बिल्डरोट सेटअप है जो आपके मेजबान को मारे बिना इसे आज़मा सकता है।
कर्नेल मॉड्यूल का नकारात्मक पक्ष यह है कि अन्य kthreads चल रहे हैं और आपके प्रयोगों में हस्तक्षेप कर सकते हैं। लेकिन सिद्धांत रूप में आप अपने कर्नेल मॉड्यूल के साथ सभी रुकावट संभाल सकते हैं और सिस्टम के मालिक हैं, जो वास्तव में एक दिलचस्प परियोजना होगी।
नेगेटिव रिंग्स
जबकि नकारात्मक रिंग्स वास्तव में इंटेल मैनुअल में संदर्भित नहीं होते हैं, वास्तव में सीपीयू मोड हैं जिनके पास रिंग 0 की तुलना में आगे की क्षमता है, और इसलिए "नेगेटिव रिंग" नाम के लिए एक अच्छा फिट है।
एक उदाहरण वर्चुअलाइजेशन में उपयोग किया जाने वाला हाइपरविजर मोड है।
अधिक जानकारी के लिए देखें:
एआरएम
एआरएम में, छल्ले को इसके बजाय अपवाद स्तर कहा जाता है, लेकिन मुख्य विचार समान रहते हैं।
ARMv8 में 4 अपवाद स्तर मौजूद हैं, जिनका आमतौर पर उपयोग किया जाता है:
EL0: उपयोगकर्ता क्षेत्र
EL1: कर्नेल (एआरएम शब्दावली में "पर्यवेक्षक")।
svcनिर्देश (सुपरवाइजर कॉल) के साथ दर्ज किया गया , जिसे swi पहले एकीकृत असेंबली के रूप में जाना जाता था , जो कि लिनक्स सिस्टम कॉल करने के लिए उपयोग किया जाने वाला निर्देश है। नमस्ते दुनिया ARMv8 उदाहरण:
hello.S
.text
.global _start
_start:
/* write */
mov x0, 1
ldr x1, =msg
ldr x2, =len
mov x8, 64
svc 0
/* exit */
mov x0, 0
mov x8, 93
svc 0
msg:
.ascii "hello syscall v8\n"
len = . - msg
गिटहब ऊपर ।
16.04 पर QEMU के साथ इसका परीक्षण करें:
sudo apt-get install qemu-user gcc-arm-linux-gnueabihf
arm-linux-gnueabihf-as -o hello.o hello.S
arm-linux-gnueabihf-ld -o hello hello.o
qemu-arm hello
यहां एक ठोस नंगेपन का उदाहरण है जो एक एसवीसी हैंडलर को पंजीकृत करता है और एक एसवीसी कॉल करता है ।
EL2: हाइपरविजर , उदाहरण के लिए Xen ।
hvcनिर्देश (हाइपरविजर कॉल) के साथ दर्ज किया गया ।
एक हाइपरविजर एक ओएस के लिए है, एक ओएस क्या उपयोगकर्ता के लिए है।
उदाहरण के लिए, Xen आपको एक ही समय में एक ही सिस्टम पर कई OS जैसे कि Linux या Windows चलाने की अनुमति देता है, और यह OSes को एक दूसरे से सुरक्षा और डिबग की आसानी के लिए अलग करता है, ठीक वैसे ही जैसे कि लिनक्स उपयोगकर्ता कार्यक्रमों के लिए करता है।
Hypervisers आज के क्लाउड बुनियादी ढांचे का एक महत्वपूर्ण हिस्सा हैं: वे कई सर्वरों को एक हार्डवेयर पर चलने की अनुमति देते हैं, हार्डवेयर उपयोग को हमेशा 100% के करीब रखते हैं और बहुत सारे पैसे बचाते हैं।
उदाहरण के लिए AWS ने 2017 तक Xen का उपयोग किया जब इसके KVM के कदम ने समाचार बनाया ।
EL3: अभी तक एक और स्तर। TODO उदाहरण।
smcनिर्देश (सुरक्षित मोड कॉल) के साथ दर्ज किया गया
ARMv8 वास्तुकला संदर्भ मॉडल DDI 0487C.a - अध्याय डी 1 - AArch64 सिस्टम स्तर प्रोग्रामर मॉडल - चित्रा D1-1 इस खूबसूरती से दिखाता है:
ARMv8.1 वर्चुअलाइजेशन होस्ट एक्सटेंशन्स (VHE) के आगमन के साथ ARM की स्थिति थोड़ी बदल गई । यह एक्सटेंशन कर्नेल को EL2 में कुशलतापूर्वक चलाने की अनुमति देता है:
VHE इसलिए बनाया गया था क्योंकि KVM जैसे लिनक्स-कर्नेल वर्चुअलाइजेशन सॉल्यूशन को ज़मीन पर अधिग्रहित किया गया है (उदाहरण के लिए देखें कि AWS 'KVM में ऊपर उल्लिखित है), क्योंकि अधिकांश क्लाइंट को केवल Linux VMs की आवश्यकता होती है, और जैसा कि आप कल्पना कर सकते हैं, सभी एक में होने के नाते प्रोजेक्ट, KVM सरल और संभावित रूप से Xen से अधिक कुशल है। तो अब मेजबान लिनक्स कर्नेल उन मामलों में हाइपरवाइजर के रूप में कार्य करता है।
ध्यान दें कि कैसे एआरएम, शायद hindight के लाभ के कारण, नकारात्मक स्तर की आवश्यकता के बिना x86 की तुलना में विशेषाधिकार स्तरों के लिए एक बेहतर नामकरण सम्मेलन है: 0 कम और 3 उच्चतम। उच्च स्तर कम लोगों की तुलना में अधिक बार बनाए जाते हैं।
वर्तमान ईएल को MRSनिर्देश के साथ समझा जा सकता है : वर्तमान निष्पादन मोड / अपवाद स्तर, आदि क्या है?
एआरएम को कार्यान्वयन के लिए अनुमति देने के लिए सभी अपवाद स्तरों की आवश्यकता नहीं है जो चिप क्षेत्र को बचाने के लिए सुविधा की आवश्यकता नहीं है। ARMv8 "अपवाद स्तर" कहते हैं:
कार्यान्वयन में अपवाद स्तर शामिल नहीं हो सकते हैं। सभी कार्यान्वयन में EL0 और EL1 शामिल होना चाहिए। EL2 और EL3 वैकल्पिक हैं।
Q1U उदाहरण के लिए EL1 में चूक, लेकिन EL2 और EL3 को कमांड लाइन विकल्पों के साथ सक्षम किया जा सकता है: qemu-system-anarch64 जब a1 पावर अप का अनुकरण करते हुए el1 में प्रवेश करता है
कोड स्निपेट्स ने उबंटू 18.10 पर परीक्षण किया।