🏳️ 👨🏻‍🚀 🤴🏻 फूट का उपयोग करके लिनक्स कर्नेल में अवरोधन कार्य 🔤 ⏹️ 🤟🏿

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

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

(ऊपर सिर्फ पेंगुइन छवि: © De3antArt के साथ En3l ।)

ज्ञात अनुमोदन

लिनक्स सुरक्षा एपीआई

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

दुर्भाग्य से, लिनक्स सुरक्षा एपीआई में कुछ महत्वपूर्ण सीमाएँ हैं:

सुरक्षा मॉड्यूल को गतिशील रूप से लोड नहीं किया जा सकता है, कर्नेल का हिस्सा हैं और पुनर्निर्माण की आवश्यकता होती है
सिस्टम में केवल एक सुरक्षा मॉड्यूल हो सकता है (कुछ अपवादों के साथ)

यदि कर्नेल डेवलपर्स की स्थिति मॉड्यूल की बहुलता के बारे में अस्पष्ट है, तो गतिशील लोडिंग पर प्रतिबंध मौलिक है: सुरक्षा मॉड्यूल को लोडिंग के क्षण से, लगातार सुरक्षा सुनिश्चित करने के लिए कर्नेल का हिस्सा होना चाहिए।

इस प्रकार, सुरक्षा एपीआई का उपयोग करने के लिए, आपको अपनी कर्नेल असेंबली की आपूर्ति करनी चाहिए, साथ ही SELinux या AppArmor के साथ ऐड-ऑन मॉड्यूल को एकीकृत करना होगा, जो कि लोकप्रिय वितरण द्वारा उपयोग किया जाता है। ग्राहक ऐसे दायित्वों की सदस्यता नहीं लेना चाहता था, इसलिए यह मार्ग बंद था।

इन कारणों के लिए, सुरक्षा एपीआई हमें सूट नहीं करता है, अन्यथा यह एक आदर्श विकल्प होगा।

सिस्टम कॉल टेबल का संशोधन

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

इस दृष्टिकोण के कुछ फायदे हैं:

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

हालाँकि, वह कुछ खामियों से भी ग्रस्त है:

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

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

Kprobes का उपयोग करना

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

अवरोधन का उपयोग करने के लाभ:

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

Kprobes के नुकसान:

तकनीकी कठिनाई। Kprobes कर्नेल में कहीं भी एक ब्रेकपॉइंट सेट करने का एक तरीका है। किसी फ़ंक्शन या स्थानीय चरों के मानों के तर्क प्राप्त करने के लिए, आपको यह जानना होगा कि कौन से रजिस्टर या जहां वे स्थित हैं, और स्वतंत्र रूप से उन्हें वहां से हटा दें। फ़ंक्शन कॉल को ब्लॉक करने के लिए, आपको मैन्युअल रूप से प्रक्रिया की स्थिति को संशोधित करना होगा ताकि प्रोसेसर को लगे कि यह फ़ंक्शन से पहले ही नियंत्रण वापस कर चुका है।
Jprobes को पदावनत किया जाता है। Jprobes kprobes के लिए एक ऐड-ऑन है जो आपको आसानी से फ़ंक्शन कॉल को इंटरसेप्ट करने की अनुमति देता है। यह स्वतंत्र रूप से रजिस्टरों या स्टैक से फ़ंक्शन के तर्कों को हटा देगा और आपके हैंडलर को कॉल करेगा, जिसमें हुक किए गए फ़ंक्शन के समान हस्ताक्षर होना चाहिए। पकड़ यह है कि जिपर को आधुनिक गुठली से निकाला और काटा जाता है।
गैर-तुच्छ ओवरहेड। ब्रेकप्वाइंट महंगे हैं, लेकिन एक बार। ब्रेकप्वाइंट अन्य कार्यों को प्रभावित नहीं करते हैं, लेकिन उनका प्रसंस्करण अपेक्षाकृत महंगा है। सौभाग्य से, x86_64 आर्किटेक्चर के लिए जंप-ऑप्टिमाइज़ेशन लागू किया गया है, जो किप्रोब्स की लागत को काफी कम कर देता है, लेकिन यह अभी भी अधिक है, उदाहरण के लिए, जब सिस्टम कॉल टेबल को संशोधित करता है।
क्रेटप्रोब्स की सीमाएं। स्टैक पर रिटर्न एड्रेस को स्पूफ करके क्रेटप्रोब्स को लागू किया जाता है। तदनुसार, उन्हें क्रेटप्रोब के प्रसंस्करण के बाद वहां लौटने के लिए मूल पते को कहीं स्टोर करना होगा। पते एक निश्चित आकार के बफर में संग्रहीत किए जाते हैं। अतिप्रवाह के मामले में, जब सिस्टम में इंटरसेप्टेड फ़ंक्शन के एक साथ कई कॉल निष्पादित होते हैं, तो क्रेटप्रॉब्स ऑपरेशन को छोड़ देगा।
विकलांग बाहर निकालना। चूँकि kprobes interrupts और juggles प्रोसेसर रजिस्टरों पर आधारित है, इसलिए सिंक्रोनाइज़ेशन के लिए सभी हैंडलर को प्रीइम्पेक्शन डिसेबल के साथ निष्पादित किया जाता है। यह हैंडलर पर कुछ प्रतिबंध लगाता है: आप उनमें इंतजार नहीं कर सकते हैं - बहुत सारी मेमोरी आवंटित करें, क्या मैं / ओ, टाइमर और सेमाफोरस में नींद, और अन्य ज्ञात चीजें।

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

स्प्लिसिंग

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

यह है कि कैसे kprobes के लिए कूद अनुकूलन लागू किया जाता है। स्प्लिसिंग का उपयोग करके, आप एक ही परिणाम प्राप्त कर सकते हैं, लेकिन kprobes के लिए अतिरिक्त लागत के बिना और स्थिति के पूर्ण नियंत्रण के साथ।

स्प्लिसिंग के लाभ स्पष्ट हैं:

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

हालांकि, इस दृष्टिकोण का मुख्य दोष गंभीरता से चित्र पर बादल है:

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

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

नए दृष्टिकोण के साथ

फ्रेस एक फंक्शन-लेवल कर्नेल ट्रेसिंग फ्रेमवर्क है। यह 2008 से विकसित किया गया है और उपयोगकर्ता कार्यक्रमों के लिए एक शानदार इंटरफ़ेस है। फ्रेस्रेस आपको फ़ंक्शन कॉल की आवृत्ति और अवधि को ट्रैक करने, कॉल ग्राफ़ प्रदर्शित करने, टेम्पलेट द्वारा रुचि के कार्यों को फ़िल्टर करने की अनुमति देता है, और इसी तरह। आप यहाँ से ftrace फीचर्स के बारे में पढ़ना शुरू कर सकते हैं , और फिर लिंक और आधिकारिक प्रलेखन का पालन कर सकते हैं।

यह संकलक कुंजी -pg और -mfentry आधार पर -pg को -mfentry , जो प्रत्येक फ़ंक्शन की शुरुआत में विशेष ट्रेस फ़ंक्शन mcount () या __fentry __ () में कॉल सम्मिलित करता है। आमतौर पर, उपयोगकर्ता कार्यक्रमों में, इस संकलक सुविधा का उपयोग प्रोफाइलरों द्वारा सभी कार्यों को कॉल ट्रैक करने के लिए किया जाता है। कर्नेल इन कार्यों का उपयोग फ़ुट्रेस फ्रेमवर्क को लागू करने के लिए करता है।

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

आवश्यक कार्यों का विवरण

प्रत्येक इंटरसेप्टेड फ़ंक्शन को निम्नलिखित संरचना द्वारा वर्णित किया जा सकता है:

 /** * struct ftrace_hook -    * * @name:    * * @function:  -,     *   * * @original:   ,     *  ,    * * @address:   ,    * * @ops:   ftrace,  , *      */ struct ftrace_hook { const char *name; void *function; void *original; unsigned long address; struct ftrace_ops ops; };

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

 #define HOOK(_name, _function, _original) \ { \ .name = (_name), \ .function = (_function), \ .original = (_original), \ } static struct ftrace_hook hooked_functions[] = { HOOK("sys_clone", fh_sys_clone, &real_sys_clone), HOOK("sys_execve", fh_sys_execve, &real_sys_execve), };

इंटरसेप्ट किए गए कार्यों पर रैपर्स निम्नानुसार हैं:

 /* *        execve(). *     .      *  :       , *    ABI (  "asmlinkage"). */ static asmlinkage long (*real_sys_execve)(const char __user *filename, const char __user *const __user *argv, const char __user *const __user *envp); /* *      .   —  *   .      *  .      ,  *    . */ static asmlinkage long fh_sys_execve(const char __user *filename, const char __user *const __user *argv, const char __user *const __user *envp) { long ret; pr_debug("execve() called: filename=%p argv=%p envp=%p\n", filename, argv, envp); ret = real_sys_execve(filename, argv, envp); pr_debug("execve() returns: %ld\n", ret); return ret; }

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

फुट्रेस इनिशियलाइज़ेशन

सबसे पहले, हमें उस फ़ंक्शन का पता ढूंढना और सहेजना होगा जिसे हम इंटरसेप्ट करेंगे। Ftrace आपको नाम से फ़ंक्शन का पता लगाने की अनुमति देता है, लेकिन हमें अभी भी इसे कॉल करने के लिए मूल फ़ंक्शन का पता जानना होगा।

आप kallsyms का उपयोग कर पता प्राप्त कर सकते हैं - कर्नेल में सभी पात्रों की एक सूची। इस सूची में सभी वर्ण शामिल हैं, न केवल मॉड्यूल के लिए निर्यात किया गया है। हुक किए गए फ़ंक्शन का पता प्राप्त करना कुछ इस तरह है:

 static int resolve_hook_address(struct ftrace_hook *hook) { hook->address = kallsyms_lookup_name(hook->name); if (!hook->address) { pr_debug("unresolved symbol: %s\n", hook->name); return -ENOENT; } *((unsigned long*) hook->original) = hook->address; return 0; }

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

 int fh_install_hook(struct ftrace_hook *hook) { int err; err = resolve_hook_address(hook); if (err) return err; hook->ops.func = fh_ftrace_thunk; hook->ops.flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY; /* ... */ }

fh_ftrace_thunk () हमारी कॉलबैक है जिसे फ़ंक्शन को ट्रेस करते समय ftrace कॉल करेगा। उसके बारे में बाद में। अवरोधन को पूरा करने के लिए हमारे द्वारा निर्धारित झंडे आवश्यक होंगे। वे प्रोसेसर रजिस्टरों को सहेजने और पुनर्स्थापित करने के लिए ftrace का निर्देश देते हैं, जिनकी सामग्री हम कॉलबैक में बदल सकते हैं।

अब हम अवरोधन को सक्षम करने के लिए तैयार हैं। ऐसा करने के लिए, आपको पहले ftrace_set_filter_ip () का उपयोग करके हमारे लिए रुचि के कार्य के लिए ftrace को सक्षम करना होगा, और फिर ftrace को register_ftrace_function () का उपयोग करके हमारे कॉलबैक को कॉल करने की अनुमति दें:

 int fh_install_hook(struct ftrace_hook *hook) { /* ... */ err = ftrace_set_filter_ip(&hook->ops, hook->address, 0, 0); if (err) { pr_debug("ftrace_set_filter_ip() failed: %d\n", err); return err; } err = register_ftrace_function(&hook->ops); if (err) { pr_debug("register_ftrace_function() failed: %d\n", err); /*    ftrace   . */ ftrace_set_filter_ip(&hook->ops, hook->address, 1, 0); return err; } return 0; }

अवरोधन को उसी तरह बंद कर दिया जाता है, केवल रिवर्स ऑर्डर में:

 void fh_remove_hook(struct ftrace_hook *hook) { int err; err = unregister_ftrace_function(&hook->ops); if (err) { pr_debug("unregister_ftrace_function() failed: %d\n", err); } err = ftrace_set_filter_ip(&hook->ops, hook->address, 1, 0); if (err) { pr_debug("ftrace_set_filter_ip() failed: %d\n", err); } }

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

एक फंक्शन हुक का प्रदर्शन करना

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

Ftrace के लिए कॉलबैक इस प्रकार है:

 static void notrace fh_ftrace_thunk(unsigned long ip, unsigned long parent_ip, struct ftrace_ops *ops, struct pt_regs *regs) { struct ftrace_hook *hook = container_of(ops, struct ftrace_hook, ops); regs->ip = (unsigned long) hook->function; }

struct ftrace_hook () मैक्रो का उपयोग करते हुए, हम अपने struct ftrace_hook का पता प्राप्त करते हैं, जो इसमें एम्बेडेड struct ftrace_hook के पते पर है, जिसके बाद हम अपने हैंडलर के पते के साथ स्ट्रक्चर struct pt_regs संरचना में% rip रजिस्टर मान को प्रतिस्थापित करते हैं। वह सब है। X86_64 के अलावा अन्य आर्किटेक्चर के लिए, इस रजिस्टर को अलग तरह से कहा जा सकता है (जैसे आईपी या पीसी), लेकिन विचार उनके लिए लागू सिद्धांत में है।

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

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

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

पुनरावर्ती कॉल संरक्षण

ऊपर दिए गए कोड में एक पकड़ है: जब हमारा रैपर मूल फ़ंक्शन को कॉल करता है, तो वह फिर से फ़्रेस हो जाता है, जो फिर से हमारे कॉलबैक को कॉल करता है, जो फिर से रैपर पर नियंत्रण स्थानांतरित करता है। इस अनंत पुनरावृत्ति को किसी तरह कम करने की आवश्यकता है।

हमारे पास होने वाला सबसे सुरुचिपूर्ण तरीका है parent_ip, फ़ुटेज कॉलबैक के एक तर्क का उपयोग करना , जिसमें फ़ंक्शन का पता पता होता है जिसे ट्रेस किए गए फ़ंक्शन कहा जाता है। आमतौर पर इस तर्क का उपयोग फ़ंक्शन कॉल के ग्राफ के निर्माण के लिए किया जाता है। इंटरसेप्टेड फ़ंक्शन के पहले कॉल को बार-बार अलग करने के लिए हम इसका उपयोग कर सकते हैं।

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

वर्तमान मॉड्यूल की सीमाओं के साथ पते की तुलना करके प्रवेश जांच बहुत कुशलता से की जा सकती है (जिसमें हमारे सभी कार्य शामिल हैं)। यह बहुत अच्छा काम करता है अगर मॉड्यूल में केवल रैपर इंटरसेप्टेड फ़ंक्शन को कॉल करता है। अन्यथा, आपको अधिक चयनात्मक होने की आवश्यकता है।

कुल में, सही ftrace कॉलबैक इस प्रकार है:

 static void notrace fh_ftrace_thunk(unsigned long ip, unsigned long parent_ip, struct ftrace_ops *ops, struct pt_regs *regs) { struct ftrace_hook *hook = container_of(ops, struct ftrace_hook, ops); /*      . */ if (!within_module(parent_ip, THIS_MODULE)) regs->ip = (unsigned long) hook->function; }

इस दृष्टिकोण की विशिष्ट विशेषताएं / लाभ:

कम ओवरहेड। बस कुछ घटाव और तुलना। कोई स्पिनलॉक, सूची पास नहीं है, और इसी तरह।
. . , .
. kretprobes , ( ). , .

आइए एक उदाहरण देखें: आपने मौजूदा निर्देशिका में फ़ाइलों की सूची देखने के लिए टर्मिनल में ls कमांड टाइप किया । शेल (कहो बाश) एक नई प्रक्रिया शुरू करने के लिए सी मानक पुस्तकालय से कांटा () + निष्पादित () कार्यों की एक पारंपरिक जोड़ी का उपयोग करता है । आंतरिक रूप से, इन कार्यों को क्रमशः सिस्टम कॉल क्लोन () और निष्पादित () के माध्यम से लागू किया जाता है। मान लें कि हम नई प्रक्रियाओं की शुरुआत को नियंत्रित करने के लिए निष्पादित () सिस्टम कॉल को रोकते हैं।

ग्राफिक रूप में, हैंडलर फ़ंक्शन का अवरोधन इस तरह दिखता है:

अवरोधन अनुक्रम आरेख

यहां हम देखते हैं कि उपयोगकर्ता प्रक्रिया ( नीला ) कर्नेल को एक सिस्टम कॉल कैसे करती है ( लाल)), जहां फूट्रेस फ्रेमवर्क ( बैंगनी ) हमारे मॉड्यूल ( ग्रीन ) से कार्य करता है ।

उपयोगकर्ता प्रक्रिया SYSCALL निष्पादित करती है। इस निर्देश का उपयोग करके, कर्नेल मोड को स्थानांतरित कर दिया जाता है और नियंत्रण को निम्न-स्तरीय सिस्टम कॉल हैंडलर - प्रविष्टि_SYSCALL_64 () में स्थानांतरित कर दिया जाता है । वह 64-बिट कर्नेल पर 64-बिट प्रोग्राम के सभी सिस्टम कॉल के लिए जिम्मेदार है।
. , , do_syscall_64 (), . sys_call_table — sys_execve ().
ftrace. __fentry__ (), ftrace. , , nop , sys_execve() .
Ftrace . ftrace , . , %rip, .
. parent_ip , do_syscall_64() — sys_execve() — , %rip pt_regs .
Ftrace . FTRACE_SAVE_REGS, ftrace pt_regs . ftrace . %rip — — .
-. - sys_execve() . fh_sys_execve (). , do_syscall_64().
. . fh_sys_execve() ( ) . . — sys_execve() , real_sys_execve , .
. sys_execve(), ftrace . , -…
. sys_execve() fh_sys_execve(), do_syscall_64(). sys_execve() . : ftrace sys_execve() .
. sys_execve() fh_sys_execve(). . , execve() , , , . .
प्रबंधन कोर में लौटता है। अंत में, fh_sys_execve () समाप्त हो जाता है और नियंत्रण do_syscall_64 () को पास करता है, जो मानता है कि सिस्टम कॉल हमेशा की तरह पूरा हो गया था। कोर अपने परमाणु कारोबार को जारी रखता है।
प्रबंधन उपयोगकर्ता प्रक्रिया पर लौटता है। अंत में, कर्नेल IRET निर्देश (या SYSRET, लेकिन निष्पादित () यह हमेशा IRET होता है) को कार्यान्वित करता है, नए उपयोगकर्ता प्रक्रिया के लिए रजिस्टर स्थापित करता है और केंद्रीय प्रोसेसर को उपयोगकर्ता कोड निष्पादन मोड में डालता है। सिस्टम कॉल (और एक नई प्रक्रिया शुरू) पूरा हो गया है।

फायदे और नुकसान

नतीजतन, हमें कर्नेल में किसी भी फ़ंक्शन को बाधित करने का एक बहुत ही सुविधाजनक तरीका मिलता है, जिसमें निम्नलिखित फायदे हैं:

API . . , , . — -, .
. . - , , , - . ( ), .
अनुरेखण अनुरेखण के साथ संगत है। जाहिर है, यह विधि फूट के साथ संघर्ष नहीं करती है, इसलिए आप अभी भी कर्नेल से बहुत उपयोगी प्रदर्शन संकेतक ले सकते हैं। Kprobes या splicing का उपयोग करने से ftrace तंत्र में बाधा आ सकती है।

इस समाधान के नुकसान क्या हैं?

कर्नेल कॉन्फ़िगरेशन आवश्यकताओं। फ्रेस का उपयोग करके फंक्शन हुक को सफलतापूर्वक करने के लिए, कर्नेल को कई सुविधाएँ प्रदान करनी चाहिए:
- नाम से फ़ंक्शंस की खोज करने के लिए कॉल्स जिम के पात्रों की सूची
- अनुरेखण के लिए सामान्य रूप से फुट्रेस फ्रेमवर्क
- महत्वपूर्ण आलोचना अवरोधन विकल्प
. , , , , . , - , .
ftrace , kprobes ( ftrace ), , , . , ftrace — , «» ftrace .
. , . , , ftrace . , , .
डबल कॉल फुट्रेस। सूचक विश्लेषण दृष्टिकोण parent_ipएक परिणाम के रूप में ऊपर वर्णित है फिर से हुक कार्यों के लिए कॉल। यह ओवरहेड का एक सा जोड़ता है और अन्य निशान नीचे दस्तक दे सकता है जो कई कॉल के रूप में दो बार देखेंगे। थोड़ा काला जादू लगाने से इस खामी को टाला जा सकता है: फंक्शन के शुरुआत में फूट्रेस कॉल स्थित है, इसलिए यदि मूल फ़ंक्शन का पता 5 बाइट्स (कॉल इंस्ट्रक्शन की लंबाई) द्वारा आगे बढ़ाया जाता है, तो आप फ़ुट्रेस से कूद सकते हैं।

कुछ नुकसानों पर अधिक विस्तार से विचार करें।

कर्नेल कॉन्फ़िगरेशन आवश्यकताओं

शुरुआत के लिए, कर्नेल को ftrace और kalls Gym का समर्थन करना चाहिए। ऐसा करने के लिए, निम्नलिखित विकल्पों को सक्षम किया जाना चाहिए:

CONFIG_FTRACE
CONFIG_KALLSYMS

फिर, फ्रेस को गतिशील रजिस्टर संशोधन का समर्थन करना चाहिए। इसके लिए विकल्प जिम्मेदार है।

CONFIG_DYNAMIC_FTRACE_WITH_REGS

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

अंत में, अवरोधन करने के लिए, फ़ंक्शन के अंदर ft कॉल का स्थान महत्वपूर्ण है: कॉल को फ़ंक्शन के प्रस्तावना से पहले (जहां स्थान स्थानीय चर के लिए आवंटित किया जाता है और स्टैक फ्रेम बनता है) से पहले ही स्थित होना चाहिए। यह आर्किटेक्चर सुविधा विकल्प द्वारा माना जाता है

CONFIG_HAVE_FENTRY

X86_64 आर्किटेक्चर इस विकल्प का समर्थन करता है, लेकिन i386 नहीं करता है। I386 वास्तुकला सीमाओं के कारण, कंपाइलर फंक्शन प्रोलॉग से पहले एक फ्रेस कॉल नहीं डाल सकता है, इसलिए, जब तक फील्रेस कहा जाता है, तब तक फ़ंक्शन स्टैक पहले से ही संशोधित हो जाता है। इस स्थिति में, अवरोधन करने के लिए, यह केवल% eip रजिस्टर के मूल्य को बदलने के लिए पर्याप्त नहीं है - आपको प्रोयोग में किए गए सभी कार्यों को उलटना चाहिए जो फ़ंक्शन से फ़ंक्शन में भिन्न होते हैं।

इस कारण से, ftrace इंटरसेप्शन x86 32-बिट आर्किटेक्चर का समर्थन नहीं करता है। सिद्धांत रूप में, इसे कुछ काले जादू का उपयोग करके लागू किया जा सकता है ("एंटी-प्रोलॉग" उत्पन्न करना और निष्पादित करना), लेकिन फिर समाधान की तकनीकी सादगी को भुगतना होगा, जो फ़ुट्रेस का उपयोग करने के फायदों में से एक है।

अचंभित आश्चर्य

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

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

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

इस विकल्प ने काम किया:

 static asmlinkage long fh_sys_execve(const char __user *filename, const char __user *const __user *argv, const char __user *const __user *envp) { long ret; pr_debug("execve() called: filename=%p argv=%p envp=%p\n", filename, argv, envp); ret = real_sys_execve(filename, argv, envp); pr_debug("execve() returns: %ld\n", ret); return ret; }

लेकिन इस एक - प्रणाली को लटका दिया:

 static asmlinkage long fh_sys_execve(const char __user *filename, const char __user *const __user *argv, const char __user *const __user *envp) { long ret; pr_devel("execve() called: filename=%p argv=%p envp=%p\n", filename, argv, envp); ret = real_sys_execve(filename, argv, envp); pr_devel("execve() returns: %ld\n", ret); return ret; }

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

बात, जैसा कि यह निकला, pr_devel () के लिए कॉल शून्य में विस्तारित हैं। प्रिंट मैक्रो के इस संस्करण का उपयोग विकास के दौरान लॉगिंग के लिए किया जाता है। ऑपरेशन के दौरान ऐसी लॉग प्रविष्टियाँ दिलचस्प नहीं हैं, इसलिए, यदि DEBUG मैक्रो घोषित नहीं किया जाता है, तो वे स्वचालित रूप से कोड से बाहर हो जाते हैं। उसके बाद, संकलक का कार्य इस में बदल जाता है:

 static asmlinkage long fh_sys_execve(const char __user *filename, const char __user *const __user *argv, const char __user *const __user *envp) { return real_sys_execve(filename, argv, envp); }

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

 0000000000000000 <fh_sys_execve>: 0: e8 00 00 00 00 callq 5 <fh_sys_execve+0x5> 5: ff 15 00 00 00 00 callq *0x0(%rip) b: f3 c3 repz retq

और गैर-काम - इस तरह:

 0000000000000000 <fh_sys_execve>: 0: e8 00 00 00 00 callq 5 <fh_sys_execve+0x5> 5: 48 8b 05 00 00 00 00 mov 0x0(%rip),%rax c: ff e0 jmpq *%rax

पहला CALL स्टेटमेंट समान __fentry __ () कॉल है जिसे कंपाइलर द्वारा सभी फंक्शन्स की शुरुआत में डाला गया है। लेकिन फिर सामान्य कोड में, आप कॉल को निर्देश के माध्यम से real_sys_execve (मेमोरी में पॉइंटर द्वारा) देख सकते हैं और fh_sys_execve () से RET निर्देश का उपयोग करके वापस आ सकते हैं। टूटे हुए कोड JMP का उपयोग करके सीधे real_sys_execve () फ़ंक्शन में जाता है।

टेल कॉल का अनुकूलन आपको "अर्थहीन" स्टैक फ्रेम के निर्माण पर थोड़ा समय बचाने की अनुमति देता है, जिसमें कॉल निर्देश द्वारा स्टैक में संग्रहीत वापसी पता शामिल है। हालांकि, हमारे लिए, वापसी पते की शुद्धता एक महत्वपूर्ण भूमिका निभाती है - हम इसका उपयोग parent_ipअवरोधन के बारे में निर्णय लेने के लिए करते हैं। अनुकूलन के बाद, fh_sys_execve () फ़ंक्शन अब स्टैक पर नए रिटर्न एड्रेस को सेव नहीं करता है, वहीं पुराना रहता है - कर्नेल की ओर इशारा करता है। इसलियेparent_ipनाभिक के अंदर इंगित करना जारी रखता है, जो अंततः एक अनंत लूप के गठन की ओर जाता है।

यह भी बताता है कि समस्या केवल कुछ वितरणों पर ही क्यों पुन: उत्पन्न हुई। जब संकलन मॉड्यूल, विभिन्न वितरण संकलन झंडे के विभिन्न सेट का उपयोग करते हैं। व्यथित वितरण में, पूंछ कॉल अनुकूलन डिफ़ॉल्ट रूप से सक्षम था।

हमारे लिए समस्या का समाधान रैपर फ़ंक्शन के साथ पूरी फ़ाइल के लिए टेल कॉल ऑप्टिमाइज़ेशन को अक्षम करना था:

 #pragma GCC optimize("-fno-optimize-sibling-calls")

निष्कर्ष

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

यदि आप स्वयं अवरोधन के साथ प्रयोग करना चाहते हैं, तो गिथब पर पूर्ण कर्नेल मॉड्यूल कोड पाया जा सकता है ।

फूट का उपयोग करके लिनक्स कर्नेल में अवरोधन कार्य