Para Linux 5.18 se planea mover el codigo a una versión más actual de C con la finalidad de resolver diversos problemas
Durante el proceso de la discusión por parte de los desarrolladores del Kernel de Linux sobre el tema de un conjunto de parches para corregir las vulnerabilidades de Spectre en el código para trabajar con listas enlazadas, quedó en claro para muchos desarrolladores que el problema podría resolverse con más facilidad si se permitiera en el kernel código C que se ajuste a una versión más nueva del estándar.
Y es que actualmente el código agregado al Kernel de Linux debe cumplir con la especificación ANSI C (C89), que se formó en 1989.
Es por ello que el problema relacionado con Spectre en el código se debió a que se siguió usando un iterador definido por separado después del ciclo.
A pesar de su naturaleza generalmente rápida, el proyecto kernel se basa en una serie de herramientas antiguas. Si bien a los críticos les gusta enfocarse en el uso extensivo del correo electrónico por parte de la comunidad, un anacronismo posiblemente más significativo es el uso de la versión de 1989 del estándar de lenguaje C para el código del kernel, un estándar que fue codificado antes de que el proyecto del kernel comenzara hace más de 30 años. Parece que esa práctica de larga data podría llegar a su fin tan pronto como el kernel 5.18, que se espera para mayo de este año.
Se menciona que se usa una macro para iterar sobre los elementos de la lista vinculada, y dado que el iterador de ciclo se pasa a esta macro, se define fuera del bucle mismo y permanece disponible después del bucle. El uso del estándar C99 le permitiría a los desarrolladores poder definir variables para el bucle en el bloque for(), lo que resolvería el problema sin inventar soluciones alternativas.
Desafortunadamente, hay varias ubicaciones en el kernel donde la lista
iterator se usa después del ciclo que se rompe con tal cambio. Afortunadamente
existe el script use_after_iter.cocci que se puede usar para identificar tales
ubicaciones de código. Tuve que adaptar un poco el guión ya que reduce las falsas
positivos en el caso de uso original, pero esos son relevantes para este parche.Una gran variedad de ubicaciones de códigos informados solo usan el iterador de lista después de
el ciclo si hubo una salida anticipada (break/goto) y por lo tanto no son
pertinente.
Por su parte, Linus Torvalds estuvo de acuerdo con la idea de poder implementar el soporte para las especificaciones más nuevas y ademas de ello sugirió moverse en el kernel 5.18 para usar el estándar C11, publicado en 2011.
Despues de ello, durante la verificación preliminar, el montaje en GCC y Clang en el nuevo modo pasó sin desviaciones. A menos que surjan problemas imprevistos debido a pruebas más exhaustivas, los scripts de compilación del kernel 5.18 cambiarán la opción ‘–std=gnu89’ a ‘–std=gnu11 -Wno-shift-negative-value’.
A Linus Torvalds no le gustó mucho el parche y no vio cómo se relacionaba con las vulnerabilidades de ejecución especulativa. Sin embargo, después de que Koschel explicara más la situación, Torvalds estuvo de acuerdo en que «este es solo un error normal, simple y llanamente» y dijo que debería solucionarse independientemente de la serie más grande. Pero luego se adentró en la fuente real del problema: que el iterador pasado a las macros de recorrido de lista debe declararse en un ámbito fuera del bucle mismo:
La razón principal por la que puede ocurrir este tipo de error no especulativo es que históricamente no teníamos «declarar variables en bucles» al estilo C99. Así que list_for_each_entry() – y todos los demás – fundamentalmente siempre filtran la última entrada HEAD fuera del ciclo, simplemente porque no pudimos declarar la variable iteradora en el ciclo mismo.
También cabe mencionar que se consideró la posibilidad de utilizar el estándar C17, pero en este caso sería necesario aumentar la versión mínima soportada de GCC, ya que la inclusión de soporte para C11 se ajusta a los requisitos actuales para la versión GCC (5.1).
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.