Getting Started

Platform overview

This platform provides a configured environment and exercises to help you learn eBPF.

The editor compiles your code locally as you type, but you can disable this by clicking the button. Compilation errors are highlighted inline.

Try typing into the editor and see how it reacts, then click ‘Run’ to execute your code on the server.

If you prefer ‘vim mode’, the button will toggle it.

Hotkeys

  • Ctrl+Enter runs the code.
  • Ctrl+Click on type definitions (my_struct, trace_event_raw_sched_process_exec) shows a type definition popup

Debugging utilities

There are multiple DEBUG_ macros to display data from your programs. Each macro takes a label (a string constant) as its first argument.

  • DEBUG_NUM(label, num) can take any number, like u32 or ssize_t
  • DEBUG_STR(label, buf) requires a fixed-size buf, like char[64]
  • DEBUG_STR_LEN(label, ptr, len) can take any pointer, will debug len bytes
  • DEBUG_STRUCT(label, struct) can take any struct by value

Developer tools

When you run a program, the panel on the right becomes a set of tabs that let you inspect what actually happened inside the kernel:

  • Events — the live stream of everything your program emitted, in order.
  • Bytecode — the compiled BPF instructions, each linked back to the C line it came from. Hover an instruction to highlight every instruction from the same source line.
  • Complexity — a live count of instructions, maps, and loops, shown against the verifier’s limits so you can see how heavy your program is.
  • Timeline — the kernel verifier’s report, walked step by step, so a rejection is easier to read than one wall of log.
  • Maps — the contents of any hash/array/lru_hash map your program wrote, decoded to hex plus an integer/string view.
  • Rate — a histogram of how often your program fired over time.
  • Flame — a flame graph of captured kernel stacks (only for programs that record them with bpf_get_stackid()).
  • Steps — a transport to step forward and back through the emitted events one at a time and replay what your program did.

The editor itself also helps as you write:

  • Autocomplete inside SEC("...") suggests the tracepoints and kprobes that actually exist on this kernel, so you don’t guess an attach point.
  • Helper autocomplete offers the eBPF helpers you can call. Note that a helper only works in some program types: this platform runs tracepoint, kprobe and XDP programs, so it documents the helpers valid there. The kernel has ~200 helpers in total, but families like LSM, sysctl, socket or cgroup belong to other program types and the verifier rejects them here — they aren’t broken, just out of scope for these exercises.
  • Inline verifier errors appear as a red marker on the offending line when a run is rejected, not just in the panel.
  • Compiler hints suggest a fix (a missing flag, a bounds check, a header) when a compile or verifier error matches a known cause.

And two more conveniences:

  • Share copies a link that encodes your current code, so you can hand someone the exact program you’re looking at.
  • Hints reveal help one step at a time when an exercise provides them, so you can get unstuck without seeing the whole answer at once.

Submitting answers

To solve the exercises, you will need to submit answers directly from your code, using SUBMIT_NUM(answer), SUBMIT_STR(answer) or SUBMIT_STR_LEN(answer, len).

Your eBPF program triggers on multiple events, so you’ll need to guard your SUBMIT_X calls, as multiple submissions invalidate all answers.

When using SUBMIT_STR, trailing null bytes are trimmed, but trailing garbage is not. Use the SUBMIT_STR_LEN variant when you can’t guarantee null termination.

Solve this exercise by uncommenting SUBMIT_STR("the answer");

Run your code to see execution events here