El modelo de lanzamiento estable del kernel de Linux comenzó en 2005, cuando se determinó que el modelo de desarrollo de kernel existente (una versión nueva cada 2 o 3 meses) no cumplía con las necesidades de la mayoría de los usuarios. Los usuarios querían que se corrigieran los errores durante esos 2 o 3 meses, y las distribuciones de Linux tenían dificultades para mantener los kernels actualizados sin comentarios de la comunidad del kernel. En general, los intentos de mantener kernels individuales seguros y con las correcciones de errores más recientes fueron un esfuerzo grande y confuso de muchas personas diferentes.
Las versiones estables del kernel se basan directamente en las versiones de Linus Torvalds y se publican aproximadamente cada semana, según varios factores externos (estación del año, parches disponibles, carga de trabajo del encargado de mantenimiento, etcétera). 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 lanzó el kernel 4.4 y, luego, las versiones estables del kernel basadas en este se numeraron como 4.4.1, 4.4.2, 4.4.3, etcétera. Por lo general, esta secuencia se abrevia con el número 4.4.y cuando se hace referencia a un árbol de lanzamientos de kernel estable. Cada árbol de lanzamientos estables del kernel es mantenido por un solo desarrollador de kernel, que es responsable de elegir los parches necesarios para la versión y administrar el proceso de revisión y lanzamiento.
Los kernels estables se mantienen durante el ciclo de desarrollo actual. Después de que Linus lanza un nuevo kernel, se detiene el árbol de lanzamientos del kernel estable anterior y los usuarios deben cambiar al kernel más reciente.
Kernels 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 durante más tiempo que solo unos meses. En respuesta, se creó la versión del kernel de compatibilidad a largo plazo (LTS), y el primer kernel LTS (2.6.16) se lanzó en 2006. Desde entonces, se selecciona un nuevo kernel LTS una vez al año, y la comunidad del kernel lo mantiene durante un mínimo de 2 años.
En el momento de la redacción de este documento, 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. Se lanza un nuevo kernel semanalmente. Debido a las necesidades de algunos usuarios y distribuciones, los desarrolladores de kernels mantienen algunos kernels más antiguos con un ciclo de lanzamiento más lento. En la página de lanzamientos de kernel.org, puedes encontrar información sobre todos los kernels estables a largo plazo, quién está a cargo de ellos y durante cuánto tiempo se mantienen.
Las versiones del kernel LTS aceptan un promedio de 6 a 8 parches por día, mientras que las versiones normales del kernel estable contienen de 10 a 15 parches por día. La cantidad de parches varía según la versión, según la hora actual de la versión del kernel de desarrollo correspondiente y otras variables externas. Cuanto más antiguo sea un kernel LTS, menos parches se le pueden aplicar, ya que muchas correcciones de errores recientes no son relevantes para kernels más antiguos. Sin embargo, cuanto más antiguo es un kernel, más difícil es portar a versiones anteriores los cambios que se deben aplicar debido a los cambios en la base de código. Por lo tanto, si bien es posible que se aplique una menor cantidad de parches generales, el esfuerzo que implica mantener un kernel LTS es mayor que el de 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 mantuvieron casi idénticas desde su introducción y se resumen a continuación:
- Deben ser claramente correctas y estar probadas.
- No debe tener más de 100 líneas.
- Solo debes corregir un problema.
- Se debe corregir un problema que se informó como tal.
- Puede ser un ID de dispositivo nuevo o una peculiaridad del hardware, pero no agrega funciones nuevas importantes.
- Ya debe estar fusionado en el árbol de Linus Torvalds.
La última regla, “Debe estar fusionada en el árbol de Linus Torvalds”, evita que la comunidad del kernel pierda correcciones. La comunidad nunca quiere que una corrección se incluya en una versión estable del kernel que aún no esté en el árbol de Linus Torvalds, de modo que cualquier persona que realice la actualización nunca debería ver una regresión. Esto evita muchos problemas que pueden tener otros proyectos que mantienen una rama estable y de desarrollo.
Actualizaciones del kernel
La comunidad del kernel de Linux prometió a su base de usuarios que ninguna actualización dañaría nada que funcione en una versión anterior. Esa promesa sigue vigente en la actualidad. Las regresiones ocurren, pero son los errores de prioridad más alta y se corrigen rápidamente, o bien el cambio que causó la regresión se revierte rápidamente desde el árbol del kernel de Linux.
Esta promesa es válida tanto para las actualizaciones incrementales del kernel estable como para las actualizaciones principales más grandes que se realizan cada tres meses. Sin embargo, la comunidad del kernel solo puede hacer esta promesa para el código que se combina en el árbol del kernel de Linux. Cualquier código que se combine en 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 conjuntos de parches grandes pueden tener problemas importantes cuando se actualizan a kernels más nuevos debido a la gran cantidad de cambios entre cada versión (de 10,000 a 14,000 cambios por versión). Los conjuntos de parches de SoC son conocidos por tener 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 kernel principal. Como resultado, la mayoría de los proveedores de SoC comienzan a estandarizar el uso de las versiones LTS para sus dispositivos, lo que permite que esos dispositivos reciban actualizaciones de seguridad y errores directamente de la comunidad del kernel de Linux.
Seguridad
Cuando se lanzan versiones 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 errores es una corrección de seguridad o no en el momento de la creación. Además, muchas correcciones de errores solo se determinan como relacionadas con la seguridad después de mucho tiempo, por lo que la comunidad del kernel recomienda encarecidamente que siempre se apliquen todas las correcciones de errores que se lanzan.
Cuando se informan problemas de seguridad a la comunidad del kernel, se solucionan lo antes posible y se envían públicamente al árbol de desarrollo y a las versiones estables. Como se describió anteriormente, los cambios casi nunca se describen como una “corrección de seguridad”, sino que parecen cualquier otra corrección de errores del kernel. Esto se hace para permitir que las partes afectadas puedan actualizar sus sistemas antes de que el informador del problema lo anuncie.
Para obtener información detallada sobre cómo informar errores de seguridad a la comunidad del kernel para que se resuelvan y corrijan lo antes posible, consulta los errores de seguridad en la Guía para usuarios y administradores del kernel de Linux en www.kernel.org.
Debido a que el equipo del kernel no anuncia los errores de seguridad al público, los números de CVE para los problemas relacionados con el kernel de Linux suelen publicarse semanas, meses y, a veces, años después de que la corrección se haya fusionado en las ramas estables y de desarrollo.
Mantén un sistema seguro
Cuando implementes un dispositivo que use Linux, te recomendamos que el fabricante realice todas las actualizaciones del kernel de LTS y las envíe a los usuarios después de que las pruebas adecuadas demuestren que la actualización funciona bien. Este cambio tiene varias ventajas, por ejemplo:
- Los desarrolladores del kernel revisaron las versiones en su totalidad, no en partes individuales.
- Es difícil determinar qué parches solucionan los problemas de “seguridad” y cuáles no. Casi todas las versiones LTS contienen al menos una corrección de seguridad conocida y muchas aún son "desconocidas".
- Si las pruebas muestran un problema, la comunidad de desarrolladores del kernel reacciona rápidamente para resolverlo.
- Los intentos de filtrar solo los cambios que ejecutas generan un árbol de kernel que es imposible combinar correctamente con las versiones futuras upstream.