Visor g

gVisor es un entorno aislado de contenedores de código abierto desarrollado por Google que se centra en la seguridad, la eficiencia y la facilidad de uso. ^{[ 1 ] [ 2 ]} Proporciona un aislamiento similar al de la virtualización, manteniendo la eficiencia de recursos de los contenedores estándar. gVisor intercepta las llamadas al sistema de las aplicaciones e implementa una gran parte de la ABI de llamadas al sistema de Linux en el espacio de usuario , ofreciendo seguridad adicional en comparación con los contenedores estándar que se ejecutan directamente sobre el kernel de Linux y se aíslan simplemente con espacios de nombres . ^{[ 3 ] [ 4 ]} A diferencia del kernel de Linux, gVisor está escrito en el lenguaje de programación Go , seguro para la memoria , para evitar errores comunes que ocurren con frecuencia en el software escrito en C. [ ^{5 ] Las} características modernas de la plataforma incluyen funcionalidad de punto de control/restauración, integración de monitorización en tiempo de ejecución (como con Falco) y aislamiento de GPU/CUDA para cargas de trabajo de IA/ML. ^{[ 6 ]}

Según Google ^{[ 7 ]} y Brad Fitzpatrick ^{[ 8 ]} , gVisor se utiliza ampliamente en el entorno de producción de Google, incluyendo el entorno estándar de App Engine , Cloud Functions y Google Cloud Run ^{[ 9 ]} . Además, gVisor está integrado con Google Kubernetes Engine (GKE Sandbox), lo que permite a los usuarios aislar sus pods de Kubernetes para casos de uso como SaaS y multitenencia ^{[ 10 ]} .

Además de Google, gVisor es adoptado por numerosas organizaciones para proteger su infraestructura de contenedores y aplicaciones. Entre los usuarios más destacados se encuentran DigitalOcean para su plataforma de aplicaciones, Cloudflare para la creación de páginas de Cloudflare y empresas de IA como OpenAI y Anthropic para ejecutar de forma segura código no confiable o tareas de alto riesgo. Asimismo, proyectos como Docker (en su versión de escritorio para Mac) y Tailscale dependen de la biblioteca de pila de red de gVisor para la comunicación en red en el espacio de usuario. ^{[ 11 ]}

gVisor actúa como un núcleo de aplicación, intercepta y maneja las llamadas al sistema y los fallos de página de la carga de trabajo aislada, en lugar de pasarlos al núcleo Linux del host . ^{[ 12 ]}

• Sentry es el componente central de gVisor. Es un núcleo de espacio de usuario, escrito en Go , que implementa un gran subconjunto de la interfaz de llamadas al sistema de Linux junto con subsistemas como la gestión de procesos, el manejo de señales y la red. La lógica se ejecuta completamente dentro del código seguro para la memoria de gVisor en lugar de delegarse al núcleo del sistema. ^{[ 12 ] [ 13 ]}
• El Gofer es un proceso auxiliar independiente, con privilegios ligeramente mayores, que gestiona el acceso al sistema de archivos del host. El Sentry no puede abrir archivos del host directamente; las operaciones de archivo se envían al Gofer mediante el protocolo 9P , lo que añade una capa adicional de aislamiento entre el entorno aislado y los recursos del host. ^{[ 12 ]}

Para minimizar la superficie de ataque expuesta al host, Sentry se ejecuta bajo un filtro seccomp restrictivo y en espacios de nombres de usuario y montaje aislados , de modo que incluso el pequeño conjunto de llamadas al sistema del host que puede realizar está estrictamente restringido. ^{[ 12 ]}

gVisor debe interceptar las llamadas al sistema de la aplicación en entorno aislado y redirigirlas a Sentry. Abstrae esto detrás de una interfaz de "plataforma", de las cuales actualmente se proporcionan dos:

• Systrap utiliza la función del subsistema seccompSECCOMP_RET_TRAP -bpf : una llamada al sistema en un entorno aislado activa una SIGSYSseñal que transfiere el control a gVisor. No requiere virtualización de hardware y funciona incluso dentro de máquinas virtuales, lo que la convierte en la opción más portátil. Systrap reemplazó a la antigua plataforma ptrace como predeterminada a mediados de 2023. ^{[ 14 ]}

• KVM utiliza la funcionalidad KVM del kernel , lo que permite que Sentry actúe como kernel invitado y monitor de máquina virtual. Su rendimiento es óptimo en hosts bare-metal, pero sufre bajo virtualización anidada y no está disponible en hardware que carece de las extensiones de virtualización pertinentes. ^{[ 14 ]} La plataforma ptrace original , basada en PTRACE_SYSEMU, permanece en el código fuente, pero ya no recibe soporte. ^{[ 14 ]}

Debido a que Sentry intercepta y reproduce las llamadas al sistema, gVisor agrega una sobrecarga que recae principalmente en las cargas de trabajo intensivas en llamadas al sistema y en E/S, mientras que tiene poco efecto en las cargas de trabajo que permanecen dentro de su propio espacio de direcciones. La propia documentación de gVisor señala que el acceso directo a la memoria y la E/S de disco secuencial no generan una sobrecarga estructural significativa una vez que se establecen las asignaciones. ^{[ 15 ]}

Un estudio de caso independiente de USENIX encontró que las llamadas que llegaban al host o al Gofer eran sustancialmente más lentas que las operaciones atendidas completamente dentro de Sentry, y concluyó que las cargas de trabajo con muchas llamadas al sistema deberían evitar la plataforma ptrace. ^{[ 13 ]}