El modelo de lanzamiento estable del kernel de Linux comenzó en 2005, cuando se determinó que el modelo de desarrollo del kernel existente (un nuevo lanzamiento cada 2 o 3 meses) no satisfacía las necesidades de la mayoría de los usuarios. Los usuarios querían que se hicieran correcciones de errores durante esos 2 o 3 meses, y las distribuciones de Linux tenían dificultades para mantener los núcleos actualizados sin los comentarios de la comunidad del núcleo. En general, los intentos de mantener seguros los núcleos individuales y con las últimas correcciones de errores fueron un esfuerzo grande y confuso por parte de muchas personas diferentes.
Los lanzamientos estables del núcleo se basan directamente en los lanzamientos de Linus Torvalds y se lanzan cada semana, dependiendo de varios factores externos (época del año, parches disponibles, carga de trabajo del mantenedor, etc.). La numeración de las versiones estables comienza con el número de la versión del kernel y se agrega un número adicional al final de la misma. Por ejemplo, Linus lanza el kernel 4.4, y luego las versiones estables del kernel basadas en este kernel se numeran 4.4.1, 4.4.2, 4.4.3, etc. Esta secuencia generalmente se abrevia con el número 4.4.y cuando se refiere a un árbol de lanzamiento estable del kernel. Cada árbol de versión de kernel estable es mantenido por un solo desarrollador de kernel, que es responsable de seleccionar los parches necesarios para la versión y administrar el proceso de revisión/lanzamiento.
Los núcleos estables se mantienen durante el ciclo de desarrollo actual. Después de que Linus lanza un nuevo kernel, el árbol de lanzamiento del kernel estable anterior se detiene y los usuarios deben pasar al kernel más reciente.
Núcleos estables a largo plazo
Después de un año de este nuevo proceso de lanzamiento estable, se determinó que muchos usuarios diferentes de Linux querían que un kernel fuera compatible por más de unos pocos meses. En respuesta, se creó la versión del kernel con soporte a largo plazo (LTS), con el primer kernel LTS (2.6.16) lanzado en 2006. Desde entonces, se ha seleccionado un nuevo kernel LTS una vez al año y la comunidad del kernel mantiene ese kernel durante un mínimo de 2 años.
Al momento de escribir este artículo, los kernels LTS son las versiones 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y y 5.10.y. Un nuevo kernel se lanza semanalmente. Debido a las necesidades de algunos usuarios y distribuciones, los desarrolladores de kernel mantienen algunos kernels más antiguos en un ciclo de lanzamiento más lento. Puede encontrar información sobre todos los kernels estables a largo plazo, quién está a cargo de ellos y cuánto tiempo se mantendrán en la página de lanzamientos de kernel.org .
Los lanzamientos de kernel LTS tienen un promedio de 6 a 8 parches aceptados por día, mientras que los lanzamientos de kernel estables normales contienen de 10 a 15 parches por día. La cantidad de parches fluctúa por versión dada la hora actual de la versión del kernel de desarrollo correspondiente y otras variables externas. Cuanto más antiguo es un kernel LTS, menos parches se le aplican, ya que muchas correcciones de errores recientes no son relevantes para los kernels más antiguos. Sin embargo, cuanto más antiguo es un kernel, más difícil es respaldar los cambios que se necesitan aplicar, debido a los cambios en la base de código. Por lo tanto, si bien es posible que se aplique una cantidad menor de parches generales, el esfuerzo que implica mantener un kernel LTS es mayor que mantener el kernel estable normal.
Reglas de parches de kernel estables
Las reglas sobre lo que se puede agregar a una versión estable del kernel se han mantenido casi idénticas desde su introducción y se resumen a continuación:
- Debe ser obviamente correcto y probado.
- No debe tener más de 100 líneas.
- Debe arreglar solo una cosa.
- Debe solucionar algo que se ha informado que es un problema.
- Puede ser una nueva identificación de dispositivo o una peculiaridad para el hardware, pero no agregar una nueva funcionalidad importante.
- Ya debe estar fusionado con el árbol de Linus Torvalds.
La última regla, "Ya debe estar fusionado con el árbol de Linus Torvalds", evita que la comunidad del núcleo pierda arreglos. La comunidad nunca quiere una solución para entrar en una versión estable del kernel que no esté ya en el árbol de Linus Torvalds, de modo que cualquiera que actualice nunca debería ver una regresión. Esto evita muchos problemas que pueden tener otros proyectos que mantienen una rama estable y en desarrollo.
Actualizaciones del kernel
La comunidad del kernel de Linux ha prometido a su base de usuarios que ninguna actualización romperá nada que esté funcionando actualmente en una versión anterior. Esa promesa sigue siendo válida hoy. Las regresiones ocurren, pero esos son los errores de mayor prioridad y se solucionan rápidamente o el cambio que causó la regresión se revierte rápidamente del árbol del kernel de Linux.
Esta promesa es válida tanto para las actualizaciones estables incrementales del kernel, como para las actualizaciones importantes más grandes que ocurren cada tres meses. Sin embargo, la comunidad del kernel solo puede hacer esta promesa para el código que se fusiona con el árbol del kernel de Linux. Cualquier código que se fusione con el kernel de un dispositivo que no esté en las versiones de kernel.org es desconocido y las interacciones con él nunca se pueden planificar ni considerar.
Los dispositivos basados en Linux que tienen grandes conjuntos de parches pueden tener problemas importantes al actualizar a kernels más nuevos, debido a la gran cantidad de cambios entre cada versión (10-14 mil cambios por versión). Se sabe especialmente que los conjuntos de parches de SoC tienen problemas con la actualización a kernels más nuevos debido a su gran tamaño y a la gran modificación del código del kernel específico de la arquitectura y, a veces, del núcleo. Como resultado, la mayoría de los proveedores de SoC están comenzando a estandarizar el uso de las versiones LTS para sus dispositivos, lo que les permite recibir actualizaciones de errores y seguridad directamente de la comunidad del kernel de Linux.
Seguridad
Al realizar lanzamientos del kernel, la comunidad del kernel de Linux casi nunca declara cambios específicos como soluciones de seguridad . Esto se debe al problema básico de la dificultad de determinar si una corrección de errores es una corrección de seguridad o no en el momento de la creación. Además, se determina que muchas correcciones de errores solo están relacionadas con la seguridad después de que haya pasado mucho tiempo, por lo que la comunidad del kernel recomienda enfáticamente tomar siempre todas las correcciones de errores que se publiquen.
Cuando los problemas de seguridad se informan a la comunidad del kernel, se solucionan lo antes posible y se publican en el árbol de desarrollo y las versiones estables. Como se describió anteriormente, los cambios casi nunca se describen como una "corrección de seguridad", sino que se parecen a cualquier otra corrección de errores para el kernel. Esto se hace para permitir que las partes afectadas actualicen sus sistemas antes de que el informador del problema lo anuncie.
Para obtener detalles sobre cómo informar errores de seguridad a la comunidad del kernel para que los resuelva y corrija lo antes posible, consulte Errores de seguridad en la guía del usuario y administrador del kernel de Linux en www.kernel.org .
Debido a que el equipo del kernel no anuncia al público los errores de seguridad, los números CVE para los problemas relacionados con el kernel de Linux generalmente se publican semanas, meses y, a veces, años después de que la solución se fusionó con las ramas estable y de desarrollo.
Mantener un sistema seguro
Al implementar un dispositivo que usa Linux, se recomienda encarecidamente que el fabricante tome todas las actualizaciones del kernel LTS y las envíe a sus usuarios después de que las pruebas adecuadas muestren que la actualización funciona bien. Esto tiene varias ventajas:
- Los desarrolladores del kernel han revisado las versiones en su conjunto, no en partes individuales.
- Es difícil, si no imposible, determinar qué parches corrigen problemas de "seguridad" y cuáles no. Casi todas las versiones de LTS contienen al menos una solución de seguridad conocida y muchas aún "desconocidas".
- Si las pruebas muestran un problema, la comunidad de desarrolladores del kernel reaccionará rápidamente para resolver el problema.
- Los intentos de filtrar solo los cambios que ejecuta darán como resultado un árbol del kernel que es imposible de fusionar correctamente con futuras versiones anteriores.