Los ingenieros utilizan eBPF para inspeccionar el comportamiento del kernel de Linux sin módulos del kernel

Dan Fineran, defensor comunitario principal de Isovalent en Cisco, dijo a InfoQ que los desarrolladores ahora usan eBPF mucho más allá del filtrado de paquetes, aplicándolo a la observabilidad de Linux, el networking de Kubernetes, la aplicación de syscalls y experimentos tempranos en Windows.

Los desarrolladores del kernel crearon eBPF a partir del modelo más antiguo de Berkeley Packet Filter. El BPF original dio a los administradores una forma de filtrar paquetes. eBPF conservó la idea de pequeños programas adjuntos a hooks del kernel y luego expandió el modelo a una capa de extensión más amplia.

Fineran dijo que el atractivo comienza con la ruta de contribución a Linux. Un equipo que desea un nuevo comportamiento del kernel puede escribir un parche, buscar revisiones de los mantenedores del subsistema, esperar la inclusión en el kernel y luego esperar de nuevo para que distribuciones como Ubuntu o Red Hat incluyan ese kernel. Esa ruta protege a los usuarios de Linux, pero ralentiza a los equipos que necesitan visibilidad o aplicación en producción ahora.

Los equipos también pueden escribir módulos del kernel, pero esa ruta acerca el acoplamiento de versiones y el riesgo de fallos. Un autor de módulos a menudo compila contra una versión específica del kernel. Un código de módulo defectuoso puede bloquear la ejecución o provocar un fallo del host. eBPF ofrece a los desarrolladores un objetivo más pequeño con barreras de protección más sólidas.

La barrera de protección que Fineran enfatizó es el verificador. Los desarrolladores compilan el código de eBPF en bytecode y luego solicitan al kernel que lo cargue. El verificador verifica los accesos a memoria, los límites de bucles y el comportamiento del programa antes de que el kernel acepte el programa. Si el verificador detecta un acceso inseguro o una ruta de ejecución que puede ejecutarse sin límites, rechaza el programa.

Ese modelo ofrece a los ingenieros de plataforma una ruta de despliegue en caliente para comportamientos a nivel del kernel. Puedes adjuntar código a hooks compatibles en un sistema en ejecución y eliminarlo sin recompilar el kernel. Aún se necesitan habilidades de bajo nivel, a menudo en C y ahora más frecuentemente con herramientas de Rust, pero se evita el perfil de riesgo operativo de un módulo completo del kernel.

Fineran también rebatió la idea de que los desarrolladores deben aprender eBPF antes de poder usar herramientas basadas en eBPF. Cilium, el proyecto de networking de Kubernetes de Isovalent, oculta gran parte de esa mecánica detrás de abstracciones de políticas y servicios. Los operadores definen qué cargas de trabajo pueden comunicarse entre sí. Los ingenieros de Cilium usan eBPF internamente para dirigir paquetes y aplicar políticas.

El mismo patrón se aplica a Tetragon, que los ingenieros de Isovalent construyeron para la seguridad y observabilidad en tiempo de ejecución. Los equipos de seguridad pueden usar políticas de Tetragon sin escribir programas eBPF en bruto. Tetragon se adjunta a syscalls y otros hooks del kernel, registra actividad y puede bloquear acciones específicas antes de que el kernel las complete.

Ese modelo de pre-hook cambia las operaciones de seguridad. Un agente tradicional puede registrar una eliminación de archivo o escalada de privilegios después de que el kernel complete la acción. Con eBPF, un equipo de seguridad puede colocar lógica antes de un syscall y detener la operación. Fineran dio ejemplos como bloquear eliminaciones en un directorio de proyecto protegido, limitar el acceso a archivos de base de datos al demonio de base de datos o prevenir la escalada de privilegios fuera de las rutas aprobadas.

Los ingenieros también pueden usar políticas de Tetragon para mitigar patrones de vulnerabilidades conocidas. Si un equipo entiende que una función vulnerable maneja mal entradas superiores a un tamaño determinado, puede adjuntar una política antes de la ruta vulnerable y rechazar entradas que coincidan con el patrón de explotación. Eso no reemplaza las correcciones, pero ofrece a los equipos de operaciones una forma de reducir la exposición mientras los propietarios de las aplicaciones preparan soluciones permanentes.

Fineran vinculó el mismo mecanismo a la observabilidad. Los desarrolladores pueden adjuntar programas a sondas del kernel, sondas de retorno, tracepoints, syscalls y sondas del espacio de usuario. Eso brinda a los equipos visibilidad sobre accesos a archivos, llamadas de red, llamadas de bibliotecas, rutas de almacenamiento y comportamiento de controladores sin agregar bibliotecas de instrumentación a cada aplicación.

La utilización de GPU ofreció un ejemplo. Fineran describió equipos que adjuntan programas eBPF cerca de las rutas del controlador NVIDIA CUDA para leer actividad de bajo nivel y correlacionarla con la demanda de las cargas de trabajo. Los equipos de plataforma pueden usar esa señal para mantener ocupados los aceleradores costosos y reducir la capacidad desperdiciada.

Los desarrolladores aún necesitan comprender las limitaciones. El verificador restringe el tamaño del programa, el comportamiento de bucles y el acceso a memoria. Los mensajes de error pueden resultar difíciles para nuevos usuarios, especialmente cuando el verificador devuelve diagnósticos densos. Fineran dijo que la comunidad ha mejorado las herramientas y la documentación, incluyendo Learning eBPF de Liz Rice y los recursos de la comunidad eBPF.

Microsoft también ha abierto una ruta para eBPF en Windows a través del proyecto eBPF for Windows. Los usuarios de Linux obtienen soporte de eBPF en el kernel, mientras que los usuarios de Windows aún necesitan controladores adicionales. Fineran dijo que esa dirección multiplataforma podría ayudar a las organizaciones a unificar la observabilidad y las políticas en sistemas operativos mixtos.

La conversación también abordó micro VMs y aislamiento de Kubernetes. Fineran dijo que los equipos pueden combinar el aislamiento del kernel con controles de ejecución basados en eBPF. Las micro VMs reducen el riesgo de kernel compartido, mientras que Tetragon aún puede inspeccionar y aplicar comportamiento dentro de entornos de huésped compatibles. Edera, dijo, ha añadido soporte de eBPF dentro de su kernel de micro VM.

Las operaciones impulsadas por IA surgieron como una ruta futura. Fineran dijo que Cisco y la comunidad han experimentado con políticas de Tetragon generadas por modelos, aunque los modelos actuales pueden producir campos de política que parecen plausibles pero fallan la validación. Describió un flujo de trabajo probable en el que una herramienta de vulnerabilidades identifica una forma de explotación, un modelo redacta una política y un sistema de validación humano o automatizado prueba la política antes de su implementación.

Ese flujo de trabajo requiere revisión. Fineran advirtió que los usuarios de código abierto deben evaluar la fortaleza de los mantenedores, la frecuencia de actualizaciones, la profundidad del soporte y la procedencia del código antes de adoptar proyectos eBPF. El código generado por IA puede aumentar el volumen de contribuciones, pero los propietarios del proyecto aún necesitan suficiente comprensión para corregir errores, apoyar a los usuarios y mantener el proyecto después de cambios en modelos o herramientas.

Para la mayoría de los desarrolladores, eBPF seguirá siendo un detalle de implementación dentro de herramientas como Cilium y Tetragon. Para los equipos de plataforma, seguridad y observabilidad, ofrece una forma directa de inspeccionar y dar forma al comportamiento del sistema en la frontera del kernel sin distribuir módulos del kernel o esperar cambios del kernel upstream.