… de microcódigo de processadores x86! A partir do momento em que as CPUs passaram a sofrer com várias vulnerabilidades recém- descobertas, passei a acompanhar mais de perto o desenvolvimento das soluções designadas para corrigir e/ou mitigar estes problemas, bem como o suporte para os sistemas GNU/Linux. Dentre elas, as que me chamaram mais a atenção são as atualização do microcódigo das CPUs, que por sua vez são responsáveis pela tradução das instruções de alto nível dos sistemas (software), para o processamento das CPUs (hardware)…
“Via tip.git’s x86/microcode branch is an initial batch of x86 microcode handling improvements for the Linux kernel. The patches remove some useless mutexes, dropping some old debug code, and also make it now that CPU microcode loading support is no longer an option on x86-based systems but is always enabled. With any “reasonable configuration” needing microcode loading support on Intel and AMD systems, the option is now always enabled.”
— by Phoronix.
Estas instruções podem ser atualizadas de duas maneiras: através do BIOS/UEFI (se o firmware ofereça suporte para estas operações) ou a partir dos sistemas operacionais. No caso do Linux, os engenheiros da Intel estão trabalhando para aprimorar as experiências de atualização de suas CPUs x86 no kernel Linux, além de melhorar o suporte para o carregamento tardio (feito após a inicialização do sistema). Dentre as melhorias promovidas, estão a remoção de alguns mutexers inúteis e a eliminação de alguns códigos de depuração antigos (especialmente para as antigas CPUs x86 de 32 bits), além de outras pequenas melhorias.
Estas mudanças farão parte do próximo ciclo do kernel Linux 6.6 e são designadas para servidores e usuários corporativos. Elas receberam uma atenção especial por parte dos engenheiros da Intel, em vista dos problemas inerentes ao carregamento tardio para as atualizações de microcódigo, tornando possível estas alterações afetar algum recurso que já está sendo usado e/ou acessado pelo próprio kernel. Por isto, foi adicionado recentemente um novo campo de cabeçalho, que contém a revisão mínima do microcódigo que deve estar em execução na CPU: caso este valor seja 0 (indicando revisões mais antigas), o kernel então irá assumir como inseguros, rejeitando o seu carregamento e evitando corrupções.
Infelizmente, tais mudanças não resolvem outros problemas conhecidos pela utilização do carregamento tardio. Dentre eles, um dos que mais me chamaram a atenção foi a falta de segurança em relação ao NMI (interrupção de hardwre que não pode ser ignorada, para sinalizar erros de hardware), quando o hyper-threading (HT) está ativo. E sabendo que as próximas gerações de processadores da Intel não terão mais suporte para a tecnologia HT, eis a questão: isto foi planejado, já considerando os impactos positivos em relação aos problemas do carregamento tardio? Não sei dizer…
Mas como dizia o trocadilho ditado: “antes tarde, do que nunca”… &;-D