Google reescribe una librería C crítica en Rust con Gemini y fuzzing diferencial

El equipo de seguridad de Google ha traducido una dependencia crítica escrita en C a Rust usando Gemini y la ha puesto en producción. El conejillo de indias es giflib, una librería de decodificación de imágenes de unas 3.000 líneas que procesa entrada no confiable y que hasta ahora vivía dentro de un sandbox de proceso para compensar su falta de seguridad de memoria. El binario resultante se publica como giflib-rs bajo licencia abierta.

La relevancia del experimento está en el punto de partida: los bugs de corrupción de memoria explican alrededor del 70% de las vulnerabilidades graves en bases de código maduras de C y C++. Bastian Kersting y Max Hils montaron un proceso de tres etapas con bucle de retroalimentación automático en lugar de emprender una conversión manual de años.

Un prompt, mucha auditoría detrás

Primero, un único prompt a Gemini para portar toda la lógica de la librería. Como el objetivo era reemplazar el objeto compartido sin romper a quien lo llama, mantuvieron los símbolos exportados y las definiciones de struct originales. Ahí apareció el primer problema: modelar la interfaz FFI introdujo semántica de punteros crudos que no era sólida, y hicieron falta expertos humanos para revisar y ajustar la propiedad de punteros y los invariantes de tiempo de vida. Después, motores de testing diferencial detectaron discrepancias de comportamiento y realimentaron las trazas de fallo al modelo para que sintetizara parches iterativos.

La validación fue la parte seria. Regresión a escala masiva sobre más de 30 millones de GIF reales para garantizar paridad bit a bit en el renderizado, y un fuzzer diferencial ejecutando ambas implementaciones en paralelo durante seis días, con 200 millones de iteraciones sin deriva funcional. En el proceso apareció un caso límite no cubierto en el descompresor LZW y una escritura fuera de límites que Google había introducido ella misma en un parche interno anterior sobre el C original.

El espaldarazo llegó en staging: un investigador externo encontró una escritura fuera de límites en el heap de la giflib upstream, catalogada como CVE-2026-26740, y los nodos que ya ejecutaban la versión en Rust resultaron estructuralmente inmunes antes de la divulgación pública.

Sin coste en latencia

El miedo habitual al portar C a Rust es el sobrecoste de las comprobaciones de límites. La telemetría de los clústeres globales de decodificación de imágenes da paridad de rendimiento con el binario C. Y como la seguridad de memoria vive en el sistema de tipos, los ingenieros pudieron desmontar los sandboxes que aislaban la decodificación; eliminar esa frontera de aislamiento redujo de forma apreciable la latencia de cola p99.

Los propios autores ponen los límites. Bifurcar una dependencia upstream crea divergencia de mantenimiento en cuanto el repositorio original publique cambios, y los envoltorios FFI siguen necesitando criterio humano para evitar fugas de tiempo de vida y garantizar invariantes de thread-safety. En Hacker News y r/rust el debate fue justo ese: se aplaudió el marco de fuzzing diferencial, pero se cuestionó el enfoque de un solo disparo, con varios comentarios defendiendo transpiladores deterministas como c2rust seguidos de refactorización asistida hacia Rust idiomático a medida que las librerías crecen más allá de objetivos pequeños y autocontenidos como giflib.