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 (um novo lançamento a cada 2-3 meses) não estava atendendo às necessidades da maioria dos usuários. Os usuários queriam correções de bugs feitas durante esses 2-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 muitos indivíduos diferentes.
Os lançamentos estáveis do kernel são baseados diretamente nos lançamentos de Linus Torvalds e são lançados a cada semana, 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 por Linus, e então 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 encurtada com o número 4.4.y quando se refere a uma árvore de lançamento do 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.
Os kernels estáveis são mantidos durante o ciclo de desenvolvimento atual. Depois que o Linus lança um novo kernel, a árvore de lançamento do kernel estável anterior é interrompida e os usuários devem passar para o kernel mais recente lançado.
Kernels estáveis a longo prazo
Após um ano desse 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 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.ye 5.10.y. Um novo kernel é lançado semanalmente. Devido às necessidades de alguns usuários e distribuições, alguns kernels 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 serão mantidos, podem ser encontradas na página de lançamentos do kernel.org .
O kernel LTS libera em média 6 a 8 patches aceitos por dia, enquanto os lançamentos normais do kernel estável contêm 10 a 15 patches por dia. O número de patches flutua por versão, de acordo com a hora atual da versão do kernel de desenvolvimento correspondente e outras variáveis externas. Quanto mais antigo for um kernel LTS, menos patches são aplicáveis a ele, pois 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 backport das alterações necessárias para serem aplicadas, devido às alterações 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 de kernel estáveis
As regras para o que pode ser adicionado a uma versão estável do kernel permaneceram quase idênticas desde sua introdução e estão resumidas abaixo:
- Deve ser obviamente correto e testado.
- Não deve ser maior que 100 linhas.
- Deve corrigir 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 uma nova funcionalidade importante.
- Já deve ser mesclado na árvore de Linus Torvalds.
A última regra, "Já deve ser 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 estável do kernel que ainda não esteja na árvore de Linus Torvalds, de modo que qualquer um que atualizar nunca deve ver uma regressão. Isso evita muitos problemas que outros projetos que mantêm um branch estável e de desenvolvimento podem ter.
Atualizações do kernel
A comunidade do kernel Linux prometeu à sua base de usuários que nenhuma atualização jamais quebrará qualquer coisa que esteja funcionando atualmente em uma versão anterior. Essa promessa ainda é válida hoje. 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.
Essa promessa é válida tanto para as atualizações incrementais estáveis do kernel, quanto para as grandes atualizações 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 que seja 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 novos, devido ao grande número de alterações entre cada versão (10-14 mil alterações por versão). Os conjuntos de patches do SoC são especialmente conhecidos por terem problemas com a atualização para kernels mais novos devido ao seu grande tamanho e pesada modificação do código do kernel específico da arquitetura e, às vezes, do núcleo. Como resultado, a maioria dos fornecedores de SoC está começando a padronizar o uso das versões LTS para seus dispositivos, permitindo que esses dispositivos recebam atualizações de bugs e segurança diretamente da comunidade do kernel Linux.
Segurança
Ao fazer lançamentos do kernel, a comunidade do kernel Linux quase nunca declara alterações específicas como correções de segurança . Isso 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 da 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 pegar todas as correções de bugs que são lançadas.
Quando problemas de segurança são relatados à comunidade do kernel, eles são corrigidos o mais rápido possível e enviados publicamente para a árvore de desenvolvimento e as versões estáveis. Como 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 para o 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 para 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 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 de CVE para problemas relacionados ao kernel do Linux geralmente são lançados semanas, meses e às vezes anos após a correção ter sido mesclada 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 para seus usuários após testes adequados mostrarem que a atualização funciona bem. Isso 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 do 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 do kernel que é impossível de mesclar corretamente com futuras versões upstream.