Chapter 1: What Is eBPF, and Why Is It Important?

Artikel ini merupakan rangkuman dari buku Learning eBPF karya Liz Rice, yang membahas bagaimana eBPF berkembang dari teknologi packet filtering sederhana menjadi platform serbaguna di dalam kernel Linux. Buku ini menjelaskan konsep dasar, arsitektur, hingga berbagai use case nyata eBPF di bidang networking, observability, dan security.

Catatan: Seluruh gambar yang digunakan dalam artikel ini bersumber dari buku Learning eBPF dan digunakan untuk membantu menjelaskan konsep-konsep yang dibahas.

Chapter 1: What Is eBPF, and Why Is It Important?

eBPF’S Roots

• eBPF berawal dari Berkeley Packet Filter (BPF) yang diperkenalkan pada tahun 1993 oleh Steven McCanne dan Van Jacobson. Awalnya, BPF adalah mesin semu sederhana yang menjalankan program filter berbasis instruksi 32-bit mirip assembly untuk memutuskan apakah paket jaringan diterima atau ditolak. Contoh klasiknya adalah filter yang hanya menerima paket Internet Protocol (IP).
• Keunggulan utama BPF sejak awal adalah kemampuannya menjalankan program buatan user di dalam kernel, namun tetap aman dan efisien. BPF pertama kali masuk ke Linux pada tahun 1997 (kernel 2.1.75) dan digunakan oleh tcpdump untuk menyaring paket jaringan secara efisien.
• Perkembangan besar terjadi pada 2012 dengan hadirnya seccomp-bpf (kernel 3.5), yang memungkinkan BPF digunakan untuk mengontrol system call aplikasi user space. Sejak titik ini, BPF berevolusi dari sekadar packet filtering menjadi platform general-purpose di dalam kernel, sehingga istilah “packet filter” dalam namanya mulai kehilangan relevansi.

Dari BPF ke eBPF (Kernel 3.18, 2014)

• Instruction set dirombak total

  Dioptimalkan untuk arsitektur 64-bit dan performa lebih tinggi.

• Interpreter baru

  Mesin eksekusi BPF ditulis ulang agar lebih efisien dan fleksibel.

• Diperkenalkan eBPF Maps

  Struktur data yang bisa diakses program eBPF dan aplikasi user space untuk berbagi informasi.

• Muncul system call bpf()

  Memungkinkan user space:

  • Memuat program eBPF
  • Mengelola maps
  • Berinteraksi dengan program di kernel

• Penambahan helper functions

  Fungsi bawaan kernel yang bisa dipanggil program eBPF untuk tugas kompleks secara aman.

• Hadirnya eBPF Verifier

  Mekanisme keamanan yang memastikan program aman dijalankan (tidak crash, tidak akses memori sembarangan, tidak infinite loop).

Evolusi eBPF ke Sistem Produksi

• Fitur kprobes sudah ada sejak 2005 untuk memasang hook pada hampir semua instruksi kernel
• Tahun 2015: eBPF bisa di-attach ke kprobes → revolusi dalam kernel tracing & observability
• Kernel juga mulai menambahkan hook eBPF di networking stack
• 2016: Tool berbasis eBPF dipakai di production (dipopulerkan oleh Brendan Gregg di Netflix)
• 2016: Proyek Cilium diumumkan → networking container berbasis eBPF
• 2017: Meta membuka Katran, load balancer L4 berbasis eBPF/XDP
• 2018: eBPF jadi subsystem resmi kernel Linux
• Maintainer utama: Daniel Borkmann & Alexei Starovoitov
• Diperkenalkan BTF (BPF Type Format) → program eBPF lebih portable antar kernel
• 2020: Hadir LSM BPF → eBPF bisa dipasang ke Linux Security Module
• eBPF resmi punya tiga pilar utama use case:
  1. Networking
  2. Observability/Tracing
  3. Security

Naming Is Hard

• Istilah eBPF sekarang tidak lagi mencerminkan arti aslinya (“extended Berkeley Packet Filter”) karena penggunaannya sudah jauh melampaui packet filtering.
• Di praktik modern, eBPF dan BPF sering dipakai secara bergantian, karena hampir semua kernel Linux saat ini sudah mendukung versi “extended”-nya.
• Di dalam kernel Linux, istilah yang lebih umum dipakai adalah BPF, misalnya:
  • System call: bpf()
  • Helper functions diawali bpf_
  • Tipe program memakai awalan BPF_PROG_TYPE
• Di luar komunitas kernel, nama eBPF lebih populer dan melekat, misalnya dipakai oleh:
  • Situs komunitas eBPF.io
  • Organisasi eBPF Foundation

Linux Kernel

• Kernel = penghubung antara aplikasi dan hardware

  Semua akses ke disk, jaringan, memori, dan perangkat keras dikontrol oleh kernel.

• Aplikasi berjalan di user space (tidak punya akses langsung ke hardware)

  Untuk melakukan operasi penting, aplikasi harus meminta bantuan kernel.

• Komunikasi lewat system call (syscall)

  Syscall adalah pintu resmi bagi aplikasi untuk meminta kernel melakukan sesuatu (baca file, kirim data jaringan, alokasi memori, dll).

• Bahasa pemrograman menyembunyikan syscall

  Developer jarang memanggil syscall langsung karena sudah dibungkus oleh library tingkat tinggi.

• Kernel menangani banyak hal sekaligus

  Termasuk manajemen proses, memori, I/O, dan multitasking.

• Tool seperti strace bisa menunjukkan syscall aplikasi

  Ini membantu melihat seberapa sering aplikasi berinteraksi dengan kernel.

• Mengamati interaksi aplikasi ↔ kernel memberi insight besar

  Karena hampir semua aktivitas penting aplikasi melewati kernel.

• Di sinilah eBPF berperan

  eBPF memungkinkan kita menambahkan instrumentation di dalam kernel untuk:

  • Melihat syscall yang dipanggil aplikasi
  • Melacak akses file, jaringan, dan resource lain
  • Memahami perilaku sistem tanpa mengubah kode aplikasi atau kernel secara permanen

Adding New Functionality to the Kernel

• Kernel Linux sangat besar dan kompleks

  ±30 juta baris kode → sulit dimodifikasi tanpa pengalaman kernel.

• Kontribusi ke kernel tidak hanya soal teknis

  Perubahan harus diterima komunitas kernel dan Linus Torvalds; hanya ~⅓ patch yang lolos.

• Proses upstream lama dan berat

  Bisa memakan waktu berbulan-bulan hingga perubahan diterima.

• Rilis kernel ≠ langsung dipakai di produksi

  Walau kernel rilis tiap 2–3 bulan, distro Linux sering memakai versi kernel lama.

• Distribusi Linux memperlambat adopsi fitur baru

  Contoh: RHEL 8.5 (2021) masih memakai kernel 4.18 (rilis 2018).

• Fitur baru butuh waktu bertahun-tahun sampai ke produksi

  Berbeda dengan patch keamanan yang biasanya lebih cepat.

Kernel Modules

• Alternatif selain ubah kernel utama: pakai kernel module

  Modul bisa dimuat/dilepas tanpa perlu masuk ke rilis resmi kernel Linux.

• Tidak perlu proses upstream

  Modul bisa didistribusikan terpisah dari source kernel utama.

• Tapi tetap pemrograman level kernel

  Kompleks dan berisiko tinggi.

• Jika modul crash → seluruh sistem bisa ikut crash

  Karena berjalan di kernel space dengan hak akses penuh.

• Risiko keamanan besar

  Modul punya akses ke seluruh sistem → bug atau malicious code bisa sangat berbahaya.

• Inilah alasan distro Linux konservatif soal kernel

  Mereka menunggu kernel “teruji di lapangan” sebelum dipakai luas.

• eBPF menawarkan pendekatan berbeda

  Program eBPF diverifikasi oleh verifier sebelum dijalankan:

  • Tidak boleh crash kernel
  • Tidak boleh infinite loop
  • Tidak boleh akses memori sembarangan

Dynamic Loading of eBPF Programs

• Program eBPF bisa dimuat & dilepas secara dinamis

  Tidak perlu reboot atau upgrade kernel.

• Program berjalan saat event terjadi

  Misalnya di-attach ke syscall buka file → aktif setiap ada proses membuka file, termasuk proses yang sudah berjalan sebelumnya.

• Langsung memberi visibilitas sistem secara menyeluruh

  Cocok untuk observability dan security karena bisa melihat semua aktivitas di mesin secara real time.

• Berlaku juga untuk lingkungan container

  eBPF bisa memantau proses di dalam container dan di host.

• Tidak perlu memaksa perubahan ke semua pengguna Linux

  Fitur baru bisa dibuat dan dipakai lewat eBPF tanpa mengubah kernel utama.

High Performance of eBPF Programs

• Dijalankan sebagai native machine code

  Setelah di-load, program eBPF di-JIT compile → performanya mendekati kode kernel biasa.

• Tidak perlu bolak-balik kernel ↔ user space

  Menghindari overhead syscall dan context switch untuk setiap event.

• Peningkatan performa signifikan di networking (XDP)

  eBPF di jalur cepat jaringan bisa jauh lebih cepat dibanding pemrosesan jaringan tradisional di kernel.

• Filtering dilakukan langsung di kernel

  Hanya event yang relevan yang dikirim ke user space → hemat CPU & bandwidth.

• Mendukung filter kompleks berbasis logika program

  Tidak hanya rule statis, tapi bisa keputusan dinamis berdasarkan kondisi sistem.

eBPF in Cloud-Native Environments

Konteks Cloud Native

• Workload modern berjalan di container, Kubernetes, atau serverless
• Walaupun abstrak, semuanya tetap berjalan di mesin dengan kernel Linux
• Semua container di satu node Kubernetes berbagi kernel yang sama

Visibilitas Penuh dengan eBPF

• eBPF yang berjalan di kernel bisa melihat semua proses di node, termasuk semua container dalam semua pod
• Tidak perlu ubah kode aplikasi atau konfigurasi pod
• Bisa langsung mengamati proses yang sudah berjalan saat program eBPF dimuat

Model lama: fitur observability / security / service mesh ditambahkan lewat sidecar container

Kekurangan sidecar:

• Pod harus restart untuk menambahkan sidecar
• Perlu modifikasi YAML (bisa gagal → pod tidak terinstrumentasi)
• Menambah kompleksitas startup & potensi race condition
• Menambah latensi jaringan karena trafik harus lewat proxy container

eBPF tidak punya masalah ini karena:

• Berjalan di level kernel, bukan per-pod
• Tidak menambah container tambahan
• Tidak mengubah jalur jaringan aplikasi

Keunggulan Keamanan

• Tool berbasis sidecar hanya melihat pod yang punya sidecar
• Aplikasi jahat (misalnya crypto miner) bisa jalan tanpa sidecar → lolos pengawasan
• eBPF bisa memantau semua trafik & proses di host, termasuk yang tidak “terdaftar” secara resmi

Summary

• eBPF memungkinkan perubahan perilaku kernel tanpa memodifikasi source kernel
• Bisa dipakai untuk membangun tool kustom dan kebijakan sistem khusus
• Visibilitas menyeluruh: eBPF dapat mengamati event apa pun di kernel → berarti semua aplikasi di mesin (VM maupun bare metal, container atau tidak)
• Bisa dimuat secara dinamis: Perilaku sistem dapat diubah on the fly tanpa reboot atau redeploy aplikasi
• Fondasi untuk berbagai use case: Observability, networking, dan security semuanya bisa dibangun di atas platform eBPF