La faille L1TF sur les processeurs Intel aura un impact détestable sur les performances

De multiples correctifs pour les OS et un nouveau microcode pour les processeurs

La publication de la faille, le 14 août dernier, a une nouvelle fois contraint l’ensemble de l’industrie à développer des correctifs et a amené Intel à produire une mise à jour pour le microcode de ses processeurs existants afin de tenter d’enrayer d’éventuelles attaques.

Le problème est que selon le niveau de confiance et de paranoïa des utilisateurs, la seule façon radicale de prévenir tout risque est non seulement d’appliquer les correctifs, mais aussi de désactiver l’hyperthreading, ce qui, l’on s’en doute, peut avoir des conséquences particulièrement détestables sur la performance des environnements virtualisés.

Pour mieux comprendre l’impact de la faille, il est important de résumer les attaques qu’elle rend possibles. La première est une attaque sur les systèmes d’exploitation du marché. Tous les OS stockent des informations en mémoire et référencent les adresses utilisées dans des tables de pointeur (ou PTE, pour page table entry).

L1TF permet à une application malicieuse d’accéder aux informations vers lesquels pointent ces tables (alors que c’est en principe impossible) si le noyau système ne dispose pas des correctifs appropriés. Il faut donc appliquer les correctifs adéquats pour protéger les OS en place, qu’ils tournent sur des serveurs physiques ou virtuels.

La seconde attaque est plus complexe et il est bien plus délicat de s’en protéger. Si le serveur est virtualisé, L1TF permet à une VM malicieuse de s’attaquer à la mémoire de l’hôte en particulier s’il fait usage des fonctions d’hyperthreading. Sur un processeur Intel, les cœurs virtuels hyperthreadés partagent un même cache de niveau 1.

Via L1TF, il est possible à une VM tournant sur un cœur logique d’accéder au contexte d’une autre VM ou de l’hyperviseur tournant sur un autre cœur logique du même cœur physique. Pour en savoir plus le site kernel.org, qui héberge le noyau Linux propose une analyse détaillée de la faille.

Désactiver l'hyperthreading, seule solution pour se protéger à coup sûr

Cela pose un défi de taille. Soit une organisation estime qu’elle fait une confiance implicite aux applications tournant sur son infrastructure, auquel cas, appliquer les correctifs processeurs et OS est suffisant. Soit la même organisation estime que cette confiance implicite n’existe pas et il lui faut désactiver l’hyperthreading (et idéalement la fonction EPT - extended Page Table- des puces Intel) pour avoir la certitude de ne pas être vulnérable.

Une entreprise peut par exemple estimer qu’il y a toujours un risque de corruption d’une VM par un malware, puis de cascade d’exploitation via L1TF et que de ce fait elle ne peut être sûre de l’intégrité des applications tournant sur son infrastructure.

Plus grave, si cette entreprise est un hébergeur cloud opérant une large infrastructure virtualisée, il est tout simplement impossible d’être certain que ses clients ne feront pas fonctionner des applications malicieuses sur son infrastructure, avec le risque de voir ces applications corrompues accéder aux données des VM d’autres clients. La solution dépendra alors de la taille des hébergeurs.

Les plus gros pourront sans doute personnaliser leur schedulers et leurs hyperviseurs afin d’assurer que les applications d’un client ne cohabiteront jamais sur le même cœur physique que celles d’un autre client, ce qui permettra de limiter la casse. Les organisations les plus petites n’auront pas ce luxe et devront sans doute désactiver l’hyperthreading avec le risque de mettre en jeu leur modèle économique.

Un impact potentiellement élevé sur les performances

Sans surprise, Intel se veut rassurant et insiste sur le fait que L1TF n’a que peu d’impact sur les performances. Et il est vrai que l'impact reste modéré si l'on se borne à appliquer les correctifs et mise à jour de microcode. Mais le fondeur se garde bien de mettre en avant le dernier scénario, consistant à inactiver l'hyperthreading, dans ses évaluations. 

Pourtant les chiffres mêmes d’Intel font froid dans le dos. La désactivation de l’hyperthreading se traduit ainsi par une baisse de 31 % des performances au benchmark SpecVirt_sc2013 (qui mesure la performance des systèmes virtualisés), mais aussi par une réduction de 18 % du score obtenu au benchmarck de base de données HammerDB sous PostGreSQL ou par une chute de 20 % du score au benchmark Spec_jbb2015.

Pire, Intel a initialement réagi à L1TF en associant de nouvelles restrictions de licence à ses nouveaux microcodes. Ces restrictions prohibaient notamment la publication de benchmarks. La levée de boucliers de la communauté open source, et en particulier des développeurs Linux et BSD, a contraint le fondeur à faire marche arrière précipitamment.

Theo De Raadt, le mainteneur d’OpenBSD indique dans un message sur la liste de discussion technique de l’OS qu’il est persuadé que L1TF n’est que la première d’une série de failles que l’implémentation défectueuse d’hyperthreading par Intel va exacerber. Sa recommandation est radicale : « Désactivez hyperthreading dans le BIOS de toutes vos machines Intel ». Il ajoute « qu’Intel ne nous fournit aucune information sur ce qui arrive et rend un mauvais service en ne documentant pas publiquement ce que les systèmes d’exploitation doivent faire pour résoudre les problèmes ».

Red Hat estime, quant à lui, dans une note technique, que la désactivation de l’hyperthreading, seul moyen de se protéger de VM malicieuses, se traduit par des pertes de performances pouvant atteindre 50 %. L’éditeur met toutefois un bémol à son analyse : si la charge CPU des systèmes affectés est inférieure à 50 %, les dégradations de performances seront à peine détectables. En revanche, si la charge processeur des serveurs concernés est supérieure à 50 %, l’impact perçu augmente avec la charge CPU.

Selon l’éditeur, la faille pourrait avoir un impact catastrophique pour les clouds OpenStack mais aussi affecter OpenShift et Kubernetes. Encore une fois l’impact sera d’autant plus fort que la charge CPU des serveurs affectés dépassera la barre des 50 %. Notons que Red hat estime par ailleurs que le travail sur la mitigation de L1TF lui a coûté plus de 10 000 h d’ingénierie.

Vice caché ?

Ces dégradations de performances viennent bien entendu s’ajouter à celles déjà apparues après l’application des correctifs pour Spectre et Meltdown.

Intel indique que les nouvelles générations de processeurs Xeon (à commencer par les futures puces « Cascade Lake » attendues pour la fin de l’année) embarqueront des mécanismes pour se prémunir de L1TF et des failles antérieures. Cela sera toutefois une maigre consolation pour les clients de ses puces existantes.

Ces derniers pourraient même finir par se demander si l’accumulation de ces failles ne ressemble pas à un vice caché, tant l’impact cumulé des correctifs déployés depuis le début de l’année affecte la performance annoncée des processeurs du fondeur.

À notre connaissance, aucune entreprise ou association de consommateurs n’a à ce jour attaqué le fondeur en Europe pour faire jouer la réglementation sur les vices cachés. Mais, il suffirait d’une fois pour que les vannes s’ouvrent et mettent en péril les profits du fondeur.