Skip to content

eBPF Key Benefits: CCA practice questions

eBPF lets the Linux kernel run small, checked programs at defined hook points. Its benefits come from the way a program is built, loaded and checked, so it helps to follow the path from source code to a running hook.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What eBPF Key Benefits covers in CCA

eBPF lets the Linux kernel run small, checked programs at defined hook points. Its benefits come from the way a program is built, loaded and checked, so it helps to follow the path from source code to a running hook.

Programs are usually written in a restricted subset of C and compiled to BPF bytecode by a compiler back end such as LLVM. The instruction set is a general purpose RISC design with eleven 64-bit registers, r0 to r10, a program counter and a 512 byte stack, and every instruction has a fixed 64-bit encoding. That design maps closely onto real CPUs, which matters for the next step.

Before a program is attached it passes the in-kernel verifier. The verifier makes sure that the program cannot crash the kernel and always terminates, so loops are restricted, and programs are bounded in size: 4096 instructions on older kernels and 1 million instructions on kernels newer than 5.1. A JIT compiler then translates the bytecode into native opcodes, so the program runs at close to the speed of code compiled into the kernel. Hardening adds protection on top: the program image is kept read-only for the lifetime of the program, and JIT hardening can blind constants so that injected opcodes hidden in immediate values cannot be used for JIT spraying.

Programs cannot reach into arbitrary kernel code. They call helper functions, which let them consult core kernel functionality, and the set of available helpers differs per program type. State is kept in maps that both programs and user space can read and write; generic types include hash tables, arrays, per-CPU variants, LRU hashes and LPM tries for longest-prefix lookups. Tail calls let one program jump into another, with a nesting limit of 33 calls, which is how a large datapath is split into pieces.

For a networking platform these properties add up to concrete gains. The kernel becomes programmable without crossing into user space, so policy and load balancing happen without copying packets out and back. Programs can be built with only the features a node needs, for example without IPv4 support where it is not used. BPF has a stable ABI towards user space, needs no third-party kernel modules, and existing programs keep running on newer kernels. tc and XDP programs can be replaced atomically, without restarting the kernel, services or containers and without traffic interruption, while state survives in maps. XDP comes in native, offloaded and generic modes; generic mode works without driver support but runs later in the stack and is meant mainly for testing.

Key points

  • The verifier rejects programs that could crash the kernel or fail to terminate.
  • JIT compilation gives eBPF programs near-native speed.
  • Programs reach kernel functionality only through helper functions that differ per program type.
  • tc and XDP programs can be swapped atomically while state stays in maps.
  • Tail calls chain programs, up to 33 nested calls.

Three sample questions

11 CCA questions on eBPF Key Benefits, 11 with explanations. How practice works

Question 1

Which feature is NOT enabled by Cilium's use of eBPF?
  1. A.Socket-based load balancing
  2. B.Application protocol visibility
  3. C.Container image vulnerability scanning
  4. D.Transparent encryption

Correct answer: C

Cilium's use of eBPF does not enable container image vulnerability scanning. While eBPF enables network visibility, policy enforcement, and encryption, image scanning is a separate security function not directly related to eBPF networking.

Question 2

What feature does Cilium's eBPF implementation allow that traditional CNI solutions cannot provide?
  1. A.Basic IP address management
  2. B.Pod-to-pod connectivity
  3. C.Protocol-aware security policies
  4. D.NodePort service implementation

Correct answer: C

Cilium's eBPF implementation allows protocol-aware security policies, which traditional CNI solutions cannot provide. This enables filtering based on application-layer information like HTTP methods, paths, or other protocol-specific attributes.

Question 3

What does the eBPF verifier check before a program is attached to a hook?
  1. A.That the policy decisions made by the program are correct for the cluster
  2. B.That it is safe: it terminates and stays within memory bounds
  3. C.That the program was compiled with LLVM
  4. D.That the program is signed by a trusted vendor

Correct answer: B

ebpf.io and the BPF reference guide describe the verifier as ensuring programs always run to completion (only bounded loops), do not use uninitialised variables or access memory out of bounds, and stay within size and complexity limits. Why the other options are wrong. "That the policy decisions made by the program are correct ...": the verifier is a safety tool, not a security tool inspecting what the program does. "That the program is signed by a trusted vendor": verification is static analysis of the program, not signature checking. "That the program was compiled with LLVM": the kernel accepts bytecode from any toolchain; the verifier checks the bytecode itself.

Sources: CNCF CCA curriculum (CCA_Curriculum.pdf), ebpf.io: What is eBPF?, Cilium docs: BPF Architecture (BPF and XDP Reference Guide)

Practice this topic

Focus mode keeps every question on eBPF Key Benefits until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CCA practice across all topics.

Sources

The explanation above was checked against these official documents.