Proposto há alguns anos o Kernel Address Space Isolation (KASI/ASI) tem como principal objetivo limitar vazamentos de dados com o crescente número de ataques de execução especulativa em CPUs. E são os próprios engenheiros do Google defendem Linux “ASI” para lidar melhor com ataques de execução especulativa
Várias organizações estiveram envolvidas nos esforços de isolamento de espaço de endereço para o kernel Linux, incluindo IBM, Oracle e Google com várias abordagens. Os engenheiros do Google publicaram no início deste ano uma nova iteração de ASI focada no uso de KVM para a nuvem/VMs.
A ASI ainda não chegou ao kernel da linha principal, mas os engenheiros do Google esta semana na LPC argumentaram que deveria ser o caminho a seguir para a linha principal para lidar melhor com essas vulnerabilidades de segurança da CPU.
Como vimos apenas ataques de execução mais especulativos com o tempo (e nenhum sinal de que eles vão acabar) e cada nova vulnerabilidade exigindo recursos e testes significativos de engenharia, os engenheiros do Google que optam pela rota de isolamento de espaço de endereço podem ser mais robustos e levar a tempos de resposta mais rápidos em mitigações e menos custoso para o desempenho.
Engenheiros do Google defendem Linux “ASI” para lidar melhor com ataques de execução especulativa
Da opinião do Google sobre o ASI no início deste ano com seus patches “RFC” personalizados para KVM:
O Address Space Isolation é uma mitigação de segurança abrangente para vários tipos de ataques de execução especulativa. Mesmo que o kernel já tenha várias mitigações de vulnerabilidade de execução especulativa, algumas delas podem ser bastante caras se ativadas totalmente, por exemplo, para mitigar totalmente o L1TF usando os mecanismos existentes, é necessário fazer uma limpeza de cache L1 em cada entrada da VM, bem como desabilitar o hyperthreading completamente.
Notícias Relacionadas
Inovação tecnológica
OpenAI pode desafiar o Google com navegador próprio
OpenAI, criadora do ChatGPT, pode lançar um navegador com integração ao chatbot, desafiando o domínio do Google no mercado de buscas e navegadores.
Estratégia confusa
Google cancela Pixel Tablet 3 e redesenha sua estratégia
Google cancela o Pixel Tablet 3 e redireciona equipes para outros projetos, sugerindo uma nova abordagem tecnológica.
(Embora o agendamento do núcleo possa fornecer alguma proteção quando o hyperthreading está habilitado, ele não é suficiente por si só para proteger contra todos os vazamentos, a menos que o atordoamento do hyperthread irmão também seja executado em cada saída de VM.) ASI fornece uma mitigação muito mais barata para essas vulnerabilidades enquanto ainda fornece um nível de proteção quase semelhante. Dado isso, a ideia de usar ASI para impedir ataques especulativos é que podemos executar o kernel usando um conjunto restrito de tabelas de páginas na maioria das vezes e alternar para o espaço de endereço do kernel irrestrito completo somente quando o kernel precisar acessar algo que não é mapeado no espaço de endereço restrito. E acompanhamos quando uma mudança para o espaço de endereço do kernel completo é feita, para que, antes de retornar ao processo/VM, possamos voltar ao espaço de endereço restrito. Nos caminhos em que o kernel é capaz de executar inteiramente enquanto permanece no espaço de endereço restrito, podemos pular outras mitigações para ataques de execução especulativa (como descargas de buffer de cache L1/micro-arch, atordoamento de hyperthread irmão etc.).
Apenas nos casos em que acabamos mudando as tabelas de páginas, realizamos essas mitigações mais caras. Supondo que isso aconteça com pouca frequência, o desempenho pode ser significativamente melhor em comparação com a execução dessas mitigações o tempo todo.
Junaid Shahid e Ofir Weisse, ambos do Google, usaram a Linux Plumbers Conference esta semana em Dublin para tentar despertar um interesse renovado em adotar o Address Space Isolation.
Não apenas o ASI deve significar menos degradação do desempenho, mas a correção de novas vulnerabilidades deve significar menos alteração de código/recursos de engenharia necessários.
Mas um dos desafios com o próprio ASI é que ele toca em muito código de kernel de baixo nível para entrar no lugar. Com o ASI tocando no gerenciamento de memória, no tratamento de interrupções, no hipervisor (KVM), etc., a ativação inicial do ASI é invasiva. O ASI também precisará provar que pode ser tão seguro quanto as técnicas de mitigação existentes, porém mais caras.
Mas pelo menos os engenheiros do Google acreditam que o ASI pode ser tão eficaz quanto as técnicas de mitigação existentes, ao mesmo tempo em que induz menos sobrecarga.
Resta saber se/quando o isolamento de espaço de endereço estaria em uma forma boa o suficiente para o kernel da linha principal, pelo menos para uso do hipervisor KVM. Com os recursos do Google, veremos se isso pode acontecer mais cedo ou mais tarde ou se serão necessários mais alguns ataques de execução especulativos com maior degradação do desempenho antes de serem empurrados. Aqueles que desejam saber mais sobre o trabalho ASI atual do Google para Linux podem ver este conjunto de slides e a apresentação LPC 2022 incorporada abaixo.
