Spectre, Meltdown et Hana

Fin 1967, les bases de ce que nous appelons aujourd'hui "out-of-order execution" ont été posées, vers une parallélisation au niveau du processeur principal et donc une meilleure utilisation des capacités disponibles et finalement un meilleur débit de l'ensemble du système.

Les failles de sécurité ne remettent certes pas en cause ces acquis, mais les mesures de protection nécessaires limitent dans un premier temps leur utilisation pratique sous certaines conditions, mais surtout, des répercussions sur le débit global du système sont possibles.

J'aimerais aborder le sujet en quatre étapes : premièrement, que sont Spectre et Meltdown et qui est concerné ? Deuxièmement : que pouvons-nous faire ? Troisièmement : qu'a fait Suse jusqu'à présent et que prévoyons-nous pour les prochains mois ? Et quatrièmement : pourquoi certains fabricants ne donnent-ils pas de chiffres concrets sur la perte potentielle de performance du système ?

1. qui sont les victimes de Spectre et de Meltdown ?

L'extension de l'"exécution hors ordre" dont il a été question plus haut a eu pour conséquence que les CPU peuvent aujourd'hui exécuter des parties de programme alternatives avant même que l'on sache laquelle des options doit être exécutée.

Pendant cette exécution "spéculative", des failles apparaissent, dans lesquelles les mécanismes de protection de la mémoire habituellement présents entre le noyau du système d'exploitation et les processus ou entre les processus eux-mêmes n'interviennent plus, ce qui peut entraîner des accès non autorisés (voir tableau 1).

Comme le défaut se situe au niveau du matériel, le niveau logiciel (c'est-à-dire le système d'exploitation et les programmes d'application) ne se rend même pas compte de cet accès. Chaque famille actuelle de CPU performantes est concernée par une ou plusieurs des erreurs possibles (voir tableau 2).

2. que pouvons-nous faire ?

La solution la plus évidente - le remplacement de toutes les unités centrales - n'est manifestement ni économiquement viable ni pratiquement possible : toutes les unités centrales de serveurs actuelles (y compris celles d'autres architectures et fabricants que ceux mentionnés ci-dessus) sont concernées.

Une solution complète des problèmes de sécurité n'est pas possible uniquement dans le logiciel (donc sur la base du système d'exploitation ou de la couche d'application). Il ne reste donc plus qu'à "colmater" la brèche autant que possible - en anglais, on trouvera donc principalement le terme de "mitigation" plutôt que celui de "fix" - en combinant des modifications de l'unité centrale elle-même (si elle peut être modifiée par ce que l'on appelle le microcode) et des modifications du système d'exploitation.

Ces modifications visent soit à empêcher totalement la "spéculation" au niveau de l'unité centrale, soit au moins à empêcher un autre processus/application/machine virtuelle d'accéder à des données étrangères en mémoire principale (voir tableau 3).

Dans le tableau 3, on remarque certainement la formulation quelque peu ambiguë "et/ou". Cette formulation suggère l'un des défis fondamentaux de la communication par les fabricants de logiciels et surtout de systèmes d'exploitation comme Suse :

Pour la variante 2 de Spectre en particulier, il n'est pas possible de trouver une solution simple et univoque, car selon le fabricant de l'unité centrale, le type d'unité centrale et la génération de l'unité centrale, une autre solution doit être adoptée. Nous y reviendrons dans la section 4.

3. qu'a fait Suse et que prévoit Suse ?

Début janvier, Suse a publié un premier ensemble de correctifs pour toutes les versions de Suse Linux Enterprise actuellement prises en charge, y compris bien sûr Suse Linux Enterprise Server for SAP Applications, qui limite le risque de Spectre (variante 1), prépare le noyau du système d'exploitation pour les approches décrites de Spectre (variante 2) et corrige Meltdown (variante 3) au moins pour l'architecture x86-64.

Sur la base des commentaires de nos partenaires matériels et de nos clients, nous proposons depuis la mi-février, dans une deuxième vague de mises à jour du noyau, une approche améliorée de Spectre (variante 2) pour l'architecture x86-64, appelée "retpolines", et améliorons les performances notamment en surveillant plus finement les accès mémoire.

Ce travail d'amélioration constante de la sécurité et d'ajustement plus fin des accès et des restrictions prendra encore des mois, voire des années selon certains experts en sécurité.

4. pas de chiffres concrets ?

Chaque application, et même l'utilisation spécifique d'une application et les données correspondantes, contribuent à déterminer si et comment les correctifs de sécurité ont un impact (voir tableau 4).

Il ressort presque naturellement de ce qui précède qu'il n'est pas possible de faire une déclaration générale sur l'impact des mises à jour de sécurité sur le débit global d'un système ; en effet, chaque déclaration n'est valable que pour une combinaison spécifique des quatre facteurs suivants :

1. Type d'application
2. Données sur lesquelles l'application opère
3. Architecture CPU/matériel
4. le type et la génération de l'unité centrale, y compris la disponibilité des mises à jour du microcode, notamment en ce qui concerne la variante 2 de Spectre (voir ci-dessus, section 2).

Le mieux que l'on puisse dire est que les applications qui effectuent de très longs calculs dans l'unité centrale sans accéder à la mémoire sont les moins touchées. J'espère que ces explications permettront de comprendre pourquoi, du point de vue de Suse, il est plus sérieux de ne pas publier de chiffres sur l'impact des mises à jour de sécurité actuelles sur les performances, même si un tel impact semble inévitable en fonction des circonstances.

Nous conseillons néanmoins à tous nos clients d'appliquer le plus rapidement et le plus régulièrement possible les mises à jour du système d'exploitation et du microcode dans le cadre de leurs processus de gestion du changement, afin de minimiser les risques liés à cette famille de failles de sécurité nouvellement découvertes - et pourtant étonnamment anciennes.