eBPF บน Linux: เจาะลึกความต่าง kprobe และ fentry ในระบบจริง

บทความจากนักพัฒนาเบื้องหลังโปรเจกต์โอเพนซอร์ส SentinelEdge ได้ออกมาเผยแพร่ข้อมูลเชิงลึกเกี่ยวกับการใช้งาน eBPF บนเคอร์เนล Linux โดยเฉพาะการเปรียบเทียบระหว่างวิธีการแนบโปรแกรมสองแบบที่พบบ่อย ได้แก่ kprobe และ fentry ซึ่งมักถูกมองข้ามและเข้าใจผิดว่าเป็นสิ่งเดียวกันที่สามารถสลับใช้งานแทนกันได้ทันที แต่ในความเป็นจริงแล้ว ทั้งสองวิธีมีกลไกการติดตั้งภายในเคอร์เนล รูปแบบการส่งต่ออาร์กิวเมนต์ และต้นทุนการประมวลผลต่อการเรียกใช้งานที่แตกต่างกันอย่างสิ้นเชิง

ในโปรเจกต์ SentinelEdge ซึ่งมีการเชื่อมต่อเคอร์เนลผ่าน kprobe ถึง 13 จุด เช่น การตรวจสอบกิจกรรม memory-mapping ด้วย do_mmap หรือเหตุการณ์อื่นๆ อย่าง do_exit, init_module และ do_mount เผยให้เห็นว่าจุดเด่นของ kprobe คือความดิบและความยืดหยุ่นที่ไม่จำเป็นต้องพึ่งพาข้อมูลประเภท (Type Information) หรือการคอมไพล์พิเศษ สามารถแพตช์ไบต์และเกาะติดฟังก์ชันเกือบทุกประเภทได้ทันที แม้กระทั่งบนเคอร์เนลรุ่นเก่าที่ไม่มีโครงสร้างการติดตามแบบมีไทป์รองรับ

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ในทางตรงกันข้าม การใช้งาน fentry จะอาศัยโครงสร้างพื้นฐานที่ทันสมัยกว่า โดยทำงานผ่านการเรียกฟังก์ชันโดยตรง (Call/Trampoline) แทนที่จะเป็นการสร้างข้อยกเว้นแบบ int3 ทำให้ไม่มีกระบวนการ trap หรือ single-step ส่งผลให้ต้นทุน CPU ใกล้เคียงกับการเรียกฟังก์ชันทางอ้อมปกติมากที่สุด นอกจากนี้ fentry ยังมาพร้อมกับความปลอดภัยด้านไทป์ (Type Safety) แต่มีข้อแลกเปลี่ยนคือต้องทำงานบนเคอร์เนลยุคใหม่ที่เปิดใช้งาน BTF (BPF Type Format) เท่านั้น

ความแตกต่างที่สำคัญที่สุดคือเรื่องของต้นทุนต่อความถี่ในการเรียกใช้งาน (Per-call cost) หากเป็นการดักจับเหตุการณ์ที่เกิดขึ้นไม่บ่อย เช่น การโหลดโมดูลหรือการออกจากกระบวนการ ต้นทุนจากกลไกข้อยกเว้นของ kprobe ถือเป็นเรื่องเล็กน้อยที่ยอมรับได้ แต่หากนำไปใช้กับเส้นทางคำขอที่มีความหนาแน่นสูง (Hot Path) เช่น ฟังก์ชัน recvmsg ในระบบที่รองรับคำขอแสนครั้งต่อวินาที ต้นทุนที่เพิ่มขึ้นจะกลายเป็นภาระหนักต่อทรัพยากรของเครื่องทันที โดยเฉพาะในโครงสร้างพื้นฐานด้าน AI ที่ eBPF มักเป็นเครื่องมือเดียวในการตรวจสอบความหน่วงของระบบ syscall ระหว่างการประมวลผล