- Sandbox de proceso único basado en KVM
- Permite ejecutar en el sandbox programas normales de Linux o programas que usan una API específica
- Ofrece rendimiento nativo mediante virtualización por hardware
- Usa solo una parte de la API de KVM → la base de código es pequeña y eficiente
Diseño de TinyKVM
- Compatibilidad con ejecución de programas Linux ELF estáticos
- El soporte para ejecutables dinámicos se agregará más adelante
- También puede ampliarse con una API para dar acceso a servidores HTTP externos o cachés
- Actualmente funciona en AMD64 (x86_64), y está planeado el port a AArch64 (ARM de 64 bits)
- Compatibilidad con hugepages
- Se pueden crear hugepages para las páginas del guest
- También se pueden usar hugepages en el host → mejora el rendimiento
- Ejemplo: al asignar páginas de 2 MB se confirmó una mejora del 5% en el rendimiento de compilación con LLVM
- Llamadas a funciones rápidas
- Al llamar funciones desde el guest, el overhead es de 2 μs
- Al ejecutarse sin temporizador, el overhead baja a 1.2 μs
- Compatibilidad con depuración remota
- Se puede depurar remotamente con GDB
- Después de depurar, el programa puede reanudarse normalmente
- Compatibilidad con Copy-on-Write
- Incluye su propia función de
fork → permite minimizar la duplicación de memoria
- Ejemplo: al clonar un modelo de 6 GB, solo se requieren 260 MB de memoria por instancia
- Inicialización rápida de estado
- El estado del guest puede reiniciarse rápidamente → mejora la seguridad
- Reiniciarlo en cada solicitud reduce el riesgo de exposición de estado
- Base de código simplificada
- Usa alrededor de 42k LOC de la API de KVM
- La base de código propia de TinyKVM es de unas 9k LOC → mucho más pequeña que las soluciones competidoras
- Ejemplo: Wasmtime 350k LOC, FireCracker 165k LOC
- Creación estática de tablas de páginas
- No se pueden modificar las tablas de páginas durante la ejecución → mejora la seguridad
- Se realizan verificaciones de integridad de las tablas de páginas
- Contexto de proceso aislado
- El guest de KVM usa un PCID/ASID separado → es más resistente a ataques de ejecución especulativa como Spectre
- Kernel reforzado en seguridad
- SMEP y SMAP habilitados
- Es posible manejar excepciones de CPU en modo usuario
Manejo de llamadas al sistema
- Conexión de API con el host
- Las llamadas al sistema se realizan mediante las instrucciones SYSCALL/SYSRET o OUT
- Al ejecutar una llamada al sistema ocurre una VM exit → tarda alrededor de 1 μs
- Se recomienda diseñar APIs con unidades grandes de entrada/salida y reducir las llamadas pequeñas
Benchmarks
- Overhead de llamadas a la VM
- Se midió la tail latency al reiniciar la VM
- En llamadas simples sin reinicio, el overhead es bajo
- Rendimiento de memoria
- El rendimiento de memoria está en niveles normales
- Ejemplo: en un benchmark HTTP puede codificar 1500 imágenes AVIF por segundo
- Rendimiento de conversión de JPEG → AVIF
- Puede convertir alrededor de 1582 imágenes por segundo
- Es posible una conversión sin pérdida usando la ruta de conversión YUV
Por qué el rendimiento del sandbox es tan rápido
- Sin uso de I/O ni drivers
- No hay I/O, drivers ni dispositivos virtuales → se evita la degradación de rendimiento
- Usa solo recursos de CPU → se acerca a la velocidad nativa
- Optimización con hugepages
- El uso de hugepages reduce los page walks → mejora el rendimiento
- En grandes cargas de trabajo de LLM alcanza el 99.7% del rendimiento nativo
- Llamadas rápidas a la VM
- Se minimiza el overhead al llamar funciones desde el guest
- Permite procesar datos a velocidad nativa de la CPU
Limitaciones
- No se puede reducir la cantidad de vCPU
- La API de KVM no permite reducir la cantidad de vCPU
- El multiprocesamiento puede resolverse ejecutando varias VM en paralelo
- Problema de degradación de rendimiento al reiniciar
- Puede haber una caída de rendimiento al reiniciar el estado de la VM
- Pero puede resolverse mediante compartición y clonación de estado
Próximas tareas
- Agregar soporte para Intel TDX y AMD SEV
- Port a AArch64
- Agregar función de bloqueo de memoria (
KVM_MEM_READONLY) → mejora la seguridad
- Mejorar la API para que sea más fácil de usar
- Agregar soporte para carga de enlaces dinámicos → reforzar la integración con Varnish
Conclusión
- TinyKVM es una de las soluciones de sandbox más pequeñas y rápidas
- Logra tanto refuerzo de seguridad como optimización de rendimiento
- Su base de código pequeña facilita el mantenimiento
- Se ofrece como librería de código abierto → si te interesa, puedes revisar el repositorio
Repositorio de TinyKVM
2 comentarios
Qué curioso.
Comentarios en Hacker News
Me encanta esto. Ojalá no dejen de hacer lo que están haciendo ahora
Es parecido a Firecracker, pero mucho más rápido
Publicación original: enlace
Muy interesante. El rendimiento de restauración de snapshots de 2.5us está a la par de Wasmtime, pero con la gran ventaja de poder ejecutar código nativo. Aun así, es mucho más lento, aunque sigue teniendo interoperabilidad en el rango de microsegundos
tinykvm_examplesya tiene un demo de QuickJS, pero sería mucho más rápido si se comprobara si puede ejecutar un runtime de JavaScript con JITBásicamente, ¿no es algo como libkrun? enlace
Esto no es exactamente para el caso de uso previsto, pero ¿alguien tiene experiencia ejecutando un servidor X (o Wayland)?
Es interesante, pero me cuesta entender el panorama general. ¿Se trata de ejecutar un proceso de usuario dentro de una VM sin kernel? ¿Todas las llamadas al sistema hacen que la VM termine y sean proxied al host? ¿O simplemente no hay llamadas al sistema?
Si encaja con tu caso de uso, está realmente genial
Muy genial
El artículo no dice que se ejecute sobre Varnish y, de hecho, el autor dice que no fue hecho para ejecutar Varnish