O modelo de lançamento estável do kernel Linux começou em 2005, quando foi determinado que o modelo de desenvolvimento do kernel existente (uma nova versão a cada 2-3 meses) não atendia às necessidades da maioria dos usuários. Os usuários queriam que correções de bugs fossem feitas durante esses 2 a 3 meses, e as distribuições Linux acharam difícil manter os kernels atualizados sem feedback da comunidade do kernel. Em geral, as tentativas de manter os kernels individuais seguros e com as correções de bugs mais recentes foram um esforço grande e confuso por parte de muitos indivíduos diferentes.
As versões estáveis do kernel são baseadas diretamente nas versões de Linus Torvalds e são lançadas a cada semana ou mais, dependendo de vários fatores externos (época do ano, patches disponíveis, carga de trabalho do mantenedor, etc.). A numeração das versões estáveis começa com o número da versão do kernel e um número adicional é adicionado ao final dela. Por exemplo, o kernel 4.4 é lançado pelo Linus e, em seguida, as versões estáveis do kernel baseadas neste kernel são numeradas 4.4.1, 4.4.2, 4.4.3 e assim por diante. Esta sequência geralmente é abreviada com o número 4.4.y quando se refere a uma árvore de lançamento de kernel estável. Cada árvore de lançamento de kernel estável é mantida por um único desenvolvedor de kernel, que é responsável por escolher os patches necessários para o lançamento e gerenciar o processo de revisão/lançamento.
Kernels estáveis são mantidos durante o ciclo de desenvolvimento atual. Depois que Linus lança um novo kernel, a árvore de lançamento do kernel estável anterior é interrompida e os usuários devem migrar para o kernel lançado mais recente.
Kernels estáveis a longo prazo
Após um ano deste novo processo de lançamento estável, foi determinado que muitos usuários diferentes do Linux queriam que um kernel fosse suportado por mais do que apenas alguns meses. Em resposta, o lançamento do kernel Long Term Supported (LTS) foi criado, com o primeiro kernel LTS (2.6.16) lançado em 2006. Desde então, um novo kernel LTS foi selecionado uma vez por ano e a comunidade do kernel mantém esse kernel por um mínimo de 2 anos.
No momento em que este livro foi escrito, os kernels LTS eram as versões 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y e 5.10.y. Um novo kernel é lançado semanalmente. Devido às necessidades de alguns usuários e distribuições, alguns kernels mais antigos adicionais são mantidos pelos desenvolvedores do kernel em um ciclo de lançamento mais lento. Informações sobre todos os kernels estáveis de longo prazo, quem é responsável por eles e por quanto tempo eles serão mantidos podem ser encontradas na página de lançamentos do kernel.org .
O kernel LTS lança em média de 6 a 8 patches aceitos por dia, enquanto as versões normais do kernel estável contêm de 10 a 15 patches por dia. O número de patches varia por versão, dependendo da hora atual da versão do kernel de desenvolvimento correspondente e de outras variáveis externas. Quanto mais antigo for um kernel LTS, menos patches serão aplicáveis a ele, já que muitas correções de bugs recentes não são relevantes para kernels mais antigos. No entanto, quanto mais antigo for o kernel, mais difícil será fazer backport das alterações que precisam ser aplicadas, devido às alterações na base de código. Portanto, embora possa haver um número menor de patches gerais aplicados, o esforço envolvido na manutenção de um kernel LTS é maior do que na manutenção de um kernel estável normal.
Regras de patch de kernel estáveis
As regras sobre o que pode ser adicionado a uma versão estável do kernel permaneceram quase idênticas desde a sua introdução e estão resumidas abaixo:
- Deve estar obviamente correto e testado.
- Não deve ser maior que 100 linhas.
- Deve consertar apenas uma coisa.
- Deve corrigir algo que foi relatado como um problema.
- Pode ser um novo ID de dispositivo ou peculiaridade de hardware, mas não adiciona novas funcionalidades importantes.
- Já deve estar mesclado na árvore de Linus Torvalds.
A última regra, "Já deve estar mesclada na árvore de Linus Torvalds", evita que a comunidade do kernel perca correções. A comunidade nunca quer que uma correção entre em uma versão de kernel estável que ainda não esteja na árvore de Linus Torvalds, de modo que qualquer pessoa que atualize nunca verá uma regressão. Isso evita muitos problemas que outros projetos que mantêm um branch estável e em desenvolvimento podem ter.
Atualizações do kernel
A comunidade do kernel Linux prometeu à sua base de usuários que nenhuma atualização quebrará qualquer coisa que esteja funcionando atualmente em uma versão anterior. Essa promessa ainda é válida hoje. As regressões acontecem, mas esses são os bugs de maior prioridade e são rapidamente corrigidos ou a alteração que causou a regressão é rapidamente revertida da árvore do kernel do Linux.
Esta promessa é válida tanto para as atualizações incrementais do kernel estável, quanto para as atualizações principais maiores que acontecem a cada três meses. No entanto, a comunidade do kernel só pode fazer esta promessa para o código que é mesclado na árvore do kernel Linux. Qualquer código mesclado no kernel de um dispositivo que não esteja nas versões do kernel.org é desconhecido e as interações com ele nunca podem ser planejadas ou mesmo consideradas.
Dispositivos baseados em Linux que possuem grandes conjuntos de patches podem ter grandes problemas ao atualizar para kernels mais recentes, devido ao grande número de alterações entre cada versão (10 a 14 mil alterações por versão). Os conjuntos de patches SoC são especialmente conhecidos por terem problemas com a atualização para kernels mais recentes devido ao seu grande tamanho e grande modificação do código específico da arquitetura e, às vezes, do núcleo do kernel. Como resultado, a maioria dos fornecedores de SoC está começando a padronizar o uso de versões LTS para seus dispositivos, permitindo que esses dispositivos recebam atualizações de bugs e de segurança diretamente da comunidade do kernel Linux.
Segurança
Ao lançar o kernel, a comunidade do kernel Linux quase nunca declara alterações específicas como correções de segurança . Isto se deve ao problema básico da dificuldade em determinar se uma correção de bug é uma correção de segurança ou não no momento de sua criação. Além disso, muitas correções de bugs só são determinadas como relacionadas à segurança depois de muito tempo, então a comunidade do kernel recomenda sempre fazer todas as correções de bugs lançadas.
Quando problemas de segurança são relatados à comunidade do kernel, eles são corrigidos o mais rápido possível e divulgados publicamente na árvore de desenvolvimento e nas versões estáveis. Conforme descrito acima, as alterações quase nunca são descritas como uma "correção de segurança", mas se parecem com qualquer outra correção de bug do kernel. Isso é feito para permitir que as partes afetadas atualizem seus sistemas antes que o relator do problema o anuncie.
Para obter detalhes sobre como relatar bugs de segurança à comunidade do kernel para resolvê-los e corrigi-los o mais rápido possível, consulte Bugs de segurança no guia do usuário e do administrador do kernel Linux em www.kernel.org .
Como os bugs de segurança não são anunciados ao público pela equipe do kernel, os números CVE para problemas relacionados ao kernel Linux são geralmente divulgados semanas, meses e às vezes anos após a correção ter sido incorporada nas ramificações estável e de desenvolvimento.
Mantendo um sistema seguro
Ao implantar um dispositivo que usa Linux, é altamente recomendável que todas as atualizações do kernel LTS sejam feitas pelo fabricante e enviadas aos usuários após testes adequados mostrarem que a atualização funciona bem. Isto tem várias vantagens:
- As versões foram revisadas pelos desenvolvedores do kernel como um todo, não em partes individuais.
- É difícil, se não impossível, determinar quais patches corrigem problemas de “segurança” e quais não. Quase todas as versões LTS contêm pelo menos uma correção de segurança conhecida e muitas ainda "desconhecidas".
- Se o teste mostrar um problema, a comunidade de desenvolvedores do kernel reagirá rapidamente para resolver o problema.
- As tentativas de filtrar apenas as alterações executadas resultarão em uma árvore de kernel que é impossível de mesclar corretamente com versões futuras do upstream.