Spectre V2 est une série de vulnérabilités de sécurité affectant la quasi-totalité des processeurs modernes. De type fuite de données, elle donne l’opportunité à des logiciels malveillants de voler des informations confidentielles dans la mémoire, comme les mots de passe et les clés de chiffrement, là où ce ils ne devraient pas avoir accès.

Single Thread Indirect Branch Prediction (STIBP) est la solution d’atténuation des risques de sécurité contre Spectre V2 qui a été développée pour Linux.

Elle a été développée pour le noyau 4.20, puis rétro porté pour la version 4.19.2. Sur ces deux versions, elle est activée par défaut.

Malheureusement, elle occasionne des dégradations de performances considérables sur les processeurs Intel pour lequel Hyper-Threading est activé : jusqu’à 50 % !

Hyper-Threading est la version Intel de la technologie Simultaneous Multi-threading (SMT, fils d’exécution simultanée). Dans ce mode, chaque cœur du processeur se présente comme deux cœurs au système d’exploitation. Comme certaines ressources sont partagées, on obtient des gains de performance, parfois considérables, pour un coût de seulement 5 % de consommation électrique et de surface occupée en plus, par rapport à un processeur sans.

Linus Torvalds, le créateur et le superviseur de Linux, a donc décidé que dans les prochaines versions du noyau, STIBP sera désactivé. Un outil permettra aux administrateurs qui le souhaitent, de l’activer.

Il part du principe qu’à ce niveau de dégradation des performances, mieux vaut désactiver complètement l’Hyper-Threading quand la sécurité est essentielle : la dégradation de performances devrait être inférieure.

C’est d’ailleurs la stratégie déjà mise en place par OpenBSD, un autre Unix, depuis juin 2018.

Les administrateurs auront alors 4 possibilités d’activation :

STIBP

Hyper-Threading  

Non

Non

La sécurité n’est pas une considération majeure

Charges de travail ne profitant pas de l’Hyper-Threading

Non

Oui

La sécurité n’est pas une considération majeure
Charges de travail profitant de l’Hyper-Threading

Oui

Oui

Sécurité nécessaire

Charges de travail profitant de l’Hyper-Threading

Oui

Non

Sécurité maximale

Charges de travail ne profitant pas de l’Hyper-Threading

 

Aujourd’hui, le choix s’opère un peu à l’aveugle : si l’on sait que les vulnérabilités existent, on n’a guère de probabilité et aucune statistique de cas réels.

On sait que théoriquement, une attaque pourrait être lancée par un script JavaScript dans un navigateur web, qui s’approprierait les données confidentielles d’un second onglet.

Mais aucune attaque de ce type n’a été détectée à ce jour.