लिनक्स में एक दागी गिरी क्या है?

Question

कुछ शर्तों के तहत, लिनक्स कर्नेल दागी हो सकता है । उदाहरण के लिए, एक मालिकाना वीडियो ड्राइवर को कर्नेल में लोड करना कर्नेल को दागता है। यह स्थिति सिस्टम लॉग, कर्नेल त्रुटि संदेश (उफ़ और पैनिक) में और उपकरण जैसे माध्यम से दिखाई दे सकती है lsmod, और सिस्टम के रिबूट होने तक बनी रहती है।

इसका क्या मतलब है? क्या यह सिस्टम का उपयोग करने की मेरी क्षमता को प्रभावित करता है, और यह मेरे समर्थन विकल्पों को कैसे प्रभावित कर सकता है?

Comments

लैसमोड आउटपुट के

— गिल

@ दोस्तों, मुझे लगता है कि आपके द्वारा जुड़े प्रश्न को इस एक में विलय कर दिया जाना चाहिए। इसके अलावा, यह स्पष्ट नहीं है कि एक प्रश्न दूसरे का डुप्लिकेट है।

— bwDraco

मैं इस प्रश्न का विहित संस्करण बनाने की उम्मीद कर रहा हूं; प्रश्न के सबसे हाल के संपादन को देखें।

— bwDraco

@MichaelMrozek: 1) मैंने मौजूदा प्रश्न नहीं देखा था, क्योंकि यह स्पष्ट नहीं था कि उपयोगकर्ता "दागी 'का मतलब क्या पूछ रहा था, और 2) शब्द के रूप में प्रश्न एक एकल आदेश के लिए विशिष्ट है lsmod। मैंने यह प्रश्न और उत्तर इसे और अधिक सामान्य बनाने के लिए लिखा है ताकि कोई यह पूछे कि "क्या मतलब है" दागी 'का मतलब यह आसानी से मिल सकता है।

— bwDraco

वे एक ऐसे शब्द का उपयोग कर सकते थे जो "दागी" की तुलना में थोड़ा अधिक तटस्थ था।

— रोजर डाह

Answer 1

जब कर्नेल को दागी किया जाता है, तो इसका मतलब है कि यह ऐसी स्थिति में है जो समुदाय द्वारा समर्थित नहीं है । अधिकांश कर्नेल डेवलपर्स दागी गुठली को शामिल करने वाली बग रिपोर्ट को अनदेखा कर देंगे, और समुदाय के सदस्य पूछ सकते हैं कि कर्नेल से संबंधित समस्याओं का निदान करने से पहले आप दागी स्थिति को ठीक कर सकते हैं। इसके अलावा, कर्नेल के दागी होने पर कुछ डीबगिंग कार्यक्षमता और API कॉल अक्षम हो सकती हैं।

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

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

कर्नेल कई कारणों में से किसी के लिए भी दागी हो सकता है , जिसमें निम्न शामिल हैं (लेकिन इन तक सीमित नहीं):

• मालिकाना (या गैर-जीपीएल-संगत) कर्नेल मॉड्यूल का उपयोग-यह दागी गुठली का सबसे आम कारण है और आमतौर पर मालिकाना NVIDIA या एएमडी वीडियो ड्राइवरों को लोड करने से होता है।
• स्टेजिंग ड्राइवरों का उपयोग , जो कर्नेल स्रोत कोड का हिस्सा हैं, लेकिन पूरी तरह से परीक्षण नहीं किया गया है
• लिनक्स कर्नेल स्रोत कोड के साथ आउट-ऑफ-ट्री मॉड्यूल का उपयोग शामिल नहीं है
• कर्नेल मॉड्यूल को जबरन लोड करना या उतारना (जैसे कि कर्नेल के वर्तमान संस्करण के लिए निर्मित मॉड्यूल को जबरन सम्मिलित करना)
• कुछ असमर्थित यूनीप्रोसेसर CPUs पर SMP (मल्टीप्रोसेसर) कर्नेल का उपयोग, मुख्य रूप से पुराने AMD Athens प्रोसेसर
• की अधिभावी ACPI DSDT, कभी कभी बिजली प्रबंधन कीड़े के लिए सही करने के लिए (देखें जरूरत यहाँ जानकारी के लिए)
• कुछ महत्वपूर्ण त्रुटि की स्थिति, जैसे कि मशीन की जाँच अपवाद और कर्नेल ऊप्स
• सिस्टम फ़र्मवेयर में कुछ गंभीर बग (BIOS, UEFI) जो कर्नेल के आसपास काम करना चाहिए

इन स्थितियों में से प्रत्येक को कर्नेल में एक विशेष ध्वज द्वारा दर्शाया गया है। कुछ लिनक्स वेंडर, जैसे SUSE, एक मॉड्यूल लोड करने जैसी स्थितियों को इंगित करने के लिए अतिरिक्त दागदार झंडे जोड़ते हैं जो विक्रेता द्वारा समर्थित नहीं है।

अधिक जानकारी कर्नेल प्रलेखन में उपलब्ध है । वहाँ सूचीबद्ध दागी झंडे (_ 'खाली' के लिए स्टैंड-इन के साथ)

• G | P : G यदि लोड किए गए सभी मॉड्यूल में GPL या संगत लाइसेंस है, अन्यथा एक मालिकाना मॉड्यूल लोड किया गया है। MODULE_LICENSE के बिना या MODULE_LICENSE के साथ मॉड्यूल जिन्हें insmod द्वारा मान्यता प्राप्त नहीं है, क्योंकि GPL संगत को मालिकाना माना जाता है।
• F | _ : यदि कोई मॉड्यूल "insmod -f" द्वारा लोड किया गया था, अन्यथा यदि सभी मॉड्यूल सामान्य रूप से लोड किए गए थे।
• S | _ : अगर oops हार्डवेयर पर चलने वाले SMP कर्नेल पर हुआ है जो मल्टीप्रोसेसर को चलाने के लिए सुरक्षित नहीं है। वर्तमान में यह केवल विभिन्न एथलीटों पर होता है जो एसएमपी सक्षम नहीं हैं।
• R | _ : यदि कोई मॉड्यूल द्वारा अनलोड किया गया था rmmod -f, अन्यथा यदि सभी मॉड्यूल सामान्य रूप से अनलोड किए गए थे।
• M | _ : यदि किसी प्रोसेसर ने मशीन जांच अपवाद की सूचना दी है , अन्यथा कोई मशीन जाँच अपवाद नहीं हुआ है।
• B | _ : यदि किसी पृष्ठ-विमोचन समारोह में एक बुरा पृष्ठ संदर्भ या कुछ अनपेक्षित पृष्ठ झंडे मिले हैं।
• U | _ : यदि कोई उपयोगकर्ता या उपयोगकर्ता एप्लिकेशन विशेष रूप से अनुरोध करता है कि दागी झंडा सेट किया जाएगा।
• D | _ : यदि कर्नेल की हाल ही में मृत्यु हुई है, तो एक OOPS या BUG था।
• A | _ : यदि ACPI तालिका ओवरराइड हो गई है।
• W | _ : यदि पहले कर्नेल द्वारा चेतावनी जारी की गई है (हालांकि कुछ चेतावनियाँ अधिक विशिष्ट टेंट फ़्लैग सेट कर सकती हैं)।
• C | _ : यदि एक स्टेजिंग ड्राइवर लोड किया गया है।
• I | _ : यदि कर्नेल प्लेटफ़ॉर्म फर्मवेयर (BIOS या समान) में एक गंभीर बग के आसपास काम कर रहा है।
• O | _ : यदि बाहरी रूप से निर्मित ("आउट-ऑफ-ट्री") मॉड्यूल लोड किया गया है।
• ई | _ : एक अहस्ताक्षरित मॉड्यूल कर्नेल समर्थन मॉड्यूल हस्ताक्षर में लोड किया गया है यदि।
• एल | _ : यदि सिस्टम पर पहले से एक नरम लॉकअप हुआ है।
• K | _ : यदि कर्नेल को लाइव पैच किया गया है।

Comments

यह उत्तर इस प्रश्न के विस्थापित होने की स्थिति से बहुत सी जानकारी गुम है।

मैं "अहस्ताक्षरित मॉड्यूल" परिदृश्य की कम से कम एक महत्वपूर्ण संभावना जोड़ूंगा - कर्नेल रूटकिट को कर्नेल में लोड किया गया था या कर्नेल शोषण को बस निष्पादित किया गया था।

— kravietz