ipcdump

منشور الإعلان

ipcdump هي أداة لتتبع الاتصالات بين العمليات (IPC) على لينكس. تغطي معظم آليات IPC الشائعة — الأنابيب، الـ fifos، الإشارات، مآخذ يونكس، الشبكات المعتمدة على الحلقة المحلية، والمحطات الطرفية الزائفة. إنها أداة مفيدة لتصحيح أخطاء التطبيقات متعددة العمليات، كما أنها طريقة بسيطة لفهم كيفية تواصل الأجزاء المختلفة في نظامك مع بعضها البعض. يمكن لـ ipcdump تتبع كل من البيانات الوصفية ومحتويات هذا الاتصال، وهي مناسبة بشكل خاص لتتبع IPC بين العمليات قصيرة العمر، والتي قد يكون من الصعب تتبعها باستخدام أدوات التصحيح التقليدية مثل strace أو gdb. كما أن لديها بعض قدرات التصفية الأساسية لمساعدتك في غربلة كميات كبيرة من الأحداث. معظم المعلومات التي يجمعها ipcdump تأتي من خطافات BPF الموضوعة على kprobes و tracepoints في وظائف رئيسية في النواة، على الرغم من أنه يملأ أيضًا بعض البيانات الإضافية من نظام ملفات /proc. لهذا الغرض، يستخدم ipcdump بشكل كبير gobpf، الذي يوفر روابط golang لإطار bcc.

المتطلبات والاستخدام

• golang >= 1.15.6

أنظمة التشغيل والنوى المختبرة

*يتطلب بناء bcc من المصدر

البناء

التبعيات

1. تثبيت golang

snap install go --classic

أو مباشرة من موقع golang

2. تثبيت BCC باستخدام تعليمات iovisor اعتمادًا على نظام التشغيل الذي اخترته (عادةً ما تتطلب الإصدارات الأحدث البناء من المصدر)

بناء ipcdump

git clone https://github.com/guardicore/IPCDump
cd IPCDump/cmd/ipcdump
go build

الاستخدام

./ipcdump -h
Usage of ./ipcdump:
  -B uint
        max number of bytes to dump per event, or 0 for complete event (may be large). meaningful only if -x is specified.
  -D value
        filter by destination comm (can be specified more than once)
  -L    do not output lost event information
  -P value
        filter by comm (either source or destination, can be specified more than once)
  -S value
        filter by source comm (can be specified more than once)
  -c uint
        exit after <count> events
  -d value
        filter by destination pid (can be specified more than once)
  -f string
        <text|json> output format (default is text) (default "text")
  -p value
        filter by pid (either source or destination, can be specified more than once)
  -s value
        filter by source pid (can be specified more than once)
  -t value
        filter by type (can be specified more than once).
        possible values: 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    dump IPC bytes where relevant (rather than just event details).

أمثلة سطر واحد

شغّل كجذر:

# dump all ipc on the system
./ipcdump

# dump signals sent between any two processes
./ipcdump -t kill

# dump loopback TCP connection metadata to or from pid 1337
./ipcdump -t loopback-tcp -p 1337

# dump unix socket IPC metadata and contents from Xorg
./ipcdump -t unix -x -S Xorg

# dump json-formatted pipe i/o metadata and first 64 bytes of contents
./ipcdump -t pipe -x -B 64 -f json

الميزات

• دعم الأنابيب و FIFOs
• IPC عبر الحلقة المحلية
• الإشارات (العادية والوقت الفعلي)
• تدفقات يونكس وحزم البيانات
• IPC عبر المحطات الطرفية الزائفة
• تصفية الأحداث بناءً على PID أو اسم العملية
• إخراج بتنسيق بشري أو JSON

التصميم

تم بناء ipcdump من سلسلة من المجموعات (collectors)، كل منها مسؤول عن نوع معين من أحداث IPC. على سبيل المثال، IPC_EVENT_LOOPBACK_SOCK_UDP أو IPC_EVENT_SIGNAL.

من الناحية العملية، تم بناء جميع المجموعات باستخدام خطافات bpf المرفقة بـ kprobes و tracepoints. ومع ذلك، فإن تطبيقاتها منفصلة تمامًا — لا يوجد سبب معين لافتراض أن معلوماتنا ستأتي دائمًا من 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). تعتبر البيانات الإضافية التي تتم في كل منها مهمة بشكل خاص للعمليات قصيرة العمر؛ على الرغم من أنه يمكن ملء هذه المعلومات لاحقًا في وضع المستخدم عن طريق تحليل /proc، إلا أن العملية المعنية غالبًا ما تكون قد اختفت بحلول الوقت الذي يصل فيه الحدث إلى المعالج. ومع ذلك، فإننا نقوم أحيانًا بملء المعلومات من /proc. يحدث هذا في الغالب للعمليات التي كانت موجودة قبل تشغيل ipcdump؛ لن نلتقط أحداثًا مثل تسمية العملية في هذه الحالة. يحاول SocketIdentifier و CommIdentifier نوعًا ما تجريد هذه الثنائية بين كود bcc وتحليل /proc خلف واجهة API واحدة، على الرغم من أنها ليست نظيفة جدًا. بالمناسبة، في إصدارات لينكس الجديدة جدًا (5.8)، يمكن لمكررات bpf (bpf iterators) استبدال هذه البيانات الإضافية تمامًا، على الرغم من أنه من أجل التوافق مع الإصدارات السابقة، يجب أن نلتزم بنموذج الخطافات و procfs في الوقت الحالي.

يتم إخراج الأحداث من خلال الدالة المشتركة EmitIpcEvent()، التي تأخذ تنسيق حدث قياسي (عملية المصدر، عملية الوجهة، أزواج المفتاح والقيمة للبيانات الوصفية، والمحتويات) وتخرجه بتنسيق موحد. لتوفير عرض النطاق الترددي للأحداث، لا تقوم المجموعات عادةً بإخراج محتويات IPC إذا لم يتم تحديد العلم -x. يتم ذلك باستخدام بعض معالجة ما قبل التحليل المتقنة في internal/collection/ipc_bytes.go.

المساهمة

من فضلك ساهم! تحقق من TODO للأشياء المهمة حقًا. من المرجح أن يتضمن معظم العمل المبكر على ipcdump إجراء تعديلات لإصدارات النواة والرموز المختلفة.