Récemment, le leader du développement du noyau Linux Linus Torvalds a proposé de revoir le mécanisme d'activation des correctifs STIBP (Single Thread Indirect Branch Predictors), qui offrent une protection supplémentaire contre Spectre v2.
Ces correctifs ont récemment été inclus dans la branche 4.20 du noyau Linux en cours de développement et ont été réexportés vers la version stable du noyau Linux 4.19.2.
En utilisant STIBP dans sa forme actuelle, les utilisateurs remarqué une diminution significative des performances de certaines applications lors de l'utilisation de cette technologie multithreading simultanée (SMT ou Hyper-Threading).
Étant donné que la baisse de performance peut atteindre 50%, selon les mots de Linus Torvalds lui-même, l'utilisation de la STIBP dans sa forme actuelle n'a pas de senscar il est plus facile et plus fiable de désactiver complètement SMT / Hyper-Threading, ce que font souvent les personnes soucieuses de la sécurité.
Le plus gros ralentissement causé par le nouveau noyau Linux 4.20 est dû à une atténuation pour la variante 2 de Spectre que le fondateur de Linux Linus Torvalds veut maintenant restreindre.
C'est à ce moment que se pose la question de savoir s'il est nécessaire d'activer STIBP par défaut, alors que SMT / Hyper-Threading est déjà désactivé pour ceux qui se soucient vraiment de la sécurité.
Tandis que, Pour les utilisateurs normaux, une perte de performance de 50% est un facteur important qui peut représenter certains problèmes et Il est douteux que ces vulnérabilités théoriques valent la peine d'être bloquées.
Torvalds exige que STIBP ne soit plus activé par défaut
En attendant Linus Torvalds considère qu'il est peu probable que des attaques pratiques basées sur Spectre v2 émergent comme, sur des systèmes utilisateurs normaux.
Linus Torvalds soutient que les navigateurs sont la principale cible des attaques, qui ont déjà ajouté une protection à leur niveau (la menace concerne les processus JIT isolés pour lesquels une méthode de protection sélective peut être développée).
Se propose de n'utiliser par défaut que les méthodes de protection Spectre, qui ne conduisent pas à une grosse baisse des performances, mais utilisent à la place des méthodes supplémentaires de manière sélective ou en option.
Alors pourquoi ce STIBP ralentit-il par défaut alors que les gens qui se soucient * vraiment * désactivent déjà SMT?
Je pense que nous devrions utiliser la même logique que pour L1TF - par défaut, nous ne pouvons pas supprimer les performances. Donnez un avis une fois à ce sujet et laissez les fous dire "Je préfère avoir un taux de réussite de 50% plutôt que de m'inquiéter d'un problème théorique." Linus Torvalds
L'utilisation par défaut de STIBP doit être annulée
En outre, Arjan van de Ven d'Intel a déclaré qu'Intel et AMD ne recommandent pas l'utilisation de STIBP par défaut, car que cette fonctionnalité peut être comparée à un marteau très lourd, car elle n'est pas utilisée dans le travail quotidien, mais est nécessaire dans certaines circonstances.
Il soutient que le mécanisme STIBP proposé dans la mise à jour du microcode permet de contrôler l'arrêt des caches du processeur en mettant un bit spécial dans le registre CR0, ce qui ne devrait pas être fait partout, mais seulement dans des situations particulièrement critiques.
Tim Chen d'Intel a proposé que le blocage sélectif des attaques sandbox n'inclue STIBP que lorsqu'il est explicitement demandé via prctl ou pour les processus qui interdisent la création de vidages de mémoire de base (PR_SET_DUMPABLE), tels que sshd.
En ce qui concerne la baisse des performances lors de l'utilisation des correctifs STIBP sur le noyau Linux 4.20, le résultat dépend en grande partie du type de charge.
Par exemple, les tests qui ont été menés ont montré que le package SpecInt Rate 2006 montre une réduction des performances de 21%, tandis que les tests Phoronix montrent une dégradation des performances de 3% à 20%.
Ingo Molnar, un développeur de noyau Linux bien connu et auteur du planificateur de tâches CFS, commentant la situation, a suggéré d'ajouter la liste des modifications des informations de test de performance lorsque des solutions aux problèmes sont ajoutées.