लिनक्स कर्नेल में प्रबंधित पेजफॉल्ट

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

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

मुख्य अपवाद

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

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

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

अपवाद हैंडलिंग इंटरफ़ेस

यह समझने के लिए कि संकेतित तंत्र कैसे लागू किया जाता है, यह कर्नेल से उपयोगकर्ता को 4 बाइट्स की प्रतिलिपि बनाने के आदिम के कार्यान्वयन पर विचार करने के लायक है - __put_user_4 फ़ंक्शन:

 62 ENTRY(__put_user_4) 63 ENTER 64 mov TI_addr_limit(%_ASM_BX),%_ASM_BX 65 sub $3,%_ASM_BX 66 cmp %_ASM_BX,%_ASM_CX 67 jae bad_put_user 68 ASM_STAC 69 3: movl %eax,(%_ASM_CX) <-     70 xor %eax,%eax 71 EXIT 72 ENDPROC(__put_user_4) ... 89 bad_put_user: 90 CFI_STARTPROC 91 movl $-EFAULT,%eax 92 EXIT ... 98 _ASM_EXTABLE(3b,bad_put_user) 

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

 43 # define _ASM_EXTABLE(from,to) \ 44 .pushsection "__ex_table","a" ; \ 45 .balign 8 ; \ 46 .long (from) - . ; \ 47 .long (to) - . ; \ 48 .popsection 

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

अपवाद तालिकाओं और उनके प्रसंस्करण

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

 97 struct exception_table_entry { 98 int insn, fixup; 99 }; 

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

कर्नेल मॉड्यूल के व्यक्तिगत अपवाद तालिकाओं के लिए, इन तालिकाओं के तत्वों का प्रारूप मानक है और कर्नेल के लिए संगत है। प्रत्येक मॉड्यूल के लिए ऐसी तालिका का लिंक THIS_MODULE->extable तहत उपलब्ध है, जबकि तालिका तत्वों की संख्या THIS_MODULE->num_exentries में निहित है। स्वयं THIS_MODULE मैक्रो मॉड्यूल डिस्क्रिप्टर संरचना का लिंक प्रदान करता है:

 223 struct module 224 { ... 276 /* Exception table */ 277 unsigned int num_exentries; 278 struct exception_table_entry *extable; ... 378 }; 

निम्नलिखित एक महत्वपूर्ण कर्नेल फ़ंक्शन है जो उस हैंडलर की खोज करता है जो उस निर्देश से मेल खाता है जो अपवाद का कारण बनता है। यहाँ उसका कोड है :

  50 /* Given an address, look for it in the exception tables. */ 51 const struct exception_table_entry *search_exception_tables(unsigned long addr) 52 { 53 const struct exception_table_entry *e; 54 55 e = search_extable(__start___ex_table, __stop___ex_table-1, addr); 56 if (!e) 57 e = search_module_extables(addr); 58 return e; 59 } 

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

कर्नेल मॉड्यूल में अपवाद हैंडलिंग

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

तो, पेजफॉल्ट अपवादों की पीढ़ी के साथ नियमित NULL पॉइंटर डिफरेंस डील करने वाले फ़ंक्शन को दें:

 static void raise_page_fault(void) { debug(" %s enter\n", __func__); ((int *)0)[0] = 0xdeadbeef; debug(" %s leave\n", __func__); } 

जाहिर है, अशक्त सूचक को लिखने की कोशिश से दुर्घटना हो सकती है। और यह वही है जो आपको चाहिए। ठीक से प्रतिक्रिया देने के लिए, आपको यह करना होगा:

• अपवाद के कारण निर्देश का पता निर्धारित करें
• एक मान्य तत्व exception_table_entry ______ बनाएँ
• मॉड्यूल की extable तालिका में बनाया गया तत्व जोड़ें

निम्नलिखित एक ऐसा कार्य है जो udis86 का उपयोग करके disassembly का उपयोग करके उपरोक्त क्रियाएं करता है:

 static int fixup_page_fault(struct exception_table_entry * entry) { ud_t ud; ud_initialize(&ud, BITS_PER_LONG, \ UD_VENDOR_ANY, (void *)raise_page_fault, 128); while (ud_disassemble(&ud) && ud.mnemonic != UD_Iret) { if (ud.mnemonic == UD_Imov && \ ud.operand[0].type == UD_OP_MEM && ud.operand[1].type == UD_OP_IMM) { unsigned long address = \ (unsigned long)raise_page_fault + ud_insn_off(&ud); extable_make_insn(entry, address); extable_make_fixup(entry, address + ud_insn_len(&ud)); return 0; } } return -EINVAL; } 

जैसा कि आप देख सकते हैं, पहला कदम raise_page_fault को कॉन्फ़िगर करना है (विश्लेषण की शुरुआत है raise_page_fault )। अगला, दी गई खोज गहराई के साथ, कमांड्स पर पुनरावृति। वांछित कमांड (क्या ऑपरेशन का अनुवाद किया गया है ((int *)0)[0] = 0xdeadbeef; ) एक नियमित movl $0xdeadbeef, 0 प्रकार के पहले ऑपरेंड के साथ UD_OP_MEM और दूसरा प्रकार UD_OP_IMM । जैसे ही कमांड एड्रेस मिलता है, टेबल एलिमेंट बनता है। उसी समय, कार्य किए जाते हैं:

 static void extable_make_insn(struct exception_table_entry * entry, unsigned long addr) { #if LINUX_VERSION_CODE >= KERNEL_VERSION(3,5,0) entry->insn = (unsigned int)((addr - (unsigned long)&entry->insn)); #else entry->insn = addr; #endif } static void extable_make_fixup(struct exception_table_entry * entry, unsigned long addr) { #if LINUX_VERSION_CODE >= KERNEL_VERSION(3,5,0) entry->fixup = (unsigned int)((addr - (unsigned long)&entry->fixup)); #else entry->fixup = addr; #endif } 

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

निष्कर्ष

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

इसके अलावा, तैयार किए गए परीक्षण मामले से हमें कुछ अन्य अपवादों को संभालने की संभावना का मूल्यांकन करने की अनुमति मिलती है, जैसे कि विभाजन त्रुटि (#DE) और अपरिभाषित opcode (#UD):

 struct { const char * name; int (* fixup)(struct exception_table_entry *); void (* raise)(void); } exceptions[] = { { .name = "0x00 - div0 error (#DE)", .fixup = fixup_div0_error, .raise = raise_div0_error, }, { .name = "0x06 - undefined opcode (#UD)", .fixup = fixup_undefined_opcode, .raise = raise_undefined_opcode, }, { .name = "0x14 - page fault (#PF)", .fixup = fixup_page_fault, .raise = raise_page_fault, }, };