A perda de desempenho universal causada pela vulnerabilidade do GhostRace
Parece que não há mês em que as vulnerabilidades não sejam detectadas. Além disso, nos últimos tempos, a maioria está sendo por gravidade. Projetar um processador completamente seguro é impossível, todos nós sabemos disso, mas embora as vulnerabilidades sejam um problema que normalmente tem solução, essa resposta para acabar com a insegurança geralmente traz uma penalidade de desempenho. GhostRace não parece ser exceção, e o problema é que afeta toda a CPU e sistema operacional, pois ataca a chamada Speculative Race Conditions (SRC).
À luz das informações fornecidas no âmbito do impacto da vulnerabilidade, pode-se inferir que uma extensa gama de processadores contemporâneos que suportam execução especulativa são suscetíveis a ataques. Isto abrange a grande maioria dos sistemas existentes, estando apenas os computadores pessoais excepcionalmente antigos isentos desta classificação.
Execução especulativa mais uma vez no centro das atenções na segurança da CPU
A vulnerabilidade foi descoberta pelo grupo VUSec da VU Amsterdam e pela IBM, através de Hany Ragab, Cristiano Giuffrida, Andrea Mambretti e Anil Kurmus. Mais uma vez, outra vulnerabilidade ataca a chamada execução especulativa, e já temos experiência de todas aquelas que surgiram, sendo a mais popular provavelmente Spectre V1.
A execução especulativa refere-se a uma abordagem centrada em hardware empregada em unidades centrais de processamento (CPUs) para aumentar a eficiência por meio da otimização proativa das operações. Este processo envolve aproveitar recursos ociosos para executar tarefas simultaneamente antes de sua demanda real, melhorando assim a capacidade de resposta geral do sistema quando recursos adequados estão disponíveis.
Em outras palavras e simplificando, tente “prever” por especulação qual parte da CPU terá recursos disponíveis para movimentar a informação para trabalhar em direção a ela. O problema é que isso deixa rastros em registros, como acessos à memória ou cache, bem como em preditores de ramificações, e é justamente aí que estão as vulnerabilidades, para esses dados específicos.
GhostRace, a vulnerabilidade da qual ninguém escapa no setor: nem hardware nem software
O método utilizado já é conhecido, então iremos para a novidade e realmente interessante, que nada mais é do que como ele aproveita a lacuna que as CPUs deixam para obter as informações. Para acessar, o invasor utiliza chamadas SRC (Speculative Race Conditions) , que utilizam as primitivas de Sincronização de threads usando ramificações condicionais para fazer algo não visto até agora: **contornar microeletronicamente caminhos especulativos usando uma vulnerabilidade anterior.* *
E sim, esta vulnerabilidade é Spectre V1. Facilitando, pode-se dizer que se trata de uma vulnerabilidade que ataca através de outra vulnerabilidade que já foi corrigida anteriormente, contornando total ou parcialmente esse patch por meio do Sistema Operacional ou firmware (microcódigo).
Os invasores que exploram o Spectre V1 por meio do GhostRace verificam os limites de acesso à memória usando uma ramificação mal especulada pelo processador e conseguem acessar informações confidenciais. Os pesquisadores explicam assim:
Hardware: Confirmamos que todos os principais fornecedores de hardware são afetados por SRCs, pois, independentemente da implementação específica da instrução de comparação e troca, a ramificação condicional a seguir Está sujeita à previsão de ramificação (ruim). Em outros palavras, todas as microarquiteturas afetadas pelo Spectre-v1 também são afetadas pelo CRS.
Software: qualquer objetivo que dependa de ramificações condicionais para determinar se deve entrar nas críticas das regiões (um padrão de design comum que se estende muito além do Linux) é vulnerável a SRCs.
Resumindo, qualquer software, por ex. System Operational, hypervisor, etc. , que implementa a sincronização de primitivas através de ramificações condicionais sem nenhuma instrução de serialização nesse caminho e executa-a em qualquer microarquitetura (por exemplo, x86, ARM, RISC-V, etc ), que permite a execução especulativa de ramificações condicionais, é vulnerável a SRCs. Tal como acontece com outros ataques de execução especulativa, isso permite o vazamento de dados do software alvo.
AMD já confirmou que foi afetada, o resto, por enquanto, está em silêncio
amd foi o primeiro a confirmar que foi afetado, Linux Foundation e Red Hat também declararam que precisam corrigir seu hardware e software. Em troca, Amazon, Arm, Dell, Google, IBM, Intel, Linux Kernel e Xen ainda não se manifestaram.
A lógica por trás desta situação é bastante simples. Sempre que se possui evidências empíricas juntamente com microcódigo atualizado para plataformas Linux e Microsoft, torna-se imperativo expressar tais descobertas. No entanto, a situação surge do facto de que identificar o problema não implica necessariamente ter uma resolução em mãos. Embora a AMD, entre outras, possa parecer tranquila em meio a essa incerteza, ela continua sendo uma preocupação urgente.
A AMD sugere aderir às recomendações estabelecidas relativas aos ataques Spectre, conforme descrito em publicações anteriores.
A AMD acredita que a orientação acima ainda aplicável para mitigar esta vulnerabilidade.
Dito isto, quanto custa esta nova vulnerabilidade em termos de desempenho? Bem, as primeiras estimativas do Linux afirmam que é mais de 5% aproximadamente , independentemente de a CPU ser Intel, AMD ou Arm. Portanto, já temos a primeira informação chave, que agora tem que ser recolhida e testada em sistemas Microsoft, porque normalmente no Windows o número aumenta um pouco.
O lançamento antecipado de patches para o kernel do Linux, Windows Update e atualizações do BIOS incorporando microcódigo atualizado é iminente, embora datas específicas ainda não tenham sido fornecidas.
*️⃣ Link da fonte:
o grupo VUSec da VU Amsterdã e da IBM , todo mundo quer falar quando tem dados em mãos , os vermelhos colocam um pouco de calma: , https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/software-techniques-for-managing-speculation.pdf,