Resumo Técnico: Modelo de Programação e Compartimentação Universal para a Extensão de Sobreposição de Permissões Arm 2

Declaração do Problema

A Extensão de Sobreposição de Permissões (POE) da Arm e o Intel Memory Protection Keys (MPK) oferecem isolamento intra-processo ao particionar a memória virtual em regiões com permissões de acesso reconfiguráveis, evitando o overhead de desempenho de trocas de contexto mediadas pelo kernel. No entanto, esses mecanismos (especificamente o POE1) carecem de separação de privilégios dentro dos compartimentos, permitindo que o código executando em um domínio de proteção modifique os direitos de acesso de outros domínios (por exemplo, via wrpkru ou POR_ELx), tornando-os adequados apenas para isolamento de falhas de software, e não para isolamento de segurança contra código adversário.

A nova extensão POE2 da Arm aborda isso introduzindo separação de privilégios por meio de um modelo de permissão multidimensional envolvendo índices espaciais (chaves de proteção/POIndex) e índices temporais (estado da thread/TIndex). Embora o POE2 forneça garantias de segurança mais fortes, ele introduz uma complexidade arquitetônica significativa. As permissões efetivas são determinadas pela interação de múltiplos componentes de hardware (Tabela de Região de Instrução, Tabela de Sobreposição de Permissão de Dados, Tabela de Transição de TIndex, etc.), tornando a programação direta propensa a erros e não trivial. Além disso, o POE2 carece de um modelo de programação explícito, deixando os desenvolvedores responsáveis por gerenciar manualmente complexas transições de estado e configurações de tabelas.

Metodologia

O artigo propõe um Modelo de Programação Universal centrado em uma nova abstração chamada Complet (um applet compartimentado) e um componente Monitor privilegiado.

1. Abstração (Complets): Um Complet é um binário isolado e mutuamente desconfiado que não pode acessar a memória de outros Complets diretamente. Ele mapeia para uma combinação única de POIndex e TIndex.
2. Orquestração (Monitor): Um componente confiável e privilegiado dentro do processo, responsável pelo ciclo de vida dos Complets. O Monitor:
   • Implanta e vincula binários a regiões de memória distintas.
   • Configura as tabelas do POE2 (IRT, DPOT, TTT) para definir permissões.
   • Media a comunicação via Trampolins Confiáveis (Trusted Trampolines).
3. Transições Seguras: Para evitar que o código não confiável realize um salto para endereços arbitrários dentro de uma região permitida (um risco fundamental no POE2), o modelo impõe transições através de trampolins estateless (sem estado) e mínimos.
   • Um Complet salta para um trampolim (um POIndex específico).
   • O trampolim executa uma instrução TCHANGE para alternar o índice temporal (TIndex).
   • O trampolim então salta para a função alvo do Monitor ou para outro Complet.
   • Este processo de dois passos (Branch -> TCHANGE -> Branch) garante que o fluxo de controle não possa ser sequestrado para endereços indesejados em um único passo.
4. Premissas de Segurança: O modelo assume que o código do Complet é adversário e pode conter gadgets ROP. O Monitor e seus trampolins são confiáveis e livres de bugs. O kernel é confiável.

Principais Contribuições

O artigo apresenta três contribuições primárias:

1. Visão Geral do POE2: Uma análise detalhada do POE2 para o Nível de Exceção 0 (EL0), incluindo suas novas instruções, registradores (TINDEX) e tabelas de memória (IRT, DPOT, TTT).
2. Análise de Segurança: Uma identificação dos riscos de transição no POE2, especificamente a incapacidade de os chamadores controlarem totalmente o fluxo de controle de partes mutuamente desconfiadas sem estados intermediários confiáveis. Demonstra que transições seguras requerem elementos confiáveis (trampolins) para garantir o pouso nos pontos de entrada pretendidos.
3. Modelo de Programação Universal: A introdução da abstração Complet e da arquitetura Monitor, que abstrai a complexidade dos índices espaciais e temporais. Este modelo suporta três padrões principais de isolamento intra-processo:
   • Isolamento Simétrico: Partes mutuamente desconfiadas trocando dados via memória compartilhada (ex: Hodor, IskiOS).
   • Isolamento Assimétrico (JIT): Separando código gerado não confiável de código de runtime confiável (ex: ERIM, Shreds).
   • Reverso-Sandbox estilo Enclave: Um componente isolado com acesso total ao host, enquanto o host tem acesso restrito ao enclave (ex: Intel SGX).

Resultados e Implementação

Os autores implementaram um protótipo do sistema de compartimentação em um modelo funcional (Arm FVP) e estenderam o kernel Linux com novas syscalls para gerenciar as tabelas do POE2 (aproximadamente 300 linhas de código).

• Overhead de Transição: Uma transição segura e unidirecional entre um Complet e o Monitor requer aproximadamente 75 instruções para armazenamento de contexto, carregamento e troca de domínio.
• Design do Trampolim: O trampolim confiável é minimalista (menos de 100 instruções em assembly) e stateless, reduzindo a superfície de ataque.
• Validação de Padrão: O protótipo demonstrou com sucesso a implementação dos padrões de design simétrico, assimétrico e estilo enclave usando a API proposta.

Significância e Alegações

O artigo afirma fornecer a primeira análise detalhada e um modelo de programação universal para o POE2, abordando a lacuna entre as complexas capacidades do hardware e a implementação prática de software.

• Segurança: O modelo impõe garantias de segurança fortes ao tratar o código isolado como hostil e utilizar trampolins confiáveis para prevenir o sequestro de fluxo de controle, uma vulnerabilidade inerente ao uso bruto do POE2.
• Usabilidade: Ao abstrair o espaço de índice multidimensional (POIndex/TIndex) na interface Complet, o modelo permite que desenvolvedores construam software particionado usando padrões padrão de isolamento intra-processo sem gerenciar diretamente as tabelas de baixo nível do hardware.
• Flexibilidade: A arquitetura suporta tanto modelos de segurança estritos (com isolamento total) quanto modelos mais fracos (transições diretas se o Monitor for assumido como livre de bugs), permitindo trocas entre segurança e desempenho.

Os autores observam que, embora a biblioteca sirva como uma prova de conceito, as características de desempenho reais dependem fortemente de futuras implementações microarquiteturais (cache de novas tabelas e registradores), e a avaliação de desempenho no mundo real é reservada para trabalhos futuros.