Proposto há alguns anos foi o Kernel Address Space Isolation (KASI/ASI) para limitar vazamentos de dados com o crescente número de ataques de execução especulativa em CPUs. 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 do 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 só vimos ataques de execução mais especulativos com o tempo (e nenhum sinal de que eles vão acabar) e cada nova vulnerabilidade que exige recursos de engenharia e testes significativos, 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 nas mitigações e menos dispendiosos para o desempenho.
Da opinião do Google sobre o ASI no início deste ano com seus patches”RFC”adaptados para KVM:
O isolamento de espaço de endereço é 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 vulnerabilidades 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 completamente o hyperthreading. (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 tais vulnerabilidades enquanto ainda fornece um nível de proteção quase semelhante.
…
O isolamento de espaço de endereço é 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 vulnerabilidades 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 completamente o hyperthreading. (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.
Junaid Shahid e Ofir Weisse, ambos do Google, usaram a Linux Plumbers Conference esta semana em Dublin para tentar angariar um interesse renovado em ir para o Address Space Isolation.
O ASI não deve apenas significar menos degradação de 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, induzindo 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 atual de ASI do Google para Linux podem ver este conjunto de slides e a apresentação LPC 2022 incorporada abaixo.