Durante o processo de discussão do desenvolvedor do kernel linux sobre el tema de um conjunto de patches para corrigir vulnerabilidades de Spectre no código para trabalhar com listas encadeadas, ficou claro para muitos desenvolvedores que o problema poderia ser resolvido mais facilmente se foi permitido no código do kernel C que está em conformidade com uma versão mais recente do padrão.
E é que atualmente o código adicionado ao Kernel Linux deve estar em conformidade com a especificação ANSI C (C89), formada em 1989.
É por isso que o problema relacionado ao Spectre no código foi porque se continuou usando um iterador definido separadamente após o loop.
Apesar de sua natureza geralmente rápida, o projeto do kernel depende de várias ferramentas mais antigas. Enquanto os críticos gostam de se concentrar no uso extensivo de e-mail pela comunidade, um anacronismo possivelmente mais significativo é o uso da versão de 1989 do padrão da linguagem C para código do kernel, um padrão que foi codificado antes do início do projeto do kernel, há mais de 30 anos. Parece que essa prática de longa data pode chegar ao fim assim que o kernel 5.18, esperado para maio deste ano.
É mencionado que uma macro é usada para iterar sobre os elementos da lista vinculada, e como o iterador de loop é passado para essa macro, ele é definido fora do próprio loop e permanece disponível após o loop. Usar o padrão C99 permitiria aos desenvolvedores definir variáveis para o loop no bloco for(), o que resolveria o problema sem inventar soluções alternativas.
Infelizmente, existem vários locais no kernel onde a lista
iterador é usado após o loop que interrompe essa alteração. Felizmente
existe o script use_after_iter.cocci que pode ser usado para identificar tais
localizações do código. Eu tive que adaptar um pouco o script, pois reduz false
positivos no caso de uso original, mas esses são relevantes para este patch.Uma grande variedade de locais de código relatados usa apenas o iterador de lista após
o ciclo se houve uma saída antecipada (break/goto) e, portanto, eles não são
relevante.
Por sua parte, o Linus Torvalds concordou com a ideia para ser capaz de implementar o suporte para as especificações mais recentes e sugeriu ainda a mudança no kernel 5.18 para usar o padrão C11, lançado em 2011.
Depois disso, durante a verificação preliminar, a montagem no GCC e Clang no novo modo passou sem desvio. A menos que surjam problemas imprevistos devido a testes mais extensos, os scripts de compilação do kernel 5.18 mudarão a opção '–std=gnu89' para '–std=gnu11 -Wno-shift-negative-value'.
Linus Torvalds não gostou muito do patch e não viu como ele se relacionava com vulnerabilidades de execução especulativa. No entanto, depois que Koschel explicou melhor a situação, Torvalds concordou que "este é apenas um bug normal, puro e simples" e disse que deveria ser corrigido independentemente da série maior. Mas então ele mergulhou na verdadeira fonte do problema: que o iterador passado para as macros de travessia da lista deve ser declarado em um escopo fora do próprio loop:
A principal razão pela qual esse tipo de erro não especulativo pode ocorrer é que historicamente não tínhamos "declarar variáveis em loops" no estilo C99. Então list_for_each_entry() - e todos os outros - fundamentalmente sempre filtram a última entrada HEAD do loop, simplesmente porque não poderíamos declarar a variável do iterador no próprio loop.
Também vale a pena mencionar que foi considerada a possibilidade de usar o padrão C17, mas neste caso seria necessário aumentar a versão mínima suportada do GCC, uma vez que a inclusão do suporte para C11 está em conformidade com os requisitos atuais para a versão GCC (5.1).
Finalmente se você estiver interessado em saber mais sobre isso, você pode verificar os detalhes no link a seguir