सावधानी: सिस्टम प्रोग्रामिंग है। हां, संक्षेप में, इसमें कुछ और शामिल नहीं है।

आइए कल्पना करें कि आपको एक काल्पनिक फंतासी खेल लिखने का काम दिया गया था। खैर, वहाँ कल्पित बौने के बारे में। और आभासी वास्तविकता के बारे में। बचपन से, आपने ऐसा कुछ लिखने का सपना देखा था और बिना किसी हिचकिचाहट के सहमत थे। जल्द ही, आपको एहसास होता है कि आप ज्यादातर पुराने बशीरघ और अन्य विवादित स्रोतों से चुटकुलों की दुनिया के बारे में जानते हैं। उफ़, एक समस्या। खैर, जहां हमारा गायब नहीं हुआ ... समृद्ध प्रोग्रामिंग अनुभव द्वारा सिखाया गया है, आप Google पर जाएं, "एल्फ विनिर्देश" दर्ज करें और लिंक का पालन करें। ओह! यह किसी प्रकार की पीडीएफ की ओर जाता है ... तो हमारे पास यहां क्या है ... कुछ प्रकार के Elf32_Sword तलवार - Elf32_Sword तलवारें - ऐसा लगता है कि आपको क्या चाहिए। 32 जाहिर तौर पर चरित्र का स्तर है, और निम्नलिखित कॉलम में दो चार शायद नुकसान हैं। वास्तव में आप क्या जरूरत है, और इसके अलावा कैसे व्यवस्थित!

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

आज मैं किसी फ़ाइल को 64-बिट ईएलएफ प्रारूप में पार्स करने के बारे में बात करने की कोशिश करूंगा। सिद्धांत रूप में, जो वे इसमें संग्रहीत करते हैं, वे हैं मूल कार्यक्रम, स्थिर पुस्तकालय, डायनेमिक लाइब्रेरी, हर कार्यान्वयन विशिष्ट, जैसे क्रैशडम्प्स ... इसका उपयोग किया जाता है, उदाहरण के लिए, लिनक्स और कई अन्य यूनिक्स जैसे सिस्टम, हां, वे कहते हैं, यहां तक ​​कि फोन भी। इसका समर्थन सक्रिय रूप से पहले पैच किए गए फर्मवेयर में भरा हुआ था। ऐसा लगता है कि गंभीर ऑपरेटिंग सिस्टम से कार्यक्रमों के भंडारण के लिए प्रारूप का समर्थन करना मुश्किल होना चाहिए। तो मैंने सोचा। हाँ, यह शायद है। लेकिन हम एक बहुत विशिष्ट उपयोग के मामले का समर्थन करेंगे: .o फ़ाइलों से eBPF बाइटकोड लोड करना। ऐसा क्यों? बस आगे के प्रयोगों के लिए, मुझे कुछ गंभीर (यानी, घुटने-ऊंचे नहीं ) क्रॉस-प्लेटफॉर्म बायटेकोड की आवश्यकता होगी, जिसे मैन्युअल रूप से लिखे जाने के बजाय सी से प्राप्त किया जा सकता है, इसलिए ईएक्सपीएफ सरल है और इसके लिए एलएलवीएम बैकएंड है। और मुझे बस एक कंटेनर के रूप में ईएलएफ को पार्स करने की आवश्यकता है जिसमें इस बायटेकोड को संकलक द्वारा डाला जाता है।

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

हैडर

ईएलएफ में शून्य ऑफसेट से शुरू हेडर निहित है। इसमें बहुत अक्षर E, L, F शामिल हैं, जिन्हें आप पाठ संपादक और कुछ वैश्विक चर के साथ खोलने का प्रयास कर सकते हैं। दरअसल, हेडर एक निश्चित ऑफसेट पर स्थित फ़ाइल में एकमात्र संरचना है, और इसमें बाकी संरचना को खोजने के लिए जानकारी शामिल है। (इसके बाद, मैं 32-बिट प्रारूप और elf.h लिए प्रलेखन द्वारा निर्देशित elf.h , जो 64-बिट के बारे में जानता है। इसलिए, यदि आप त्रुटियों को नोटिस करते हैं, तो उन्हें सुधारने के लिए स्वतंत्र महसूस करें)

पहली चीज़ जो हमें फ़ाइल में मिलती है, वह unsigned char e_ident[16] । इन मजेदार लेखों को याद रखें "निम्नलिखित बयानों में से सभी झूठे हैं" श्रृंखला? यहाँ यह उसी के बारे में है: ELF में 32- या 64-बिट कोड, लिटिल या बिग एंडियन और यहां तक ​​कि एक दर्जन से अधिक आर्किटेक्चर हो सकते हैं। आप इसे थोड़ा एंडियन के तहत एल्फ 64 के रूप में पढ़ने जा रहे हैं - अच्छी तरह से, सौभाग्य ... बाइट्स की यह सरणी एक तरह का हस्ताक्षर है जो अंदर है और इसे पार्स कैसे किया जाए।

पहले चार बाइट्स के साथ, सब कुछ सरल है - यह [0x7f, 'E', 'L', 'F'] । यदि वे मेल नहीं खाते हैं, तो यह मानने का कारण है कि वे किसी प्रकार की गलत मधुमक्खियाँ हैं। अगले बाइट में क्लास होता है चरित्र फ़ाइल: ELFCLASS32 या ELFCLASS64 - बिट गहराई। सादगी के लिए, हम केवल 64-बिट फ़ाइलों के साथ काम करेंगे (क्या 32-बिट ईएक्सपीएफ?) है। यदि कक्षा ELFCLASS32 हो ELFCLASS32 , तो हम बस एक त्रुटि के साथ बाहर निकलते हैं: सभी समान, संरचना "फ्लोट" करेंगे, और पवित्रता जांच ऐसा करने के लिए चोट नहीं पहुंचेगी। इस संरचना में हमारे लिए ब्याज की अंतिम बाइट फ़ाइल की समाप्ति का संकेत देती है - हम अपने प्रोसेसर के लिए केवल मूल बाइट ऑर्डर के साथ काम करेंगे।

यदि मैं C में ELF प्रारूप के साथ काम कर रहा हूं, तो आप स्पष्ट रूप से बताएंगे: आपको प्रत्येक गणना को चतुराई से गणना किए गए ऑफसेट से घटाया जाना चाहिए - elf.h में आवश्यक संरचनाएं हैं, और यहां तक ​​कि e_ident में बाइट नंबर भी हैं: EI_MAG0 , EI_MAG1 , EI_MAG2 , EI_MAG3 , EI_CLASS डेटा से पॉइंटर को फाइल से मेमोरी में मैप या मैप करने के लिए पॉइंटर से स्ट्रक्चर और रीड किया जाता है।

e_ident अलावा e_ident हेडर में अन्य फ़ील्ड शामिल हैं, कुछ हम सिर्फ जाँच करेंगे, और कुछ का उपयोग आगे के विश्लेषण के लिए किया जाएगा, लेकिन बाद में। अर्थात्, हम e_machine == EM_BPF कि e_machine == EM_BPF (अर्थात, यह "eBPF प्रोसेसर की वास्तुकला के अंतर्गत है"), e_type == ET_REL , e_shoff != 0 । अंतिम चेक के निम्नलिखित अर्थ हैं: एक फ़ाइल में लिंकिंग (सेक्शन टेबल और सेक्शन), लॉन्च करने के लिए (प्रोग्राम टेबल और सेगमेंट), या दोनों के लिए जानकारी हो सकती है। पिछले दो चेक के साथ, हम यह सत्यापित करते हैं कि हमें जो जानकारी चाहिए (जैसे कि लिंक करने के लिए) फाइल में है। यह भी जांचें कि प्रारूप का संस्करण EV_CURRENT ।

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

अनुभाग तालिका

जैसा कि मैंने कहा, हम फाइल के लिंकिंग व्यू, यानी सेक्शन टेबल और स्वयं सेक्शन में रुचि रखते हैं। हेडर में सेक्शन टेबल की तलाश के लिए जानकारी कहाँ है। इसका आकार वहां भी इंगित किया गया है, साथ ही एक तत्व का आकार - यह आकार से बड़ा हो सकता है sizeof(Elf64_Shdr) (क्योंकि यह प्रारूप के संस्करण संख्या को प्रभावित करेगा, मुझे ईमानदारी से पता नहीं है)। कुछ प्रमुख खंड संख्याएँ आरक्षित हैं, और वास्तव में तालिका में मौजूद नहीं हैं। उन्हें संदर्भित करने का विशेष अर्थ है। हम स्पष्ट रूप से केवल SHN_UNDEF में रुचि रखते हैं (शून्य भी आरक्षित है - लापता अनुभाग; जैसा कि आप जानते हैं, तालिका में इसका शीर्षक अभी भी है) SHN_ABS । चरित्र " SHN_UNDEF अनुभाग में परिभाषित" वास्तव में अपरिभाषित है, और SHN_ABS इसका वास्तव में एक पूर्ण मूल्य है और इसे स्थानांतरित नहीं किया जाता है। हालाँकि, SHN_ABS मेरे SHN_ABS नहीं लगती है।

पंक्ति तालिका

यहाँ हम पहली बार स्ट्रिंग टेबल - फाइल में प्रयुक्त स्ट्रिंग्स के टेबल के लिए आते हैं। वास्तव में, यदि const char *strtab स्ट्रिंग्स की एक तालिका है, तो sh_name केवल strtab + sh_name । हां, यह केवल एक निश्चित सूचकांक से शुरू होने वाली रेखा है और शून्य बाइट तक जारी है। पंक्तियाँ प्रतिच्छेद कर सकती हैं (अधिक सटीक रूप से, एक दूसरे का प्रत्यय हो सकता है)। अनुभागों में नाम हो सकते हैं, फिर ELF हैडर में e_shstrndx फ़ील्ड पंक्ति तालिका (अनुभाग नामों के लिए एक, यदि कई हैं) के एक खंड को इंगित करेगा, और अनुभाग हेडर में एक विशिष्ट पंक्ति में sh_name फ़ील्ड।

पंक्ति तालिका के पहले (शून्य) और अंतिम बाइट में अशक्त वर्ण होते हैं। उत्तरार्द्ध समझ में आता है क्यों: मूल्य-घंटे, अंतिम पंक्ति समाप्त होती है। लेकिन शून्य ऑफसेट एक अनुपस्थित या खाली नाम निर्दिष्ट करता है - संदर्भ के आधार पर।

लोड हो रहा है वर्गों

प्रत्येक सेक्शन के हेडर में दो एड्रेस होते हैं: एक, sh_addr लोड एड्रेस (जहाँ सेक्शन को मेमोरी में रखा जाएगा), दूसरा, sh_offset उस फाइल में ऑफसेट होता है जिस पर यह सेक्शन निहित है। मुझे नहीं पता कि वे दोनों कैसे हैं, लेकिन व्यक्तिगत रूप से इनमें से प्रत्येक मान 0 हो सकता है: एक मामले में, अनुभाग "डिस्क पर रहता है", क्योंकि किसी प्रकार की सेवा जानकारी है। दूसरे में, अनुभाग डिस्क से लोड नहीं किया जाता है , उदाहरण के लिए, आपको बस इसे चुनने और इसे शून्य ( .bss ) के साथ स्कोर करने की आवश्यकता है। ईमानदारी से, जबकि मुझे डाउनलोड पते को संसाधित नहीं करना था - जहां इसे अपलोड किया गया था, वहां इसे अपलोड किया गया :) हालांकि, हमारे पास विशिष्ट कार्यक्रम हैं, स्पष्ट रूप से, भी।

पुनर्वास

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

मेरे प्रयोग के लिए, मुझे नियमित libdl साथ लोड किए गए एक नियमित बूट में संकलित कोड का एक टुकड़ा libdl । यहाँ मैंने विस्तार से वर्णन भी नहीं किया है - बस dlopen खोलें, dlsym माध्यम से वर्णों को बाहर dlsym , कार्यक्रम dlclose होने पर इसे dlclose साथ बंद करें। हालांकि, यहां तक ​​कि ये कार्यान्वयन विवरण भी हैं जो हमारे ईएलएफ फ़ाइल लोडर से संबंधित नहीं हैं। बस कुछ संदर्भ है : नाम से सूचक प्राप्त करने की क्षमता।

सामान्य तौर पर, eBPF निर्देश सेट संरेखित मशीन कोड की एक जीत है: एक निर्देश में हमेशा 8 बाइट्स होते हैं और एक संरचना होती है

 struct { uint8_t opcode; uint8_t dst:4; uint8_t src:4; uint16_t offset; uint32_t imm; }; 

इसके अलावा, प्रत्येक विशिष्ट निर्देश में कई क्षेत्रों का उपयोग नहीं किया जा सकता है - एक "मशीन" कोड के लिए अंतरिक्ष की बचत हमारे बारे में नहीं है।

वास्तव में, पहला निर्देश तुरंत दूसरे का पालन कर सकता है, जिसमें कोई भी ऑपकोड नहीं होता है, लेकिन बस 32 से 64 बिट्स तक तत्काल क्षेत्र का विस्तार होता है। इस तरह के एक यौगिक निर्देश के लिए एक पैच है जिसे R_BPF_64_64 कहा जाता है।

स्थानांतरण करने के लिए, एक बार फिर हम sh_type == SHT_REL के अनुभाग तालिका को sh_type == SHT_REL । शीर्ष लेख का sh_info फ़ील्ड इंगित करेगा कि हम किस अनुभाग को पैच कर रहे हैं, और sh_link - वर्णों का वर्णन किस तालिका से लेना है।

 typedef struct { Elf64_Addr r_offset; Elf64_Xword r_info; } Elf64_Rel; 

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

• प्रतीक SHN_ABS अनुभाग को संदर्भित करता है। तो बस st_value ले st_value
• चरित्र `SHN_UNDEF अनुभाग को संदर्भित करता है। फिर बाहरी प्रतीक खींचें
• अन्य मामलों में, बस उसी फ़ाइल के किसी अन्य अनुभाग के लिंक को पैच करें

इसे खुद कैसे आजमाएं

पहला, क्या पढ़ना है? पहले से निर्दिष्ट विनिर्देश के अलावा , यह इस फ़ाइल को पढ़ने के लिए समझ में आता है, जिसमें iovisor टीम eBPF के माध्यम से लिनक्स कर्नेल से निकाली गई जानकारी एकत्र करती है।

दूसरे, कैसे, वास्तव में, सभी को इसके साथ काम करना चाहिए? पहले आपको कहीं से ELF फ़ाइल प्राप्त करने की आवश्यकता है। जैसा कि स्टैकऑवरफॉ में कहा गया है , टीम हमारी मदद करेगी।

 clang -O2 -emit-llvm -c bpf.c -o - | llc -march=bpf -filetype=obj -o bpf.o 

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

 $ objdump : objdump <> <()>     <()>.          : -a, --archive-headers Display archive header information -f, --file-headers Display the contents of the overall file header -p, --private-headers Display object format specific file header contents -P, --private=OPT,OPT... Display object format specific contents -h, --[section-]headers Display the contents of the section headers -x, --all-headers Display the contents of all headers -d, --disassemble Display assembler contents of executable sections -D, --disassemble-all Display assembler contents of all sections --disassemble=<sym> Display assembler contents from <sym> -S, --source Intermix source code with disassembly -s, --full-contents Display the full contents of all sections requested -g, --debugging Display debug information in object file -e, --debugging-tags Display debug information using ctags style -G, --stabs Display (in raw form) any STABS info in the file -W[lLiaprmfFsoRtUuTgAckK] or --dwarf[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames, =frames-interp,=str,=loc,=Ranges,=pubtypes, =gdb_index,=trace_info,=trace_abbrev,=trace_aranges, =addr,=cu_index,=links,=follow-links] Display DWARF info in the file -t, --syms Display the contents of the symbol table(s) -T, --dynamic-syms Display the contents of the dynamic symbol table -r, --reloc Display the relocation entries in the file -R, --dynamic-reloc Display the dynamic relocation entries in the file @<file> Read options from <file> -v, --version Display this program's version number -i, --info List object formats and architectures supported -H, --help Display this information 

लेकिन इस मामले में, यह शक्तिहीन है:

 $ objdump -d test-bpf.o test-bpf.o:   elf64-little objdump:      UNKNOWN! 

अधिक सटीक रूप से, यह वर्गों को दिखाएगा, लेकिन असंतुष्ट एक समस्या है। यहां हमें याद है कि हमने LLVM का उपयोग करके क्या एकत्र किया था। llvm-< > से उपयोगिताओं के अपने स्वयं के विस्तारित एनालॉग हैं, फॉर्म llvm-< > नामों के साथ। वे, उदाहरण के लिए, एलएलवीएम बिटकोड को समझते हैं। और वे eBPF को भी समझते हैं - यह सुनिश्चित करने के लिए कि यह संकलन विकल्पों पर निर्भर करता है, लेकिन चूंकि यह संकलित है, इसलिए इसे हमेशा पार्स किया जाना चाहिए। इसलिए, सुविधा के लिए, मैं एक स्क्रिप्ट बनाने की सलाह देता हूं:

 vim test-bpf.c #     clang -Oz -emit-llvm -c test-bpf.c -o - | llc -march=bpf -filetype=obj -o test-bpf.o llvm-objdump -d -t -r test-bpf.o 

फिर ऐसे स्रोत के लिए:

 #include <stdint.h> extern uint64_t z; uint64_t func(uint64_t x, uint64_t y) { return x + y + z; } 

ऐसा परिणाम होगा:

 $ ./compile-bpf.sh test-bpf.o: file format ELF64-BPF Disassembly of section .text: 0000000000000000 func: 0: bf 20 00 00 00 00 00 00 r0 = r2 1: 0f 10 00 00 00 00 00 00 r0 += r1 2: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll 0000000000000010: R_BPF_64_64 z 4: 79 11 00 00 00 00 00 00 r1 = *(u64 *)(r1 + 0) 5: 0f 10 00 00 00 00 00 00 r0 += r1 6: 95 00 00 00 00 00 00 00 exit SYMBOL TABLE: 0000000000000000 l df *ABS* 00000000 test-bpf.c 0000000000000000 ld .text 00000000 .text 0000000000000000 g F .text 00000038 func 0000000000000000 *UND* 00000000 z 

कोड ।

भाग 1. QInst: एक दिन खोना बेहतर है, फिर पांच मिनट में उड़ान भरें (लेखन उपकरण तुच्छ है)