Resumen

  • RFC 9669 define instrucciones y grupos de conformidad para coordinar compiladores y runtimes; no certifica la trayectoria operativa de un programa concreto.
  • Un objeto cargado puede no estar enlazado, no ser invocado o no producir el resultado esperado. Cada transición exige identidad y evidencia propias.

La automatización recibió una respuesta satisfactoria de carga. Guardó el ID del programa, comparó el hash con el artefacto revisado y pintó de verde la política. El contador de paquetes del nuevo programa no se movió durante veinte minutos.

El problema no estaba en sus instrucciones. La actualización había creado un objeto nuevo, pero el enlace del hook conservaba el ID anterior. La plataforma tenía dos verdades simultáneas: una versión cargada y otra versión ejecutándose.

Llamar “desplegado” a la primera borró precisamente la relación que había que comprobar.

El estándar resuelve la identidad de la instrucción

RFC 9669 especifica una arquitectura para BPF. La forma básica ocupa 64 bits y la forma ancha añade otros 64. El opcode, los registros, el desplazamiento y el inmediato forman una codificación estable cuya semántica depende de la clase. Esa precisión permite que una herramienta produzca bytes que un runtime pueda interpretar de la misma manera.

No todas las instrucciones son obligatorias para toda implementación. base32 constituye el mínimo requerido; los demás grupos son opcionales. base64 incorpora base32, atomic64 incorpora atomic32 y divmul64 incorpora divmul32. Quien declara un grupo debe implementar todas sus instrucciones.

Los registros de IANA convierten esas capacidades en objetos gobernables. Un registro de grupo conserva nombre, descripción, inclusiones, exclusiones, estado y referencia. El registro de instrucciones asigna combinaciones de campos, descripción y pertenencia a grupos. Las extensiones nuevas crean grupos nuevos en vez de cambiar silenciosamente el significado de uno antiguo.

Ese diseño protege la interoperabilidad, pero no observa una máquina. Que una asignación sea Permanente no obliga al runtime instalado a implementarla. Que una flota anuncie base64 no prueba atomic64. Que el host admita una instrucción tampoco prueba que la misma ruta exista en una NIC con offload.

La planificación necesita capacidad descubierta por destino, con versión y momento. “BPF disponible” es una etiqueta de producto; no es una negociación de instrucciones.

Las instrucciones válidas pueden formar un programa inadmisible

La ISA describe piezas y parte de su composición, pero no sustituye al verificador. Un salto cuenta su offset en unidades de 64 bits. Si aterriza en la segunda mitad de una instrucción ancha de 128 bits, el comportamiento es indefinido. Reconocer cada opcode no salva esa secuencia.

Las funciones y los objetos de plataforma abren más dependencias. La especificación usa operaciones abstractas para mapas, variables y direcciones. La plataforma decide qué existe y cómo se resuelve. El tipo de programa delimita el contexto accesible y las funciones invocables.

RFC 9669 atribuye a los verificadores controles de terminación, memoria segura, contratos de API y comportamiento indefinido. También declara que esos detalles quedan fuera de su alcance. No hay una contradicción: el estándar fija el lenguaje; el runtime conserva la autoridad de admisión.

En Linux, el verificador revisa primero el flujo de control y después explora caminos mientras rastrea registros y pila. Un callback puede autorizar cierto campo de contexto para un tipo de programa y denegarlo para otro. Los prototipos de funciones impondrán tipos de argumentos. Una operación aritmética permitida sobre un escalar puede destruir la validez de un puntero.

La documentación de diseño resume la prueba decisiva: para saber si un programa será aceptado por ese verificador, hay que intentar cargarlo. La compatibilidad histórica de Linux con programas antes aceptados es valiosa, pero no es una garantía para otro runtime, otro tipo de programa ni otro destino de hardware.

Cargar no enlaza; enlazar no invoca

Cuando el verificador acepta el programa y el loader crea un objeto, existe un recibo de carga. Aún falta nombrar el punto de ejecución. Un enlace debe asociar la generación exacta con el hook exacto. Su identidad, tiempo de creación y estado de sustitución son parte del despliegue.

Después, el hook debe ocurrir. Un enlace correcto sobre una ruta sin tráfico puede producir cero invocaciones. Un selector equivocado puede observar otra interfaz o cgroup. Un programa invocado puede tomar una rama que no modifica nada. Un contador interno puede aumentar mientras el paquete o la transacción no alcanza el resultado externo que interesa.

Por eso, el recibo operativo no termina en el ID del programa. Debe correlacionar hash de artefacto, ID cargado, ID de enlace, hook, generación de mapas, contadores de ejecución y una medición exterior. Para una política de red, esa medición podría ser un flujo de prueba observado después del punto de control. Para una política de aplicación, podría ser el resultado durable de una transacción.

La firma ofrece otra capa, no un atajo. La documentación Linux actual separa una firma válida de los permisos y del verificador. Un programa auténtico aún puede ser rechazado. Esta observación pertenece a Linux, no a las obligaciones de RFC 9669, pero muestra por qué cada estado debe conservar su verbo exacto.

El rollback también es un grafo

Reemplazar un programa sin enumerar enlaces deja generaciones mezcladas. Reutilizar mapas puede combinar decisiones antiguas y nuevas. Borrar el objeto más reciente no garantiza que el hook haya regresado al estado esperado. Un rollback serio conoce todos los enlaces entrantes, la generación de cada mapa y el orden de desenganche.

Los fallos negativos son diagnósticos: grupo no soportado, relocación fallida, rechazo del verificador, carga fallida, enlace ausente, invocación nula y resultado divergente. Reducirlos a un único “falló BPF” desperdicia la arquitectura de evidencia.

RFC 9669 ofrece el punto común que debe ser común. La decisión de ejecutar un programa privilegiado y creer en su efecto sigue siendo local, reversible y demostrable mediante código en funcionamiento.

Fuentes