Suite aux informations qui circulaient ces derniers jours (voir notre actualité), Project Zero, le groupe de sécurité de Google a décidé d'avancer la date de l'embargo concernant non pas une, mais deux failles massives qui s'attaquent au fonctionnement interne des processeurs.

Deux failles distinctes ont été dévoilées simultanément (ce qui explique la confusion entretenue ces dernières heures par certaines sociétés dont Intel), Meltdown et Spectre .

Meltdown, exploitation anormale des caches, ne touche qu'Intel à ce jour

La première faille, Meltdown (CVE-2017-5754), est celle qui était évoquée ces derniers jours. Il s'agit d'une faille qui permet de bypasser les mécanismes d'isolation mémoire entre mémoire classique (utilisée par les applications) et mémoire kernel (utilisée par le noyau du système d'exploitation, et protégée normalement par des mécanismes hardware dans le CPU). Meltdown est une attaque side channel  qui s'attaque à une faille de certains processeurs OOO (Out Of Order, la plupart des processeurs performants modernes depuis le Pentium Pro) qui, dans leur mécanismes d'exécution spéculatifs, peuvent non seulement lire des données mémoires protégées mais aussi exécuter des instructions sur ces données mémoires.

Le papier publié par l'université autrichienne de Graz (qui a trouvé cette faille en simultanée avec l'équipe de Google) s'accompagne d'explications détaillées  qui montrent qu'il est possible de lire tout type de mémoire à partir d'un process malicieux, y compris côté serveur de bypasser toutes les protections de type VM/Hyperviseur/Docker.

Cette vulnérabilité est massive, mais on peut la contourner en forçant une isolation plus forte au niveau du système d'exploitation (voir notre article précédent sur l'implémentation KPTI du noyau Linux).

Meltdown ne concerne, pour l'instant, que les processeurs Intel et n'a pas été démontré de manière effective ailleurs. Les processeurs Intel ne respectent pas l'isolation kernel de la mémoire dans leur algorithme d'exécution spéculative, et c'est cette faille qui est exploitée.

A noter qu'Apple a également indiqué avoir patché iOS et tvOS  pour Meltdown sans préciser si la faille touchait précisément ses architectures ARM custom, ou s'il s'agissait juste de protéger les versions x86 d'iOS et de tvOS utilisées pour les simulateurs fournis avec ses outils de développements.

Nombre de systèmes d'exploitations ont déjà été patchés, c'était le cas de MacOS en novembre, Microsoft est en cours de déploiement de son patch, et dans le monde Linux le patch est en cours de finalisation également. Vous trouverez plus d'informations sur le site mis en place pour l'occasion  avec des liens directs vers les différents fournisseurs de matériel et de système d'exploitation (ou de solutions de virtualisation). Comme nous l'indiquions dans notre news précédente, au delà de quelques benchmarks théoriques assez spécifiques (notamment autour des I/O), l'impact pour le grand public sur les performances de ces patchs devrait être réduit. Pour le monde serveur, de multiples benchmarks montrent un impact, parfois dans des cas d'école, parfois d'autres non, qui semblent toucher plus spécifiquement les logiciels type base de données.

Il est impératif, vu la criticité du problème, d'appliquer ces patchs sur les systèmes utilisant un processeur Intel, étant donné qu'elle est relativement facile a exploiter.

Spectre, deux failles sur le même thème, qui touchent tout le monde

En parallèle à Meltdown, une autre faille a été dévoilée baptisée Spectre. Il s'agit toujours d'une variation sur le même thème, à savoir tenter d'exploiter les mécanismes d'exécution spéculative des processeurs. Il est difficile de classer la gravité des failles, dans un sens elle est moins grave que Meltdown car elle ne permet pas de s'attaquer à la mémoire noyau directement (Meltdown repose sur le bug d'implémentation spécifique des architectures Intel) mais uniquement à la mémoire "utilisateur".

Le papier décrit deux attaques distinctes. La première, connue sous le nom de CVE-2017-5753 (bounds check bypass) permet à un process d'accéder, dans certains conditions un peu plus complexes, à la mémoire d'un autre process (ou forcer une VM a partager des données qu'elles ne devrait pas, a noter que Google Project Zero a publié un PoC permettant, dans certaines conditions assez précises/complexes, d'attaquer la mémoire kernel de manière indirecte). Contrairement à Meltdown dont l'exploitation est triviale, il faut ici connaître les spécificités du programme que l'on attaque pour réussir à l'exploiter (rien d'impossible, bien évidemment !).

Le groupe Google Project Zero a montré que cette attaque était exploitable aussi bien sur les CPU Intel, AMD (FX et APU), et ARM (un Cortex A57 à été testé). Si tous les processeurs sont exploitables, c'est que tous les modèles OOO modernes reposent, dans les grandes lignes, sur l'algorithme de Tomasulo , du nom de l'ingénieur qui l'a développé en 1967 chez IBM.

Virtuellement, tous les systèmes (du serveur au smartphone) sont vulnérables à cette attaque pour laquelle des PoC existent même en Javascript (pour bypasser les barrières des VM qui isolent le code Javascript de vos différents onglets), ce qui la rend assez grave. Des méthodes de mitigations, aussi bien au niveau des compilateurs, des navigateurs, et des systèmes d'exploitations sont en cours de développement et des patchs sont attendus rapidement pour limiter le problème.

Côté navigateurs, Firefox a publié une première salve de modifications  pour éviter un certain type d'attaque (celles qui mesurent le temps entre deux instructions, en réduisant la résolution des instructions de mesures) mais ce n'est qu'un début, des changements plus importants devraient intervenir dans de prochaines versions au niveau de la VM Javascript. Google et Apple ont indiqué que les prochaines versions de Chrome et Safari ajouteraient des protections spécifiques également.

La seconde variante de Spectre (CVE-2017-5715, branch target injection), est cette fois spécifique une fois de plus à Intel et s'attaque aux mécanismes de branchement d'Haswell en permettant à un process root, dans un environnement virtualisé, d'accéder à la mémoire de l'hyperviseur. Intel, pour corriger ce problème, a déployé une mise à jour de microcode qui ajoute de nouvelles possibilités pour contrer de manière logicielle le problème via de futurs patchs dont on ne connaît pas encore forcément l'impact pratique (on notera la sortie sur le sujet de Linus Torvalds ).

En bref

Si Intel a tenté de minimiser par sa communication la manière dont il était touché par ces problèmes, en pratique, ce sont bien ses processeurs qui sont touchés le plus fortement à court terme avec la faille critique Meltdown. L'impact des patchs, pour les utilisateurs grand public devrait être relativement nul sur les performances mais dans des situations spécifiques et des charges serveurs, l'impact sur les performances pourra être ressenti ce qui ne ravira pas les clients Pro d'Intel (un premier exemple concret est Epic, derrière le jeu Fortnite à indiqué avoir constaté une très forte augmentation de la charge CPU  suite à l'application du patch Meltdown sur AWS, ce qui cause des problèmes de login sur son titre). En tentant de mélanger les deux failles dans sa communication à la presse, la société ne sort pas non plus grandie d'autant plus qu'une deuxième faille, dans la famille Spectre, s'attaque spécifiquement là aussi à ses processeurs !

Malgré tout, Spectre est de loin la vulnérabilité qui nous préoccupe le plus dans le sens ou l'on peut imaginer bien d'autres variantes que les deux évoquées par Google (on vous recommande si vous souhaitez plus de détails la lecture de ce post assez long ), dont certaines liées à des architectures précises (comme le cas de celle d'Haswell).

Et si AMD (probablement un peu vexé d'avoir été pointé du doigt par Intel) s'est empressé de contre communiquer en indiquant ne pas être vulnérable à deux des trois PoC présentées aujourd'hui (ce qui est vrai), il faut rester relativement prudent tant l'on risque de voir des variantes de Spectre se multiplier dans les années à venir et qu'il ne semble pas y avoir de solution miracle, à part patcher les failles trouvées au fur et à mesure qu'elles seront rendues publiques.

La complexité des scénarios d'utilisation modernes des processeurs, entre le code Javascript dans les navigateurs qui ouvre des portes à tout le monde (littéralement dans le cas des publicités, sans parler du futur potentiel désastre qu'est WebAssembly !), mais aussi l'utilisation mutualisée dans les Cloud qui se multiplie en baissant toujours plus les barrières de sécurité (le passage des VM aux solutions types Docker) ont massivement multiplié les surfaces d'attaque. Les modèles de sécurité, conçus en grande partie durant les 50 dernières années, vont devoir être réévalués sérieusement par toute l'industrie car l'on risque de reparler pendant encore un long moment des variantes de Spectre.

Des chercheurs semblent avoir détecté une vulnérabilité assez importante dans les CPU modernes, qui ne concernerait, c'est encore spéculatif, que les processeurs Intel. Les informations autour de ce bug sont assez limitées, les méthodes de mitigations sont connues mais pas exactement les méthodes d'attaques qui restent sous embargo.

Tout semble partir de ce blog datant de juillet dernier  qui décrit une tentative (a première vue ratée) d'accéder à la mémoire protégée (la mémoire utilisée par le noyau/kernel) à partir du mode utilisateur (userland, l'espace mémoire utilisé par les programmes classiques) avec les risques (massifs) que cela implique question sécurité. La méthode décrite sur le blog tente d'exploiter les mécanismes d'exécution spéculative intégrés dans les CPU modernes.

Pour rappel, les processeurs modernes, depuis le Pentium Pro, sont de type OOO (Out Of Order), non seulement les instructions des programmes ne sont plus exécutées les unes derrière les autres exactement dans l'ordre dans lequel elles existent dans les programmes (certaines instructions sont anticipées, l'exemple typique est le cas des chargement en mémoire, dont la latence est coûteuse), mais elles peuvent être exécutées en parallèle par différentes unités d'exécution.

Le vecteur proposé s'attaque à ce mécanisme en tentant d'exploiter le moment entre lequel une instruction non autorisée (une lecture d'une adresse mémoire non autorisée) est exécuté et celui ou il génère une erreur (une interruption). L'auteur du blog indique ne pas avoir réussi à lire la mémoire protégée via sa méthode, mais note que le chargement mémoire interdit est bel et bien effectué par le CPU même s'il ne copie jamais l'information dans le registre. Il note que l'exécution spéculative continue (dans les unités d'exécutions internes) jusqu'à ce que l'interruption soit effective, ouvrant la voie vers de multiples attaques potentielles basées par exemple sur les temps d'exécution des instructions  pour déterminer les adresses mémoires utilisées par le kernel, et potentiellement d'autres types d'attaques.

Connaître les adresses mémoires utilisées par le kernel, a partir d'un programme userland, est quelque chose que les systèmes d'exploitation tentent de rendre impossible par différentes techniques depuis des années, une des méthodes les plus efficace étant l'ASLR (Address Space Layout Randomization ) pour rendre aléatoires les adresses mémoires utilisées par les applications (et le kernel).

Depuis fin octobre, un patch est en développement pour Linux  pour tenter d'imposer de nouvelles restrictions et mieux protéger les espaces mémoires du noyau. Ce patch a été significativement réécrit et porte le nom de KPTI (Kernel Page-Table Isolation) qui comme son nom l'indique tente de séparer les tables qui pointent vers les pages mémoires utilisées par le noyau de toutes les autres.

Ce patch qui est encore en cours de développement mais il est significatif par son coût important sur les performances pour certains types d'applications. En pratique, ce sont les applications qui effectuent beaucoup d'appels aux instructions systèmes (syscall) qui sont les plus touchées.

Les premiers benchmarks réalisés sur ces nouveaux patchs par nos confrères de Phoronix  pointent des chutes de performances très significatives dans les benchmarks théoriques sur les I/O disques. Pour les tests pratiques, les plus gros perdants semblent être (assez logiquement) les logiciels de base de données avec des impacts variables jusqu'ici allant de 6%  à 25%  pour Postgres. Redis, dans la même veine, semble également notablement impacté.

Microsoft a été réactif en appliquant également un patch de ce type

Pour une utilisation non serveur, tout semble pointer vers un impact nul ou infinitésimal, pour preuve, Microsoft semble avoir également appliqué le même type de patch dès novembre dans Windows 10 . Au delà de benchmarks synthétiques, l'impact devrait être réduit, on peut le voir dans les benchs de Phoronix ou FFMpeg, x264 et la compilation d'un noyau Linux ne sont pas impactés.

Côté serveur l'impact est donc plus large, et semble toucher assez massivement les infrastructures Cloud où la virtualisation est largement utilisée et cette dernière particulièrement utilisatrice de syscalls pour isoler les espaces mémoires des machines virtuelles.

L'impact pratique final restera a mesurer, ce patch sera déployé dans la prochaine version du kernel (4.16) d'ici quelques semaines. Et il sera important de suivre quels CPU seront concernés en pratique. Car si le patch tel qu'appliqué actuellement sur le git  est appliqué de manière indiscriminée à tous les processeurs x86 (les architectures ARM/RISC ne semblent pas touchées), AMD a demandé a ce que ce patch ne soit pas appliqué sur leurs processeurs , indiquant que les microarchitectures du constructeur n'autorisent pas les références mémoires et les exécutions spéculatives qui semblent pointées par le premier blog plus haut dans cet article.

Il sera intéressant de suivre si, oui ou non, ce patch d'AMD sera accepté dans les prochaines semaines. On suppose qu'AMD dispose de détails encore sous embargo pour clamer ne pas être touché même s'il faut probablement être assez prudent sur la question tant que les détails ne sont pas dévoilés publiquement.

De nouvelles puces AMD viennent de passer les tests de compatibilités du PCI-SIG , les chipsets AMD Série 400. Elles utilisent le nom de code Promontory 400 Series, Promontory étant également utilisé par la génération 300 (X370, B350, A320).

Il ne s'agit toutefois pas d'un simple renommage puisque le PCI-SIG précise que les tests ont été effectués en PCIe 3.0 x4, là où la génération 300 se contentait du PCIe 2.0 x4. Sur plate-forme AM4 le port M.2 fonctionnant en PCIe 3.0 x4 est en effet connecté directement au processeur et non au chipset.

Le lien entre le chipset et l'AM4 devrait toutefois rester en x4 Gen3, on sera donc (très) loin de pouvoir exploiter pleinement la bande passante cumulée des différentes E/S supportées par le chipset qui en version "X470" proposera donc probablement 8 lignes Gen3 mais aussi des ports USB 3.1/3.0 et des ports SATA 6Gb/s !

Le lancement de ces chipsets devrait intervenir en même temps que les nouveaux Ryzen attendus pour mars.

Intel a lancé la semaine passée ces Gemini Lake, qui prennent la suite d'Appolo Lake. Destinés à l'entrée de gamme ces SoC intègrent 2 à 4 coeurs x86 basés sur l'architecture low power d'Intel, moins performant que ceux utilisés sur les CPU classiques, et 12 à 18 Executions Units côté graphique cette-fois identiques. Le tout est gravé en 14nm et trois versions desktop et trois versions mobiles sont lancées :

• Pentium Silver J5005 : 4C @ 1.5-2.8 GHz, 18 EU @ 250-800 MHz, 10W, 161$
• Celeron J4105 : 4C @ 1.5-2.5 GHz, 12 EU @ 250-750 MHz, 10W, 107$
• Celeron J4005 : 2C @ 2.0-2.7 GHz, 12 EU @ 250-700 MHz, 10W, 107$
• Pentium Silver N5000 : 4C @ 1.1-2.7 GHz, 18 EU @ 200-750 MHz, 6W, 161$
• Celeron N4100 : 4C @ 1.1-2.4 GHz, 12 EU @ 200-700 MHz, 6W, 107$
• Celeron N4000 : 2C @ 1.1-2.6 Hz, 12 EU @ 200-650 MHz, 6W, 107$

 

 

Ce qui distingue principalement les versions mobile et desktop est le TDP, et bien entendu par voie de conséquence les fréquences, avec 6W d'un côté et 10W de l'autre. Du côté des E/S l'iGPU peut gérer jusqu'à 3 écrans et la 4K @ 60 Hz est de la partie. On a par ailleurs droit à 6 lignes PCI Express Gen2, 8 ports USB 2.0/3.0 et 2 SATA 6.0 Gb/s.

Les tarifs annoncés semblent un peu élevés vu la cible de ces produits, mais sur ce type de gammes les OEM ont souvent droit à des rabais non négligeables. On notera que par ailleurs les Pentium Kaby Lake deviennent des Pentium Gold, en opposition donc aux Pentium Silver basés sur Gemini Lake.

Une présentation AMD dont une photo a été publiée sur MOEPC.net  fait mention d'une seconde génération de Ryzen dont le lancement semble prévu à la fin du premier trimestre 2018.

Il ne devrait pas y avoir de changement architectural majeur, Zen 2 étant prévu en 7nm et pas avant 2019. Cette itération pourrait par contre profiter de la version "14nm+" de Zen mentionnée sur les roadmap officielle, ce process ayant finalement pris l'appellation de 12LP chez GlobalFoundries et AMD ayant confirmé son utilisation l'an prochain.

Reste à voir ce qu'il apportera en pratique et quelles seront les autres améliorations qu'aura pu apporter AMD à Zen, en attendant Zen 2.