We’ll do your first eBPF program three ways — a one-liner, a Python script, and a C++ loader — in about fifteen minutes. No kernel modules. No reboots.

Python First, C++ Second

I’ll write this three times, starting with Python and ending in C++. Python first because BCC handles the compile, load, and verify steps for you — so the first time you see eBPF run, nothing’s hidden behind a build system. Once it clicks, we’ll redo it in C++ to see what BCC was doing on your behalf.

Let’s Write It

#!/usr/bin/env python3
from bcc import BPF

program = r"""
int hello(void *ctx) {
    char comm[16];
    bpf_get_current_comm(&comm, sizeof(comm));
    bpf_trace_printk("hello from %s\n", comm);
    return 0;
}
"""

b = BPF(text=program)
syscall = b.get_syscall_fnname("execve")
b.attach_kprobe(event=syscall, fn_name="hello")

print("tracing every execve on the system. ctrl-c to exit.")
b.trace_print()

Under the Hood

   ┌─────────────────────────────────────────────────────┐
   │                       Hello.py                      │
   └─────────────────────────────────────────────────────┘

   BPF(text=program)
        │
        ├─►  clang compiles C string → BPF bytecode
        │
        ├─►  bpf() syscall: load into kernel
        │
        ├─►  verifier checks safety  ──► ✗ reject (raises exception)
        │                            └─► ✓ accept
        │
        └─►  JIT compiles to native machine code

   get_syscall_fnname("execve")
        │
        └─►  returns "__x64_sys_execve"  (or arm64 equivalent)

   attach_kprobe(event=syscall, fn_name="hello")
        │
        └─►  patches kernel function entry
             every execve now runs hello() first

   trace_print()
        │
        └─►  reads /sys/kernel/debug/tracing/trace_pipe
             prints to your terminal, blocks until ctrl-c


   ┌─────────────────────────────────────────────────────┐
   │                     THE KERNEL                      │
   │                                                     │
   │   any process calls execve                          │
   │        │                                            │
   │        ▼                                            │
   │   hello() runs  ──► bpf_trace_printk(...)           │
   │        │                       │                    │
   │        ▼                       ▼                    │
   │   real execve continues   trace_pipe                │
   │                                │                    │
   └────────────────────────────────┼────────────────────┘
                                    │
                                    ▼
                            your terminal

That’s the easy version. One sensor, every program launch on the box.

BCC did four things for you behind that one BPF(...) call: compile, load, attach, tail. Great for learning. Not how eBPF ships to production.

Let’s do it again without the magic.

Now Without the Magic

Kernel Code

// Kernel side code
// hello.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

char LICENSE[] SEC("license") = "Dual BSD/GPL";

SEC("tracepoint/syscalls/sys_enter_execve")
int hello(void *ctx)
{
    char comm[16];
    bpf_get_current_comm(&comm, sizeof(comm));
    bpf_printk("hello from %s\n", comm);
    return 0;
}

Userspace code

// Userspace code
// hello.cpp
#include <iostream>
#include <unistd.h>
#include "hello.skel.h"

int main() {
    auto* skel = hello_bpf__open_and_load();
    if (!skel) { std::cerr << "load failed\n"; return 1; }

    if (hello_bpf__attach(skel)) {
        std::cerr << "attach failed\n";
        hello_bpf__destroy(skel);
        return 1;
    }

    std::cout << "tracing every execve on the system. ctrl-c to exit.\n";
    std::cout << "watch output in another terminal:\n";
    std::cout << "  sudo cat /sys/kernel/debug/tracing/trace_pipe\n";

    pause();   // sleep until ctrl-c

    hello_bpf__destroy(skel);
    return 0;
}

Under the hood

   ┌─────────────────────────────────────────────────────┐
   │              ONE-TIME SETUP (per machine)           │
   └─────────────────────────────────────────────────────┘

   bpftool btf dump file /sys/kernel/btf/vmlinux format c
        │
        └─►  vmlinux.h  (all kernel types, ~5 MB header)


   ┌─────────────────────────────────────────────────────┐
   │                  BUILD TIME (you)                   │
   └─────────────────────────────────────────────────────┘

   clang -target bpf -c hello.bpf.c
        │   #include "vmlinux.h"  ◄── pulled in here
        │
        └─►  C source  →  BPF bytecode (hello.bpf.o)

   bpftool gen skeleton hello.bpf.o
        │
        └─►  generates hello.skel.h  (typed loader functions)

   clang++ hello.cpp -lbpf
        │
        └─►  your binary (hello)


   ┌─────────────────────────────────────────────────────┐
   │                   YOUR C++ BINARY                   │
   └─────────────────────────────────────────────────────┘

   hello_bpf__open_and_load()
        │
        ├─►  reads embedded bytecode from hello.skel.h
        │
        ├─►  bpf() syscall: load into kernel
        │
        ├─►  verifier checks safety  ──► ✗ reject (returns NULL)
        │                            └─► ✓ accept
        │
        └─►  JIT compiles to native machine code

   hello_bpf__attach()
        │
        └─►  reads SEC("tracepoint/...") annotation
             attaches program to that hook

   pause()
        │
        └─►  sleeps until ctrl-c
             (kernel-side keeps firing the whole time)

   hello_bpf__destroy()
        │
        └─►  detaches, unloads, frees


   ┌─────────────────────────────────────────────────────┐
   │                     THE KERNEL                      │
   │                                                     │
   │   any process calls execve                          │
   │        │                                            │
   │        ▼                                            │
   │   hello() runs  ──► bpf_printk(...)                 │
   │        │                       │                    │
   │        ▼                       ▼                    │
   │   real execve continues   trace_pipe                │
   │                                │                    │
   └────────────────────────────────┼────────────────────┘
                                    │
                                    ▼
                       sudo cat /sys/kernel/debug/
                            tracing/trace_pipe

Same program. Same sensor. Same output.

What changed: clang ran at build time, not runtime. The binary stands alone. The four loader calls — open, load, attach, destroy — are yours to see, not buried inside BCC.

This is eBPF without the training wheels. Same physics, exposed plumbing.

Same Program, Two Paths

Up Next

Two questions this article didn’t answer, on purpose:

• What does the JIT actually compile your eBPF into? You can see the assembly. It’s worth seeing.
• How does one binary run across kernel versions when struct offsets change between releases? That’s CO-RE, and it’s the reason eBPF ships at scale.

Both deserve their own articles. Both are coming.

Follow if you want them when they land …

Userspace v/s Kernel space :

   ┌─────────────────────────┐
   │      USER SPACE         │
   │                         │
   │   apps   libraries      │
   └───────────┬─────────────┘
               │
            syscalls
               │
   ┌───────────▼─────────────┐
   │     KERNEL SPACE        │
   │                         │
   │   subsystems   drivers  │
   └───────────┬─────────────┘
               │
   ┌───────────▼─────────────┐
   │       HARDWARE          │
   └─────────────────────────┘

Single command from userspace:

strace -c echo "Hello, World!"
Hello, World!
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 35.31    0.000131          14         9           mmap
 11.32    0.000042          14         3           openat
 10.78    0.000040          13         3           mprotect
  7.28    0.000027           5         5           close
  6.74    0.000025          25         1           munmap
  6.47    0.000024           6         4           fstat
  3.50    0.000013          13         1           write
  3.23    0.000012           4         3           brk
  2.70    0.000010           5         2           pread64
  2.70    0.000010          10         1         1 access
  1.89    0.000007           7         1           read
  1.62    0.000006           6         1           prlimit64
  1.62    0.000006           6         1           getrandom
  1.35    0.000005           5         1           arch_prctl
  1.35    0.000005           5         1           rseq
  1.08    0.000004           4         1           set_tid_address
  1.08    0.000004           4         1           set_robust_list
  0.00    0.000000           0         1           execve
------ ----------- ----------- --------- --------- ----------------
100.00    0.000371           9        40         1 total

So a single echo triggers ~40 syscalls. If you want broad observability coverage, the syscall layer is the natural place to hook. The catch: doing that traditionally meant kernel modules, ptrace overhead, or auditd's firehose — none of them cheap. This is where eBPF comes in.

Why eBPF Instead of the Alternatives?

If you want code running in the kernel, you’ve historically had two options. Both are painful.

Option 1: Change the kernel itself.

write patch  →  convince maintainers  →  merged upstream
                →  wait for kernel release
                →  wait for distros to ship it
                →  wait for users to upgrade
                                                    ⏱  ~1 year

Right path for things that truly belong in the kernel. Absurd overhead for “count how many times a function runs.”

Option 2: Write a kernel module.

edit  →  compile  →  insmod  →  💥 panic  →  reboot  →  repeat
   ⚠ no safety net      ⚠ ABI breaks across kernels
   ⚠ ships per-kernel   ⚠ once loaded, it IS the kernel

Faster than upstreaming. Still painful — and one bug is a hung machine.

Option 3: eBPF.

write  →  load  →  verifier ✓  →  attached  →  detach
                          │
                          └─ ✗ rejected if unsafe (never runs)
   ✓ no kernel rebuild    ✓ no reboot
   ✓ can't crash kernel   ✓ works across kernel versions

Same outcome — code running in the kernel — without either of the costs above.

The three options, side by side

                  KERNEL PATCH      KERNEL MODULE         eBPF
                  ────────────      ─────────────         ────
   speed to ship    ~1 year         days                  minutes
   reboot needed    yes             usually               no
   can crash box    yes             yes                   no
   ships how        kernel release  per-kernel binary     one binary
   trust model      full kernel     full kernel           sandboxed

The trade-off: you can’t do anything in eBPF. The verifier’s rules are strict, and some things genuinely need a kernel module or a kernel patch. But for “observe, filter, or decide when X happens in the kernel” — which is most of what people actually want — eBPF is the right tool.

So What Is eBPF, Actually?

The name is unhelpful. “Extended Berkeley Packet Filter” sounds like router config from 1998. The original BPF really was just a packet filter — what tcpdump uses under the hood. Today's eBPF has outgrown that name. Here's a simpler take:

eBPF lets you run small, safe programs inside the Linux kernel without writing a kernel module.

Three things make that work:

1. The kernel checks your code before running it. You write a small program, compile it, and hand it to the kernel. A component called the verifier inspects it first — looking for things like infinite loops, bad memory access, anything that could crash the system. If it can’t prove your program is safe, it refuses to load it. No surprises at runtime.

2. You attach it to an event. Your program does nothing until you hook it to something the kernel does: a system call, a network packet arriving, a function being called, a file being opened. When that event happens, your program runs. When it doesn’t, it costs nothing.

3. It talks to your app through a shared mailbox. The kernel-side program writes events into a shared data structure called a map. Your normal app, running in userspace, reads from that map. That’s the whole communication model.

   USER SPACE                  KERNEL SPACE
   ──────────                  ────────────
   ┌──────────┐               ┌──────────────┐
   │  your    │               │  eBPF prog   │
   │  app     │               │  on a hook   │
   └────┬─────┘               └──────┬───────┘
        │       ┌──────────┐         │
        └──────►│   MAP    │◄────────┘
         ◄──────│ (shared) │
                └──────────┘

Put together, the loop looks like this:

write a small program  →  kernel verifies it  →  attach to an event
                                              →  read results from a map

No compile-against-kernel-headers. No reboot. No risk of taking the machine down. Compared to the kernel module loop from the last section, it’s a different sport.

What Can You Actually Build With This?

Three domains, one runtime.

1. See what your system is doing (observability)

Want to know which programs are opening files right now? One line:

$ sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat
                       { @[comm] = count(); }'
   @[bash]:        14
   @[chrome]:    1847
. . .

No agent to install. No log pipeline. Just ask the kernel.

2. Stop bad things from happening (security)

When a program tries to run something, eBPF can step in and decide:

program tries to run /tmp/sketchy
                │
                ▼
          eBPF checks
                │
        ┌───────┴───────┐
        ▼               ▼
      ALLOW           BLOCK

This is how modern security tools work. Same idea: hook the event, decide inline.

3. Make networking faster (networking)

eBPF runs your code right where packets arrive, before the kernel even processes them:

packet arrives
        │
        ▼
   ┌──────────────┐
   │  eBPF here   │──► drop  (bad traffic)
   │              │──► route (load balancing)
   │              │──► pass  (normal)
   └──────────────┘

The big picture

   OLD WORLD              NEW WORLD
  ─────────              ─────────
   observe          perf, logs, /proc      ┐
   secure           auditd, EDR modules    ├──►  eBPF
   network          iptables               ┘

Your first eBPF program will fail the verifier. That’s the point .