eBPF: La tecnología que rediseñó el kernel de Linux

De dónde viene eBPF: PLUMgrid y Alexei Starovoitov#

En 2013, una startup de redes de Silicon Valley llamada PLUMgrid tiene un problema. Están construyendo infraestructura SDN (redes definidas por software): quieren que Linux sea la red y que el kernel mueva los paquetes con lógica programable. Pero cada vez que necesitan cambiar esa lógica, se arriesgan a romper el sistema entero.

Alexei Starovoitov, uno de sus ingenieros senior, decide que la solución no está fuera del kernel, sino dentro. Toma BPF, el Berkeley Packet Filter, un filtro de paquetes de 1992 que Linux incorporó en 1997, y lo rehace por completo. Reescribe el JIT y añade los maps. Poco después llegarían las tail calls. Lo convierte en una máquina virtual de propósito general dentro del kernel, y la llaman eBPF.

$ git log --oneline --grep="bpf: introduce BPF syscall and maps"
99c55f7d47c0 bpf: introduce BPF syscall and maps

El 28 de junio de 2014, Alexei envía 14 patches a la mailing list del kernel, firmados desde ast@plumgrid.com. Daniel Borkmann, que entonces estaba en Red Hat y hoy está en Isovalent, se implica a fondo en esos patches y los lleva hasta el kernel junto a Alexei.

El 10 de julio de 2014, Alexei se reúne con Brendan Gregg en Netflix, uno de los ingenieros de rendimiento más influyentes de su generación. La conversación es tan intensa que los echan de la sala de reuniones. Gregg sale de ahí convencido y se compromete a llevar eBPF a la observabilidad, y acaba siendo uno de los grandes impulsores de bcc y bpftrace.

En algún momento de esa reunión, Alexei confesó que no estaba muy seguro de que los patches se fueran a mergear. Gregg le contestó que tenían que mergearse, porque la idea era demasiado buena para desperdiciarla. Y se mergearon. Gregg cuenta esta anécdota en su blog personal.

El problema: cómo meter lógica nueva en el kernel sin romperlo#

Como vimos en la lección del kernel, tu servidor tiene dos zonas separadas. Arriba está el user space, con tus aplicaciones y tus contenedores. Abajo está el kernel space, desde donde se controla todo el hardware.

Cuando querías añadir lógica nueva al kernel, tenías dos opciones.

Podías modificar el código fuente del kernel y compilarlo, lo que suponía horas de compilación solo para probar un cambio. Y si querías que ese cambio llegara al kernel oficial, hablamos de meses de revisiones, iteraciones y de convencer a los maintainers del subsistema.

La otra opción era escribir un módulo del kernel. Es más rápido, pero si tu módulo tiene un bug, el kernel se cae entero, y todo se muere en producción:

KERNEL PANIC — not syncing: Fatal exception

Así que la pregunta era cómo meter lógica nueva en el kernel de forma segura y sin reiniciar nada. Eso es lo que Starovoitov se propuso resolver.

Qué es eBPF: una máquina virtual ligera dentro del kernel#

eBPF significa Extended Berkeley Packet Filter. La idea con la que te tienes que quedar es que eBPF es una máquina virtual ligera que vive dentro del kernel de Linux.

Te permite cargar pequeños programas directamente en el kernel, en tiempo real, sin reiniciar y sin comprometer la estabilidad del sistema. Pero hay una pieza que lo diferencia de meter cualquier código ahí dentro.

El verificador#

Antes de ejecutarse, cada programa pasa por el verificador. El kernel analiza el programa entero antes de ejecutar una sola instrucción:

• Si tiene bucles infinitos, lo rechaza.
• Si accede a memoria no autorizada, lo rechaza.
• Si existe la posibilidad de que provoque un crash, lo rechaza.

Solo si pasa todas las comprobaciones, el programa entra en el kernel.

El compilador JIT#

Una vez dentro, entra el compilador JIT (Just In Time), que convierte el bytecode verificado en código máquina nativo del procesador.

El programa no se interpreta. Se ejecuta igual que cualquier otro código del kernel, a velocidad nativa y con muy poco overhead.

Dónde se ejecuta un programa eBPF: el recorrido de un paquete#

Ya tienes un programa verificado, compilado con JIT y corriendo dentro del kernel. ¿Pero dónde se ejecuta exactamente? eBPF funciona con hooks, que son puntos de intercepción repartidos por el kernel donde se engancha el programa.

Para entenderlos, en lugar de hacer una lista, vamos a seguir el recorrido de un paquete de datos desde que llega a la tarjeta de red hasta tu aplicación.

XDP: en la tarjeta de red#

El paquete acaba de llegar a la interfaz de red. Antes de que el kernel asigne memoria y antes de que se active su stack de red, entra el primer hook: XDP (eXpress Data Path).

Es el punto más temprano donde puedes ejecutar lógica programable en Linux. Si este paquete formara parte de un ataque DDoS, XDP lo descartaría ahí mismo, antes de que el kernel gaste memoria en él.

TC: dentro del stack de red#

Nuestro paquete es legítimo, así que pasa y sube al stack de red de Linux. Ahí lo intercepta el hook TC (Traffic Control). A este nivel, eBPF ya tiene el contexto completo: IPs, puertos y cabeceras.

Aquí es donde trabaja Cilium: intercepta el tráfico y reescribe la ruta para enviarlo directamente al Pod de destino, y así reemplaza por completo a kube-proxy.

Kprobes y tracepoints: dentro de las funciones del kernel#

Mientras el paquete avanza, el kernel ejecuta cientos de funciones internas para procesarlo. Si quieres ver qué pasa ahí dentro sin detener nada, usas kprobes y tracepoints.

Con ellos te enganchas a cualquier función del kernel y ves qué está ejecutando, en tiempo real y sin tocar una línea de su código.

Uprobes: en tu aplicación#

Al final, el paquete cruza la frontera y llega al user space, a tu aplicación. ¿Quieres saber cuánto tarda tu proceso en responder, o qué función interna consume más tiempo? Para eso están los uprobes.

Te enganchas al proceso desde fuera, sin recompilarlo, sin modificarlo y sin que el proceso lo note.

Los eBPF maps: cómo salen los datos del kernel#

Falta la pieza que conecta todo. Los hooks no trabajan solos: escriben sus datos en los eBPF maps, que son estructuras de memoria que viven en el kernel y que tus herramientas pueden leer desde fuera, en tiempo real, sin interrumpir el flujo de datos.

Qué cambia eBPF en la práctica: tres casos#

Con la arquitectura completa, veamos qué cambia esto en networking, en observabilidad y en seguridad.

Networking#

Como vimos en la lección de Cilium, cuando un paquete llega al nodo, kube-proxy tradicional lo hace recorrer cientos de reglas de iptables, una por una, hasta encontrar el Pod de destino.

Con eBPF, un programa enganchado en TC intercepta el paquete, consulta un mapa con la identidad del Pod y lo envía directamente, sin recorrer las reglas una por una.

Observabilidad#

Antes, para ver qué pasaba dentro del kernel, tenías que insertar printk en el código fuente, recompilar y esperar.

Ahora puedes ver en tiempo real qué archivos abre cada proceso del sistema, directamente desde la terminal y sin recompilar ni reiniciar nada.

Herramientas como Hubble, Pixie o Parca hacen esto a escala de clúster: trazas completas, métricas y perfiles de CPU, sin instrumentar tus aplicaciones.

Seguridad#

En seguridad, el problema clásico siempre ha sido el mismo: te enteras de lo que pasó después de que pasara. Revisas los logs, los mandas al SIEM, y cuando llegas a la alerta ya han pasado cinco minutos.

Tetragon, del ecosistema de Cilium, usa eBPF para vigilar el comportamiento de cada proceso del clúster directamente desde el kernel. Si un contenedor intenta ejecutar bash, si alguien accede a /etc/shadow o si un proceso abre una conexión de red que no debería, Tetragon lo detecta en el momento exacto en que ocurre y puede bloquearlo en caliente.

Por qué se habla tanto de eBPF ahora#

Si eBPF existe desde 2014, ¿por qué es ahora cuando todo el mundo habla de él? Porque en el kernel las cosas avanzan por fases. Primero entra la base técnica. Después madura durante años con commits, revisiones y bugs reales. Y cuando empiezan los resultados en producción, despega la adopción.

2014 — Se mergea eBPF en Linux 3.18
2016 — Nace Cilium, primer CNI basado en eBPF
2018 — Facebook lo usa en producción a escala global
2021 — eBPF Foundation: Google, Meta, Microsoft, Netflix, Isovalent
2023 — Cilium se gradúa en la CNCF como proyecto estable

Hoy, eBPF viene en el kernel por defecto de cualquier distribución Linux moderna, sin instalar ni habilitar nada.

Lo que hemos visto#

• eBPF nació en PLUMgrid: Alexei Starovoitov convirtió BPF en una máquina virtual de propósito general dentro del kernel y envió los patches en 2014.
• Antes de eBPF, extender el kernel exigía recompilarlo o cargar un módulo que, con un bug, provocaba un kernel panic.
• El verificador rechaza cualquier programa que pueda colgar o romper el kernel, y el compilador JIT lo convierte en código máquina nativo.
• Los programas se enganchan en hooks (XDP, TC, kprobes, tracepoints y uprobes) y dejan sus datos en los eBPF maps para que los lean tus herramientas.
• Se usa en networking con Cilium, en observabilidad con Hubble, Pixie o Parca, y en seguridad con Tetragon.