O modelo de lançamento estável do kernel do Linux começou em 2005, quando foi determinado que o modelo de desenvolvimento do kernel existente (uma nova versão a cada dois ou três meses) não atendeu às necessidades da maioria dos usuários. Os usuários queriam correções de bugs feitas durante esses dois a três meses, e as distribuições do Linux achavam difícil manter os kernels atualizados sem feedback da comunidade. 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 de muitas pessoas 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, dependendo de vários fatores externos (época do ano, patches disponíveis, carga de trabalho do administrador 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 por Linus, e as versões estáveis do kernel baseadas nele são numeradas 4.4.1, 4.4.2, 4.4.3 e assim por diante. Essa sequência geralmente é abreviada com o número 4.4.y quando se refere a uma árvore de lançamento estável do kernel. Cada árvore de lançamento estável do kernel é mantida por um único desenvolvedor do kernel, que é responsável por escolher os patches necessários para a versão e gerenciar o processo de análise/lançamento.
Os 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 precisam migrar para o kernel mais recente.
Kernels estáveis de longo prazo
Após um ano de lançamento desse novo processo estável, foi determinado que muitos usuários diferentes do Linux queriam que um kernel tivesse suporte por mais tempo do que apenas alguns meses. Em resposta, a versão do kernel com suporte de longo prazo (LTS) foi criada, e o primeiro kernel LTS (2.6.16) foi lançado em 2006. Desde então, um novo kernel LTS é selecionado uma vez por ano, e a comunidade de kernel mantém esse kernel por pelo menos dois anos.
No momento da redação deste artigo, os kernels LTS são 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 são mantidos pelos desenvolvedores 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 são mantidos, podem ser encontradas na página kernel.org releases.
As versões do kernel LTS têm uma 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 flutua por versão, considerando o tempo atual da versão do kernel de desenvolvimento correspondente e 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 um kernel, mais difícil será fazer o backport das mudanças que precisam ser aplicadas devido às mudanças na base de código. Portanto, embora possa haver um número menor de patches gerais sendo aplicados, o esforço envolvido na manutenção de um kernel LTS é maior do que manter o kernel estável normal.
Regras de patch do kernel estável
As regras para o que pode ser adicionado a uma versão estável do kernel permaneceram quase idênticas desde a introdução e estão resumidas abaixo:
- Precisam ser obviamente corretas e testadas.
- Não pode ter mais de 100 linhas.
- Precisa corrigir apenas uma coisa.
- Precisa corrigir algo que foi informado como um problema.
- Pode ser um novo ID de dispositivo ou uma peculiaridade do hardware, mas não adicionar uma nova funcionalidade importante.
- Já precisa estar mesclada na árvore de Linus Torvalds.
A última regra, "Já precisa estar mesclada na árvore de Linus Torvalds", impede que a comunidade do kernel perca correções. A comunidade nunca quer que uma correção seja incluída em uma versão estável do kernel que ainda não esteja na árvore de Linus Torvalds, para que ninguém que faça upgrade nunca tenha uma regressão. Isso evita muitos problemas que outros projetos que mantêm uma ramificação estável e de desenvolvimento podem ter.
Atualizações do kernel
A comunidade do kernel do Linux prometeu à base de usuários que nenhum upgrade jamais vai quebrar nada que esteja funcionando em uma versão anterior. Essa promessa ainda é válida hoje. As regressões acontecem, mas são os bugs de maior prioridade e são corrigidos rapidamente ou a mudança que causou a regressão é revertida rapidamente da árvore do kernel do Linux.
Essa promessa é válida para as atualizações incrementais do kernel estável e para as atualizações principais maiores que acontecem a cada três meses. No entanto, a comunidade do kernel só pode fazer essa promessa para o código que é mesclado na árvore do kernel do 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 consideradas.
Dispositivos baseados em Linux com conjuntos de patches grandes podem ter problemas graves ao atualizar para kernels mais recentes devido ao grande número de mudanças entre cada versão (de 10 a 14 mil mudanças por versão). Os conjuntos de patches de SoC são conhecidos por terem problemas com a atualização para kernels mais recentes devido ao tamanho grande e à modificação pesada do código do kernel específico da arquitetura e, às vezes, do núcleo. Como resultado, a maioria dos fornecedores de SoC estão começando a padronizar o uso das versões LTS para os dispositivos, permitindo que eles recebam atualizações de bugs e segurança diretamente da comunidade do kernel do Linux.
Segurança
Ao fazer lançamentos do kernel, a comunidade do kernel do Linux quase nunca declara mudanças específicas como correções de segurança. Isso se deve ao problema básico de dificuldade para determinar se uma correção de bug é uma correção de segurança ou não no momento da criação. Além disso, muitas correções de bugs só são determinadas como relacionadas à segurança depois de muito tempo. Portanto, a comunidade do kernel recomenda fortemente que todas as correções de bugs sejam sempre aplicadas.
Quando os problemas de segurança são informados à comunidade do kernel, eles são corrigidos assim que possível e enviados publicamente para a árvore de desenvolvimento e as versões estáveis. Como descrito acima, as mudanças quase nunca são descritas como uma "correção de segurança", mas parecem com qualquer outra correção de bugs do kernel. Isso é feito para permitir que as partes afetadas atualizem os sistemas antes que o informante do problema o anuncie.
Para detalhes sobre como informar bugs de segurança à comunidade do kernel para que eles sejam resolvidos e corrigidos o mais rápido possível, consulte Bugs de segurança no Guia para usuários e administradores do kernel do 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 de CVE para problemas relacionados ao kernel do Linux geralmente são lançados semanas, meses e, às vezes, anos depois que a correção foi mesclada às ramificações estáveis e de desenvolvimento.
Manter um sistema seguro
Ao implantar um dispositivo que usa o Linux, recomendamos que todas as atualizações do kernel LTS sejam feitas pelo fabricante e enviadas aos usuários depois que os testes adequados mostrarem que a atualização funciona bem. Isso tem muitas vantagens:
- As versões foram analisadas pelos desenvolvedores do kernel como um todo, não em partes individuais.
- É difícil determinar quais correções 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 são "desconhecidas".
- Se o teste mostrar um problema, a comunidade de desenvolvedores do kernel vai reagir rapidamente para resolvê-lo.
- As tentativas de filtrar apenas as mudanças executadas resultam em uma árvore do kernel que é impossível de mesclar corretamente com versões upstream futuras.