Devido à nova mitigação de segurança”Retbleed”prejudicar ainda mais o desempenho da CPU para os processadores afetados, os engenheiros da Intel revisitaram o trabalho de mitigação de rastreamento de profundidade de chamadas como uma alternativa à mitigação de especulação restrita de ramificação indireta (IBRS) para ajudar a reduzir os custos indiretos.
Thomas Gleixner, da Linutronix, que a Intel adquiriu no início deste ano, e o engenheiro de longa data da Intel, Peter Zijlstra, estão trabalhando em”retbleed=stuff”como uma nova abordagem de mitigação para Retbleed com rastreamento de profundidade de chamadas.
Esta nova abordagem de mitigação visa ter uma sobrecarga menor do que o uso do IBRS. Gleixner resumiu a situação neste fim de semana na lista de discussão do kernel:
De volta aos bons e velhos dias do espectro v2 (2018), decidimos não usar o IBRS. Em retrospectiva, esta pode ter sido a decisão errada porque não forçou as pessoas a apresentarem abordagens alternativas.
Já foi discutido na época tentar a contabilidade de profundidade de chamada baseada em software e o preenchimento de RSB no underflow para sistemas Intel SKL[-X] para evitar a sobrecarga insana do IBRS.
Isso foi tentado em 2018 e foi rejeitado devido à enorme sobrecarga e outras deficiências da abordagem para colocar a contabilidade em cada prólogo de função:
1) Aumento do tamanho do texto que é infligida a todos. Embora as CPUs sejam boas em ignorar NOPs, elas ainda poluem o I-cache.
2) Isso resulta em excesso de contas de chamadas finais que podem ser exploradas.
Desativar chamadas finais também não é uma opção e adicionar um preenchimento de 10 bytes na frente de cada chamada direta é ainda pior em termos de tamanho do texto e impacto do I-cache. Também poderíamos corrigir chamadas além da contabilidade no prólogo da função, mas isso se torna um pesadelo em relação ao ENDBR.
Como o IBRS é um show de horror de performance, Peter Zijstra e eu revisitamos a abordagem de rastreamento de profundidade de chamadas e a implementamos de uma maneira que esperamos ser mais palatável e evite as desvantagens da tentativa original.
Nós dois, sem surpresa, odiamos o resultado com paixão…
…
O rastreamento de profundidade de chamadas é projetado para quebrar esse caminho de especulação, colocando chamadas de armadilhas de especulação no RSB que nunca estão recebendo um retorno correspondente executado. Isso paralisa o caminho de previsão até que ele seja restabelecido,A suposição é que o preenchimento no 12º retorno é suficiente para quebrar a especulação antes que ela atinja o underflow e o fallback para os outros preditores. Os testes confirmam que funciona. Johannes, um dos pesquisadores de ressangramento. tentou atacar essa abordagem e confirmou que ela traz a relação sinal-ruído para o nível da bola de cristal.
Obviamente, não há prova científica de que isso irá resistir ao progresso de pesquisas futuras, mas tudo o que podemos fazer agora é especular sobre isso.
Seus benchmarks mostraram isso mitigação de rastreamento de profundidade de chamadas seja menor sobrecarga do que tomar a rota atual do IBRS. Gleixner comentou:”Assim, o benefício varia dependendo do hardware e dos cenários de carga de trabalho. Pelo menos não fica pior do que o IBeeRS.”
No momento, essa nova estratégia de mitigação é um conjunto de 38 patches agora em análise na lista de discussão. Na forma atual com esses patches, a abordagem de rastreamento de profundidade de chamada é ativada usando a opção de kernel”retbleed=stuff”. Os 38 patches somam quase duas mil linhas de novo código do kernel para lidar com esse pesadelo de segurança.
