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é…
TL;DR : impact pour le moment négligeable sur les processeurs récents sous Windows 10. Et pour les + anciens il est assez limité.