Nos últimos dias, a lista de discussão do kernel Linux trouxe uma série de novidades. Houve uma grande discussão sobre a capacidade do kernel Linux de mitigar os chamados ‘estouros aritméticos’ inesperados/underflows/wraparounds. Assim, Linus Torvalds e outros desenvolvedores discutem sobre problemas do kernel Linux.
Kees Cook com o Google tem trabalhado para descobrir como lidar melhor com bugs de estouro aritmético inesperados dentro do código-fonte C do kernel Linux. Ele espera ver uma maneira sistemática para o kernel Linux ser capaz de lidar com esses problemas aritméticos de estouro/underflow/wrap-around.
Linus Torvalds e outros desenvolvedores discutem sobre problemas do kernel Linux
Entre os pensamentos iniciais está a melhor contratação de sanitizantes baseados em compiladores ou uma proposta recente de linguagem C para sobrecarga de operadores sem manipulação de nomes. Nesta última proposta como uma solução potencial, a sobrecarga do operador C poderia permitir o tratamento arbitrário de transbordamentos dentro dos auxiliares.
Kees pensou inicialmente em buscar mitigações baseadas em sanitizantes e concluiu seu tópico de lista de discussão com:
“Estou buscando algum consenso geral sobre a abordagem #1 acima. Qualquer solução que realmente nos ganhe cobertura significativa exigirá mudanças bastante extensas nos tipos do Linux, então esse é um ponto problemático universal. Mas eu venho batendo o tambor de “tornar o Linux mais seguro” há muito tempo, e espero poder convencer as pessoas de que precisamos realmente fazer uma mudança aqui. O status quo não é bom o suficiente, e podemos fazer melhor. Só preciso de encontrar uma solução comum com a qual possamos chegar a acordo e aplicar de forma realista nos próximos anos.
Vou buscar meu terno de amianto agora… Quais são seus pensamentos, sugestões, alternativas?”
Linus Torvalds foi rápido em compartilhar seus pensamentos sobre a proposta:
“Ainda não estou totalmente convencido. A questão é que o wrap-around não é apenas bem definido, é comum e ESPERADO. Exemplo:
static inline u32 __hash_32_generic(u32 val)
{
return val * GOLDEN_RATIO_32;
}
e caramba, eu absolutamente NÃO ACHO que devemos anotar isso como uma espécie de “multiplicação especial”. Não faço ideia de quantas delas existem. Mas estou 100% convencido de que fazer os humanos anotarem isso e piorar o código-fonte é absolutamente a abordagem errada. Basicamente, a aritmética não assinada é bem definida como envolvimento, e é assim por uma boa razão.
Então eu vou ter um HARD REQUIREMENT de que qualquer reclamação do compilador precisa ser realmente sã. Eles precisam detectar quando as pessoas fazem coisas assim de propósito, e eles precisam FECHAR o ^&% UP sobre o fato de que o envolvimento acontece.
Qualquer ferramenta que seja tão estúpida a ponto de reclamar do envoltório acima é uma FERRAMENTA QUEBRADA QUE PRECISA SER IGNORADA.
Realmente. Isso é inegociável. Isso é semelhante a todo o int a, b não assinado;
se (a+b < a) ..
Notícias Relacionadas
Futuro incerto para o BcacheFS
Debates acalorados: a suspensão de Kent Overstreet e as reações da comunidade
A suspensão temporária de Kent Overstreet, criador do BcacheFS, provocou uma avalanche de reações na comunidade Linux. Com opiniões divididas, desenvolvedores e membros da comunidade discutem sobre o impacto de suas ações e as consequências para o futuro do projeto no kernel Linux. O desenvolvedor suspenso também comentou em seu blog como tudo aconteceu. Comentários […]
Kent Overstreet
Kent Overstreet comenta suspensão em seu blog
Kent Overstreet, desenvolvedor da inovadora sistema de arquivos BcacheFS, enfrenta um momento delicado em sua carreira como contribuidor do kernel Linux. Sua suspensão temporária pelo comitê de Código de Conduta (CoC) gerou controvérsias sobre a forma como conflitos são geridos dentro da comunidade e levantou questões sobre os processos culturais e técnicos que guiam o […]
Tipo de padrão: Uma ferramenta que reclama de envoltório no acima está absolutamente quebrada e precisa ser ignorada.
Então, acho que você precisa limitar suas queixas e realmente pensar em como limitá-las. Se você for “enrolar está errado” como uma espécie de general; Eu vou te ignorar, e vou dizer para as pessoas te ignorarem, e recusarem qualquer correção que seja resultado de regras tão.
Dito de outra forma, a primeira e fundamental coisa que você deve olhar é garantir que as ferramentas não reclamem de comportamento são. Enquanto você não fizer isso, e não levar isso a sério, essa discussão nunca resultará em nada produtivo.
Linus”
Algumas informações claras de Linus Torvalds. Mais tarde, acrescentou:
“Qualquer tipo de ‘isso pode enrolar’ é imperdoável. Precisa ser mais inteligente do que isso. E sim, isso significa exatamente levar em conta como o resultado do possível envoltório é realmente usado.
Se ele for usado como um tamanho ou como um índice de matriz, pode ser um problema. Mas se ele é usado para mascaramento e, em seguida, uma versão mascarada é usada para um índice, claramente não é um problema.
IOW, exatamente o mesmo que “a+b < a”. Sim, “a+b” pode enrolar, mas se o uso for para compará-lo com um dos adendos, então claramente tal wrap-around é bom.
Uma ferramenta que não olha para como o resultado é usado, e apenas diz cegamente “erro de envolvimento” é uma ferramenta que eu acho que é ativamente prejudicial.
E não, a resposta é ABSOLUTAMENTE NÃO adicionar carga cognitiva nos desenvolvedores do kernel adicionando ainda mais tipos de auxiliares aleatórios e/ou funções. Já esperamos muitos desenvolvedores de kernel. Não devemos aumentar esse fardo por causa do seu projeto de animal de estimação.
Dito de outra forma: estou colocando o ônus em VOCÊ para garantir que seu projeto de animal de estimação seja o “Urso Yogi” dos projetos de animais de estimação – mais inteligente do que o urso médio. Enquanto você estiver abordando isso a partir de um “isso coloca o ônus sobre os outros”, VOCÊ é o problema. Seja a solução, não o problema.
Linus”
Como outro seguimento, ele sugeriu dar mais passos em direção a uma possível solução. As discussões permanecem em andamento, então veremos como a discussão evolui e, finalmente, qual código acaba sendo proposto para tentar lidar melhor com o código C do kernel Linux para mitigar possíveis estouros/wrap-arounds aritméticos inesperados.
