You have SSH'd into a Linux host you did not set up and want to know which eBPF programs are loaded and what they are attached to. Which bpftool subcommands answer that, and what do their outputs tell you?

## bpftool is the ground truth bpftool ships with the kernel source (under `tools/bpf/bpftool`) and is packaged by every distribution. It is the only general-purpose way to see BPF state on a box, because loaded programs belong to no process by name and leave no trace in `ps`. Everything below needs root or `CAP_BPF`/`CAP_SYS_ADMIN` depending on kernel version. ## What is loaded ```bash bpftool prog show ``` A typical entry looks like: ``` 6: tracepoint name handle_exec tag 6deef7357e7b4530 gpl loaded_at 2026-08-19T10:12:04+0000 uid 0 xlated 528B jited 397B memlock 4096B map_ids 4,5 btf_id 12 ``` Read it as: the **id** is bpftool's handle for later commands; the **type** (`tracepoint`, `kprobe`, `xdp`, `cgroup_skb`, …) tells you what class of hook it is written for; **name** comes from the C function; **loaded_at** and **uid** are your first forensic clues about who put it there and when; **xlated**/**jited** are instruction-stream sizes; **memlock** is the kernel memory charged for it; **map_ids** links it to its maps; **btf_id** shows it carries type information, which is what makes a readable dump possible. ```bash bpftool map show ``` gives `id: type name`, `key`/`value` sizes, `max_entries` and `memlock`. `memlock` across all maps is the number to watch when you suspect BPF is holding meaningful kernel memory; a large hash map with a big `max_entries` allocates up front. ## Where it is attached — the part `prog show` omits This is the detail that separates someone who has used bpftool from someone who has read about it. A program's *existence* and its *attachment* are separate facts, so you need more commands: - `bpftool link show` — modern attachments are `bpf_link` objects and this lists them with the link type, the program id and, for many types, the attach target. If a program has a link, this is the fastest answer. - `bpftool net show` — programs attached to network interfaces, per device. - `bpftool cgroup tree` — walks the cgroup hierarchy and prints programs attached to each cgroup, which is where systemd-managed and container-runtime filters live. - `bpftool perf show` — perf-event attachments (older kprobe/uprobe/tracepoint style) held open by processes, printed with the owning pid. If a program appears in `prog show` but in none of these, it is loaded and idle — most likely held alive by a pin under `/sys/fs/bpf`. `ls -R /sys/fs/bpf` plus `bpftool prog show pinned <path>` closes that loop. ## Looking inside ```bash bpftool prog dump xlated id 6 bpftool map dump id 4 ``` `dump xlated` prints the instruction stream *after* the verifier has processed it, with source line and function annotations when BTF is present — enough to tell whether a program is counting events or rewriting packets. `dump jited` shows the native code instead. `bpftool map dump` prints live key/value pairs, which is often the actual data the tool was collecting. ## Practical habits - Add `-p` (pretty JSON) or `-j` when feeding output to `jq`; the plain format is not stable enough to parse. - `bpftool feature probe` reports what the running kernel supports — useful when a colleague's tool refuses to load and you want to know whether the kernel or the tool is at fault. - `bpftool prog tracelog` streams what programs write with `bpf_trace_printk`, saving you from opening the trace pipe yourself. - Programs with `uid 0`, a recent `loaded_at` and no visible attachment on a host you did not configure deserve attention: eBPF is a legitimate tool for security agents and CNI plugins, and equally a place attackers hide. Identify the owner before you remove anything, because detaching a security agent's program is its own incident.