Nos últimos anos, o surgimento constante de vulnerabilidades no nível do hardware, como Heartbleed, Spectre, Rowhammer e muitas outras, colocou todos os fabricantes de CPUs sob escrutínio. Nenhuma família de chips ou arquitetura — seja Intel, AMD ou ARM — se mostrou imune a essas explorações.
A equipe de desenvolvimento do kernel do Linux reagiu com rapidez e dedicação impressionantes, corrigindo vulnerabilidades e oferecendo soluções alternativas. No entanto, o custo dessas medidas de mitigação costuma prejudicar o desempenho.
Já faz pouco mais de um ano desde que discutimos esse assunto em nosso blog. Você pode conferir o artigo anterior aqui, já que ele ainda é relevante – mas a história está longe de terminar.
Medidas de mitigação: uma faca de dois gumes
Embora os patches protejam os sistemas contra vulnerabilidades devastadoras, a perda de desempenho costuma ser inevitável. Por exemplo, vulnerabilidades de execução especulativa, como Meltdown e Spectre, levaram a reduções no desempenho da CPU de até 30% em alguns casos, dependendo da carga de trabalho e da arquitetura.
Medidas de mitigação, como desativar o hyper-threading, implementar barreiras de memória adicionais ou aumentar a sobrecarga no acesso à memória, foram implementadas, mas prejudicam o desempenho da CPU de forma tão significativa que os usuários podem perceber que suas CPUs de ponta e de última geração apresentam desempenho comparável ao de hardware de gerações anteriores.
A frustração, tanto dos usuários finais quanto dos desenvolvedores, vem aumentando. Até mesmo Linus Torvalds expressou grande frustração com a situação dos bugs de hardware. Em suas declarações recentes, ele lamentou o fardo cada vez maior de ter que compensar as implementações falhas dos fornecedores. Desta vez, suas observações foram direcionadas aos patches propostos para proteger operações de cópia de memória – que, teoricamente, poderiam ser exploradas. Anteriormente, ele já havia se desviado do roteiro ao falar sobre fTPM da AMD, um Trusted Platform Module baseado em hardware, que tem enfrentado problemas de desempenho e bugs. Os usuários enfrentam lentidão, o que causa interrupções nas atividades diárias e torna inúteis as caras atualizações de hardware. Há uma série de outras situações em que a equipe do Kernel se mobilizou para resolver problemas no nível do hardware, e, desta vez, Linus parece estar adotando uma abordagem diferente – deixar que as empresas de hardware consertem suas próprias falhas (ou seja, criar produtos melhores).
De certa forma, isso é compreensível — quando seu sistema Linux perde desempenho repentinamente, é tão provável que você culpe o sistema operacional quanto o hardware, mesmo que o sistema operacional, na verdade, não tenha nenhum problema. Mas também é importante levar em conta que bugs no nível do hardware nem sempre podem ser resolvidos com uma atualização de microcódigo. Alguns problemas decorrem de decisões arquitetônicas inadequadas que só poderão ser revertidas daqui a 3 ou 4 anos. E, enquanto isso, seus sistemas ficam em risco. Ou será que não? Outro ponto que o incomoda, mencionado em seu desabafo, é que a maioria dessas vulnerabilidades nunca se materializou totalmente em exploits aptos para produção e permanece como um exercício puramente teórico. Mas o impacto das medidas de mitigação é, sem dúvida, muito real.
A realidade das vulnerabilidades modernas dos processadores
As falhas de segurança de hardware evoluíram de afetar apenas algumas unidades para impactar praticamente todas as CPUs modernas. Vulnerabilidades como Spectre, Meltdown, Foreshadow e Lazy FPU demonstram a profundidade desses problemas. Os projetos complexos das CPUs modernas muitas vezes resultam em vulnerabilidades que não são apenas difíceis de corrigir, mas que, quando corrigidas, levam a uma degradação perceptível no desempenho.
A tabela abaixo ilustra o impacto no desempenho de vulnerabilidades comuns da CPU e as medidas de mitigação aplicadas por diferentes fornecedores:
| Vulnerabilidade | CPUs afetadas | Impacto no desempenho | Mitigação | Perda de desempenho (aprox.) |
| Spectre/Meltdown | Intel Core, AMD Ryzen | Grave | Atualizações de microcódigo | 10% a 30% (varia de acordo com a carga de trabalho) |
| FPU preguiçosa | Processadores Intel x86 | Moderado | Atualizações de microcódigo | 5% a 10% |
| Prelúdio | Intel Core | Alto | Desativação de recursos | Até 30% |
| Rowhammer | Memória DDR | Grave | ECC, correções de software | Mínimo em alguns casos, perceptível em outros |
| Heartbleed | Várias arquiteturas | Insignificante (CPU) | Aplicação de correções em bibliotecas | Insignificante |
Um futuro de concessões?
A queda no desempenho resultante das medidas de mitigação de vulnerabilidades da CPU leva a uma constatação desagradável: atualizar para a geração mais recente de hardware pode não valer a pena se a vantagem de desempenho na prática for anulada pelos patches de segurança necessários. Muitos usuários, especialmente aqueles que precisam de desempenho consistente — como gamers, profissionais de mídia ou operadores de servidores —, percebem que seu hardware caro tem seu desempenho prejudicado por correções de segurança que não podem ser evitadas.
O equilíbrio entre segurança e desempenho está se tornando cada vez mais precário. Até que os fornecedores consigam desenvolver arquiteturas resistentes a esses ataques sofisticados, os usuários finais são obrigados a fazer uma escolha difícil: segurança em detrimento do desempenho. Enquanto isso, parece que a comunidade Linux, sob a liderança de Torvalds, continuará travando essa batalha justa em um mundo de “hardware burro”.
Vulnerabilidades de hardware continuam surgindo e, embora desenvolvedores de kernel, como a equipe do Linux, trabalhem incansavelmente para mitigá-las, o preço a pagar é o desempenho. Para quem investe em hardware de última geração na esperança de obter um aumento significativo de desempenho, a realidade é desanimadora. Até que os fabricantes de CPUs consigam corrigir essas falhas no nível do hardware, atualizar seu sistema pode não ser tão vantajoso quanto costumava ser.

