eBPF: Cómo Linux Obtuvo un Kernel Seguro, Rápido y Programable

El Problema con el Método Antiguo

Durante décadas, si querías cambiar cómo el kernel de Linux manejaba paquetes, filtraba syscalls o rastreaba cuellos de botella de rendimiento, tenías dos opciones: enviar un parche al kernel y esperar años a que llegara a las distribuciones, o escribir un módulo de kernel. Los módulos de kernel son poderosos pero peligrosos. Un bug en un módulo derriba el host. Son específicos para cada versión del kernel, así que un módulo compilado para 5.15 falla en 6.1. Desplegarlo en una flota heterogénea implica mantener docenas de compilaciones. Para una empresa que opera cientos de miles de servidores, esto no es un problema de ingeniería — es un pasivo.

eBPF resuelve esto. Permite inyectar lógica personalizada en el kernel en ejecución — para networking, seguridad u observabilidad — de forma segura, portable y sin reiniciar nada.

Qué Es Realmente eBPF

BPF (Berkeley Packet Filter) fue creado en 1992 para hacer que tcpdump fuera rápido. En lugar de copiar cada paquete al espacio de usuario para filtrarlo, BPF ejecutaba una pequeña máquina virtual dentro del kernel para filtrar paquetes en el lugar. Era limitado por diseño.

En 2014, Alexei Starovoitov y Daniel Borkmann introdujeron extended BPF en Linux 3.18. El conjunto de instrucciones fue rediseñado para arquitecturas de 64 bits, se amplió el número de registros y — de forma crucial — el conjunto de puntos de enganche se expandió mucho más allá del filtrado de paquetes. Hoy puedes adjuntar programas eBPF a rutas de entrada y salida de red, tracepoints, kprobes (sondas dinámicas de funciones del kernel), uprobes (sondas de funciones en espacio de usuario) y puntos de entrada/salida de syscalls. El kernel se volvió programable.

El modelo de seguridad es lo que hace esto viable en producción. Escribes un programa eBPF en C restringido, o usando bibliotecas de Go o Rust que emiten bytecode eBPF. Antes de que el programa se ejecute, el verificador del kernel analiza estáticamente cada posible ruta de ejecución: sin bucles no acotados, sin accesos a memoria fuera de límites, sin aritmética de punteros insegura. Los programas que no superan la verificación son rechazados de plano. Los que la superan son compilados con JIT a código máquina nativo — así no hay sobrecarga de intérprete en tiempo de ejecución. El resultado es código ejecutándose dentro del kernel a velocidad casi nativa, con garantías de seguridad que el kernel aplica automáticamente.

XDP y la Revolución en Networking

La capacidad eBPF más impactante para los equipos de infraestructura es XDP — eXpress Data Path. Los hooks XDP se ejecutan antes de que la pila de networking del kernel procese un paquete. Antes de la asignación de sk_buff. Antes de la búsqueda de rutas. Antes de todo. Un programa XDP puede descartar, redirigir o modificar un paquete en la capa del controlador de NIC a más de 100 millones de paquetes por segundo en hardware convencional.

Para la defensa contra DDoS, esto lo cambia todo. Un ataque volumétrico que saturara la ruta de red normal del kernel — llenando colas de sockets, agotando CPU en el manejo de interrupciones — es descartado a nivel del controlador antes de que ocurra cualquiera de esa sobrecarga. Cloudflare utiliza programas eBPF basados en XDP para absorber ataques DDoS a escala de terabits. El paquete nunca llega a la pila. El host se mantiene activo.

Meta fue más lejos. Reemplazaron toda su infraestructura de balanceo de carga — construida previamente sobre IPVS — con Katran, un balanceador de carga open-source basado en eBPF/XDP. Katran se ejecuta en cada servidor de los centros de datos de Meta, manejando el tráfico a escala de Facebook sin appliances dedicados de balanceo de carga. La flexibilidad de eBPF significa que pueden actualizar la lógica de balanceo cargando un nuevo programa, sin reiniciar ni redesplegar hardware.

Networking en Kubernetes mediante Cilium

El problema de networking en Kubernetes es complejo. Cada pod necesita una IP. Los pods necesitan comunicarse entre nodos. Las políticas de red deben aplicarse. El balanceo de carga de servicios debe ocurrir. La respuesta tradicional era iptables — un motor de reglas que no escala. Con unos pocos miles de reglas, la búsqueda en iptables se vuelve O(n) y el consumo de CPU sube visiblemente. Con decenas de miles de pods, colapsa.

Cilium reemplaza iptables por completo con eBPF. El enrutamiento pod a pod, el balanceo de carga de servicios y la aplicación de políticas de red ocurren en programas eBPF adjuntos a las interfaces de red. Las búsquedas son O(1) mediante mapas hash de eBPF. La aplicación de políticas ocurre en la ruta rápida del kernel. Cilium también entiende HTTP, gRPC y Kafka en la Capa 7 — porque los programas eBPF pueden inspeccionar las cargas de los paquetes, no solo las cabeceras.

La adopción es reveladora. AWS EKS, Google GKE y Azure AKS ofrecen Cilium como CNI predeterminado o recomendado. Clústeres Kubernetes con cientos de nodos y miles de pods están usando eBPF para cada decisión de paquete, y el cuello de botella de iptables ha desaparecido.

Observabilidad Sin Instrumentación

Las herramientas APM tradicionales requieren cambios en el código: agregar una biblioteca, envolver funciones, redesplegar. La observabilidad con eBPF no requiere nada de eso. Adjuntas un kprobe o uprobe a cualquier función del kernel o del espacio de usuario y recopilas datos — latencia, argumentos, valores de retorno, trazas de pila — sin modificar la aplicación.

Netflix utiliza bpftrace en producción exactamente para esto. bpftrace es un lenguaje de scripting de alto nivel para eBPF, comparable a lo que DTrace era en Solaris. Una sola línea puede rastrear cada I/O de disco superior a 1ms en un host de producción, o generar histogramas de latencias de conexión TCP, o encontrar qué procesos causan más cambios de contexto — todo con una sobrecarga medida en porcentajes de un solo dígito, no el costo del 10–30% del perfilado tradicional.

Pixie va más lejos para Kubernetes, instrumentando automáticamente cada servicio en un clúster usando eBPF para capturar datos de solicitud/respuesta, distribuciones de latencia y tasas de error sin ninguna configuración por servicio. Sin sidecars. Sin integración de SDK. La observabilidad está integrada en la capa del kernel.

Aplicación de Seguridad a Nivel del Kernel

seccomp-BPF lleva años filtrando syscalls en contenedores Linux — es lo que Docker, Chrome y Firefox usan para restringir qué llamadas al sistema puede hacer un proceso en sandbox. Ese es el extremo limitado de la seguridad con eBPF.

El extremo más amplio es la aplicación de seguridad en tiempo de ejecución. Falco usa eBPF para vigilar cada syscall en un clúster Kubernetes y alertar sobre comportamientos sospechosos — un contenedor lanzando un shell, un proceso escribiendo en /etc, una conexión de red a una IP inesperada. Tetragon, del proyecto Cilium, va más lejos: no solo puede detectar violaciones de políticas en tiempo real sino también aplicarlas eliminando el proceso infractor antes de que la syscall se complete. La lógica de políticas se ejecuta en el kernel mediante eBPF. No hay ventana de carrera entre la detección y la respuesta.

Portabilidad: CO-RE y BTF

Una queja persistente sobre eBPF era el bloqueo por versión del kernel. Un programa eBPF compilado contra las cabeceras del kernel 5.15 podría no funcionar en 6.1 si los layouts de structs cambiaron. CO-RE — Compile Once, Run Everywhere — resuelve esto. Con BTF (BPF Type Format), el kernel expone su información de tipos internos en tiempo de ejecución. El cargador eBPF usa BTF para reubicar accesos a campos en tiempo de carga, adaptando el programa compilado a cualquier kernel que esté ejecutándose. Un único binario eBPF puede ahora ejecutarse en toda una flota con kernels mixtos sin recompilación.

Lo Que Viene Después

Microsoft está portando activamente eBPF a Windows mediante el proyecto ebpf-for-windows. Los fabricantes de SmartNIC están agregando offload de hardware para programas eBPF, de modo que el filtrado XDP pueda ejecutarse en la propia NIC, liberando completamente las CPUs del host. Los runtimes eBPF en espacio de usuario están madurando, habilitando extensibilidad en sandbox al estilo eBPF fuera del kernel.

El patrón subyacente es consistente: un mecanismo de extensión programable con fuertes garantías de seguridad supera al código de kernel estático para todo lo que necesita evolucionar a la velocidad de producción. eBPF no solo mejoró el networking y la observabilidad de Linux — cambió el modelo de cómo se extiende el comportamiento del kernel. Los equipos de infraestructura que entendieron esto temprano están operando más rápido, con mayor seguridad y a mayor escala que quienes aún escriben reglas de iptables y módulos de kernel.