El modelo de versión estable del kernel de Linux comenzó en 2005, cuando se determinó que el modelo de desarrollo del kernel existente (una nueva versión cada 2 o 3 meses) no satisfacía las necesidades de la mayoría de los usuarios. Los usuarios querían que se corrigieran errores durante esos 2 o 3 meses, y a las distribuciones de Linux les resultó difícil mantener los kernels actualizados sin comentarios de la comunidad del kernel. En general, los intentos de mantener los núcleos individuales seguros y con las últimas correcciones de errores fueron un esfuerzo grande y confuso por parte de muchas personas diferentes.
Las versiones estables del kernel se basan directamente en las versiones de Linus Torvalds y se publican aproximadamente 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. 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 acorta con el número 4.4.y cuando se hace referencia a un árbol de lanzamiento de kernel estable. Cada árbol de lanzamiento estable del kernel es mantenido por un único desarrollador del kernel, quien es responsable de seleccionar los parches necesarios para el lanzamiento y administrar el proceso de revisión/lanzamiento.
Los núcleos estables se mantienen durante todo 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 lanzado 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 tuviera soporte por más de unos pocos meses. En respuesta, se creó la versión del kernel con soporte a largo plazo (LTS), y el primer kernel LTS (2.6.16) se lanzó 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 núcleos LTS son las versiones 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y y 5.10.y. Semanalmente se lanza un nuevo kernel. Debido a las necesidades de algunos usuarios y distribuciones, los desarrolladores del kernel mantienen algunos núcleos más antiguos adicionales 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 durante cuánto tiempo se mantendrán en la página de lanzamientos de kernel.org .
Las versiones del kernel LTS se aceptan en promedio entre 6 y 8 parches por día, mientras que las versiones estables normales del kernel contienen entre 10 y 15 parches por día. La cantidad de parches fluctúa por versión según el momento 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 pueden aplicar, 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 deben aplicar, debido a los cambios en el código base. Entonces, si bien es posible que se aplique una cantidad menor de parches generales, el esfuerzo involucrado en mantener un kernel LTS es mayor que mantener el kernel estable normal.
Reglas de parches estables del kernel
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 sólo una cosa.
- Debe solucionar algo que se ha informado que es un problema.
- Puede ser una nueva identificación de dispositivo o una peculiaridad del hardware, pero no agregar nuevas funciones importantes.
- Ya debe estar fusionado en el árbol de Linus Torvalds.
La última regla, "Ya debe estar fusionado en el árbol de Linus Torvalds", evita que la comunidad del kernel pierda correcciones. La comunidad nunca quiere que se incluya una solución 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 núcleo
La comunidad del kernel de Linux ha prometido a su base de usuarios que ninguna actualización dañará nada de lo 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 incrementales del kernel estable como para las actualizaciones importantes más importantes que se realizan cada tres meses. Sin embargo, la comunidad del kernel sólo puede hacer esta promesa para el código que se fusiona en el árbol del kernel de Linux. Cualquier código que se fusione en el kernel de un dispositivo que no esté en las versiones de kernel.org es desconocido y las interacciones con él nunca pueden planificarse ni siquiera considerarse.
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 (entre 10.000 y 14.000 cambios por versión). Se sabe especialmente que los conjuntos de parches de SoC tienen problemas con la actualización a núcleos más nuevos debido a su gran tamaño y a la gran modificación del código del núcleo 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, permitiendo que esos dispositivos reciban actualizaciones de seguridad y errores 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 correcciones de seguridad . Esto se debe al problema básico de la dificultad para determinar si una corrección de error es una solución de seguridad o no en el momento de su creación. Además, se determina que muchas correcciones de errores están relacionadas con la seguridad después de mucho tiempo, por lo que la comunidad del kernel recomienda encarecidamente tomar siempre todas las correcciones de errores que se publiquen.
Cuando se informan problemas de seguridad a la comunidad del kernel, se solucionan lo antes posible y se publican en el árbol de desarrollo y en las versiones estables. Como se describió anteriormente, los cambios casi nunca se describen como una "solución de seguridad", sino que parecen cualquier otra corrección de errores para el kernel. Esto se hace para permitir que las partes afectadas puedan actualizar sus sistemas antes de que el informante del problema lo anuncie.
Para obtener detalles sobre cómo informar errores de seguridad a la comunidad del kernel para resolverlos y solucionarlos lo antes posible, consulte Errores de seguridad en la guía del administrador y del usuario 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 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ó en 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 demuestren 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 solucionan 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 son "desconocidas".
- Si las pruebas muestran un problema, la comunidad de desarrolladores del kernel reaccionará rápidamente para resolverlo.
- Los intentos de filtrar solo los cambios que ejecuta darán como resultado un árbol del kernel que es imposible fusionar correctamente con futuras versiones anteriores.