Versões e atualizações do kernel estável

O modelo de versão estável do kernel do Linux começou em 2005, quando foi determinado que o modelo de desenvolvimento de kernel existente (uma nova versão a cada 2 ou 3 meses) foi não atende às necessidades da maioria dos usuários. Os usuários queriam correções de bugs feitas durante esses dois ou três períodos. meses, e as distribuições do Linux tiveram dificuldade para manter os kernels atualizados sem feedback da comunidade do kernel. Em geral, as tentativas de manter kernels individuais seguros e, com as últimas correções de bugs, era uma tarefa o esforço de muitas pessoas diferentes.

As versões estáveis do kernel são baseadas diretamente lançamentos e são lançado a cada semana, dependendo de vários fatores externos (época do ano, patches disponíveis, carga de trabalho do mantenedor etc.). A numeração do está começa com o número da versão do kernel e um número adicional é adicionado ao final. Por exemplo, a Linus lançou o kernel 4.4 e as versões de kernel estáveis baseadas nesse kernel serão numeradas como 4.4.1, 4.4.2, 4.4.3 e assim por diante. Essa sequência geralmente é encurtada com o número 4.4.y quando se referem a uma árvore de lançamento do kernel estável. Cada árvore de lançamento do kernel estável mantido 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 liberação do kernel estável anterior é parou e os usuários precisam migrar para o kernel lançado mais recentemente.

Kernels estáveis de longo prazo

Após um ano desse novo processo de lançamento estável, foi determinado que muitos diferentes usuários do Linux queriam oferecer suporte a um kernel por mais tempo que apenas um alguns meses. Em resposta, a versão do kernel com suporte de longo prazo (LTS) foi criado, com o primeiro kernel LTS (2.6.16) lançado em 2006. Desde então, O kernel do LTS foi selecionado uma vez por ano e a comunidade do kernel mantém essa por no mínimo 2 anos.

No momento em que este artigo foi escrito, os kernels de LTS são 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 a as necessidades de alguns usuários e distribuições, alguns kernels mais antigos são mantidos por desenvolvedores de kernel em um ciclo de lançamento mais lento. Informações sobre todos os kernels estáveis de longo prazo, quem é o responsável por eles e há quanto tempo eles mantidas, podem ser encontradas na kernel.org de lançamento.

O kernel LTS lança em média de 6 a 8 patches aceitos por dia, enquanto o As versões estáveis de kernel contêm de 10 a 15 patches por dia. o número de patches flutua por versão de acordo com a hora atual do ciclo de desenvolvimento a versão do kernel e outras variáveis externas. Quanto mais antigo for o kernel do 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 é o kernel, mais difícil é fazer o backport alterações que precisam ser aplicadas devido às alterações na base de código. Então, embora possa haver um número menor de patches gerais sendo aplicados, o esforço de manter um kernel de LTS é maior do que manter o um kernel estável.

Regras de patch do kernel estável

As regras sobre o que pode ser adicionado a uma versão estável do kernel permaneceram quase idênticos desde sua introdução e estão resumidos abaixo:

  • Precisa estar obviamente correta e testada.
  • Não pode ser maior do que 100 linhas.
  • Só é preciso corrigir um problema.
  • É preciso corrigir algo que foi informado como um problema.
  • Pode ser um novo ID do dispositivo ou uma peculiaridade para o hardware, mas não pode adicionar novos itens importantes. funcionalidade de armazenamento.
  • Já precisa estar mesclado com Linus Torvalds árvore.
.

A última regra, "Deve já estar mesclado com Linus Torvalds" árvore", impede que a comunidade do kernel perca correções. A comunidade nunca quer uma solução para uma versão estável do kernel que ainda não está na versão árvore, então para que as pessoas que façam upgrade nunca tenham acesso a uma regressão. Isso evita que 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 corrompe qualquer coisa que esteja funcionando em uma versão anterior. Isso promessa ainda vale hoje. Regressões acontecem, mas essas são as mais altas bugs prioritários e sejam rapidamente corrigidos, ou a mudança que causou a regressão seja revertida rapidamente da árvore de kernel do Linux.

Essa promessa é verdadeira para as atualizações incrementais do kernel estável, como além das grandes atualizações que ocorrem a cada três meses. No entanto, a comunidade do kernel só pode fazer essa promessa para o código mesclado com o Árvore de kernel do Linux. Qualquer código mesclado no kernel do dispositivo que não está no a versão kernel.org é desconhecida e interações com ele nunca podem ser planejadas ou consideradas.

Dispositivos baseados em Linux que têm grandes conjuntos de patches podem apresentar grandes problemas atualizando para kernels mais recentes, devido ao grande número de alterações entre cada versão (de 10 a 14 mil alterações por versão). Os patchessets de SoC são especialmente conhecidos problemas na atualização para kernels mais recentes devido ao tamanho grande e pesado 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 os dispositivos deles, permitindo que eles recebam atualizações de bugs e de segurança diretamente da comunidade do kernel do Linux.

Segurança

Ao fazer lançamentos do kernel, a comunidade do kernel Linux quase nunca declara mudanças específicas, como correções de segurança. Isso se deve ao problema básico de a 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ão consideradas apenas relacionadas à segurança. por isso, a comunidade do kernel recomenda enfaticamente sempre incluindo 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 disponibilizado publicamente para a árvore de desenvolvimento e a para versões estáveis. Como descrito acima, as mudanças quase nunca são descritas como uma "correção de segurança", mas parece qualquer outra correção de bug para o kernel. Isso é para que as partes afetadas possam atualizar seus sistemas antes que a o denunciante do problema o anuncia.

Confira mais detalhes sobre como informar bugs de segurança à comunidade do kernel resolvidos e corrigidos o mais rápido possível, consulte Bugs de segurança no Guia do usuário e do administrador do kernel do Linux em www.kernel.org (links em inglês)

Como bugs de segurança não são anunciados ao público pela equipe do kernel, a CVE os números de problemas relacionados ao kernel do Linux geralmente são lançados em semanas, meses e às vezes anos depois que a correção foi incorporada à versão estável e galhos.

Mantenha um sistema seguro

Ao implantar um dispositivo que usa Linux, é altamente recomendável As atualizações do kernel de LTS são feitas pelo fabricante e enviadas aos usuários após o teste adequado mostra que a atualização funciona bem. Isso tem muitas vantagens:

  • As versões foram revisadas pelos desenvolvedores do kernel como um todo, não em partes individuais.
  • É difícil determinar quais patches corrigem a "segurança" e quais não têm. Quase todas as versões de LTS contêm pelo menos de segurança e muitas ainda são "desconhecidas".
  • Se o teste mostrar um problema, a comunidade de desenvolvedores do kernel reage rapidamente para resolver o problema.
  • As tentativas de filtrar apenas as alterações que você executa resultam em um kernel. que é impossível mesclar corretamente com versões upstream futuras.