Quando a vulnerabilidade de segurança Retbleed foi introduzida no início deste ano, mitigá-la para Intel Skylake e núcleos de CPU derivados de Skylake exigiu a imposição de Indirect Branch Restricted Speculation (IBRS) que prejudicou ainda mais desempenho de caixa para essas CPUs Intel antigas. Mas sendo introduzida agora com o Linux 6.2 está uma nova técnica de mitigação chamada Call Depth Tracking que está ajudando a recuperar parte do desempenho perdido e, por sua vez, estendendo a utilidade dos processadores derivados do Skylake ainda em serviço.
Call Depth Tracking foi trabalhado nos últimos meses por desenvolvedores de kernel Intel e Linux para evitar a necessidade de IBRS para projetos de CPU baseados em Skylake/Skylake na mitigação de Retbleed. Os desenvolvedores do kernel chamaram o IBRS de”show de terror de desempenho”, os engenheiros da VMware reclamaram da perda de desempenho e foi apenas mais um golpe de desempenho doloroso para a velocidade imediata desses processadores Intel da geração anterior.
Call Depth Tracking foi mesclado para o ciclo de kernel Linux 6.2 atualmente em desenvolvimento. Embora com Linux 6.2 a mitigação IBRS ainda seja o padrão para CPUs Skylake, mas o Rastreamento de Profundidade de Chamada quando integrado ao kernel pode ser facilmente ativado com a opção de inicialização”retbleed=stuff”.
Para ver como Profundidade de Chamada O rastreamento (retbleed=stuff) afeta o desempenho do Skylake Linux, executei alguns novos benchmarks de mitigação no kernel Linux 6.2 Git. A partir do kernel Linux 6.2 Git em um servidor Xeon E3-1280 v5 (Skylake), testei as seguintes configurações de kernel:
Padrões-O servidor E3-1280 v5 Skylake executando seu configuração de estoque pronta para uso com todas as atenuações padrão. Mitigar o Retbleed por padrão ainda está ativando o IBRS.
retbleeed=stuff-Mitigando o Retbleed usando o novo mecanismo de preenchimento (Call Depth Tracking).
retbleed=off-Apenas desabilitando as mitigações Retbleed, mas deixando todas as outras mitigações de segurança da CPU em seus padrões.
mitigations=off-Nenhuma mitigação de segurança da CPU ativada em tempo de execução para este servidor Skylake.
A partir daí, uma variedade de benchmarks do Linux foram realizados para ver o que isso significa sobre o desempenho do Linux no hardware da era Intel Skylake, agora que o Call Depth Tracking está disponível para ainda mitigar contra Retbleed, mas a um custo menor.
Logo de cara, com o benchmark PostMark I/O, houve uma clara melhoria com retbleed=stuff em relação ao desempenho padrão do kernel pronto para uso em que o IBRS é ativado em Skylake. O Call Depth Tracking rendeu uma melhoria de 24% em relação ao desempenho padrão no PostMark, mas ainda assim o modo Call Depth Tracking teve cerca de 84% de desempenho em execução sem nenhuma atenuação de Retbleed ou 69% de desempenho ao executar o sistema sem nenhuma atenuação de segurança da CPU.
Para o benchmark de API de soquete de rede Sockperf, também houve benefício claro para o Call Depth Tracking sobre o desempenho padrão no Linux 6.2, mas ainda assim todas as outras mitigações incorrem em sobrecarga significativa.
Mas se agora você está executando o Linux pronto para uso em um sistema da era Skylake e usando as mitigações de segurança padrão que impõem o IBRS, com a mudança do Linux 6.2+ para o Call Depth Tracking pode pelo menos recuperar parte desse desempenho perdido.
A operação retbleed=stuff também estava ajudando com as cargas de trabalho OpenJDK Java na recuperação da penalidade de desempenho IBRS neste servidor Xeon Skylake.
Em uma ampla variedade de cargas de trabalho, a mitigação do Call Depth Tracking foi mostrar em g para ser claramente menos impactante do que a mitigação IBRS padrão para Retbleed.
Para várias cargas de trabalho de servidor Linux neste sistema Intel Xeon E3-1280 v5, a execução com rastreamento de profundidade de chamada forneceu um aumento de desempenho (retbleed=stuff) sobre as mitigações de estoque, mas ainda há um custo alto com as outras mitigações de segurança da CPU envolvidas.
A diferença do Call Depth Tracking claramente diminui nos micro-benchmarks do kernel stress-ng.
O tempo de troca de contexto é muito menor com Rastreamento de Profundidade de Chamada do que ter IBRS para Retbleed.
Se você ainda está contando com um processador derivado de Skylake/Skylake que agora é padronizado para IBRS para combater Retbleed, o Call A mitigação do Depth Tracking disponível no Linux 6.2+ pela opção retbleed=stuff claramente é capaz de ajudar a recuperar parte do desempenho perdido. Concedido, ainda há uma sobrecarga significativa das outras mitigações de segurança da CPU necessárias para as CPUs Intel mais antigas, mas pelo menos é uma melhoria notável em relação ao status quo. Particularmente para os servidores Intel Linux da era Skylake, onde os padrões de segurança são particularmente necessários, o Call Depth Tracking pode ajudar a dar um pouco mais de vida às plataformas até a atualização do hardware.
Ao obter a média geométrica entre as cargas de trabalho afetadas, alternar de o kernel Linux 6.2 pronto para uso para inicializar com retbleed=stuff aumentou o desempenho em 15%. Mas o Call Depth Tracking (retbleed=stuff) estava rodando a 89% da velocidade de simplesmente não ter mitigações Retbleed (retbleed=off) ou 71% do desempenho do servidor Xeon E3-1280 v5 onde todas as mitigações de segurança da CPU foram desativadas (mitigações=desligado).