Intel et AMD ont des (bons) plans pour dépoussiérer la gestion matérielle des interruptions x86

Si jamais l’idée saugrenue vous venait de programmer un système d’exploitation compatible x86, la gestion des interruptions risque de vous donner du fil à retordre, et pas qu’un peu. Héritée des méandres de la rétrocompatibilité avec les anciens 80286, 80386 et 80486 — rétrocompatibilité qui a d’ailleurs mené à des sempiternels conflits entre matériel et logiciel — son principe est en apparence simple : définir les routines que le processeur doit exécuter lorsqu’il est notifié d’un événement, externe ou interne.

Parmi les causes d’interruptions se trouvent trois catégories : celles générées par les périphériques — typiquement le clavier ou un timer — le genre de chose qui ne doit surtout pas être ignoré —, celles logicielles (dont les appels système font partie), qui permettent par exemple d’afficher du texte à l’écran lors des étapes suivant immédiatement le boot, et les erreurs internes du CPU, la plus connue étant certainement la Segmentation Fault signalant un accès invalide à la mémoire.

Un schéma simplifié du bouzin, par Alex Dzyoba

Pourquoi changer un système qui fonctionne ?

Certes, la programmation du bousin est un enfer, mais dans l’état actuel, les choses fonctionnent (presque), et il est rare de devoir retoucher à cette partie du code étant donnée son ancienneté... Mais vous vous doutez que la technique de l’autruche n’est pas éternelle. En effet, l’implémentation telle qu’elle est aujourd’hui soufre de problèmes structurels majeurs : d’une part, de nombreux choix de design se sont révélés extrêmement malheureux, menant à un code incompréhensible et donc difficile à maintenir et débuger... ce qui a entraîné des inexorables failles de sécurité ; et, d’autre part, les performances qui en découlent sont — de manière assez peu surprenante — mauvaises. Ainsi, que ce soit chez AMD ou Intel, deux projets de coup de balai majeurs sont menés (de front) pour y remédier.

Chez AMD, la solution se nomme Supervisor Entry Extension, et consiste à rustiner les comportements problématiques de l’implémentation originelle, en particulier en ce qui concerne les appels système et le problème des exceptions réentrantes (lorsque le CPU rencontre à nouveau une exception du même type dans le code servant, justement, à traiter cette même exception, entraînant potentiellement une boucle infinie). Le code encore en utilisation est donc en partie réutilisable ; néanmoins, la spécification reste un brouillon — datant de février 2021 — contenant encore de nombreuses zones « à définir » : le problème est donc loin d’être réglé.

Chez Intel, l’approche est plus radicale, et se nomme Flexible Return and Event Delivery (FRED) : on rajoute un bit permettant de désactiver le comportement précédent, le rendant ainsi obsolète. Cette approche induit un coût bien plus élevé en matière de logiciel, mais a l’avantage de pouvoir envoyer aux oubliettes un certain nombre de mécanismes désuets de nos jours, à savoir les Ring 1 et 2 ainsi que les registres de segmentation mémoire (voir paragraphe suivant, vous ne serez pas déçu !). Bien que cette spécification soit plus récente que celle d’AMD (mars), elle reste encore également largement préliminaire.

Sur RealWorldTech, le père du noyau Linux, Linus Torvalds, s’est exprimé à ce sujet, et — une fois n’est pas coutume — accueille avec bienveillance les deux approches (ce n’est, en fait, pas si étonnant que cela, la communauté des programmeurs bas niveau ayant particulièrement souffert des divers bugs liés aux mauvaises configurations de la table des interruptions). Nous ne résistons par contre pas à la tentation de transcrire son tact habituel, ici à propos des Ring permettant la gestion des privilèges en matériel (aujourd’hui, seuls le Ring 0, mode noyau, et le Ring 3, mode utilisateur, sont en usage) :

L’idée générale de « un ring pour les applications, un pour les pilotes de périphériques, et un pour les gouverner tous » n’était juste qu’une fan-fiction horriblement mauvaise de l’œuvre de Tolkien.

Ou encore, à propos des segments (un ancien mécanisme permettant le cloisonnement mémoire inter-processus, aujourd’hui supplanté par l’adressage virtuel et les tables des pages, si bien que les registres incriminés, dont le fameux GS, ne servent plus du tout à leur fonction originelle) :

Si vous pensez que vous en avez besoin, ou que vous les voulez absolument (mis à part pour une rétrocompatibilité désuète), je vous suggère de réexaminer vos choix de vie.

De toute manière, les processeurs équipés ne risquent pas de sortir avant plusieurs années — plutôt cinq ou dix qu’une — autant dire que les communautés impactées ont encore le temps de débattre plus ou moins posément sur l’attitude à adopter ; sachant qu’un support double (ancienne version/version AMD et nouvelle version Intel en parallèle) n’est pas forcément à proscrire, car permettant une transition moins houleuse en matière de compatibilité. Affaire à suivre ! (Source : ZDNet)