Em março, foi divulgado o ataque LVI (Load Value Injection) afetando as CPUs Intel. A mitigação do LVI requer alterações na cadeia de ferramentas do compilador e o LLVM 11 mesclou sua mitigação no LVI no mês passado, adicionando uma barreira de carga após cada instrução que possa estar vulnerável a esse ataque, semelhante às alterações do GNU Assembler. Agora, embora o LLVM esteja adicionando uma versão não otimizada do passe LVI.
As mitigações existentes do LVI nos lados do GNU e LLVM já possuem alguma sobrecarga de desempenho envolvida como resultado das LFENCEs adicionadas. Então, por que uma versão não otimizada agora está sendo adicionada como outra opção ao LLVM? Acontece que a versão (otimizada) adicionada é muito prejudicial para os tempos de compilação / compilação, onde, com essa versão menos otimizada, o código pode compilar mais rapidamente, portanto, é menos uma regressão de compilação.
Esta versão não otimizada do LVI, por sua vez, deve ser usada ao compilar código no nível de otimização -O0 .... Para os níveis mais altos de otimização ou quando não se preocupa com o tempo de compilação, a versão otimizada existente se destina ao passar o sinalizador apropriado.
Essa versão não otimizada decorre do fato de que a complexidade adicional do reforço da Injeção de Valor de Carga estava causando lentidão notável nas compilações -O0. Um exemplo citado foi o SQLite construindo 1,5% mais lento com o endurecimento do LVI. Foi discutido para desativar o reforço de carga do LVI em -O0, mas foi decidido ficar do lado da segurança ao desativar o referido reforço.
Então foi fundida no dia 10 esta versão unoptimized que tem " propriedades de segurança iguais, mas sem qualquer otimizações (e mais importante, sem a necessidade de dependências análise caros). " Será interessante agora ver a mitigação vs. padrão absoluto vs. mitigação unoptimized desempenho para binários relacionados à injeção de valor de carga. Com -O0 usado principalmente para compilações de depuração / teste, pelo menos os usuários finais não devem ser afetados por essa passagem não otimizada, mas isso tornará os binários já otimizados sem menos ainda mais lentos para esses fins.
Até a próxima !
Nenhum comentário:
Postar um comentário