Os engenheiros da Red Hat estão trabalhando para lidar com a Especulação Restrita de Filial Indireta (IBRS), que é muito cara para mitigar o Spectre V2 e o Retbleed em processadores Intel Xeon Scalable mais antigos. Um novo patch foi lançado para desabilitar o IBRS quando ocioso e está funcionando bem pelo menos para o Red Hat Enterprise Linux 9, embora ainda não esteja claro se ele será aceito no kernel upstream.
O patch de Waiman Long, da Red Hat, explica os problemas que eles ainda enfrentam em relação ao Intel IBRS para lidar com Spectre e Retbleed:
Para processadores Intel que precisam ativar o IBRS para proteção contra Spectre v2 e Retbleed, o bit IBRS no SPEC_CTRL MSR afeta o desempenho de todo o núcleo, mesmo que apenas um thread o esteja ativando ao executar no kernel. Para aplicativos com uso intenso de espaço do usuário, o impacto no desempenho de ocasionalmente ativar o IBRS durante syscalls não deve ser significativo. Infelizmente, esse não é o caso quando a thread irmã está ociosa no kernel. Nesse caso, o impacto no desempenho pode ser significativo.
Quando o DPDK está sendo executado em um thread isolado da CPU processando pacotes de rede no espaço do usuário enquanto seu thread irmão está ocioso. O desempenho do encadeamento DPDK ocupado com IBRS ativado e desativado no encadeamento ocioso irmão é:
IBRS on IBRS desativado
—————
pacotes/segundo: 7,8M 10,4M
ciclos tsc médios/pacote: 282,26 209,86
Esta é uma degradação de desempenho de 25%. O sistema de teste é uma CPU Intel Xeon 4114 @ 2,20 GHz.
Esta série de patches desativa o IBRS quando em vários modos ociosos para eliminar o impacto no desempenho do encadeamento ocioso em seu encadeamento irmão ocupado.
Ouch, um hit de 25% no Xeon Scalable Skylake para o Data Plane Development Kit (DPDK) de código aberto.
Existe este thread do kernel onde o patch para desabilitar o IBRS quando ocioso está sendo lançado. O proeminente engenheiro da Intel Linux, Peter Zijlstra, sugeriu outro patch que atualmente não é portado para RHEL9. Além disso, a possibilidade de usar Call Depth Stuff/Tracking em vez de IBRS. Em meus testes, o Call Depth Tracking encontrado no Linux 6.2+ da linha principal está realmente oferecendo para ajudar a recuperar algum desempenho perdido nas CPUs da era Intel Skylake que, de outra forma, dependem do IBRS. Portanto, veremos para onde vai a atividade upstream do kernel ou se a Red Hat acaba carregando apenas esse patch como parte de seu kernel RHEL9 por enquanto até o back-porting de quaisquer novas opções. De qualquer forma, este último tópico da lista de discussão do kernel continua a mostrar as dores de mitigação ainda experimentadas pelos usuários corporativos do Linux em meados de 2023 em plataformas mais antigas.