La protection contre Spectre titube du fait de bugs dans les correctifs de microcodes d’Intel

Les premiers correctifs de microcodes conçus par Intel pour contrer la faille Spectre sont source de redémarrages intempestifs et empêchent parfois des serveurs de démarrer. Ils ont été retirés en urgence par le fondeur et ses partenaires. Pendant qu'Intel travaille sur des correctifs, l'industrie s'intéresse à l'alternative proposée par Google : la technique retpoline

Il y a 10 jours, constructeurs et éditeurs étaient confiants dans la parade conçue par Intel pour contrer la faille Spectre. La recommandation générale était alors d’appliquer les correctifs de microcode diffusés par le fondeur (via la mise à jour firmware des BIOS des serveurs) puis de déployer des versions à jours de Linux ou Windows.

Les microcodes mis à jour par Intel étaient supposés ajouter trois mécanismes destinés à lutter contre la variante 2 de Spectre :

  • IBRS (Indirect branch restricted speculation) vise ainsi à protéger le noyau contre l’exécution d’instruction provenant d’un cache pollué par une application en mode utilisateur.
  • IBPB (indirect branch prediction barrier) qui permet de réinitialiser l’état de la prédiction de branchement.
  • STIBP (Single Thread indirect branch prediction) pour empêcher un thread tournant sur un cœur CPU d’utiliser les informations de prédiction d’un autre thread tournant sur le même cœur

Ces mécanismes devaient ensuite être utilisés par les noyaux modifiés des OS pour endiguer les exploitations potentielles de Spectre variante 2.

Une stratégie mise en péril par des bugs dans les nouveaux microcodes

Sur le papier, tout semblait donc parfait jusqu’à ce que se multiplient les retours des premiers clients faisant état de redémarrages intempestifs de serveurs voire, dans certains cas, d’impossibilité de boot de serveurs équipés de processeurs Xeon E3 et E5 v3 et v4. Initialement, Intel avait indiqué que les Xeon les plus récents, les Xeon Scalable Platform « Skylake », ne semblaient pas être affectés par ces désagréments. Mais en fin de semaine, le fondeur a finalement conhttps://newsroom.intel.com/news/firmware-updates-and-initial-performance-data-for-data-center-systems/firmé que même les microcodes des Xeon « Skylake » posaient problème et qu’il travaillait sur un correctif des correctifs.

Pour l’instant, le fondeur a diffusé de nouvelles bêtas que ses partenaires constructeurs sont en train de tester. La situation et d’autant plus surréaliste que la firme a déjà eu plus de 6 mois pour travailler sur des correctifs et les valider avec ses partenaires. De nombreux utilisateurs sont montés au créneau pour dénoncer l’amateurisme de l’industrie en général et d’Intel en particulier.

Dans les forums, on voit se multiplier les critiques reprochant au fondeur d’avoir tout d’abord tenté de minimiser sa responsabilité dans les failles, puis d’avoir sous-estimé les travaux à réaliser pour les endiguer. Et les choses pourraient ne pas s’arranger dans les semaines à venir puisque des rumeurs persistantes font état de l’émergence de failles similaires à Spectre.

Les déboires de microcodes d’Intel ont amené les constructeurs à retirer peu à peu leurs mises à jour de BIOS de leurs sites de téléchargement. Dell EMC, HPE et Lenovo ont ainsi retiré les microcodes incriminés. Puis les éditeurs de distributions Linux leur ont emboîté le pas.

Linux inclut en effet un mécanisme de mise à jour du microcode des CPU. Il suffit ainsi aux éditeurs de placer une version mise à jour des microcodes des fabricants de CPU dans le dossier /etc/firmware, pour que l’OS déploie automatiquement les correctifs.

Pour accélérer la lutte contre Spectre et Meltdown, les éditeurs de distributions ont inclus les derniers microcodes Intel avec leurs correctifs et se voient donc dans l’obligation de les retirer en urgence après avoir constaté les mêmes problèmes qu’Intel. Red Hat et Suse les ont ainsi déjà marqués comme obsolètes et n’assurent plus leur distribution.

Il est vraisemblable que de nouveaux microcodes corrigés devraient prochainement faire leur apparition, mais chat échaudé craignant l’eau froide, certains clients pourraient encore attendre pour les déployer (une attitude qui les laisse vulnérables à d’éventuelles attaques). Il est également vraisemblable que les éditeurs de distributions seront très prudents dans la distribution de ces nouveaux correctifs. Par exemple, Red Hat recommande désormais à ses clients de contacter leurs fabricants de serveurs pour obtenir de nouvelles mises à jour de BIOS pour installer les futurs correctifs de microcodes pour Spectre 2.

L’alternative « retpoline » 

Alors qu’Intel semble en difficulté, le répit pourrait à terme venir de la technique retpoline, développée par Google pour lutter contre la variante 2 de Spectre. La mise en œuvre de Retpoline requiert la mise à jour des compilateurs avec la technique et une recompilation des noyaux, packages et applications pour pallier les attaques de type Spectre.

Les premiers noyaux compilés avec des versions mises à jour de GCC sont disponibles. Mais cela n’est pas suffisant. Selon les experts c’est l’ensemble de l’écosystème applicatif qui devra être recompilé pour assurer une protection intégrale.

À ce jour, des correctifs pour les compilateurs libres GCC et LLVM sont déjà disponibles, mais il faudra sans doute beaucoup plus de temps pour que la technique s’étende aux compilateurs commerciaux et à l’ensemble des langages du marché (pour autant que cela soit possible). En attendant que l’écosystème applicatif soit « retpoliné », il n’y a pas d’autre solution que d’appliquer les correctifs de microcode dès qu’ils seront disponibles. Il faut donc espérer que les prochains microcodes Intel seront à la hauteur des attentes. Notons que le fondeur n’est pas le seul concerné. AMD propose, lui aussi, des mises à jour de microcode, et d’autres acteurs comme IBM et Oracle travaillent aussi à des mises à jour pour leurs puces Power, z et Sparc.

Pour approfondir sur x86