Pour Linux 5.18, il est prévu de déplacer le code vers une version plus récente de C afin de résoudre divers problèmes. 

Qu'est-ce que Linux et à quoi ça sert ?

Au cours du processus de discussion avec les développeurs du noyau Linux à propos etl thème d'un ensemble de correctifs pour corriger les vulnérabilités de Spectre dans le code pour travailler avec des listes chaînées, c'est devenu clair pour de nombreux développeurs que le problème pourrait être résolu plus facilement si était autorisé dans le code du noyau C que est conforme à une version plus récente de la norme. 

Et c'est qu'actuellement, le code ajouté au noyau Linux doit être conforme à la spécification ANSI C (C89), qui a été créée en 1989.

Voilà pourquoi le problème lié à Spectre dans le code était parce que se a continué à utiliser un itérateur défini séparément après la boucle.

Malgré sa nature généralement rapide, le projet de noyau s'appuie sur un certain nombre d'outils plus anciens. Alors que les critiques aiment se concentrer sur l'utilisation intensive du courrier électronique par la communauté, un anachronisme peut-être plus important est l'utilisation de la version 1989 de la norme du langage C pour le code du noyau, une norme qui a été codifiée avant le début du projet du noyau il y a plus de 30 ans. Il semble que cette pratique de longue date pourrait prendre fin dès le noyau 5.18, attendu en mai de cette année.

Il est mentionné que une macro est utilisée pour itérer sur les éléments de la liste chaînée, et puisque l'itérateur de boucle est passé à cette macro, il est défini en dehors de la boucle elle-même et reste disponible après la boucle. L'utilisation de la norme C99 permettrait aux développeurs de définir des variables pour la boucle dans le bloc for(), ce qui résoudrait le problème sans inventer de solutions de contournement.

Malheureusement, il existe plusieurs emplacements dans le noyau où la liste
iterator est utilisé après la boucle qui s'interrompt lors d'un tel changement. Heureusement
il y a le script use_after_iter.cocci qui peut être utilisé pour identifier de tels
emplacements de codes. J'ai dû adapter un peu le script car il réduit les faux
positifs dans le cas d'utilisation d'origine, mais ceux-ci sont pertinents pour ce correctif.

Une grande variété d'emplacements de code signalés n'utilisent l'itérateur de liste qu'après
le cycle s'il y a eu une sortie anticipée (break/goto) et donc ils ne sont pas
pertinent.

Pour sa part, Linus Torvalds était d'accord avec l'idée pour pouvoir implémenter la prise en charge des nouvelles spécifications et a en outre suggéré de passer au noyau 5.18 pour utiliser la norme C11, publiée en 2011.

Après cela, lors de la vérification préliminaire, le montage sur GCC et Clang dans le nouveau mode s'est déroulé sans écart. À moins que des problèmes imprévus ne surviennent en raison de tests plus approfondis, les scripts de construction du noyau 5.18 remplaceront l'option '–std=gnu89' par '–std=gnu11 -Wno-shift-negative-value'.

Linus Torvalds n'aimait pas beaucoup le correctif et ne voyait pas en quoi il était lié aux vulnérabilités d'exécution spéculatives. Cependant, après que Koschel ait expliqué plus en détail la situation, Torvalds a convenu que "ce n'est qu'un bogue normal, pur et simple" et a déclaré qu'il devrait être corrigé quelle que soit la plus grande série. Mais ensuite, il s'est penché sur la véritable source du problème : que l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même :

La principale raison pour laquelle ce type d'erreur non spéculative peut se produire est qu'historiquement, nous n'avions pas de "déclarer des variables dans des boucles" à la C99. Donc list_for_each_entry() - et tous les autres - filtrent fondamentalement toujours la dernière entrée HEAD hors de la boucle, simplement parce que nous ne pouvions pas déclarer la variable d'itérateur dans la boucle elle-même.

Il convient également de mentionner que la possibilité d'utiliser la norme C17 a été envisagée, mais dans ce cas, il serait nécessaire d'augmenter la version minimale prise en charge de GCC, car l'inclusion de la prise en charge de C11 est conforme aux exigences actuelles de la version GCC (5.1).

Enfin si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant


Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.