उपयोगकर्ता मोड प्रोग्राम को कर्नेल स्पेस मेमोरी तक पहुंचने की अनुमति नहीं देता है और CPU मोड होने के उद्देश्य से IN और OUT निर्देशों को निष्पादित करता है?

Question

जब CPU उपयोगकर्ता मोड में होता है, तो CPU विशेषाधिकार प्राप्त निर्देशों को निष्पादित नहीं कर सकता है और कर्नेल स्थान मेमोरी तक नहीं पहुंच सकता है।

और जब सीपीयू कर्नेल मोड में होता है, तो सीपीयू सभी निर्देशों को निष्पादित कर सकता है और सभी मेमोरी को एक्सेस कर सकता है।

अब लिनक्स में, एक उपयोगकर्ता मोड प्रोग्राम सभी मेमोरी (उपयोग करके /dev/mem) तक पहुंच सकता है और दो विशेषाधिकार प्राप्त निर्देशों INऔर OUT( iopl()मुझे लगता है का उपयोग करके ) निष्पादित कर सकता है ।

तो लिनक्स में एक यूजर मोड प्रोग्राम ज्यादातर चीजें कर सकता है (मुझे लगता है कि ज्यादातर चीजें) कर्नेल मोड में की जा सकती हैं।

उपयोगकर्ता मोड प्रोग्राम को यह सब करने की अनुमति नहीं देता है कि सीपीयू मोड होने का उद्देश्य क्या है?

Answer 1

तो लिनक्स में एक यूजर मोड प्रोग्राम ज्यादातर चीजें कर सकता है (मुझे लगता है कि ज्यादातर चीजें) कर्नेल मोड में की जा सकती हैं।

ठीक है, सभी उपयोगकर्ता मोड प्रोग्राम नहीं कर सकते हैं, केवल उन लोगों को जो उपयुक्त विशेषाधिकार हैं। और यह कर्नेल द्वारा निर्धारित किया जाता है।

/dev/memसामान्य फ़ाइल सिस्टम पहुँच अनुमतियाँ और CAP_SYS_RAWIOक्षमता द्वारा संरक्षित है । iopl()और ioperm()उसी क्षमता के माध्यम से प्रतिबंधित भी हैं।

/dev/memपूरी तरह से कर्नेल के बाहर भी संकलित किया जा सकता है ( CONFIG_DEVMEM)।

उपयोगकर्ता मोड प्रोग्राम को यह सब करने की अनुमति नहीं देता है कि सीपीयू मोड होने का उद्देश्य क्या है?

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

(फिर वहाँ भी तथ्य यह है कि iopl()i386 पर CPU विशेषाधिकार मोड का उपयोग करके काम करता है, इसलिए यह इस उद्देश्य को हराने के लिए अच्छी तरह से नहीं कहा जा सकता है।)

Comments

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

— पीटर कॉर्डेस

Answer 2

केवल उसी तरह से जो modprobeकर्नेल में नए कोड को लोड करके सुरक्षा को "हरा देता है"।

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

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

यह सुरक्षा के लिए बहुत कुछ नहीं करता है, लेकिन बड़ी विश्वसनीयता और सॉफ्टवेयर आर्किटेक्चर के फायदे हैं।

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

---

हां, इन निजी लोगों के साथ दुर्भावनापूर्ण कोड कर्नेल कोड को संशोधित करने के लिए उपयोग करने पर, कर्नेल के ऊपर ले जा सकता है/dev/mem ।

या उदाहरण के लिए x86 पर, अपने IO विशेषाधिकार स्तर को रिंग 0 पर सेट करने के लिए सिस्टम कॉल करने के cliबाद उस कोर पर इंटरप्ट को अक्षम करने के लिए एक निर्देश चलाएँ iopl।

लेकिन यहां तक ​​कि x86 iopl"केवल" कुछ निर्देशों तक पहुंच देता है : in / out (और स्ट्रिंग संस्करण ins / outs), और cli / sti। यह आप का उपयोग नहीं करता है rdmsrया wrmsr(जैसे पढ़ने या लिखने "मॉडल विशिष्ट रजिस्टर" के लिए IA32_LSTARजो x86-64 के लिए कर्नेल प्रवेश बिंदु का पता सेट syscallअनुदेश), या उपयोग lidtबाधा-वर्णनकर्ता तालिका (जो आप पूरी तरह से लेते हैं हैं बदलने के लिए मौजूदा कर्नेल से मशीन पर, कम से कम उस कोर पर।)

आप नियंत्रण रजिस्टर भी नहीं पढ़ सकते हैं (जैसे CR3 जो शीर्ष-स्तरीय पृष्ठ-निर्देशिका का भौतिक पता रखता है, जो एक हमलावर प्रक्रिया /dev/memको अपने स्वयं के पृष्ठ तालिकाओं को संशोधित करने के लिए एक विकल्प के रूप में संशोधित करने के लिए उपयोगी हो सकता mmapहै /dev/mem। )

invd(सभी कैश को राइट-बैक के बिना अमान्य करें !! ( उपयोग केस = रैम से पहले BIOS कॉन्फ़िगर किया गया है) का उपयोग करें) एक और मजेदार है जिसे हमेशा पूर्ण सीपीएल 0 (वर्तमान विशेषाधिकार स्तर) की आवश्यकता होती है, न कि केवल IOPL। यहां तक कि wbinvdविशेषाधिकार प्राप्त है, क्योंकि यह इतनी धीमी गति से (और व्यवधान कारक नहीं) है, और फ्लश करने के लिए है सब सब कोर भर में कैश। (देखें वहाँ एक कार्यक्रम से संबंधित पूरे सीपीयू कैश? फ्लश करने के लिए एक रास्ता है और WBINVD अनुदेश उपयोग )

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

---

वर्तमान विशेषाधिकार स्तर (संरक्षित और लंबी मोड में) (कोड खंड चयनकर्ता) के निम्न 2 बिट्स हैंcs । mov eax, cs/ and eax, 3विशेषाधिकार स्तर को पढ़ने के लिए किसी भी मोड में काम करता है।

विशेषाधिकार स्तर लिखने के लिए, आप एक jmp farया call farसेट करने के लिए करते हैं CS:RIP(लेकिन लक्ष्य खंड के लिए GDT / LDT प्रविष्टि पुराने विशेषाधिकार स्तर के आधार पर इसे प्रतिबंधित कर सकती है, यही कारण है कि उपयोगकर्ता-स्थान स्वयं को ऊपर उठाने के लिए ऐसा नहीं कर सकते हैं)। या आप कर्नेल प्रविष्टि बिंदु पर रिंग 0 पर स्विच करने के लिए उपयोग करते हैं intया syscallकरते हैं।

Comments

वास्तव में, मुझे पूरा यकीन है कि यह इंटेल पार्सल में कोड "चयनकर्ता" है। यह 8086/8088 में एक खंड था, संभवतः 80186 में, लेकिन 80286 तक, इसे एक चयनकर्ता के रूप में संदर्भित किया गया था, और मुझे नहीं लगता कि उन्होंने आधिकारिक तौर पर उस शब्दावली को बदल दिया है।

— बजे एक CVn