Engenheiros do Google defendem Linux "ASI" para lidar melhor com ataques de execução especulativa

(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.