TinyKVM - sandbox rápido executado sobre o Varnish

• Sandbox de processo único baseado em KVM
  • Pode executar programas Linux comuns ou programas que usam APIs específicas dentro do sandbox
• Fornece desempenho nativo usando virtualização de hardware
• Usa apenas uma parte da API do KVM → base de código pequena e eficiente

Arquitetura do TinyKVM

• Suporte à execução de programas Linux ELF estáticos
  • Suporte a executáveis dinâmicos será adicionado futuramente
  • Também pode ser estendido com APIs para fornecer acesso a servidores HTTP externos ou caches
  • Atualmente funciona em AMD64(x86_64), com plano de port para AArch64(ARM de 64 bits)
• Suporte a hugepages
  • É possível criar hugepages para páginas do guest
  • O host também pode usar hugepages → melhora de desempenho
  • Ex.: ao alocar páginas de 2 MB, foi observado um aumento de 5% no desempenho de compilação com LLVM
• Chamadas de função rápidas
  • Ao chamar funções no guest, o overhead é de 2μs
  • Ao executar sem timer, o overhead cai para 1,2μs
• Suporte a depuração remota
  • É possível depurar remotamente com GDB
  • Após a depuração, o programa pode ser retomado normalmente
• Suporte a Copy-on-Write
  • Suporta seu próprio mecanismo de fork → minimiza a duplicação de memória
  • Ex.: ao duplicar um modelo de 6 GB, cada instância precisa de apenas 260 MB de memória
• Inicialização rápida de estado
  • O estado do guest pode ser resetado rapidamente → reforça a segurança
  • Resetar a cada requisição reduz o risco de exposição de estado
• Base de código simplificada
  • Usa cerca de 42k LOC da API do KVM
  • A base de código do próprio TinyKVM tem cerca de 9k LOC → muito menor que soluções concorrentes
  • Ex.: Wasmtime 350k LOC, FireCracker 165k LOC
• Criação estática de tabelas de página
  • Não é possível modificar as tabelas de página em tempo de execução → reforça a segurança
  • Verificações de integridade das tabelas de página são realizadas
• Contexto de processo isolado
  • O guest KVM usa PCID/ASID separado → mais resistente a ataques de execução especulativa como Spectre
• Kernel com segurança reforçada
  • SMEP e SMAP ativados
  • Exceções de CPU podem ser tratadas em modo de usuário

Tratamento de system calls

• Conexão de API com o host
  • As system calls são executadas via instruções SYSCALL/SYSRET ou OUT
  • Ao executar uma system call, ocorre um VM exit → leva cerca de 1μs
  • Recomenda-se reduzir chamadas pequenas e projetar APIs com unidades maiores de entrada e saída

Benchmark

• Overhead de chamadas da VM
  • A tail latency é medida ao resetar a VM
  • Em chamadas simples sem reset, o overhead é baixo
• Desempenho de memória
  • O desempenho de memória está em nível normal
  • Ex.: em benchmark HTTP, é possível codificar 1500 imagens AVIF por segundo
• Desempenho de conversão JPEG → AVIF
  • É possível converter cerca de 1582 imagens por segundo
  • Conversão sem perdas é possível usando o caminho de conversão YUV

Por que o sandbox é tão rápido

• Sem uso de I/O e drivers
  • Não há I/O, drivers nem dispositivos virtuais → evita perda de desempenho
  • Usa apenas recursos de CPU → aproxima-se da velocidade nativa
• Otimização com hugepages
  • O uso de hugepages reduz page walks → melhora o desempenho
  • Em grandes workloads de LLM, atinge 99,7% do desempenho nativo
• Chamadas rápidas de VM
  • Overhead mínimo ao chamar funções no guest
  • Os dados podem ser processados na velocidade nativa da CPU

Limitações

• Não é possível reduzir o número de vCPUs
  • A API do KVM não permite reduzir o número de vCPUs
  • O multiprocessamento pode ser resolvido executando várias VMs em paralelo
• Problema de queda de desempenho no reset
  • Pode haver degradação de desempenho ao resetar o estado da VM
  • Mas isso pode ser resolvido por meio de compartilhamento e replicação de estado

Próximos passos

• Adicionar suporte a Intel TDX e AMD SEV
• Port para AArch64
• Adicionar recurso de bloqueio de memória (KVM_MEM_READONLY) → reforço de segurança
• Melhorar a API para ser mais amigável ao usuário
• Adicionar suporte ao carregamento de links dinâmicos → reforçar a integração com o Varnish

Conclusão

• TinyKVM é uma das menores e mais rápidas soluções de sandbox
• Alcança tanto reforço de segurança quanto otimização de desempenho
• A base de código é pequena, o que facilita a manutenção
• Disponível como biblioteca open source → se tiver interesse, vale conferir o repositório de código

Repositório do TinyKVM

[xcutz]

Interessante e diferente.

[GN⁺]

Comentários no Hacker News

• Gostei muito disso. Espero que continuem sem parar o trabalho que estão fazendo agora

  • Eu sabia que ele era um dos principais contribuidores do IncludeOS. Foi o primeiro projeto que me veio à cabeça ao ler este post do blog
  • Sou obcecado há muito tempo por virtualização de funções de rede. É a fronteira mais natural para separar unidades de trabalho em sistemas distribuídos, além de oferecer uma abstração limpa e um mecanismo eficiente de escalonamento
  • Uso o Varnish em produção com muita satisfação. Em alguns aspectos, ele é até mais confiável que o nginx. Normalmente, chego a esquecer que ele existe. Depois de configurado corretamente, nunca foi a causa de nenhum bug

• É parecido com o Firecracker, mas muito mais rápido

  • O que eu mais gosto é a capacidade de redefinir instantaneamente o estado da VM para um estado predefinido. É como reiniciar a VM sem de fato reiniciá-la
  • Parece uma medida ideal para serviços de rede que ficam sob ataque constante. Mesmo que um ataque tenha sucesso, o resultado é apagado na próxima requisição
  • O compartilhamento fácil de páginas COW para programas escritos sem isso em mente, como executores de modelos de ML, também é muito bom

• Post original: link

  • Dá para encontrar muitos posts relacionados a este tópico

• Muito interessante. O desempenho de restauração de snapshot em 2.5us é comparável ao Wasmtime, mas com a grande vantagem de poder executar código nativo. Em compensação, é bem mais lento, embora ainda mantenha interoperabilidade na escala de microssegundos

  • Já existe um demo de QuickJS no repositório tinykvm_examples, mas seria muito mais rápido verificar se é possível executar um runtime JavaScript com JIT
  • Em um experimento de renderização no servidor de um app React, o QuickJS nativo ficou em cerca de 12-20ms, enquanto o v8 ficou em 2-4ms após o aquecimento do JIT
  • Preciso estudar mais, mas quero criar um executável único como o Deno, que rode dentro do sandbox e processe todas as requisições HTTP via Varnish
  • Buscar uma URL JS especificada, tirar um snapshot e fazer com que cada requisição seja executada em um snapshot isolado
  • Provavelmente será necessário um mecanismo para redefinir a seed aleatória por requisição

• Basicamente não é algo como o libkrun? link

• Não é exatamente o caso de uso pretendido, mas alguém já teve experiência rodando um servidor X (ou Wayland)?

  • Estou desenvolvendo para um servidor RDP no Mac e, às vezes, preciso de outras coisas para clientes. No momento, uso UTM (frontend de Mac para QEMU) e uma VM com DietPi (um Debian extremamente enxuto)
  • Estou acostumado com Docker, mas sei bem quais procedimentos são necessários para rodar um servidor gráfico. Queria saber se existe uma forma mais simples

• É interessante, mas estou tendo dificuldade para entender o panorama geral. Isso executa um processo de usuário em uma VM sem kernel? Todas as system calls fazem a VM encerrar e são então encaminhadas por proxy para o host? Ou não há system calls?

• Se servir para o seu caso de uso, isso é realmente muito legal

  • Algumas notas do post
  • Descobriram que o TinyKVM roda a 99.7% da velocidade nativa
  • Se não precisar de acesso a arquivos ou rede e for estático, pode simplesmente ser executado diretamente
  • O guest do TinyKVM tem um pequeno kernel imutável

• Muito legal

  • Estou explorando micro-VMs para uma PaaS self-hosted, e algo com pouco overhead parece uma opção realmente interessante

• O artigo não diz que ele roda sobre o Varnish e, na verdade, o autor diz que isso não é para rodar o Varnish