Vulnérabilité Spectre : Google publie une nouvelle technique de mitigation
Elle introduirait un impact négligeable sur les performances des machines

Le , par Patrick Ruiz, Chroniqueur Actualités
Meltdown et Spectre… Seulement trois jours et l’on compte déjà une panoplie d’articles au sujet de ces vulnérabilités. Comment s’en prémunit-on ? Quel est l’impact des correctifs sur les performances des ordinateurs ? Voilà autant de questions que la communauté s’est posées jusqu’ici et auxquelles ces derniers ont apporté des réponses en fonction des éléments à leur disposition. À la manière des changements qui ont cours avec les puces, les nouvelles informations fusent. À ce propos, Google a apporté une nouvelle contribution à ces développements avec la publication d’une technique de mitigation baptisée Retpoline.

Référence faite aux publications de recherche dévoilées par la firme de Mountain View, la vulnérabilité Spectre est dotée de deux variantes. Retpoline apporte une réponse additionnelle à la seconde. Une bonne nouvelle pour l’industrie qui, à côté de la modification du microcode des processeurs comme solution à cette vulnérabilité, dispose désormais d’une alternative. D’après Paul Turner son auteur, il s’agit d’une technique de modification des binaires qui protège contre les attaques de type « branch target injection. » « Il existe une séquence de code appelée Retpoline qui permet d’effectuer des appels indirects sans spéculation », explique à son tour Andy Kleen, développeur chez Intel.

À tout seigneur tout honneur ; Google a procédé à son déploiement sur son infrastructure privée de serveurs Linux. La firme rapporte avoir observé un impact négligeable sur les performances des systèmes passés au test. Google rassure ainsi les utilisateurs de sa plateforme de cloud (GCP) en principe au courant des résultats de benchmark initiaux. Des pertes de performance de l’ordre de 15 à 30 % avaient en effet été annoncées. D’après des relevés effectués par Paul Turner sur un Intel Xeon cependant, les pertes oscillaient entre 0 et 1,5 %, mais il s’agit de données à titre indicatif puisqu’on sait que les pertes sont liées à la charge d’appels indirects émis en direction du noyau.

Cette publication de Google vient une fois de plus donner raison à Intel qui avait annoncé que l’application des correctifs ne devrait pas introduire des pertes de performance criardes. Google a mis la technique à disposition de la communauté et, avec de tels niveaux de performance, elle devrait suivre. Des implémentations LLVM et GCC sont d’ailleurs en train d’être peaufinées.

Sources

Google Security Blog

Descriptif Retpoline

Liste de diffusion LKML

Votre opinion

Google a des réactions saillantes depuis le début de cette campagne. Quelle appréciation faites-vous de cette contribution ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de marsupial marsupial - Membre expérimenté https://www.developpez.com
le 06/01/2018 à 14:20
Google a trouvé les failles donc sont à même de mieux comprendre le problème et donc de le résoudre au mieux. Ce qui a décidé Intel à sortir des correctifs serait plus à mon sens la saillie de Linus Torvalds vis à vis d'intel.

Maintenant, 3 class action sont en cours vis à vis d'intel mais que dire d'arm entièrement exposé aux 3 failles également. 1 milliard de PC contre 7 milliards de smartphones, arrivé à un tel niveau, je crois qu'on arrête de compter et on patche tous en coeur si j'ose dire.

A tout hasard, j'ajoute no script lite dans votre firefox.
Avatar de RyzenOC RyzenOC - Membre confirmé https://www.developpez.com
le 06/01/2018 à 18:01
C'est une aubaine pour AMD.
Cette faille pourrais réellement augmenter ces PDM dans le monde pro.

Je soupçonne le CEO d'intel d'avoir revendu ces actions pour justement acheter des actions AMD
Avatar de marsupial marsupial - Membre expérimenté https://www.developpez.com
le 07/01/2018 à 5:47
J'ai une bète question : comment vont faire les HPC ?
Avatar de RyzenOC RyzenOC - Membre confirmé https://www.developpez.com
le 07/01/2018 à 10:43
Citation Envoyé par marsupial Voir le message
J'ai une bète question : comment vont faire les HPC ?
Toute sécurité fait perdre de la performance

en HPC on applique pas le patch tous simplement.
Ces machines sont de toute manière déjà de vrai passoire niveau sécurité, pour optimiser les perf il faut obligatoirement désactiver le pare feu, le chiffrement... les miennent tu peut te connecter en root root.
Mais ces machines ne sont pas relié à l'extérieure (internet/intranet) et pour pouvoir y brancher une clé USB faut d'abord franchir 3 portes blindé avec badge.
Avatar de jlliagre jlliagre - Modérateur https://www.developpez.com
le 07/01/2018 à 12:34
Citation Envoyé par marsupial Voir le message
J'ai une bête question : comment vont faire les HPC ?
Pour Meltdown, la vulnérabilité principale dont la correction (patches CPU + modifs noyau) entraîne une dégradation des performances, les HPC devraient être peu impactés. Il y a déjà ceux qui utilisent des processeurs AMD, Power, SPARC ou autre (ce qui fait un peu plus que 10%) qui ne sont à priori pas touchés par le problème qui est du à une spécificité de l'architecture Intel.

Pour les ~90% qui restent, une bonne partie du boulot est souvent effectué par des coprocesseurs de type GPU, qui ne sont pas non plus impactés par Meltdown.

L'impact restant va dépendre de la manière dont sont utilisés les super calculateurs. Le plus souvent, il s'agit d'effectuer massivement du calcul numérique (météo, simulation, etc.) et là aussi, Meltdown a très peu d'impact. Ce qui est ralenti, ce sont tous les appels système et la plupart des interruptions. Donc les HPC qui font massivement des petites I/Os disque ou réseau, ou d'autres appels système, envoi de signaux, etc. vont subir une dégradation si les correctifs sont appliqués.

Les HPC étant des clusters de nœuds effectuant des calculs en parallèle, il y a forcément une communication entre ces nœuds pour lancer les calculs et récupérer les résultats mais cette partie qui utilise certainement des appels système doit être négligeable par rapport au reste.

Pour les deux vulnérabilités regroupées sous le nom de Spectre qui affectent à priori la plupart des CPUs utilisés, il n'y a pas de dégradation de performance significative de documentée quand on applique les patches éventuels et recompile ses applications avec les contournements existants (ex: retpoline), quand ils existent...
Avatar de Shol4891 Shol4891 - Futur Membre du Club https://www.developpez.com
le 08/01/2018 à 18:02
"La société affirme que cette vente d’actions n’était pas liée à la découverte de la faille en question, mais qu’elle faisait partie d’un programme de cession planifié."
C'est plausible
Avatar de Christian Olivier Christian Olivier - Chroniqueur Actualités https://www.developpez.com
le 08/01/2018 à 20:57
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

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
Avatar de e101mk2 e101mk2 - Membre actif 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...
Avatar de Ryu2000 Ryu2000 - Expert confirmé https://www.developpez.com
le 09/01/2018 à 9:23
Citation Envoyé par Christian Olivier Voir le message
AMD peut-elle tirer son épingle du jeu sur le marché des CPU serveur ?
Je ne sais pas, mais j’espère !
J'aime beaucoup AMD, les processeurs et les cartes mères sont moins chère.
La plupart des PC que je me suis monté avaient un processeur AMD.

En plus ils ont innové pour le grand public : processeur double cœur, processeur 64 bits, processeur 4 cœurs, etc.
De ce que je me rappelle les premiers processeurs 64 bits pour le grand public (2003) était des AMD et pareil pour les double cœurs (2004).

Par contre Intel est loin devant.
En gros 80% des ordinateurs sont équipé de processeurs Intel (statistique au pif).
Qu'AMD finisse par dépasser Intel ça m'étonnerait, mais AMD peut redevenir populaire (comme en 2004 ).

Citation Envoyé par Christian Olivier Voir le message
Intel aurait-elle du souci à se faire ?
Bof...
Il est toujours largement devant.
Des logiciels sont optimisés pour les processeurs Intel et pas les processeurs AMD.

Il y a quelques années j'avais testé Android Studio et l'émulateur par défaut ne fonctionnait qu'avec des processeurs Intel.

Pourvu qu'AMD gagne des parts de marché, c'est toujours bien la vraie concurrence.
AMD innove souvent en plus.
Avatar de athlon64 athlon64 - Membre confirmé https://www.developpez.com
le 09/01/2018 à 11:55
Citation Envoyé par RyzenOC Voir le message
C'est une aubaine pour AMD.
Oui, on a aussi d'autres fabricants comme Nvidia qui peuvent en profiter
Les entreprises vont aussi diversifier leur architecture et ne plus rester sur du matériel homogène

Citation Envoyé par marsupial Voir le message
Google a trouvé les failles donc sont à même de mieux comprendre le problème et donc de le résoudre au mieux...
Oui ils doivent tous coopérer en plus avec les éditeurs D'OS , c'est d'abord une faille matérielle et l'architecture détaillée est détenue par intel.

je me demande si Google ne va pas se mettre à fabriquer ses propres processeurs, il pourrait même racheter un petit fabricant...
Avatar de AoCannaille AoCannaille - Membre chevronné https://www.developpez.com
le 09/01/2018 à 15:58
Citation Envoyé par athlon64 Voir le message
je me demande si Google ne va pas se mettre à fabriquer ses propres processeurs, il pourrait même racheter un petit fabricant...
Ou un gros, ils en ont les moyens
Avatar de koyosama koyosama - Membre éclairé https://www.developpez.com
le 09/01/2018 à 16:29
Si je devais dire ça à chaque fois que Microsoft plante et pourtant on a toujours windows sur nos PC. Et les entreprises ont toujours de l'AS400.
Non c'est juste un buzz de plus pour vendre pus cher leur puce qui marchennt correctment .
Avatar de marsupial marsupial - Membre expérimenté https://www.developpez.com
le 10/01/2018 à 14:58
Meldown et Spectre expliqués en langue de Shakespeare source exploit db
Avatar de RyzenOC RyzenOC - Membre confirmé https://www.developpez.com
le 10/01/2018 à 21:26
J'ai le sentiment qu'Intel délaisse de plus en plus la fabrication/conception de CPU x86... pour d'autre secteur engendre beaucoup moins d'investissement.

Entre l'architecture core qui 10ans, leur 10nm qui se fait attendre depuis déjà quelques années... (au CES Intel n'a pas dit 1 mots sur son 10nm... ce qui peut laisser penser que c'est une cata).
L'abandon des cpu atom qui signe la fin des puce ultra mobile d'intel et en parallèle la fabrication sur commande cpu ARM dans ces fonderies.

Intel ne fait plus évoluer sont architecture CPU.
La dernière évolution majeur d'intel pour l'architecture x86 c'est l'AVX512 qui date de 2013.

Pendant ce temps dans le reste du monde :
1) AMD lance Ryzen, une gamme de cpu qui offre un meilleur rapport qualité/prix qu'intel
2) MS lance des pc portable windows sous ARM
3) A la grande surprise générale, les asiatiques reviennent sur le marché du X86. Je parle pas d'AMD mais de VIA qui vas lancer cette années des cpu 4 et 8 cœurs x86 pour le grand publique.
En tous cas les cpu Zhaoxin peuvent être intéressant dans le milieu/bas de gamme si ils sont vendu pas cher.

En réponse fin 2017 Intel lance dans la foulé des I9 mal finit, lance une 8ieme génération 6 mois après la 7ieme sans innovation (si ce n'est de mettre un gpu vega d'amd dans leurs cpu...)
et les cannonlake se font toujours attendre... espérons que le 10nm d'intel apporte une baisse significative du TDP. Cannonlake basé sur l'architecture core avec évidement la faille Meldown.

Et l'ARM est tres néfaste pour le consommateur je m'explique :
Les machines ARM grand publique (smartphone, tablette ou pc portable/chromebook) sont des machines sans UEFI avec donc un driver spécifique pour booter.
Ce qui veut dire que sur une machine ARM vous ne pouvez pas installer l'os que vous voulez. Vous êtes emprisonné dans android ou dans windowsRT.
Je dirais même plus, vous êtes emprisonné dans une version spécifique de Android si Lineage OS supporte pas votre smartphone.

L'arm condamne Linux d'une certaine manière....
C'est pas l'architecture ARM le probleme, car j'ai des serveurs arm dans ma boite qui eux ont des UEFI et je peut booter une debian/centos arm dessus sans probleme.
Mais le probleme c'est bien les constructeurs grand publique, qui ne font et ne ferons jamais aucun effort pour implémenter un bios/uefi.

Pour vous donner un exemple, voyer le "bordel" pour booter sur un raspberry par exemple. Sa n'a rien a voir avec un pc je veut dire. Il faut utiliser une rom linux spécifique au raspberry. Y'a pas une distrib linux ARM générique qui marche sur toute les machines arm. Sur X86 par contre debian 32bits peut en théorie booter sur tous les pc x86 > 1995
Avatar de chrtophe chrtophe - Responsable Systèmes https://www.developpez.com
le 11/01/2018 à 8:34
J'ai le sentiment qu'Intel délaisse de plus en plus la fabrication/conception de CPU x86... pour d'autre secteur engendre beaucoup moins d'investissement.
Pas impossible.

leur 10nm qui se fait attendre depuis déjà quelques années
On atteint peut-être les limites de faisabilité, mais j'avoue ne pas suivre de façon assidue ces évolutions.

Ce qui veut dire que sur une machine ARM vous ne pouvez pas installer l'os que vous voulez
Pourquoi ? c'est juste que le boot ne se fait pas de la même façon que sur x86 avec le bios ou l'UEFI. Il te faut un OS compatible.

Ce qui veut dire que sur une machine ARM vous ne pouvez pas installer l'os que vous voulez. Vous êtes emprisonné dans android ou dans windowsRT.
Je dirais même plus, vous êtes emprisonné dans une version spécifique de Android si Lineage OS supporte pas votre smartphone.
Ca c'est le constructeur qui décide. Au même titre que le secureboot UEFI, imposé par Microsoft pour bénéficier du logo Windows Ready complexifiera le boot sur Linux et empêchera même le boot d’anciennes versions Windows telles que Windows 7. LA version WindowsRT fonctionnant sur CPU ARM ne permet l’exécution que d'applications spécifiques, les applis win32 ne fonctionnent pas, d'où son echec.
C'est pas l'architecture ARM le probleme, car j'ai des serveurs arm dans ma boite qui eux ont des UEFI et je peut booter une debian/centos arm dessus sans probleme.
cf problème exposé ci-dessus, Debian refuse d'intégrer la clé Secureboot Microsoft, Debian reste installable en UEFI avec secureboot désactivé.

Les processeurs ARM prennent de l'ampleur au niveau serveur pour l'aspect basse consommation
Avatar de RyzenOC RyzenOC - Membre confirmé https://www.developpez.com
le 11/01/2018 à 9:22
Citation Envoyé par chrtophe Voir le message
Pourquoi ? c'est juste que le boot ne se fait pas de la même façon que sur x86 avec le bios ou l'UEFI. Il te faut un OS compatible.

Ca c'est le constructeur qui décide. Au même titre que le secureboot UEFI, imposé par Microsoft pour bénéficier du logo Windows Ready complexifiera le boot sur Linux et empêchera même le boot d’anciennes versions Windows telles que Windows 7. LA version WindowsRT fonctionnant sur CPU ARM ne permet l’exécution que d'applications spécifiques, les applis win32 ne fonctionnent pas, d'où son echec.
Oui c'est ce que j'ai dit :
Mais le probleme c'est bien les constructeurs grand publique, qui ne font et ne ferons jamais aucun effort pour implémenter un bios/uefi.
Et en théorie vous avez raison...
Dans la pratique vous savez pertinemment que le constructeur décidera de rien faire... si les constructeurs ne le font pas sur les smartphones et les tablettes je vois pourquoi ils le feraient sur des pc arm.
On en aura de toute manière la confirmation quand les 1ere machines arriverons (Q1 2018)

et même si les constructeurs publie leurs driver de boot (on peut toujours rêver), au final sa revient à dire que faudra une iso de linux pour chaque machine.... une Ubuntu raspberry sera incompatible avec un pc arm sous un S835, donc ubuntu devra fournir 2 version différente.
Maintenant imaginer avec 100 modèles différents, puis 500 puis 1000

Pour vous en convaincre, je vous invite a regarder l'installation de linux sur une surface RT
Microsoft ne veut pas signer UEFI shim pour architecture ARM, mais l'a fait pour architectures Intel, c'est pour cela que le Secure Boot n'est pas un problème pour Linux sur PCs/ordinateurs portables/Surface Pro/...
Et au pire sur un pc classique, les bios/uefi peuvent désactiver SecureBoot voir émuler un bios pour faire tourner les vieux OS.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 11/01/2018 à 11:15
La faille (et correctif perte de perf) touche aussi les console de jeux "moderne" ?

Bah c'est pas la première fois que cela arrive à Intel d'avoir une médiation négative. Ma mère m'a offert du Intel, elle en avait les moyens, trois CPU (dont un PC portable) en tous.
Après, j'ai pris la relève, que du AMD pour des raisons économiques... Si j'en avais les moyens et besoins, même maintenant je choisirai Intel...

Les vieux CPU en ont peut-être aussi... Je me fais discret.
Les Intel Atom sont surement aussi dans le même cas...
Avatar de chrtophe chrtophe - Responsable Systèmes https://www.developpez.com
le 11/01/2018 à 20:15
Je suis pas prêt à acheter un PC avec CPU ARM. Quid des logiciels x86 ? Il me semble qu'un émulateur était prévu, mais je ne sais pas ou ça en est et ce que ça donnera niveau perf.
Avatar de disedorgue disedorgue - Expert éminent https://www.developpez.com
le 11/01/2018 à 23:52
Si arm arrive à nous pondre un processeur performant comme à l'époque de l'alpha, il n'y aura pas d'inquiétude à avoir, les alpha était capable de faire tourner du NT en mode émulé plus rapidement que le intel de l'époque.
Avatar de chrtophe chrtophe - Responsable Systèmes https://www.developpez.com
le 12/01/2018 à 9:22
Si arm arrive à nous pondre un processeur performant comme à l'époque de l'alpha, il n'y aura pas d'inquiétude à avoir, les alpha était capable de faire tourner du NT en mode émulé plus rapidement que le intel de l'époque.
Il y a eu des précédents chez Apple. Quand ils sont passés du 68000 au PowerPC, et ensuite du PowerPC à Intel avec l'Universal Binary. Ca marchait bien.
Avatar de RyzenOC RyzenOC - Membre confirmé https://www.developpez.com
le 12/01/2018 à 11:18
Citation Envoyé par disedorgue Voir le message
Si arm arrive à nous pondre un processeur performant comme à l'époque de l'alpha, il n'y aura pas d'inquiétude à avoir, les alpha était capable de faire tourner du NT en mode émulé plus rapidement que le intel de l'époque.
a un détail près :
ARM est spécialisé dans des puces basse conso pas sur la puissance "brute et sauvage".
A l'heure actuel les puce arm pour serveurs (j'ai des puces puce Merlin et ThunderX 48coeurs) font moins bien, consomme autant et sont plus cher que les xeon intel.

Et pour le grand publique, actuellement les puces arm les plus puissante qui ont un tdp de 6-9watt (le S835) sont a peine moins de puissant qu'un pentium de même TDP.
Avatar de ddoumeche ddoumeche - Membre expérimenté https://www.developpez.com
le 12/01/2018 à 11:41
Citation Envoyé par Ryu2000 Voir le message
Il parait qu'après la correction la perte de performance peut être entre 5 et 30%.

Avec un peu de chance Intel va baisser le prix de ces processeurs.
Je me trouverais bien un Intel Core i7-7700K (4.2 GHz / Quad Core / Cache 8 Mo).
Mais 330€ ça fait encore une peu mal ^^

Avec ça Dolphin devrait bien tourner j'imagine.

Ou alors un AMD Ryzen 7 1700X (3.4 GHz / Octo Core / Cache 20 Mo).
Mais les performances monocœurs sont moins bonnes.
CPUmark dit que non

Il faut voir si les applications que tu utilises sont correctement optimisées pour AMD
Avatar de Ryu2000 Ryu2000 - Expert confirmé https://www.developpez.com
le 12/01/2018 à 11:59
Citation Envoyé par ddoumeche Voir le message
CPUmark dit que non
Non à quelle question ?
Pour le moment le prix des processeurs ne bougent pas.
En mono cœur l'i7-7700K (Single Thread Rating: 2582) est plus performant que le Ryzen 7 1700 (Single Thread Rating: 1772).

Je vais encore attendre j'ai pas besoin d'améliorer de monter un nouveau PC de bureau pour le moment.
Je pense qu'au final je vais revenir sur un processeur AMD.
Même si j'ai besoin d'autant de cœurs.
Avatar de liberal1 liberal1 - Inactif https://www.developpez.com
le 13/01/2018 à 1:23
Citation Envoyé par Christian Olivier Voir le message
Cette technique a ses avantages, mais elle présente également un risque non négligeable pour la sécurité, car aucune vérification de privilège n’est présente au niveau du noyau du système d'exploitation.
Le noyau n'a aucun rôle dans dedans. Propos absurde.

Citation Envoyé par Christian Olivier Voir le message
Ces processeurs disposent d’unités spécialisées dans la gestion de la mémoire (MMU) qui permettent de contrôler les accès qu’un CPU fait à la mémoire de l’ordinateur. Ils peuvent fonctionner suivant au moins deux modes de fonctionnement, dont un mode noyau qui n’impose pas de restrictions sur les instructions exécutées, et un mode utilisateur qui limite ce que peuvent faire les instructions.
C'est faux. Les limites s'appliquent, sauf évidemment qui ne concernent que les niveau utilisateur.

Citation Envoyé par Christian Olivier Voir le message
Habituellement, le système d’exploitation met en œuvre cette distinction en faisant fonctionner les autres programmes en mode utilisateur et en se réservant le mode noyau. Cette distinction entre espace utilisateur et espace noyau est à la base du contrôle d’accès qui empêche les instructions des applications de l’espace utilisateur d’accéder à une zone mémoire ne leur appartenant pas.
Faux. Une zone mémoire n'a pas de propriétaire.

Citation Envoyé par Christian Olivier Voir le message
On parle aussi de lecture d’une adresse mémoire non autorisée lorsque ce dysfonctionnement survient. Cette situation débouche rapidement sur une trappe du noyau et, en général, la fermeture du programme incriminé. Il faut noter que la trappe est déclenchée par une interruption matérielle
Encore faux. Les interruptions matérielles n'ont rien à voir avec cette histoire.
Avatar de transgohan transgohan - Expert éminent https://www.developpez.com
le 13/01/2018 à 10:04
Je ne sais pas si c'est un troll alors je vais joindre de la doc...

Trap : https://en.wikipedia.org/wiki/Trap_(computing)
C'est bien une interruption matérielle du CPU.

MMU : https://fr.wikipedia.org/wiki/Unité_de_gestion_mémoire
Donc oui chaque application n'a l'accès qu'à sa propre mémoire allouée, donc on peut parler de propriété.

CPU mode : https://en.wikipedia.org/wiki/CPU_modes
Des jeux d'instructions ne peuvent être exécutées qu'en mode noyau (ou superuser suvant le langage).

Cela infirme tes trois derniers commentaires...
Je ne m'avancerai pas pour le premier n'ayant pas compris où tu voulais en venir.
Avatar de liberal1 liberal1 - Inactif https://www.developpez.com
le 13/01/2018 à 10:18
Citation Envoyé par transgohan Voir le message
Je ne sais pas si c'est un troll alors je vais joindre de la doc...
Non, c'est de la compétence (basique) en informatique. La mienne.

Citation Envoyé par transgohan Voir le message
Trap : https://en.wikipedia.org/wiki/Trap_(computing)
C'est bien une interruption matérielle du CPU.
Non, rien à voir :

a type of synchronous interrupt
matériel se dit "hardware" en anglais, pas "synchronous"

Citation Envoyé par transgohan Voir le message
MMU : https://fr.wikipedia.org/wiki/Unité_de_gestion_mémoire
Donc oui chaque application n'a l'accès qu'à sa propre mémoire allouée, donc on peut parler de propriété.
Chaque fils d'exécution (et pas "application" ce qui ne veut rien dire) n'a accès qu'à ce qui a été projeté dans l'espace mémoire du processus où il s'exécute. Aucun notion de "propriété". C'est un contre sens grave.

Citation Envoyé par transgohan Voir le message
CPU mode : https://en.wikipedia.org/wiki/CPU_modes
Des jeux d'instructions ne peuvent être exécutées qu'en mode noyau
Certes. Et alors?

Tu n'as réfuté aucune de mes affirmations.

Citation Envoyé par transgohan Voir le message
CPU mode : https://en.wikipedia.org/wiki/CPU_modes
mode noyau (ou superuser suvant le langage).
Il n'y a pas de "mode superuser".
Avatar de jlliagre jlliagre - Modérateur https://www.developpez.com
le 13/01/2018 à 16:07
Citation Envoyé par liberal1 Voir le message
Le noyau n'a aucun rôle dans dedans. Propos absurde.
Le noyau n'a rien à voir avec KPTI ?

C'est faux. Les limites s'appliquent, sauf évidemment qui ne concernent que les niveau utilisateur.
Cette phrase ne veut rien dire. Ok, tout le monde peut se tromper. Tu pourrais être plus indulgent avec quelqu'un qui a écrit "superuser" là ou il aurait du mettre "superviseur".

Faux. Une zone mémoire n'a pas de propriétaire.
Il faudrait définir de quelle mémoire on parle.

Si c'est de la mémoire virtuelle, elle "appartient" en totalité au processus (car ses adresses n'ont de sens que pour lui). Ce qu'il y a derrière les adresses est une autre histoire (RAM, SWAP, mémoire du noyau, ou rien du tout).

Si on parle de mémoire physique, à un instant donné chaque page mémoire physique "appartient" (c'est à dire est associée) à un processus (ou plusieurs si mémoire partagée), ou "appartient" au noyau, ou est libre.

Encore faux. Les interruptions matérielles n'ont rien à voir avec cette histoire.
Edit:

Exact
Les page faults, ou plutôt leur absence quand elles surviennent dans du code spéculatif non retenu ont à voir avec cette histoire. Des page faults sont normalement générés par une tentative d'accès à une page mémoire du noyau par du code userland. Elles sont initiées par un composant externe à l'unité centrale (le mmu) et ne sont pas causée par une instruction dédiée (software interrupt).
Avatar de RyzenOC RyzenOC - Membre confirmé https://www.developpez.com
le 14/01/2018 à 22:07
si ça se trouve c'est peut être une tentative désespéré d'intel de vider son stock restant de cpu Itanium Kittson
si j'en crois leurs site, c'est toujours en vente :
performances de pointe, fiabilité, évolutivité et disponibilité.
Avatar de Jipété Jipété - Expert éminent https://www.developpez.com
le 14/01/2018 à 23:35
Bonsoir,

cette phrase m'intrigue :
Citation Envoyé par jlliagre Voir le message
Les interruptions matérielles, ou plutôt leur absence quand elles surviennent dans du code spéculatif non retenu ont tout à fait à voir avec cette histoire.
je vais me faire l'avocat du diable, mais je ne la comprends pas : comment quelque chose peur survenir si le quelque chose est absent ?


Merci de me préciser ce point (et ça t'évitera de te faire descendre en flammes, ), car c'est vraiment mystérieux : j'ai beau lire et relire, leur absence quand elles surviennent [...] me laisse sans voix !

Citation Envoyé par RyzenOC Voir le message
si ça se trouve [...]
Quoi ? Que vois-je ? Tu te ranges ? Que c'est bon, merci merci merci !
Avatar de jlliagre jlliagre - Modérateur https://www.developpez.com
le 15/01/2018 à 2:02
Citation Envoyé par Jipété Voir le message
cette phrase m'intrigue :

> Les interruptions matérielles, ou plutôt leur absence quand elles surviennent dans du code spéculatif non retenu ont tout à fait à voir avec cette histoire.

je vais me faire l'avocat du diable, mais je ne la comprends pas : comment quelque chose peur survenir si le quelque chose est absent ?


Merci de me préciser ce point (et ça t'évitera de te faire descendre en flammes, ), car c'est vraiment mystérieux : j'ai beau lire et relire, leur absence quand elles surviennent [...] me laisse sans voix !
Oui, je comprends que ça peut intriguer ! J'aurais du écrire "leur absence dans le monde réel alors qu'elles sont déjà survenues dans un monde parallèle" On est pas loin du chat de Schrödinger

Voilà une explication plus détaillée:

Les programmes accèdent à leur mémoire (virtuelle, toujours) via un MMU qui dispose d'une table (TLB) indiquant les correspondances entre les adresses virtuelles et les adresses physiques des pages mappées à un instant donné. Cette table contient aussi des flags indiquant pour chaque entrée si elle est autorisée en écriture ou pas (RO ou RW), et si elle fait partie de l'espace de l'application (user) ou du noyau (supervisor). Cette table est un cache et ne contient qu'un sous ensemble des informations de mapping qui sont stockées pour chaque processus dans sa "page table". Si le TLB ne contient pas les infos requises, c'est la page table qui sera utilisée pour mettre à jour le TLB.

Quand un programme effectue un accès mémoire interdit, dans le cas qui nous concerne c'est du code applicatif (userland) qui lit le contenu d'une adresse mémoire mappée vers la mémoire du noyau (supervisor), le MMU détecte la situation et remonte une exception qui se traduit par un "page fault" entraînant habituellement une interruption du programme (crash).

La situation se complique avec processeurs (Intel essentiellement) qui ne respectent pas cette protection de manière proactive quand une lecture est effectuée dans le cadre d'une spéculation.

Il existe alors une fenêtre de temps durant laquelle aucune exception n'est levée puisque l'instruction n'est pas encore considérée comme ayant été exécutée par le programme.

La faille de sécurité Meltdown, c'est que la pré-exécution spéculative de la branche non retenue laisse une trace dans le cache mémoire du CPU.

C'est la lecture indirecte (side channel) de données que l'on pensait auparavant inaccessibles qui est au cœur des failles Meltdown et Spectre.
Avatar de liberal1 liberal1 - Inactif https://www.developpez.com
le 15/01/2018 à 9:53
Citation Envoyé par jlliagre Voir le message
Les interruptions matérielles, ou plutôt leur absence quand elles surviennent dans du code spéculatif non retenu ont tout à fait à voir avec cette histoire. Des page faults sont normalement générés par une tentative d'accès à une page mémoire du noyau par du code userland et ce sont bien des interruptions matérielles (hardware interrupts). Elles sont initiées par un composant externe à l'unité centrale (le mmu) et ne sont pas causée par une instruction dédiée (software interrupt).
Qu'est-ce que tu appelles interruption matérielle?
Avatar de Jipété Jipété - Expert éminent https://www.developpez.com
le 15/01/2018 à 10:21
Citation Envoyé par liberal1 Voir le message
Qu'est-ce que tu appelles interruption matérielle?
je réponds à la place de jlliagre, il me corrigera si j'ai tort, mais je ne crois pas :

Du temps où j'étais jeune (et fou, ), c'était un fil (oui, une vraie connexion hardware) venant d'un contrôleur de périphérique (genre l'imprimante qui n'a plus de papier, ou le contrôleur de disquettes qui se prend une erreur de lecture depuis le lecteur) et qui remontait directement par une pinoche dédiée dans le processeur, à charge pour lui de sauvegarder le contexte en cours et de se dérouter vers une adresse initialisée dans la "table des vecteurs d'interruption" pour gérer ce qui se passait.
Avatar de liberal1 liberal1 - Inactif https://www.developpez.com
le 15/01/2018 à 10:46
Citation Envoyé par Jipété Voir le message
je réponds à la place de jlliagre, il me corrigera si j'ai tort, mais je ne crois pas :

Du temps où j'étais jeune (et fou, ), c'était un fil (oui, une vraie connexion hardware) venant d'un contrôleur de périphérique (genre l'imprimante qui n'a plus de papier, ou le contrôleur de disquettes qui se prend une erreur de lecture depuis le lecteur) et qui remontait directement par une pinoche dédiée dans le processeur, à charge pour lui de sauvegarder le contexte en cours et de se dérouter vers une adresse initialisée dans la "table des vecteurs d'interruption" pour gérer ce qui se passait.
Ah oui, c'est bien ce qu'il me semblait.
Avatar de transgohan transgohan - Expert éminent https://www.developpez.com
le 15/01/2018 à 11:40
Non mais ce troll...
J'aurai perdu du temps à répondre, j'ai bien fait de linker des liens plutôt que de détailler moi même...
Avatar de jlliagre 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.
Avatar de transgohan transgohan - Expert éminent https://www.developpez.com
le 15/01/2018 à 13:37
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.
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).
Contacter le responsable de la rubrique Accueil