Parece que o patch emitido pela AMD para o bug “Divisão por zero” do Zen 1 não foi o fim de tudo, tudo o que a empresa queria que fosse. Embora a empresa tenha lançado rapidamente um patch, agora há a suspeita de que eles podem ter sido um pouco rápidos demais: de acordo com Michael Larabel da Phoronix, o engenheiro de Linux da AMD Borislav Petkov publicou um novo patch que corrigiu um problema com a solução original (também publicado por ele). É apenas mais um ponto de dados sobre as dificuldades de proteção contra possíveis vetores de ataque.
O bug original estava relacionado a como o Zen 1 processava um cálculo inteiro dividido por 0 em certas circunstâncias: de acordo com as descobertas, havia a possibilidade de que a CPU da AMD mantivesse “dados de quociente obsoletos” em seus registros mesmo depois que a operação fosse totalmente concluída, o que poderia dar aos invasores uma janela para recuperar informações confidenciais. A solução original era executar uma “divisão fictícia 0/1 final antes de retornar do manipulador de exceção #DE”. A ideia é simples: quaisquer dados antigos ainda armazenados seriam apagados após a conclusão da divisão 0/1 (cujo resultado é sempre, bem, zero).
O problema com essa solução, como explicou Petkov, era que, quando a provisão de segurança entrasse em ação, o ataque de execução especulativa já teria avançado demais: já haveria uma certa quantidade de dados antigos no divisor da AMD, que os invasores poderiam obter antes que a divisão fictícia entrasse em ação. Como Petkov explicou, sua nova solução agora força a mesma divisão em vários cenários:
“Inicialmente, pensou-se que fazer uma divisão inócua no manipulador #DE tomaria cuidado para evitar qualquer vazamento de dados antigos do divisor, mas no momento em que a falha é levantada, a especulação já avançou demais e esses dados já poderiam têm sido usados por operações mais jovens.
Portanto, faça a divisão inócua em cada saída para o espaço do usuário para que o espaço do usuário não veja nenhum dado potencialmente antigo de divisões inteiras no espaço do kernel.
Faça o mesmo antes do VMRUN também, para evitar que os dados do host vazem para o convidado também.”
Já foi um mês agitado para vulnerabilidades no domínio da CPU, com AMD e Intel tendo sido atingidas por divulgações. Desde a vulnerabilidade Downfall mais extrema da Intel (afetando Skylake até Tiger Lake/Rocket Lake) até as vulnerabilidades SQUIP e Inception da AMD (e a agora corrigida vulnerabilidade “dividir por zero”, os pesquisadores têm trabalhado duro. Ainda não se compara a a história histórica dos dias Meltdown e Spectre (embora esses novos bugs também estejam relacionados a vulnerabilidades de execução especulativa. Execução especulativa refere-se à maneira como as CPUs modernas tentam antecipar as etapas de cálculo antes mesmo de se tornarem necessárias, para que os dados necessários sejam já disponível no caso de ser chamado para a execução.No entanto, embora as correções para algumas dessas vulnerabilidades tenham acarretado (às vezes severas) penalidades de desempenho, é pelo menos um bom sinal de que a divisão fictícia 0/1 da AMD não vem com sobrecarga adicional.
Ao mesmo tempo, é animador ver que, pelo menos neste caso, o patch de segurança não foi emitido de uma maneira “configure e esqueça” – com o tipo de trabalho de carrossel que os especialistas da equipe azul tem que carregar, havia outras maneiras pelas quais isso poderia ter acontecido (acreditava-se que o patch deficiente funcionaria totalmente, deixando a porta aberta para novas explorações de hacking no caminho (com qualquer impacto que isso pudesse causar).