Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby

Este artigo analisa os desafios e armadilhas específicas na implementação de máquinas virtuais no hardware CHERI, utilizando o caso de estudo da portabilidade do CRuby para identificar como suposições sobre comportamentos indefinidos do C em arquiteturas tradicionais causam falhas e para propor soluções validadas.

O essencial

Imagine que você tem uma biblioteca de livros muito antiga e valiosa (o CRuby, que é o "cérebro" da linguagem de programação Ruby). Essa biblioteca foi construída há décadas, e os bibliotecários (os programadores) sempre assumiram certas regras sobre como os livros funcionam. Por exemplo, eles achavam que, se um livro estava na prateleira 5, ele podia ser movido para a prateleira 6 sem problemas, ou que podiam escrever anotações em qualquer página do livro, desde que estivesse dentro do mesmo armário.

Agora, imagine que a biblioteca está se mudando para um novo prédio superseguro chamado CHERI.

Neste novo prédio, as regras são muito mais rígidas e inteligentes:

1. Chaves Mágicas (Capabilities): Em vez de apenas um número de prateleira (um ponteiro comum), cada livro tem uma "chave mágica" que diz exatamente qual livro é, onde ele está, e o que você pode fazer com ele (ler, escrever, ou apenas olhar).
2. Limites Rígidos: Se a chave diz que você só pode tocar na página 10, você não consegue, nem por acidente, tocar na página 11. O sistema bloqueia.
3. Selos de Segurança: Alguns livros têm um "selo de segurança" (como endereços de retorno de funções). Se alguém tentar rasgar uma página ou mudar o selo, o sistema soa um alarme e trava tudo.

O Problema: A Mudança de Casa

Os autores deste artigo (Hanhaotian Liu, Tetsuro Yamazaki e Tomoharu Ugawa) decidiram mover a biblioteca CRuby para esse novo prédio CHERI. Eles esperavam que fosse fácil, mas descobriram que a biblioteca antiga estava cheia de "truques de mágica" que funcionavam no prédio velho, mas que viraram desastres no novo.

Eles chamam esses desastres de "Armadilhas" (Pitfalls). Aqui estão as principais armadilhas que eles encontraram, explicadas com analogias simples:

1. A Armadilha do "Mapa de Área" (Invalid Derived Pointer)

• O Truque Antigo: No prédio velho, se você pegasse um livro da prateleira e dissesse "a partir daqui, eu vou contar até o fim do corredor", o sistema deixava. Você podia andar livremente pelo corredor.
• O Problema no CHERI: No novo prédio, a chave do livro diz "você só pode tocar neste livro específico". Se você tentar usar essa chave para "andar" pelo corredor (varrer a pilha de memória), o sistema grita: "Ei! Essa chave não tem permissão para tocar no resto do corredor!".
• A Solução: Em vez de usar a chave do livro individual, os bibliotecários agora carregam uma "Chave Mestra" que abre todo o corredor inteiro. Eles usam essa chave mestra para navegar, e só usam a chave pequena para pegar o livro específico quando necessário.

2. A Armadilha do "Livro Falso" (Dereferencing Ambiguous Pointers)

• O Truque Antigo: O sistema de segurança (Garbage Collector) olhava para um pedaço de papel na mesa. Se o papel tivesse números que pareciam um endereço de livro, o sistema assumia: "Ah, isso é um livro! Vou abrir e ler".
• O Problema no CHERI: No novo prédio, nem todo número é uma chave válida. Às vezes, é apenas um número aleatório. Se o sistema tentar abrir um "livro" que é apenas um número falso, a chave não tem o "selo de validade" e o sistema trava.
• A Solução: Antes de tentar abrir o livro, o sistema agora verifica o "selo de validade" na chave. Se não tiver o selo, ele ignora o papel. Isso até torna o sistema mais rápido, pois ele para de tentar ler papéis que não são livros.

3. A Armadilha do "Expansão de Sala" (In-Place Reallocation)

• O Truque Antigo: Imagine que você tem uma caixa de ferramentas. Se ela fica pequena, você pede para o zelador esticá-la no lugar. O zelador estica a caixa, mas diz: "A chave antiga ainda serve, ela agora é maior".
• O Problema no CHERI: No novo prédio, quando o zelador estica a caixa, ele entrega uma nova chave com novos limites. A chave antiga diz "até a parede X", mas a caixa agora vai até a parede Y. Se você continuar usando a chave antiga, vai bater na parede e o sistema bloqueia.
• A Solução: O código foi reescrito para sempre pegar a "nova chave" que o zelador entrega, em vez de insistir na antiga.

4. A Armadilha do "Espaço Vazio" (Using Padding Bits)

• O Truque Antigo: Os programadores usavam caixas de 128 bits (o tamanho das chaves no novo prédio) para guardar números pequenos, assumindo que podiam usar todos os 128 bits para fazer cálculos matemáticos.
• O Problema no CHERI: No novo prédio, a caixa de 128 bits não é só para números. A metade superior é usada para guardar os "segredos" da chave (limites, permissões). Se você tentar fazer cálculos matemáticos usando esses bits de segredo, você corrompe a chave e o sistema trava.
• A Solução: Eles pararam de usar as caixas gigantes para cálculos simples e passaram a usar caixas menores e puras (tipos inteiros exatos) que não têm segredos escondidos.

5. A Armadilha do "Selo Quebrado" (Modifying Sealed Capabilities)

• O Truque Antigo: Às vezes, o sistema pegava um endereço de retorno (um "mapa de volta para casa") e fazia cálculos matemáticos nele para encontrar informações.
• O Problema no CHERI: Esses endereços de retorno são "selados". É como se estivessem lacrados com cera. Se você tentar fazer uma conta matemática neles, você quebra o lacre. O sistema vê o lacre quebrado e trava por segurança.
• A Solução: Antes de fazer a conta, eles transformam o endereço selado em um simples número (sem a chave), fazem a conta, e só depois olham o resultado. Eles não tentam quebrar o lacre.

O Resultado Final

Depois de consertar todas essas armadilhas, os autores testaram a biblioteca.

• Funciona? Sim! O CRuby agora roda no CHERI e passa na maioria dos testes (cerca de 87% dos testes originais).
• É lento? Quase nada. Em média, o novo sistema é apenas 1,8% mais lento que o antigo. Em alguns casos específicos (como fibras, que são como "mini-tarefas"), houve uma queda maior porque a versão antiga usava truques de hardware muito específicos que não existem no novo prédio, mas a solução geral é muito eficiente.

Conclusão

Este artigo é um manual de sobrevivência. Ele diz aos programadores: "Se vocês querem construir softwares seguros no futuro (usando CHERI), parem de fazer truques de mágica que funcionavam no passado. O novo sistema é mais inteligente e seguro, mas exige que você seja mais honesto e preciso sobre como manipula a memória."

É como mudar de uma casa onde você podia pular de um telhado para o outro sem cair, para uma casa onde cada janela tem um vidro à prova de balas. Você precisa aprender a usar as escadas corretamente, mas no final, sua casa estará muito mais segura contra invasores.

Resumo técnico

Aqui está um resumo técnico detalhado do artigo "Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby" (Armadilhas na Implementação de VMs em CHERI: Lições da Portabilidade do CRuby), apresentado em português.

1. Problema

A segurança de software, especialmente a segurança de memória, é um desafio crítico. O CHERI (Capability Hardware Enhanced RISC Instructions) é uma arquitetura de hardware inovadora que substitui ponteiros tradicionais por "capacidades" (capabilities) imutáveis e verificadas pelo hardware para garantir segurança espacial e temporal.

No entanto, portar Máquinas Virtuais (VMs) complexas, como o interpretador CRuby, para o CHERI não é trivial. O problema central identificado pelos autores é que muitas VMs dependem de comportamentos indefinidos (undefined behavior) da linguagem C e de idioms de programação que assumem que ponteiros são apenas endereços de memória numéricos. Sob o CHERI, onde ponteiros são capacidades com metadados (limites, permissões, tags de validade), essas suposições falham, levando a erros de execução, violações de limites de capacidade e falhas de segurança. Embora existam guias gerais de programação para CHERI, faltam diretrizes específicas para os desafios únicos encontrados na implementação de VMs.

2. Metodologia

Os autores adotaram uma abordagem baseada em estudo de caso e análise comparativa:

• Estudo de Caso Principal: Portabilidade do CRuby (a implementação de referência da linguagem Ruby, escrita em C) para a arquitetura CHERI (modo purecap em RISC-V). O trabalho focou no sistema de tempo de execução e no interpretador, excluindo o compilador JIT e a interface de função externa (FFI).
• Análise de Código: Modificaram o código-fonte do CRuby (versão 3.4.1) para compilar e passar nos testes, documentando cada erro e sua correção.
• Revisão de Trabalhos Anteriores: Investigaram estudos de caso anteriores de portabilidade de VMs para CHERI, especificamente MicroPython, JavaScriptCore e o compilador Rust.
• Categorização: Agruparam os problemas encontrados em categorias baseadas em suas causas raízes (comportamentos indefinidos do C, metadados de capacidades, etc.).
• Avaliação de Desempenho: Compararam o desempenho da VM portada com a VM original em um ambiente x86 (usando emulação de capacidades para fins de benchmark), medindo a sobrecarga das soluções aplicadas.

3. Contribuições Chave e Armadilhas Identificadas

O artigo categoriza as armadilhas em seis áreas principais, fornecendo lições e soluções para cada uma:

A. Ponteiros Derivados Inválidos (Invalid Derived Pointer)

• Problema: VMs frequentemente derivam um ponteiro de outro para um propósito diferente (ex: pegar o endereço de uma variável local na pilha para varrer a pilha inteira). No CHERI, o operador & retorna uma capacidade com limites restritos àquela variável específica. Derivar um ponteiro para varrer além desses limites causa falha de limites (bounds fault).
• Solução: Manter uma "super capacidade" com limites amplos (ex: toda a pilha) e derivar novos ponteiros a partir dela, em vez de derivar de uma variável local restrita.

B. Desreferenciamento de Ponteiros Ambíguos (Dereferencing Ambiguous Pointers)

• Problema: Coletas de Lixo Conservadoras (Conservative GC) varrem a pilha procurando por padrões de bits que parecem ponteiros. Se um inteiro tiver o mesmo padrão de bits de um endereço válido, o GC tenta desreferenciá-lo. No CHERI, inteiros convertidos para ponteiros não possuem a "tag de validade" (validity tag) definida, causando falha de tag.
• Solução: Verificar a tag de validade da capacidade antes de desreferenciar, em vez de confiar apenas no padrão de bits. Isso permite uma varredura mais precisa e pode eliminar a necessidade de "pinar" objetos.

C. Realocação no Local (In-Place Reallocation)

• Problema: VMs frequentemente assumem que realloc pode realocar memória no mesmo endereço e que o ponteiro original permanece válido. No CHERI, realloc pode retornar uma capacidade com limites diferentes (mais amplos) ou invalidar a antiga. Usar o ponteiro antigo após a realocação pode violar os limites da nova área expandida.
• Solução: Não depender de realocação no local. Se necessário, atualizar todas as referências ao ponteiro antigo para o novo ponteiro retornado pela função de alocação.

D. Uso de Bits de Preenchimento (Using Padding Bits)

• Problema: VMs usam inteiros para empacotar dados (ex: mapas de bits, campos de bits). No CHERI, o tipo (u)intptr_t é uma capacidade de 128 bits, onde os 64 bits superiores são metadados (padding). Operações de deslocamento (shift) ou máscaras que assumem que todos os bits são dados válidos falham ou produzem resultados aleatórios nos bits superiores.
• Solução: Usar tipos inteiros de largura exata (ex: uint64_t) para mapas de bits e operações de bits, evitando o uso de (u)intptr_t para fins puramente aritméticos de dados.

E. Modificação de Capabilidades Temporárias (Modifying Temporary Capabilities)

• Problema: O compilador C do CHERI pode gerar capacidades temporárias ao realizar operações aritméticas em tipos (u)intptr_t. Se o operando for uma capacidade selada (ex: endereço de retorno), tentar modificar seu endereço (mesmo que temporariamente) causa uma falha de capacidade selada (sealed fault).
• Solução: Castar explicitamente os operandos (u)intptr_t para tipos inteiros não-capacidade (ex: uint64_t) antes da operação aritmética, evitando que o compilador crie capacidades temporárias inválidas.

F. Aritmética de Ponteiros em Tipos Não-Capacidade

• Problema: Técnicas comuns em C (como downcasting usando offsetof e aritmética de ponteiros) frequentemente usam size_t para cálculos. No CHERI, converter um ponteiro para size_t e de volta resulta em uma capacidade inválida, pois os metadados são perdidos.
• Solução: Usar estritamente (u)intptr_t para qualquer aritmética de ponteiros que envolva conversão para inteiro e retorno, garantindo a preservação dos metadados da capacidade.

4. Resultados

• Portabilidade: O CRuby portado passou em 29.609 de 34.046 casos de teste (aproximadamente 87%). As falhas restantes foram atribuídas principalmente à ausência de bibliotecas externas (libyaml) e a um teste específico de árvores de sintaxe que causava travamento, não necessariamente a falhas de portabilidade do CHERI.
• Desempenho: A avaliação de desempenho mostrou que, na média, a VM portada atingiu 98,2% do throughput da VM original.
  • A maioria dos benchmarks teve uma sobrecarga insignificante.
  • Alguns outliers (relacionados a fibras/threads) tiveram desempenho até 10x pior, devido à falta de implementações otimizadas em assembly para a arquitetura alvo no código portado, e não devido às correções de segurança do CHERI.
• Impacto das Soluções: As workarounds aplicadas (como cast para uint64_t ou verificação de tags) não introduziram sobrecarga significativa de desempenho e, em alguns casos (como a verificação de tags no GC), melhoraram a precisão e a segurança.

5. Significância

Este trabalho é fundamental para a adoção do CHERI em sistemas de linguagem complexos:

1. Guia Prático: Preenche a lacuna entre guias gerais de programação CHERI e as necessidades específicas de implementadores de VMs, documentando armadilhas sutis que não são óbvias para desenvolvedores de C tradicional.
2. Segurança vs. Compatibilidade: Demonstra que é possível portar VMs complexas mantendo a segurança do CHERI sem sacrificar drasticamente o desempenho, desde que se evitem comportamentos indefinidos do C.
3. Futuro da Segurança de Memória: As lições aprendidas ajudam a orientar o desenvolvimento de futuras VMs e runtimes que sejam nativamente seguros por construção, utilizando as capacidades de hardware para prevenir vulnerabilidades de memória que são comuns em sistemas legados.

Em resumo, o paper estabelece que a portabilidade de VMs para CHERI é viável, mas exige uma reavaliação rigorosa das suposições sobre a semântica de ponteiros e inteiros na linguagem C, oferecendo um roteiro claro para engenheiros de compiladores e desenvolvedores de runtimes.