Como o código-fonte é revisado / auditado, antes da inclusão na linha principal do Linux?

Question

Uma resposta a esta pergunta forneceria insights e referências sobre como o código-fonte do kernel do Linux é revisado antes de ser lançado?

Particular aspecto interessante desta pergunta para mim é:

• Quem e quantas pessoas revisam o código fornecido, ou seja, por meio de uma solicitação pull?
• Há alguma alteração que um backdoor possa deixar de ser detectado, em particular considerando os blobs de firmware?
• As ferramentas de análise de código estático / dinâmico são usadas? Se sim, para proteção contra bugs acidentais ou contra implantes deliberados de backdoors?

Informações: Eu consultei a FAQ do LKML que fornece a seguinte declaração relacionada

15. How do I get my patch into the kernel?

    (RRR) Depending on your patch there are several ways to get it into the kernel. The first thing is to determine under which maintainer does your code fall into (look in the MAINTAINERS file). If your patch is only a small bugfix and you're sure that it is 'obviously correct', [...]
    [...] here's another important bit: one purpose of the list is to get patches peer-reviewed and well-tested.[...]

O cerne da questão é alguma ideia, o que é que esta 'obviamente corrige' e é avaliado por pares (por exemplo, quem, quantos?).

Para um exemplo concreto, olhei para o exemplo do log de commit para o driver de dispositivo de chip staged rtl8188eu wifi, encontrado em /usr/srx/linux/drivers/staging/rtl8188eu :

• número de commits modificando o arquivo de [...]/rtl8188eu é 1560 %código%
• número de autores 190 pessoas em git log --format="%x00%h%n%an%n%cn%n%s" --name-status | tr 'sed 's/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq | wc -l\n' '\nsed 's/^[^\x00]*\x00//g;s/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq' | grep -a '8188eu' | tee commits | wc -l
• número de commiters 12 (Al Viro, David S. Miller, Greg Kroah-Hartman, Ingo Molnar, Jeff Kirsher, Jiri Kosina, Johannes Berg, John W. Linville, Cook Kees, Linus Torvalds, Michael S. Tsirkin, Peter P Waskiewicz Jr) em %code%

Answer 1

Who and how many persons review the code that is provided?

De modo geral, pelo menos o mantenedor do subsistema e, normalmente, pelo menos um ou dois outros desenvolvedores interessados no tópico geral do seu patch. Por exemplo, um patch de melhoria de segurança normalmente envolveria desenvolvedores focados na segurança, bem como os mantenedores dos subsistemas que estão sendo modificados. Patches mais complexos recebem mais atenção, a menos que seus desenvolvedores não consigam que ninguém se interesse neles. Patches que introduzem muito custo de manutenção não entram (veja este exemplo por você realmente ).

Is there a chance that a backdoor could go undedected, in particular considering firmware blobs?

Os blobs de firmware são muito opacos por definição, então sim, há uma chance de que um backdoor não seja detectado. Mais geralmente, quando você vê a complexidade de alguns ataques em navegadores da web, por exemplo, é concebível que um backdoor possa ser introduzido durante o curso de vários patches aparentemente não relacionados. Isso é especialmente verdadeiro se os patches aparentemente não relacionados acabarem sendo revisados e aprovados por diferentes desenvolvedores.

Are static/dynamic code analysis tools used, and if so to guard against accidental bugs only, or also against deliberate backdoors implants?

Não como parte do processo de revisão, tanto quanto eu sei; mas há vários grupos que executam ferramentas de análise no kernel em intervalos regulares, e reportam e / ou corrigem os problemas levantados. Um exemplo é o as verificações do Coverity .

What this obviously correct?

Isso varia muito. Patches são cuidadosamente revisados (veja este comentário em um patch simples ), mas um remetente de correções pode receber menos reação do que o esperado, especialmente porque eles estão menos familiarizados com o código que estão mudando do que o mantenedor do subsistema - portanto, uma mudança que pode parecer complexa para seu autor pode parecer óbvia para o mantenedor. A comunidade de desenvolvimento de núcleos também tende a evitar a síndrome de “revisões relaxadas de grandes patches”, exigindo que grandes patches sejam divididos em partes analisáveis, e freqüentemente exigindo que grandes conjuntos de patches obtenham mais revisões. Revisões cuidadosas não garantem correção, infelizmente; uma das minhas correções foi consertada pelo mantenedor do subsistema, com o resultado que foi mesclado com um erro desagradável! (Há uma análise recente de como os mantenedores lidam com seus próprios patches, o que é relevante.)

Os patches também são revistos em agregado quando os mantenedores do subsistema mesclam as árvores, até o mantenedor principal (Linus, Greg e os vários mantenedores estáveis). Isso geralmente não resulta em alterações solicitadas, mas isso acontece algumas vezes.

É importante considerar o aspecto social de tudo isso também. É muito mais fácil para um desenvolvedor conhecido obter comentários. minha experiência geral no mundo do desenvolvimento de software também sugeriria que desenvolvedores conhecidos pudessem ver seus patches menos examinados ... Para desenvolvedores menos conhecidos, ter um revisor bem conhecido aprovando seu patch pode facilitar a entrada também. Em geral, ajuda a conhecer as pessoas certas ou a apoiar os esforços corretos ( por exemplo, participa de uma campanha de endurecimento).