AMD pourrait vendre plus de CPU serveur dédiés au cloud computing
Après le scandale des vulnérabilités matérielles touchant surtout les CPU Intel

Le , par Christian Olivier

274PARTAGES

14  0 
Rappel des faits

Grâce aux précisions fournies par Google, on sait désormais que les vulnérabilités critiques touchant les CPU modernes, et probablement toute l’industrie des semi-conducteurs, affectent surtout les CPU x86 64-bits d’Intel. Mais ces failles de sécurité touchent aussi les CPU basés sur l’architecture ARM (Apple, Qualcomm, Samsung…) et Red Hat a prévenu que des CPU d’IBM sont également concernés.

Les chercheurs de Google ont découvert que la temporisation du cache de données des processeurs modernes peut être utilisée de manière abusive pour récupérer illégalement les informations sur un ordinateur. Cette fonctionnalité est utilisée par la plupart des processeurs modernes pour optimiser les performances, mais elle peut également occasionner de graves problèmes de sécurité.

Des attaquants peuvent en effet tirer parti de l’exécution spéculative pour exploiter des processus au niveau de l’espace utilisateur en contournant la MMU et lire le contenu de la mémoire du noyau d’un ordinateur qui en temps normal aurait dû leur être inaccessible.

Le problème étant matériel, c’est-à-dire qu’il concerne la partie non reconfigurable du processeur, il ne serait pas envisageable de recourir à un patch via microcode pour corriger toutes les variantes de cette faille de sécurité. Pour remédier efficacement à ce problème, il faut recourir à une technique d’isolation de la table de correspondance ou concevoir de nouveaux processeurs.

Meltdown et Spectre

Il existe trois variantes principales de la faille de sécurité qui exploite les mécanismes d’exécution spéculative des processeurs modernes : variante 1 (CVE-2017-5753), variante 2 (CVE-2017-5715), variante 3 (CVE-2017-5754 alias Meltdown). Google les a décrites en précisant leurs mécanismes d’action respectifs. Elles ont été baptisées Meltdown et Spectre à cause des attaques de type « ;side channel ;», « ;bounds check bypass ;» et « ;branch target injection ;» auxquelles elles exposent. Spectre correspond aux variantes 1 (bounds check bypass) et 2 (branch target injection) et expose aux types d’attaques spécifiques qui y sont relatifs, tandis que Meltdown n’est concerné que par les attaques de type « ;side channel ;».

Meltdown casse les mécanismes d’isolation mémoire entre l’espace utilisateur et la mémoire noyau, permettant ainsi à un programme malveillant d’accéder à la mémoire vive de l’appareil. Spectre, pour sa part, brise la barrière entre les applications et permet d’obtenir des informations sensibles sur des applications en cours d’exécution, même si elles sont protégées. Ces vulnérabilités critiques affecteraient l’industrie des semi-conducteurs depuis au moins 1995.

La variante 1 affecte la quasi-totalité des CPU modernes. La variante 2 affecte surtout les processeurs d’Intel et d’ARM, alors que la variante 3 (Meltdown) touche de façon spécifique, pour le moment du moins, les processeurs d’Intel. Spectre est plus difficile à exploiter que Meltdown, mais est aussi plus difficile à patcher.

Le contexte actuel

Ces vulnérabilités critiques ne devraient pas pénaliser les particuliers et certains professionnels qui peuvent accepter d’utiliser leurs appareils même s’ils sont exposés à un risque avéré de piratage. Cependant, pour des acteurs opérant dans des industries aussi sensibles que celle du cloud, un tel danger et les risques auxquels il expose pourraient avoir des conséquences désastreuses. Certains experts estiment, d’ailleurs, qu’il faudra changer de processeurs ou carrément d’appareil pour être totalement protégé.

Lorsque de nouveaux processeurs exempts de la faille de sécurité décrite seront disponibles, les exploitants de serveurs concernés par ces vulnérabilités critiques devront faire un choix : remplacer les anciens équipements avec du nouveau matériel mieux sécurisé et probablement plus cher ou continuer de travailler avec l’ancien malgré les risques.

Les entreprises qui vont décider d’acquérir de nouveaux équipements vont probablement essayer de minimiser les risques en diversifiant les architectures sur lesquelles leurs activités critiques reposent. Compte tenu des performances attrayantes offertes par les derniers processeurs EPYC de la firme de SunnyVale et du fait que ses processeurs semblent, à l’heure actuelle, être les plus sûrs du marché, il ne serait pas surprenant d’assister à un regain de croissance au sein de l’activité Enterprise, Embedded et Semi-Custom d’AMD et au repositionnement de la société sur des marchés hautement stratégiques comme celui des puces serveur, notamment celles dédiées au Cloud Computing.

Le cas particulier d’AMD

AMD a récemment annoncé dans un communiqué que « ;l’ampleur de la menace et la nature des mesures à adopter concernant les trois variantes diffèrent selon le fabricant de microprocesseurs considéré, et AMD n’est pas sensible aux trois variantes ;». La firme de SunnyVale soutient que le risque serait quasi nul pour ses processeurs x86 64-bits les plus récents et les recherches menées par Google tendent à confirmer cette annonce. En effet, Project Zero, le groupe de sécurité de la firme de Mountain View à l’origine de ces révélations a démontré que les puces conçues par AMD ne sont concernées que par la variante 1 de la faille de sécurité dont il est question.

Durant la semaine qui a suivi l’annonce de ces vulnérabilités critiques, les investisseurs se sont rués sur les actions du groupe AMD, alors que ceux qui possédaient des actions chez Intel ont plutôt commencé à s’en débarrasser. C’est probablement le même réflexe qui a animé le PDG d’Intel, Brian Krzanich, lorsqu’il a décidé de vendre les actions qu’il possédait chez Intel pour 24 millions USD après que la compagnie a été informée par Google des vulnérabilités majeures affectant ses puces.

Les actions d’AMD ont connu une hausse de 10,4 % pendant les deux premiers jours qui ont suivi la publication de ce rapport, alors que les actions d’Intel ont baissé de 5,2 % sur la même période, faisant ainsi perdre environ 11,3 milliards USD aux actionnaires de la firme de Santa Clara.

L’avenir du marché des CPU pour serveurs

« ;Les clients opérant sur le long terme pourraient être plus motivés à trouver des alternatives chez AMD et éventuellement ARM pour diversifier les risques architecturaux ;», a écrit l’analyste de Bank of America Merrill Lynch, Vivek Arya, avant d’ajouter que « ;tout porte à croire qu'AMD sera le principal bénéficiaire ;» de cette situation.

AMD pourrait profiter de cette situation et en retirer « ;un avantage marketing conséquent compte tenu des différences d’architectures et du risque de vulnérabilité négligeable ;» qui caractérisent ses puces pour le moment, a déclaré Vijay Rakesh, analyste chez Mizuho Securities. Cela permettra à la société technologique américaine AMD de tirer son épingle du jeu et de regagner du terrain face à Intel sur le marché des serveurs, un marché archidominé par la firme de Santa Clara. Rakesh a noté qu’Intel détient 99 % du marché des processeurs destinés aux datacenters.

« ;L’annonce des problèmes de sécurité affectant les processeurs d’Intel et la dégradation potentielle des performances qui pourrait résulter de leurs corrections arrivent à un moment inopportun, car Intel subit actuellement une forte pression de la part de son redoutable concurrent, AMD ;», écrit Fred Hickey, rédacteur chez High Tech Strategist. En outre, « ;la nouvelle gamme de processeurs AMD représente, pour la première fois depuis de nombreuses années, un sérieux challenger (depuis l’époque des processeurs Opteron de la marque) ;», a-t-il ajouté.

« ;Pour Intel, cela signifie probablement une perte des parts de marché (baisse des revenus) ainsi qu’une perte au niveau du contrôle des prix (marges brutes moindres) ;», a confié Hickey avant de souligner que « ;les nouvelles puces d’AMD ont déjà pris de l’ampleur et cette dynamique sera probablement amplifiée par les récentes divulgations au sujet des failles de sécurité. ;»

Source : CNBC

Et vous ?

Qu’en pensez-vous ?
AMD peut-elle tirer son épingle du jeu sur le marché des CPU serveur ?
Intel aurait-elle du souci à se faire ?

Voir aussi

Processeurs x86 pour PC : AMD aurait repris 10 % de parts de marché à Intel au premier trimestre 2017, grâce à ses processeurs Ryzen ?
AMD annonce des résultats financiers satisfaisants pour son troisième trimestre grâce aux performances de sa division Computing and Graphics

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de emixam16
Membre éprouvé https://www.developpez.com
Le 06/03/2019 à 14:45
D'un côté si il a fallu 20 ans pour trouver le problème, c'était pas si mal conçu que ça à la base.
Pas systématiquement.

Dans les cas de Spectre/Meltdown/Foreshadow/Spoiler, ces failles sont effectivement relativement balèzes (même si pas non plus exceptionnelles) et c'est compréhensible qu'elles aient mis du temps à être découvertes.

Mais des failles critiques, qui tiennent très longtemps dans le systèmes sont courantes. Voici deux exemples:
- La faille WinRar découverte récemment (https://www.developpez.com/actu/2479...-utilisateurs/) est très bête. Elle exploite une faille "bête" dans un format très peu utilisé (.ace). Et comme winrar ne prend pas en compte l'extension, en renommant simplement le fichier en .rar, je peux l'exploiter très facilement et compromettre une machine.
- L'idée derrière la faille HeartBleed était très basique aussi (principe expliqué en images par xkcd ici https://xkcd.com/1354/).

En résumé, qu'une faille n'ait été trouvé qu'après très longtemps ne veut pas dire que le logiciel était bien sécurisé... Juste qu'aucun chercheur en sécurité n'a regardé au bon endroit... Et vu le nombre d'endroits à regarder c'est compréhensible.
9  0 
Avatar de e101mk2
Membre confirmé https://www.developpez.com
Le 08/01/2018 à 21:46
Entre Intel Management Engine, Meltdown et Spectre, Intel bat des records.

Les entreprises vont ce mettre à trembler dès qu'ils vont entendre parler d'Intel...
7  0 
Avatar de benjani13
Membre extrêmement actif https://www.developpez.com
Le 28/05/2018 à 11:54
Citation Envoyé par dlandelle Voir le message
Désactiver les mises à jour, mettre un firewall, ça paraît plus efficace que d'avoir peur de ces menaces bidons ;-)
- Désactiver les mises à jour? Non. Voyez ce qu'à donné le manque applications des mises à jour quand le virus WannaCry a frappé.
- Mettre un firewall? Oui. Mais ça ne protège pas de tout, loin de là.
- Des menaces bidons? Soyons sérieux, ces vulnérabilités ont des impacts démontrés. Que votre PC personnel sois touché par une de ces vulnérabilités, il y a peu de chance. Ces attaques sont difficiles, extrêmement dépendantes de l'OS et du processeur (donc il faut faire du cas par cas). Votre PC personnel n'est pas une cible assez intéressante pour y mettre ces moyens. Les cibles de ces attaques seraient principalement les fournisseurs de cloud et d'autres infrastructures du type.

Citation Envoyé par pierre++ Voir le message
Ça me rappelle que dans les années 95 j'avais écris un petit programme en C qui explorait la mémoire du système ( windows 98, puis windows 98) à la recherche de la zone où était stockée la position des mines du jeu "Démineur". Histoire de ne pas sauter sur une bombe
Là c'est un peu plus subtile puisque c'est une exploration du cache du processeur, mais je doute que ce soit très compliqué pour un bricoleur de développer ça
Effectivement c'est plus subtile car, contrairement à la RAM, le cache ne peut être accédé directement. On ne peut pas aller demander à lire la case xxx dans le cache. Là il faut trouver des astuces pour, par déduction, obtenir des valeurs dans le cache. Dans le cas de spectre cela marche comme cela:
- On vise à obtenir la valeur à l'adresse X dans la RAM sans la lire directement
- On charge la donnée à l'adresse X dans un registre du processeur (on a pas le droit de le faire, mais l’exécution spéculatif va le faire tout de même)
- Si le dernier bit de la valeur à l'adresse X vaut 1, on charge une variable A qui correspond à une adresse Y dans la RAM.
- Sinon (le dernier bit de la valeur à l'adresse X vaut 0), on charge une variable B qui correspond à une adresse Z dans la RAM.

Après tout ça, la variable qui aura été chargé (A ou B), aura sa valeur dans le cache. On procède ensuite comme suit:
- On lance un timer 1
- On charge la variable A
- On mesure le temps écoulé
- On lance un timer 2
- On charge la variable B
- On mesure le temps écoulé

Et on analyse:
- Si le chargement de A est plus rapide, donc c'est A qui a été chargé tout à l'heure. Donc la condition "est-ce que le dernier bit de la donnée à l'adresse X vaut 1" était vrai.
- Sinon, B est plus rapide et donc le dernier bits vaut 0.

Et on recommence le processus pour chaque bits de la donnée à l'adresse X, et on obtient sa valeur sans jamais l'avoir lu directement, uniquement en inférant avec le comportement du cache.
6  0 
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 15/06/2018 à 21:10
De correctif en correctif, le fière i9 sera bientôt aussi efficace qu'un 8080 si cela continue.
6  0 
Avatar de jlliagre
Modérateur https://www.developpez.com
Le 15/01/2018 à 11:52
Citation Envoyé par liberal1 Voir le message
Qu'est-ce que tu appelles interruption matérielle?
Tu as raison de poser la question. La terminologie est parfois floue et, suivant le contexte, il n'y a parfois pas consensus sur ce que recoupent les termes "trap", "exception", "interruption", etc.

J'ai assimilé un peu vite tout ce qui n'était pas interruption logicielle à interruption matérielle alors qu'un "page fault" sur du x86 n'est techniquement ni l'une ou l'autre.

Une interruption matérielle est liée à un événement extérieur et indépendante du code exécuté, c'est donc une interruption asynchrone.

Une interruption logicielle, c'est une instruction dont le rôle est d'interrompre le cours normal du code (trap, int, syscall, etc...), c'est une interruption planifiée

Une faute de page ("page fault" est aussi une exception synchrone (liée au code exécuté) mais elle n'est pas planifiée. La finalité de l'instruction entraînant cette exception n'est pas de générer une interruption, c'est juste une éventualité. La détection de cette exception se produisait dans un composant initialement indépendant des CPU (d'où ma confusion), mais les MMU sont maintenant intégrés aux CPU.

Quand elle survient dans du code utilisateur et qu'elle n'est pas ignorée, l'effet d'une interruption matérielle, logicielle ou d'une faute de page est de transférer le controle du thread affecté à une routine dédiée du système d'exploitation, via une table de vecteurs d'interruptions.

Meltdown exploite le fait que les CPU Intel autorisent du code utilisateur à (commencer à) accéder à une page du noyau sans que la faute de page attendue ne soit immédiatement remontée.
5  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 15/06/2018 à 15:42
5  0 
Avatar de jlliagre
Modérateur https://www.developpez.com
Le 15/01/2018 à 21:53
Citation Envoyé par transgohan Voir le message
Analyse intéressante, j'en viens à revoir ma définition d'une interruption matérielle du coup...

Mais du coup pour rebondir sur l'exemple des page fault, dans quelle case la rangerais-tu ? Elle a tout de l'exception matérielle si on tente de coller à tes deux définitions, mais la suite de ton message laisse à penser que tout ce qui est interne au processeur serait catégorisé comme interruption logicielle.
Ni l'une ni l'autre.

Il y a les interruptions:

  • intimement liées aux instructions en cours d'exécution sur le CPU (synchrones):
    • provoquées intentionnellement : software interrupts, instructions dédiées
    • provoquées involontairement : page-fault, division par zéro, etc. Elles sont en général inattendues mais quelques unes sont inévitables, par exemple les page-faults. Tout le mécanisme de pagination à la demande d'Unix/Linux et autres OS s'appuie sur elles.

  • pas du tout liées aux instructions en cours d'exécution sur le CPU (asynchrones):
    • peuvent survenir n'importe quand, que le CPU soit en train d'exécuter du code user, kernel our ien du tout (idle). Elles sont provoquées par un événement externe affectant un composant matériel, hardware interrupts. Elles sont aussi inévitables, sans hardware interrupts, pas de timers, d'entrées-sortie disque ou réseau, de communication USB, d'affichage video,...



Dans le même genre, que dire d'une interruption générée par un coprocesseur de communication (dédié à la gestion des SCC par exemple) ? C'est interne au processeur, mais ce n'est pas notre code qui la génère (au mieux c'est notre configuration, voir sous certains aspects totalement extérieur).
Ce que tu décris est une hardware interrupt.

Un composant extérieur peut être géré de trois façons (ou une combinaison des trois) :

  • envoi d'un interruption au processeur pour qu'il traite chaque événement le nécessitant (hardware interrupt)
  • utilisation d'un accès direct à la mémoire (DMA) pour éviter d'interrompre (trop) le processeur.
  • attente passive, c'est le driver qui va régulièrement voir s'il y a quelque chose à traiter dans le composant extérieur (polling), rare.
4  0 
Avatar de jlliagre
Modérateur https://www.developpez.com
Le 02/02/2018 à 14:27
Contrairement à Meltdown qui est une faille bien précise affectant certains processeurs, qui permet à un processus d'accéder à la mémoire du noyau et pour laquelle les parades sont bien identifiées, il vaut mieux ne pas parler de "la" faille Spectre, mais d'une nouvelle famille de vulnérabilités comportant deux vecteurs d'attaque (type 1: bound check bypass) et (type 2: branch target injection).

Spectre n'est pas une faille affectant des processeurs spécifiques, mais un effet de bord de l'architecture de la plupart des processeurs modernes. Spectre permet à un processus d'accéder à des données auxquelles on croyait qu'il n'avait pas accès.

Les documents sur Spectre indiquent que des attaques s'attaquant au processus lui-même sont faciles à implémenter, mais indiquent aussi que sont possibles des attaques plus complexes à mettre en œuvre permettant d'accéder à des données d'autres processus, au noyau et même, au delà du noyau, à des données de l'hyperviseur en cas de virtualisation.

Il n'y a donc pas une faille, mais, en fonction des processeurs, des applications, systèmes d'exploitation et hyperviseurs utilisés, un certain nombre de failles spécifiques identifiées ou non, divulguées ou non.

Corriger ces failles semble être un travail de titan. Il faut trouver des parades dans la façon de générer du code assembleur, donc modifier les compilateurs et tout recompiler. Patcher le microcode des CPU existants ne peut pas suffire car désactiver complètement l'exécution spéculative aurait un impact trop important sur les performances.
4  0 
Avatar de mattdef
Membre habitué https://www.developpez.com
Le 05/11/2018 à 14:31
Il serait grand temps de mettre fin aux technologies HT et SMT... Les CPU d'aujourd'hui ont suffisamment de cœurs (merci AMD au passage) pour ne plus avoir besoin de cet artifice.
4  0 
Avatar de CaptainDangeax
Membre éclairé https://www.developpez.com
Le 13/03/2019 à 11:34
Je suis allé il y a 2 semaines à une conférence sur les hardware trojans. Le conférencier a présenté 2 cas d'étude, mais qui sont extrèmement complexes à mettre en oeuvre et qui de plus requièrent un accès physique au matériel et qui sont en fait faciles à détecter. Donc ce vecteur d'attaque n'est pas utilisé.
Je reste persuadé qu'on risque bien plus par des attaques de social engineering, même si ça n'excuse pas Intel.
4  0 
Les fédéraux américains ont demandé à Tesla de cesser de faire des « déclarations trompeuses » sur la sécurité de la Model 3
Un expert canadien en bitcoin réussit à arnaquer un escroc, et donne l'argent à une organisation caritative
Wine sur Windows 10, ça marche grâce au sous-système dédié à Linux
Apprendre Python et s'initier à la programmation - Partie 2 : Programmation avancée, un cours de Sébastien Combéfis
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web