Ptrace के साथ साहसिक (2)

Habré ने पहले ही ptrace माध्यम से सिस्टम कॉल के अवरोधन के बारे में लिखा था ; एलेक्सा ने इस अधिक विस्तृत पोस्ट के बारे में लिखा, जिसका मैंने अनुवाद करने का फैसला किया।

---

कहां से शुरू करें

डीबग किए गए प्रोग्राम और डीबगर के बीच संचार संकेतों का उपयोग करके होता है। यह पहले से ही मुश्किल चीजों को जटिल करता है; मनोरंजन के लिए, आप man ptrace का BUGS अनुभाग पढ़ सकते हैं।

डिबगिंग शुरू करने के लिए कम से कम दो अलग-अलग तरीके हैं:

1. ptrace(PTRACE_TRACEME, 0, NULL, NULL) वर्तमान प्रक्रिया के जनक को इसके लिए डिबगर बना देगा। माता-पिता से कोई सहायता की आवश्यकता नहीं है; man धीरे से सलाह देता है: "यदि माता-पिता इसे ट्रेस करने की उम्मीद नहीं कर रहे हैं तो एक प्रक्रिया को शायद यह अनुरोध नहीं करना चाहिए।" (अन्य जगहों पर आपने "शायद नहीं करना चाहिए" वाक्यांश देखा?) यदि वर्तमान प्रक्रिया में पहले से ही डिबगर था, तो कॉल विफल हो जाएगी।
2. ptrace(PTRACE_ATTACH, pid, NULL, NULL) वर्तमान प्रक्रिया को pid लिए डिबगर बना देगा। यदि pid पहले से ही डिबगर था, तो कॉल विफल हो जाएगी। SIGSTOP डीबग की गई प्रक्रिया SIGSTOP भेजा जाता है, और यह तब तक काम करना जारी नहीं रखेगा जब तक कि डीबगर इसे डीफ़्रॉस्ट नहीं करता।

ये दो विधियां पूरी तरह से स्वतंत्र हैं; आप या तो एक या दूसरे का उपयोग कर सकते हैं, लेकिन उनके संयोजन का कोई मतलब नहीं है। यह ध्यान रखना महत्वपूर्ण है कि PTRACE_ATTACH तात्कालिक नहीं है: ptrace(PTRACE_ATTACH) कहा जाता है के बाद, आमतौर पर ptrace(PTRACE_ATTACH) waitpid(2) को PTRACE_ATTACH "कार्य" तक प्रतीक्षा करने के लिए PTRACE_ATTACH है।

आप PTRACE_TRACEME का उपयोग करके डिबगिंग के तहत बच्चे की प्रक्रिया शुरू कर सकते हैं:

 static void tracee(int argc, char **argv) { if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) < 0) die("child: ptrace(traceme) failed: %m"); /*   ,   . */ if (raise(SIGSTOP)) die("child: raise(SIGSTOP) failed: %m"); /*  . */ execvp(argv[0], argv); /*     . */ die("tracee start failed: %m"); } static void tracer(pid_t pid) { int status = 0; /* ,       . */ if (waitpid(pid, &status, 0) < 0) die("waitpid failed: %m"); if (!WIFSTOPPED(status) || WSTOPSIG(status) != SIGSTOP) { kill(pid, SIGKILL); die("tracer: unexpected wait status: %x", status); } /*      ptrace,    . */ /* *  ,      *  ,      . *    --  API  ptrace! */ /*       PTRACE_SYSCALL. */ } /* (argc, argv) --    ,    . */ void shim_ptrace(int argc, char **argv) { pid_t pid = fork(); if (pid < 0) die("couldn't fork: %m"); else if (pid == 0) tracee(argc, argv); else tracer(pid); die("should never be reached"); } 

बिना raise(SIGSTOP) कॉल के, यह हो सकता है कि निष्पादन प्रक्रिया execvp(3) निष्पादित होगी इससे पहले कि मूल प्रक्रिया इसके लिए तैयार हो; और फिर डिबगर की क्रिया (उदाहरण के लिए, सिस्टम कॉल को इंटरसेप्ट करना) प्रक्रिया की शुरुआत से शुरू नहीं होगी।

जब डीबग करना शुरू किया जाता है, तो प्रत्येक ptrace(PTRACE_SYSCALL, pid, NULL, NULL) सिस्टम कॉल में पहली प्रविष्टि तक डीबग की गई प्रक्रिया को " ptrace(PTRACE_SYSCALL, pid, NULL, NULL) " और फिर सिस्टम कॉल छोड़ने तक।

टेलीकेनेटिक कोडांतरक

ptrace(PTRACE_SYSCALL) डीबगर को कोई जानकारी नहीं लौटाता; वह बस वादा करता है कि डिबग की जा रही प्रक्रिया हर सिस्टम कॉल पर दो बार बंद हो जाएगी। डीबग की गई प्रक्रिया के साथ क्या हो रहा है, इसके बारे में जानकारी प्राप्त करने के लिए - उदाहरण के लिए, किस सिस्टम कॉल ने इसे बंद कर दिया है - आपको कर्नेल द्वारा संग्रहीत इसके रजिस्टरों की एक प्रति में एक विशिष्ट struct user में एक प्रारूप में चढ़ने की आवश्यकता है जो विशिष्ट वास्तुकला पर निर्भर करता है। (उदाहरण के लिए, x86_64 पर, कॉल नंबर regs.orig_rax फ़ील्ड में होगा, जो पहला पैरामीटर पास किया गया है, वह regs.rdi , आदि में होगा।) एलेक्सा टिप्पणी: "ऐसा लगता है कि आप सी में असेंबली कोड लिख रहे हैं जो रिमोट प्रोसेसर के रजिस्टरों के साथ काम करता है।"

sys/user.h में वर्णित संरचना के बजाय, यह sys/reg.h में परिभाषित सूचकांक स्थिरांक का उपयोग करने के लिए अधिक सुविधाजनक हो सकता है:

 #include <sys/reg.h> /*    . */ long ptrace_syscall(pid_t pid) { #ifdef __x86_64__ return ptrace(PTRACE_PEEKUSER, pid, sizeof(long)*ORIG_RAX); #else // ... #endif } /*      . */ uintptr_t ptrace_argument(pid_t pid, int arg) { #ifdef __x86_64__ int reg = 0; switch (arg) { case 0: reg = RDI; break; case 1: reg = RSI; break; case 2: reg = RDX; break; case 3: reg = R10; break; case 4: reg = R8; break; case 5: reg = R9; break; } return ptrace(PTRACE_PEEKUSER, pid, sizeof(long) * reg, NULL); #else // ... #endif } 

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

वंश

PTRACE_O_TRACECLONE विकल्पों में से एक, जिसका नाम PTRACE_O_TRACECLONE , यह सुनिश्चित करता है कि fork(2) बाहर निकलने पर डिबग की गई प्रक्रिया के सभी बच्चों को स्वचालित रूप से डिबग किया जाएगा fork(2) । यहां एक अतिरिक्त सूक्ष्म बिंदु यह है कि डिबगिंग के लिए ले जाने वाले वंश डिबगर के "छद्म बच्चे" बन जाते हैं, और waitpid न केवल "तत्काल बच्चों" को रोकने के लिए, बल्कि "छद्म बच्चों" को रोकने के लिए भी प्रतिक्रिया देगा। मनुष्य इस बारे में चेतावनी देता है: "वाट्सएप (2) पर कॉल करते समय WCONTINUED ध्वज सेट करने की अनुशंसा नहीं की जाती है:" जारी "स्थिति प्रति-प्रक्रिया है और इसका उपभोग करना ट्रेस के वास्तविक माता-पिता को भ्रमित कर सकता है।" - यानी "छद्म बच्चे" में दो माता-पिता होते हैं जो उनके रुकने का इंतजार कर सकते हैं। डिबगर प्रोग्रामर के लिए, इसका मतलब है कि waitpid(-1) न केवल तत्काल बच्चों को रोकने के लिए, बल्कि किसी भी डीबग की गई प्रक्रिया के लिए इंतजार करेगा।

संकेत

(एक अनुवादक से बोनस सामग्री: यह जानकारी अंग्रेजी भाषा के लेख में नहीं है)
जैसा कि पहले से ही उल्लेख किया गया है, डीबग किए गए प्रोग्राम और डीबगर के बीच संचार संकेतों का उपयोग करके होता है। डिबगर से कनेक्ट होने पर एक प्रक्रिया SIGSTOP प्राप्त करता है, और फिर SIGTRAP हर बार कुछ दिलचस्प होता है प्रक्रिया में डीबग किया जा रहा है - उदाहरण के लिए, एक सिस्टम कॉल या एक बाहरी सिग्नल प्राप्त करना। डिबगर, बदले में, SIGCHLD हर बार डीबग की गई प्रक्रियाओं (जरूरी नहीं कि तत्काल बच्चा) "फ्रीज" या "फ्रीज" में से एक प्राप्त करता है।

डीबग ptrace(PTRACE_SYSCALL) प्रक्रिया को ptrace(PTRACE_SYSCALL) किया जा रहा है जिसे ptrace(PTRACE_SYSCALL) (पहले सिग्नल या सिस्टम कॉल से पहले) या ptrace(PTRACE_CONT) (पहले सिग्नल से पहले ptrace(PTRACE_SYSCALL) कॉल करके किया जाता है। जब SIGSTOP/SIGCONT संकेतों का उपयोग डिबगिंग से संबंधित उद्देश्यों के लिए भी नहीं किया जाता है, तो ptrace साथ समस्याएँ उत्पन्न हो सकती हैं: यदि डीबगर "डिबग" प्रक्रिया को SIGSTOP प्राप्त SIGSTOP , तो बाहर से यह ऐसा दिखेगा जैसे सिग्नल को अनदेखा किया गया था; यदि डीबगर प्रक्रिया को SIGCONT नहीं करता है, तो डिबग किया जा रहा है, तो बाहरी SIGCONT इसे " SIGCONT " नहीं कर सकता है।

अब मज़ेदार हिस्सा: लिनक्स स्वयं डिबगिंग से प्रक्रियाओं को प्रतिबंधित करता है, लेकिन जब माता-पिता और बच्चे एक-दूसरे को डिबग करते हैं तो लूप के निर्माण को रोकते नहीं हैं। इस स्थिति में, जब किसी एक प्रक्रिया को कोई बाहरी संकेत मिलता है, तो वह SIGTRAP माध्यम से "जमा देता है" - तब SIGCHLD दूसरी प्रक्रिया में भेजा जाता है, और यह SIGTRAP माध्यम से "जमा देता है"। बाहर से SIGCONT भेजकर इस तरह के "सह- SIGCONT " को गतिरोध से बाहर SIGCONT है; एकमात्र तरीका यह है कि बच्चे को ( SIGKILL ) को मार दिया SIGKILL , फिर माता-पिता डिबगिंग और "फ्रीज" से बाहर निकल जाएंगे। (यदि आप एक माता-पिता को मारते हैं, तो बच्चा उसके साथ मर जाएगा।) यदि बच्चा PTRACE_O_EXITKILL विकल्प को PTRACE_O_EXITKILL है, तो उसके द्वारा अभिभावक द्वारा PTRACE_O_EXITKILL गई मृत्यु भी हो जाएगी।

अब आप जानते हैं कि एक जोड़ी प्रक्रियाओं को कैसे लागू किया जाता है, जो किसी भी संकेत को प्राप्त करते समय, दोनों हमेशा के लिए स्थिर हो जाते हैं और केवल एक साथ मर जाते हैं। व्यवहार में यह आवश्यक क्यों हो सकता है, मैं समझाऊंगा नहीं :-)