Windows 10, Meltdown et Spectre : quel impact sur les performances ?

Publié le 07/02/2018 par
Imprimer

Quel est l'impact des premiers patchs des failles Meltdown et Spectre sur notre protocole de test CPU ? Les jeux sont ils également impactés ? Essayons de faire le point !

En début de mois, l'université de Graz  et Google Project Zero  ont annoncé avoir découvert deux failles de sécurité importantes s'appuyant sur les mécanismes de fonctionnement interne des processeurs.

Trois vulnérabilités permettant d'accéder à de la mémoire privilégiée ont été publiées, elles ont pour point commun d'exploiter les mécanismes d'exécution spéculative et les timings des caches mémoires. Vous retrouverez plus de détails dans notre article ici, et les explications techniques sur le fonctionnement et l'exploitation de certains processeurs chez Google Project Zero .

D'un point de vue pratique, toutes les failles ne touchent pas tous les processeurs, ou pas forcément de la même manière. Meltdown, la faille la plus critique (dans le sens ou elle permet un accès relativement aisé à la mémoire du noyau du système d'exploitation) est une faille qui touche spécifiquement les architectures d'Intel (et possiblement certaines implémentations ARM comme le Cortex A75).

Pour Spectre, la situation est plus compliquée. Tous les processeurs modernes sont concernés a différents niveau et l'on retrouve, y compris chez un même constructeur, des différences d'une architecture à l'autre en fonction des mécanismes précis de fonctionnement de chaque génération.

Des correctifs qui vont évoluer

Nous avons regardé dans cet article l'impact des performances dans notre protocole de test CPU sur deux processeurs : le Core i7-7700K (Kaby Lake) et le Core i7-2600K (Sandy Bridge). Le but est de voir l'impact, aujourd'hui, du patch proposé par Microsoft pour corriger ces failles de manière logicielle.

La situation évolue de manière constante, comme nous vous l'indiquions la semaine dernière, Microsoft a retiré son patch Spectre suite aux problèmes rencontrés avec les microcode fournis par Intel. Aucune nouvelle version des microcode n'est annoncée pour l'instant, nous reviendrons un peu plus en détails sur leur rôle en dessous.

Il s'agit donc de faire le point aujourd'hui, et nous aurons probablement l'occasion de revenir plus en détails sur les changements et l'impact sur d'autres familles de processeurs, mais il faut garder a l'esprit que la situation est fluide et la communication des différents acteurs, non seulement au compte goutte, mais extrêmement contrôlée par les départements légaux.

Windows 10 1607 et Windows 10 1709

Avant de regarder l'impact des patchs de Microsoft, il faut parler des version de Windows 10. Comme vous le savez peut être, nous avons choisis de réaliser tous nos tests de processeurs sur une version de Windows 10 spécifique afin d'éviter le maximum de variabilité dans nos tests. Vous retrouverez plus de détails dans cet article sur les choix que nous avions faits a l'époque l'année dernière. La version courte est que nous nous sommes concentrés sur la version dite "Anniversary Update" de Windows 10, également connu sous la version 1607.

Afin de nous assurer de mesurer correctement l'impact des derniers patchs fournis par Microsoft (le KB4056892  qui s'applique spécifiquement à la dernière version de Windows 10), nous avons avant tout comparé les performances entre la version utilisée dans notre protocole, et la dernière version "Fall Creators Update" (version 1709).

En pratique cette version change un certain nombre de petits détails pratiques qui nous ont demandé quelques adaptations. Regardons donc rapidement si des écarts sont à noter.

Performances applicatives


[ Core i7-7700K ] [ Core i7-2600K ]

Malgré le fait que nous tentons de limiter au maximum la variabilité des benchs, on ne l'éliminera jamais parfaitement et il n'est pas anormal de voir des variations sous le pourcent.

WinRAR semble cependant avoir un comportement différent sous la version 1709 de Windows. Nous avons reproduits à de multiples reprises un gain de performances net sur le Core i7-7700K (+5%), et une légère baisse de performances sur le 2600K (-1.6%).

Cela n'a qu'un impact minime sur l'indice applicatif mais afin d'être le plus précis possible, nous utiliserons ces chiffres sous Windows 1709 comme base de comparaison pour les patchs.

Performances dans les jeux


[ Core i7-7700K ] [ Core i7-2600K ]

On note de petits gains dans certains jeux de manière assez constante (nous effectuons la moyenne de 15 mesures). GTA V, Watch Dogs 2 et Battlefield 1 en tête sur les deux processeurs. On reste sous le pourcent de différence sur l'indice de performance global, là aussi nous utiliserons ces chiffres comme base de comparaison pour la suite.

Patch Meltdown et le rôle de l'instruction INVPCID

Nous avons eu l'occasion de le répéter à de nombreuses reprises, la faille Meltdown dans le monde du x86 est spécifique à l'implémentation des processeurs Intel. Cependant, tous les processeurs Intel ne vont pas être impactés de la même manière par le correctif déployé sous Windows.

Le KB4056892 , une fois installé, apporte un correctif pour Meltdown qui a deux modes de fonctionnement en fonction de la présence ou non d'une instruction x86.

Le patch dispose en effet d'un mode rapide ("low overhead") si et seulement si l'instruction INVPCID  est présente dans les processeurs. Cette instruction permet d'invalider rapidement des données liées à certains process (PCID, Process Context IDentifier) dans différentes structures internes du processeur (TLB par exemple).

Cette instruction a été ajoutée chez Intel, a ce que nous avons pu voir, avec Haswell. Résultat, le patch de Microsoft pour Meltdown, quand installé et actif, fonctionne en mode "low overhead" sur les processeurs Haswell et supérieurs (comme notre Core i7-7700K), et en mode "high overhead" (lent) sur les architectures précédentes (...comme notre Core i7-2600K !).

Impact du patch Meltdown avec INVPCID

Regardons donc dans un premier temps ce qui se passe avec le patch Meltdown en mode "low overhead" sur le Core i7-7700K. Nous comparons les résultats obtenus sous Windows 1709 avec et sans le KB4056892 installé.

Performances applicatives avec le patch Meltdown INVPCID


Il faut plisser les yeux pour voir les différences. En pratique, il n'y a que dans les tests de compilation sur notre protocole applicatif que l'on voit une différence clairement mesurable avec ce patch. Le temps de compilation augmente de quelques secondes de manière reproductible dans nos tests (on mettra de côté Stockfish dont la variabilité est un peu plus élevée) mais l'impact est assez négligeable, pour notre protocole applicatif en tout cas (d'autres scénarios peuvent être impactés différemment).

Quid des jeux ?

Performances dans les jeux avec le patch Meltdown INVPCID


En moyenne aucun impact à noter dans les jeux avec ce patch.

Le patch Meltdown en mode low overhead (avec l'instruction INVPCID) n'a donc quasi pas d'impact sur notre protocole sur le Core i7-7700K.

Impact du patch Meltdown sans INVPCID

Que se passe t il sans l'instruction INVPCID ? C'est ce que nous vérifions avec notre Core i7-2600K qui en est dépourvu ! Une fois de plus, nous comparons les résultats obtenus sous Windows 1709 avec et sans le KB4056892 installé.

A titre indicatif, notez que le logiciel InSpectre  sous Windows vous permet de déterminer si les patchs sont installés et les désactiver individuellement en manipulant la base de registre.

Avec un processeur Intel ne disposant pas de l'instruction INVPCID, et le patch Meltdown actif, InSpectre indique "Performance: SLOWER" pour indiquer le mode high overhead du patch Meltdown.

Performances applicatives avec le patch Meltdown High Overhead


En mode high overhead, l'impact est un peu plus elevé même s'il n'est pas catastrophique. On note la baisse nette dans GCC (ainsi que Lightroom) dépassant les 2%, tandis que d'autres applications perdent aussi plus légèrement, autour du pourcent. En moyenne, la baisse reste sous le pourcent sur notre indice applicatif pour ces processeurs.

Regardons la situation dans les jeux.

Performances dans les jeux avec le patch Meltdown High Overhead


On reste plutôt dans la marge d'erreur et il n'y a que sur Project Cars que l'on note une petite perte de performance que l'on peut reproduire de manière constante.

Impact du patch Spectre

En plus du patch Meltdown, le KB4056892  inclut un correctif pour les variantes spectres qui repose sur de nouveaux registres qui doivent être rendus disponibles dans les processeurs par une mise à jour du microcode. Sans mise à jour de microcode, cette protection est inactive. Il faut également que votre anti-virus (!) autorise l'activation de ce patch via une clef dans la base de registre (!).

Intel a fourni en début de mois une mise à jour de microcode pour certaines de ses architectures les plus récentes. Dans le cas de Kaby Lake, la version du microcode passe de 5E à 7E (vous pouvez voir la version du microcode de votre processeur via des outils comme hwinfo64 ).


InSpectre sur un Core i7-7700K avec le microcode et les deux patchs actifs.

Microsoft ne détaille pas exactement la manière dont il combat Spectre Variante 2, ce billet de blog  explique que Windows 10 utilise de nouvelles instructions fournies par les mises à jour de microcode mais ne rentre pas plus dans le détail. Intel a cependant détaillé cela dans un PDF  :

These capabilities will be available on modern existing products if the appropriate microcode update is applied, as well as on future products, where the performance cost of these mitigations will be improved. In particular, the capabilities are:

  • Indirect Branch Restricted Speculation (IBRS): Restricts speculation of indirect branches.
  • Single Thread Indirect Branch Predictors (STIBP): Prevents indirect branch predictions from being controlled by the sibling Hyperthread.
  • Indirect Branch Predictor Barrier (IBPB): Ensures that earlier code's behavior does not control later indirect branch predictions.

On suppose que Microsoft implémente aumoins une partie de ces techniques. Une autre stratégie pour limiter l'impact de cette faille a été proposée par Google sous le nom de retpoline, en s'attaquant cette fois aux compilateurs. Cette solution a été implémentée sous Linux en version 4.14 mais elle semble avoir un bon nombre de limites. La plus évidente est qu'il est nécessaire de recompiler le système d'exploitation (ce qui peut s'entendre) et les applications (ce qui est inapplicable en pratique dans le monde Windows).

De plus, retpoline ne semble pas être suffisant sur les architectures Intel les plus récentes (Skylake et ses dérivés) qui ont un mécanisme de spéculation plus évolué. Dans le monde Windows, l'utilisation de retpoline ne semble donc pas une solution, pour peu qu'elle en soit une sur d'autres systèmes d'exploitation.

La semaine dernière, Microsoft a poussé une mise à jour, le KB4078130  pour désactiver le patch Spectre suite aux problèmes de stabilité rencontrés dans certaines situations. Intel travaille toujours sur de nouvelles versions de ses microcode même si aucune nouvelle récente n'a été donnée sur le sujet. Nous avons tout de même testé l'impact du patch Spectre (sans le KB4078130 qui le désactive) avec le microcode installé pour voir à titre indicatif son coût. Rien ne dit que le coût restera le même avec de futures versions du microcode ou du patch, bien évidemment mais cela nous donne une première idée de l'impact.

Notez qu'Intel n'a pas fourni de microcode publiquement pour les processeurs antérieurs à la génération Haswell. Nous ne pouvons donc pas voir l'impact de ce patch Spectre sur le Core i7-2600K pour l'instant et nous contentons de vous montrer les résultats sur le Core i7-7700K.

Notez enfin pour être complet qu'Intel, suite aux problèmes de stabilité rencontrés avec ce microcode a demandé a ses partenaires de le retirer. Il n'est plus distribué par les diverses versions de Linux par exemple, et les constructeurs de cartes mères ont arrêté son déploiement dans les mises à jour de BIOS. Une nouvelle version est en cours de développement et dans l'attente Intel recommande de ne pas l'utiliser.

Performances applicatives avec les patchs Meltdown et Spectre


Cette fois ci, on commence a voir un impact dans à peu près tous les benchmarks avec une baisse entre 1 et 2% en fonction des logiciels. Les logiciels de traitement photo sont un peu plus touchés que d'autres mais c'est surtout la compilation qui est nettement impactée. Nos deux tests de compilation montrent une baisse de performance de 6% environ avec les deux patchs actifs, ce qui commence clairement à se remarquer.

Au global notre indice applicatif ne baisse "que" d'un peu plus de 2% ce qui n'est pas énorme mais n'est pas non plus non négligeable.

Performances dans les jeux avec les patchs Meltdown et Spectre


Dans les jeux, la situation varie assez fortement d'un titre à l'autre mais l'on note une tendance nette à la baisse. On perd autour de 2% sur beaucoup de titres et plus de 5% sous Civilization VI. Project Cars et Battlefield 1 sont aussi assez nettement impactés.

Sur l'indice, cela représente une baisse de performance de 2.5%.

Performances disques

Tout ce qui concerne les I/O, et particulièrement l'activité disque a souvent été pointée comme un endroit ou l'on peut perdre drastiquement en performance avec les patchs pour ces failles. Pour voir ce qu'il en était, nous avons regardé les performances sous CrystalDiskMark en regardant les IOPS obtenus en lecture et en écriture, sur 8 threads et 1 thread. Regardons ce qui se passe sur le Core i7-7700K d'abord avec les patchs Meltdown Low Overhead et Spectre :


Sur 8 threads, nous sommes limités par le disque SATA utilisé (un Samsung 850 EVO) pour notre test. Mais sur un thread (avec un Queue Depth de 32 ou 1) on note assez clairement la baisse avec le patch Spectre, tandis que le patch Meltdown de Microsoft, avec les instructions INVPCID ne change rien.

En QD32, on perd 23% de performances en lecture et en écriture, une perte qui s'amenuise en QD1 assez logiquement, mais qui atteint 5% en lecture et 17.5% en écriture tout de même.

Regardons maintenant ce qui se passe avec le 2600K :


Le niveau de performenaces est plus faible avec ce processeur mais le patch Meltdown ne semble pas vraiment avoir d'impact massif. Tout au plus en QD1 sur un thread, on note une baisse de performances de 2.5% avec le patch actif, ce qui est significativement plus faible que ce que l'on voit avec le patch Spectre.

En résumé

Etant donné l'importance de ces failles et la relative jeunesse des patchs, on restera assez prudent sur les conclusions à en tirer. En ce qui concerne Meltdown tout d'abord, les processeurs Intel récents qui disposent des instructions INVPCID (génération Haswell et supérieure) ne souffrent quasiment pas, dans notre protocole, du patch proposé aujourd'hui par Microsoft.

On note une très légère baisse de performances sur le test de compilation mais cela est assez faible pour que l'on puisse l'oublier. Dans les jeux, ou dans les accès disques, on ne note pas non plus de problème particulier, ce qui est plutôt une bonne nouvelle pour les possesseurs de processeurs Intel "récents" (a partir d'Haswell).

Pour ceux qui disposent de processeurs Intel antérieurs a Haswell, le patch utilisé par Microsoft est annoncé comme plus coûteux et on peut le voir assez légèrement dans notre protocole. Certes, il y a un impact applicatif, mais il est restreint, de même pour les IO dans notre test ou l'impact semble assez léger.

Pour Spectre, même si le patch a été retiré depuis, voir son impact est intéressant. On note que dans notre protocole, les tests de compilation sont toujours ceux qui perdent le plus significativement. Au global sur les applications et les jeux, la perte moyenne est autour de 2.5%, significatif sans être pour autant aussi catastrophique que certains cas spécifiques que l'on a pu voir dans des solutions serveurs/virtualisées. Certains scénarios grand public, comme Sysmark utilisé par Intel, peuvent montrer des baisses plus importantes.

L'impact variera probablement en fonction de la dépendance aux IOPS, un sujet sur lequel la baisse est cette fois ci très nette dans nos tests et aligné avec les chiffres annoncés par Intel.

En pratique l'impact sur notre protocole est donc, globalement, assez mesuré et c'est assez logique : notre protocole applicatif utilise des applications qui profitent du multithreading et qui sont limitées par les performances des processeurs, et non pas a une dépendance aux IOPS comme peuvent l'être d'autres logiciels plus spécifiques (bases de données et diverses charges serveurs). Voir un impact léger dans notre protocole est donc assez logique même s'il n'est pas insignifiant dans le cas de Spectre.

On comprend au passage un peu mieux pourquoi Intel a fixé précisément à Haswell la limite des microcodes rendus disponibles pour Spectre, cela coïncide parfaitement avec la disponibilité de l'instruction INVPCID qui permet de limiter l'impact du patch Meltdown. Tester l'impact du patch Meltdown en mode High Overhead et du patch Spectre de manière conjointe (par exemple sur le Core i7-2600K) montrerait des pertes logiquement plus importantes. En ne proposant pas (encore) ces microcode, Intel a évité cela.

Reste qu'aujourd'hui, la situation du patch Spectre chez Intel est devenue particulièrement compliquée. Intel n'a plus communiqué depuis le 22 janvier sur l'état de développement de son nouveau microcode (si ce n'est pour acquiescer la semaine dernière le fait que Microsoft ait retiré son patch) qu'il pousse toujours comme la solution pour ses processeurs pour contrer correctement la faille Spectre.

Et... AMD ?

Notez que si nous nous attardons sur Intel, c'est en grande partie parce qu'aujourd'hui sous Windows, seul le patch Meltdown est actif (depuis le retrait du patch Spectre par Microsoft) et cette faille ne concerne pas AMD.

Pour ce qui est de Spectre, AMD estime pour rappel que "des différences entre son architecture [et celle de son concurrent] rend l'exploitation plus complexe". Officiellement, AMD proposera des microcode... mais de manière optionnelle :

AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements.

Cette communication datait du 11 janvier . Pour le grand public, il n'y a pas à notre connaissance au moment ou nous écrivons ces lignes de microcode Ryzen public apportant le support "lourd" contre Spectre (Indirect Branch Prediction Barrier (IBPB), Indirect Branch Restricted Speculation (IBRS), Single Thread Indirect Branch Predictors (STIBP)) comme le faisaient les microcode proposés puis retirés par Intel.

La semaine dernière, AMD a publié un whitepaper (PDF)  dans lequel il décrit diverses manières de limiter l'impact des failles Spectre. Et si la méthode "lourde" y est abordée (MITIGATION V2-4), la conclusion du whitepaper danse également autour du sujet :

AMD is aligned with the x86 community that V1-1 (lfence) is the preferred variant 1 software solution and that the V2-1 (retpoline) is the preferred variant 2 software solution. AMD continues to evaluate opportunities for new mitigations in both the x86 ISA and micro-architecture for future AMD processors.

D'un point de vue de l'impact sur les performances, il n'y a pas de débat sur le fait que retpoline (return trampoline), cette technique proposée par Google  qui modifie les compilateurs pour contourner le problème est de loin la meilleure. Le problème est de savoir si elle est applicable en pratique (il faut recompiler le système d'exploitation et les applications, envisageable sous Linux, moins sous Windows pour la seconde partie, sans parler de la problématique des malwares) et suffisante (est-il possible de contourner retpoline sur certaines architectures ?), et pour ce second point, on rentre dans les détails internes des architectures sur lesquels les constructeurs ne communiquent habituellement jamais.

Comme le pointe Google dans son document présentant retpoline, il existe certaines situations ou l'on pourrait contourner la protection sur certains processeurs.

For example, on x86 the RSB or RAS define fixed capacities. Behavior with exhausted return stack predictors is not well-specified, which means we must potentially avoid underflow. For example, in the case that the hardware chose to instead turn to another predictor. To prevent this, in some cases it may be necessary to “refill” the return stack to guarantee that underflow cannot occur. (See the appendix for an example.)

Les lignes en gras pointent un problème spécifique rencontré par Skylake et ses dérivés qui rend l'utilisation de retpoline beaucoup plus complexe sur ces familles de processeurs. Il existe de multiples cas ou Skylake réclame des protections additionnelles, un débat qui a lieu publiquement sur la mailing list de développement du noyau Linux (LKML, voir cet exemple ici ).

On comprend donc aussi la situation compliquée dans laquelle s'est mis Intel avec ses microcode. Si AMD estime (à tort ou à raison, les détails non publics ne nous permettent pas de juger) qu'il n'est pas nécessaire pour ses architectures de déployer des microcode implémentant les méthodes lourdes pour Spectre, Intel se retrouvera significativement désavantagé. Et on voit mal le constructeur faire un retour en arrière en indiquant que finalement, ces microcode ne servent à rien et ne seront rendus disponibles que de manière optionnelle.

Intel a d'ailleurs poussé assez fortement pour que les méthodes IBRS/IBPB/STIBP, pourtant poussées dès le début comme "la bonne solution", ne soient implémentées que de manière optionnelle dans le noyau Linux (avec possiblement une exception pour Skylake, cf plus haut).

Le développement des patchs IBRS/IBPB/STIBP est encore en cours de développement (voir ici ) sous Linux, retpoline ayant été préféré à court terme, et il est trop tôt pour savoir quelle méthode sera nécessaire sur chaque architecture en pratique. Il sera intéressant de voir comment réagira Microsoft en fonction de ce qui se passe sur les OS concurrents.

Une situation qui risque qui plus est d'évoluer au fur et a mesure ces failles seront exploitées par divers malwares, quelque chose qui ne semble pas encore être le cas même si les variantes des Proof of Concept publiées en début d'année se multiplient actuellement .

Au final il n'y a qu'une chose dont nous sommes surs, nous sommes loin de la fin du feuilleton de ces failles de sécurité...

Vos réactions

Top articles