
पाइप्स, सिग्नल्स, यूनिक्स सॉकेट्स, लूपबैक, और स्यूडोटर्मिनल्स के लिए BPF-आधारित Linux IPC ट्रेसर, जिसमें मेटाडेटा और कंटेंट कैप्चर, फ़िल्टरिंग और JSON आउटपुट शामिल हैं।
ipcdump, Linux पर इंटरप्रोसेस संचार (IPC) को ट्रेस करने के लिए एक उपकरण है। यह अधिकांश सामान्य IPC तंत्रों को कवर करता है — पाइप, फ़िफ़ो, सिग्नल, यूनिक्स सॉकेट, लूपबैक-आधारित नेटवर्किंग और स्यूडोटर्मिनल। यह मल्टी-प्रोसेस अनुप्रयोगों को डिबग करने के लिए एक उपयोगी उपकरण है, और यह यह समझने का एक सरल तरीका भी है कि आपके सिस्टम में विभिन्न गतिशील भाग एक-दूसरे के साथ कैसे संचार करते हैं। ipcdump इस संचार के मेटाडेटा और सामग्री दोनों को ट्रेस कर सकता है, और यह विशेष रूप से अल्पकालिक प्रक्रियाओं के बीच IPC को ट्रेस करने के लिए उपयुक्त है, जो पारंपरिक डिबगिंग उपकरणों जैसे strace या gdb का उपयोग करके कठिन हो सकता है। इसमें बड़ी मात्रा में घटनाओं को छानने में मदद करने के लिए कुछ बुनियादी फ़िल्टरिंग क्षमताएँ भी हैं।
ipcdump द्वारा एकत्रित की गई अधिकांश जानकारी कर्नेल में प्रमुख फ़ंक्शनों पर kprobes और tracepoints पर रखे गए BPF हुक से आती है, हालाँकि यह /proc फ़ाइल सिस्टम से कुछ बहीखाता भी भरता है। इस उद्देश्य के लिए ipcdump gobpf का भारी उपयोग करता है, जो bcc फ्रेमवर्क के लिए golang बाइंडिंग प्रदान करता है।
|:--------:|:------------------:|:------------------:| | 4.15.0 | परीक्षण किया गया | परीक्षण नहीं किया गया | | 5.4.0 | परीक्षण नहीं किया गया | परीक्षण किया गया | | 5.8.0 | परीक्षण नहीं किया गया | परीक्षण किया गया* |
*स्रोत से bcc बनाने की आवश्यकता है
snap install go --classic
या सीधे golang वेबसाइट से
git clone https://github.com/guardicore/IPCDump
cd IPCDump/cmd/ipcdump
go build
./ipcdump -h
Usage of ./ipcdump:
-B uint
प्रति घटना डंप करने के लिए बाइट्स की अधिकतम संख्या, या पूर्ण घटना के लिए 0 (बड़ा हो सकता है)। केवल तभी सार्थक है जब -x निर्दिष्ट किया गया हो।
-D value
गंतव्य कम्यूनिकेशन द्वारा फ़िल्टर करें (एक से अधिक बार निर्दिष्ट किया जा सकता है)
-L खोई हुई घटना की जानकारी आउटपुट न करें
-P value
कम्यूनिकेशन द्वारा फ़िल्टर करें (या तो स्रोत या गंतव्य, एक से अधिक बार निर्दिष्ट किया जा सकता है)
-S value
स्रोत कम्यूनिकेशन द्वारा फ़िल्टर करें (एक से अधिक बार निर्दिष्ट किया जा सकता है)
-c uint
<गणना> घटनाओं के बाद बाहर निकलें
-d value
गंतव्य pid द्वारा फ़िल्टर करें (एक से अधिक बार निर्दिष्ट किया जा सकता है)
-f string
<text|json> आउटपुट प्रारूप (डिफ़ॉल्ट text है) (डिफ़ॉल्ट "text")
-p value
pid द्वारा फ़िल्टर करें (या तो स्रोत या गंतव्य, एक से अधिक बार निर्दिष्ट किया जा सकता है)
-s value
स्रोत pid द्वारा फ़िल्टर करें (एक से अधिक बार निर्दिष्ट किया जा सकता है)
-t value
प्रकार द्वारा फ़िल्टर करें (एक से अधिक बार निर्दिष्ट किया जा सकता है)।
संभावित मान: a|all k|signal u|unix ud|unix-dgram us|unix-stream t|pty lo|loopback lt|loopback-tcp lu|loopback-udp p|pipe
-x जहाँ प्रासंगिक हो, IPC बाइट्स डंप करें (सिर्फ़ घटना विवरण के बजाय)।
रूट के रूप में चलाएँ:
# सिस्टम पर सभी ipc डंप करें
./ipcdump
# किन्हीं दो प्रक्रियाओं के बीच भेजे गए सिग्नल डंप करें
./ipcdump -t kill
# pid 1337 से या तक लूपबैक TCP कनेक्शन मेटाडेटा डंप करें
./ipcdump -t loopback-tcp -p 1337
# Xorg से यूनिक्स सॉकेट IPC मेटाडेटा और सामग्री डंप करें
./ipcdump -t unix -x -S Xorg
# पाइप i/o मेटाडेटा और सामग्री के पहले 64 बाइट्स को json-स्वरूपित डंप करें
./ipcdump -t pipe -x -B 64 -f json
ipcdump संग्राहकों की एक श्रृंखला से बना है, जिनमें से प्रत्येक एक विशेष प्रकार की IPC घटना के प्रभारी है। उदाहरण के लिए, IPC_EVENT_LOOPBACK_SOCK_UDP या IPC_EVENT_SIGNAL।
व्यवहार में, सभी संग्राहक kprobes और tracepoints से जुड़े bpf हुक का उपयोग करके बनाए गए हैं। हालाँकि उनके कार्यान्वयन पूरी तरह से अलग हैं — यह मानने का कोई विशेष कारण नहीं है कि हमारी जानकारी हमेशा bpf से आएगी। फिर भी, विभिन्न संग्राहकों को एकल bpf मॉड्यूल साझा करना होगा, क्योंकि कुछ सामान्य कोड है जिसे उन्हें साझा करने की आवश्यकता है। इस उद्देश्य के लिए, हम एक एकल BpfBuilder साझा करते हैं (जो मूल रूप से bcc कोड के स्ट्रिंग को जोड़ने के चारों ओर एक आवरण है) और प्रत्येक संग्राहक उस बिल्डर के साथ अपना कोड पंजीकृत करता है। फिर पूर्ण bcc स्क्रिप्ट को gobpf के साथ लोड किया जाता है, और प्रत्येक मॉड्यूल अपने आवश्यक हुक रखता है।
वर्तमान में दो प्रकार के बहीखाता हैं जो IPC संग्राहकों के बीच साझा किए जाते हैं:
SocketIdentifier (internal/collection/sock_id.go) — कर्नेल struct sock* और उनका उपयोग करने वाली प्रक्रियाओं के बीच मैप करता है।CommIdentifier (internal/collection/comm_id.go) — pid संख्याओं और संबंधित प्रक्रिया नाम (/proc/<pid>/comm) के बीच मैप करता है।
इनमें से प्रत्येक में किया गया बहीखाता विशेष रूप से अल्पकालिक प्रक्रियाओं के लिए महत्वपूर्ण है; जबकि यह जानकारी बाद में usermode में /proc को पार्स करके भरी जा सकती है, अक्सर प्रासंगिक प्रक्रिया तब तक गायब हो चुकी होगी जब तक घटना हैंडलर तक पहुँचती है। फिर भी, हम कभी-कभी /proc से जानकारी भरते हैं। यह अधिकतर उन प्रक्रियाओं के लिए होता है जो ipcdump चलाने से पहले मौजूद थीं; इस मामले में हम प्रक्रिया नामकरण जैसी घटनाओं को नहीं पकड़ेंगे। SocketIdentifier और CommIdentifier एक अर्थ में bcc कोड और /proc पार्सिंग के बीच इस द्वैत को एक एकल API के पीछे अमूर्त करने का प्रयास करते हैं, हालाँकि यह बहुत साफ नहीं है। वैसे, Linux (5.8) के सुपर-नए संस्करणों में, bpf इटरेटर इस बहीखाता को पूरी तरह से बदल सकते हैं, हालाँकि पिछड़े संगतता के लिए हमें अभी के लिए हुक-एंड-प्रॉकफ़्स प्रतिमान पर बने रहना चाहिए।घटना आउटपुट सामान्य EmitIpcEvent() फ़ंक्शन के माध्यम से किया जाता है, जो एक मानक घटना प्रारूप (स्रोत प्रक्रिया, गंतव्य प्रक्रिया, मेटाडेटा कुंजी-मूल्य जोड़े, और सामग्री) लेता है और इसे एक एकीकृत प्रारूप में आउटपुट करता है। घटना बैंडविड्थ बचाने के लिए, संग्राहक आमतौर पर IPC सामग्री आउटपुट नहीं करते हैं यदि -x फ़्लैग निर्दिष्ट नहीं है। यह internal/collection/ipc_bytes.go में कुछ फैंसी प्रीप्रोसेसिंग जादू के साथ किया जाता है।
कृपया करें! वास्तव में महत्वपूर्ण चीज़ों के लिए TODO देखें। ipcdump पर अधिकांश प्रारंभिक कार्य में संभवतः विभिन्न कर्नेल संस्करणों और प्रतीकों के लिए समायोजन करना शामिल होगा।