eBPF (extended Berkeley Packet Filter) es una de las tecnologías más transformadoras de los últimos años en Linux, y sin embargo sigue siendo desconocida fuera de círculos especializados. Es la base sobre la que se construyen muchas herramientas modernas de observabilidad, networking y seguridad — Cilium, Pixie, Falco, Tetragon y otras. Cubrimos qué es, por qué importa y dónde lo encontrarás (probablemente sin saberlo) en tu stack.
La idea central
Tradicionalmente, modificar el comportamiento del kernel de Linux requería:
- Compilar un módulo y cargarlo (riesgo: un bug = kernel panic).
- Patchear el kernel y recompilar (impráctico en producción).
- Usar utilidades userspace que solo veían lo que el kernel exponía (limitado).
eBPF cambia esto. Permite cargar pequeños programas en el kernel que ejecutan en respuesta a eventos (syscalls, paquetes de red, accesos a archivos, cambios de proceso). Estos programas:
- Se cargan dinámicamente — no requieren recompilar ni reiniciar.
- Son verificados estáticamente antes de ejecutarse — el verificador del kernel rechaza programas que pueden colgarlo, accesar memoria no permitida o iterar sin fin.
- Se ejecutan en una máquina virtual dentro del kernel, con tipos restringidos y stack limitado.
- Son JIT-compilados a código nativo para performance.
El resultado: puedes instrumentar el kernel en tiempo real, con seguridad similar a userspace, y rendimiento cercano al código nativo.
Por qué importa
Antes de eBPF, observar qué pasaba dentro del kernel requería herramientas pesadas (SystemTap, DTrace en sus versiones limitadas en Linux) o instrumentación que ralentizaba significativamente el sistema. eBPF cambió esa ecuación: observabilidad fina con overhead pequeño.
Los casos de uso que se abren:
- Tracing de syscalls y procesos sin agente extra ni reinicios.
- Filtrado de paquetes sin pasar por iptables/nftables (mayor performance).
- Visibilidad de tráfico cifrado observando antes/después de la encriptación en el kernel.
- Auditoría de seguridad en runtime con detalles que auditd no captura.
- Profiling de aplicaciones con resolución de stack a nivel de función sin instrumentar el binario.
Herramientas que están construidas sobre eBPF
En 2023 hay un ecosistema notable de productos que dependen completamente de eBPF:
- Cilium: networking de Kubernetes con eBPF en lugar de iptables. Mejor performance y observabilidad (Hubble) en el mismo paquete.
- Pixie: observabilidad de Kubernetes que captura HTTP, mySQL, DNS, etc. sin instrumentar las apps.
- Falco: detección de amenazas en runtime. Originalmente con módulo kernel; migrado a eBPF para mayor compatibilidad.
- Tetragon: enforcement de seguridad runtime con políticas declarativas.
- bcc/bpftrace: librerías y herramientas para escribir programas eBPF más fácilmente.
- Parca: profiling continuo low-overhead de procesos en producción.
Si usas Cilium o Pixie, ya estás usando eBPF aunque no lo sepas.
Un ejemplo de bpftrace
Para ver eBPF “vivo”, bpftrace es la entrada más simple. Cuenta syscalls por proceso en una línea:
sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'Esto carga un programa eBPF que se dispara en cada syscall, indexa por nombre de proceso (comm) e incrementa un contador. Imprime resultados al hacer Ctrl-C. Sin tocar el código de las apps, sin reiniciar nada.
Otros one-liners útiles:
- Latencia de
read()por proceso:bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; } kretprobe:vfs_read /@start[tid]/ { @ns[comm] = hist(nsecs - @start[tid]); delete(@start[tid]); }' - TCP retransmisiones:
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[comm] = count(); }'
Restricciones que conviene conocer
eBPF no es magia y tiene límites:
- Verificador estricto. El verificador rechaza programas que considera no-seguros incluso si funcionarían. A veces hay que reescribir lógica para pasar la verificación.
- Sin recursión libre. Los loops están permitidos en kernels modernos pero con bounded iterations.
- Stack limitado (512 bytes). No puedes hacer estructuras grandes.
- Compatibilidad de kernel. Features avanzadas requieren kernels relativamente nuevos. RHEL 7 tiene soporte muy limitado; RHEL 9, Debian 12, Ubuntu 22.04 son razonables.
- Curva de aprendizaje. Escribir eBPF directamente es complejo. La mayoría usamos bpftrace o frameworks como bcc.
Cómo empezar a aprender
Si quieres profundizar más allá de “eBPF es bueno”:
- Brendan Gregg tiene los mejores recursos públicos sobre tracing y eBPF — su libro BPF Performance Tools (2019) sigue vigente.
- ebpf.io — sitio centralizado con tutorials, ecosistema y references.
- Lab práctico: instala bpftrace en tu Linux, prueba los one-liners de la documentación, luego escribe los tuyos.
- Para programación seria: aprende Rust o C + framework libbpf-rs / Aya.
Conclusión
eBPF ha redefinido qué es posible observar y modificar en un sistema Linux moderno. Está debajo de muchas de las herramientas modernas de Kubernetes y observabilidad — entender al menos los conceptos te ayuda a decidir entre alternativas y a debuggear problemas cuando esas herramientas se comportan de forma inesperada. No tienes que escribir eBPF directamente para beneficiarte, pero saber que está ahí amplía tu repertorio.
Síguenos en jacar.es para más sobre observabilidad, kernel Linux y herramientas modernas de Cloud Native.
