Discussion :

[jlliagre]

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).

[RyzenOC]

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é.

[Jipété]

Bonsoir,

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 !

si ça se trouve [...]

Quoi ? Que vois-je ? Tu te ranges ? Que c'est bon, merci merci merci !

[jlliagre]

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.

[liberal1]

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?

[Jipété]

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.

[liberal1]

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.

[jlliagre]

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.

[transgohan]

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).

[liberal1]

Mais du coup pour rebondir sur l'exemple des page fault, dans quelle case la rangerais-tu ?

Je pense que la seule distinction utile est synchrone/asynchrone.

Le noyau n'a rien à voir avec KPTI ?

KPTI a tout à voir avec le noyau.

Mais on ne parlait pas de ça il me semble.

Si c'est de la mémoire virtuelle, elle "appartient" en totalité au processus (car ses adresses n'ont de sens que pour lui).

Précisément!

Les adresses n'ayant pas de sens ailleurs, on ne peut pas réellement parler de "propriété".

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.

Oui

Il n'y a pas d'instructions qui permettent de lire directement les données placées en cache par les techniques précédentes mais il existe des moyens détournés sophistiqués pour le deviner. Celui qui est le plus souvent décrit consiste à mesurer le temps mis à charger le contenu d'une adresse mémoire. Si ce temps est "long", c'est que le processeur est bien allé chercher la donnée en RAM. Si ce temps est court, c'est que cette adresse viens déjà d'être lue. On a donc réussi à lire le contenu du cache alors qu'il n'existe pas de moyen direct de le faire.

Oui mais à chaque mesure de temps, on extrait une seule information : présence ou absence dans le cache.

Toute sécurité fait perdre de la performance

Non. Charabia.

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...

Pare feu? Pour quoi faire? Pour bloquer quoi?

Chiffrement? Entre où et où?

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.

Donc la sécurité est assurée par d'autres moyens que des outils logiciels.

[Coriolan]

Vulnérabilités Meltdown et Spectre : Intel devrait livrer ses premiers processeurs dotés de protections intégrées
Plus tard cette année

Intel s’attend à livrer ses premières puces dotées de protections intégrées contre Meltdown et Spectre plus tard cette année, a informé Brian Krzanich, PDG de la société. Pour rappel, au début de ce mois, des rapports accablants ont mis à la lumière du jour un défaut qui affecte les puces d’Intel et qui exposerait la mémoire du noyau.

Les failles de sécurité Spectre et Meltdown touchent la quasi-totalité des processeurs Intel. À vrai dire, toutes les puces produites par le fondeur durant les 20 dernières années sont concernées. La faille Spectre elle affecte également les processeurs d’AMD et ceux basés sur l’architecture ARM, ce qui fait que chaque PC, smartphone et tablette livrés durant les dernières années sont affectés. Ces failles rendues publiques permettraient à un code malveillant de lire le contenu de la mémoire du noyau d'un ordinateur. Autrement dit, un acteur mal intentionné pourra accéder à des données sensibles comme les mots de passe.

Pour rassurer le public, Intel a annoncé avoir mobilisé ses meilleurs cerveaux pour corriger la faille en question. Le fondeur a réorganisé ses ressources humaines et a mis en place un nouveau groupe dédié à la qualité et à la sécurité. Durant une conférence tenue par Intel pour communiquer ses résultats du quatrième trimestre, le PDG de la société a informé que la mise en place de ce nouveau groupe va se traduire en changement au niveau du silicum des futures puces du fondeur.

« Nous avons travaillé sans relâche » pour corriger la vulnérabilité et limiter les attaques, a dit Krzanish, « mais nous sommes bien conscients qu’il faudra faire plus ».

Jusqu’à présent, les correctifs proposés pour combler les failles sont venus sous forme de mises à jour logicielles publiées par Intel, Microsoft et autres. Toutefois, ces correctifs logiciels ralentissent la performance des puces.

Au début de cette semaine, Intel a été forcé de recommander aux utilisateurs de reporter l’installation de ses patchs logiciels en raison de soucis avec la microarchitecture Ivy Bridge et suivantes. Le fondeur a apporté donc réponse à des signalements de redémarrage après l’application des patchs mis à la disposition du public le 3 janvier dernier.

La sécurité a toujours été une priorité pour Intel, a dit Krzanich, mais c’est « un parcours continu ». « Nous sommes pleinement impliqués dans la tâche, je suis convaincu que nous sommes à la hauteur du défi. »

Krzanich n’a pas souhaité aborder la question de vente massive d'actions, en effet, il aurait amassé la bagatelle somme de 24 millions de dollars en mettant en vente la totalité des actions en sa propriété et autorisées à être cédées. Cette vente a eu lieu des mois après qu’Intel a été informé de l’existence des failles Spectre et Meltdown, mais avant qu’elles soient divulguées au public. La société a réagi et a informé que cette vente n’est pas liée à la connaissance des vulnérabilités de sécurité.

Source : Business Insider

Et vous ?

Pensez-vous qu'Intel va se remettre de cette apocalypse numérique ?
Ou bien c'est la concurrence qui va en tirer parti ?

Voir aussi :

Fuites sur les prochains processeurs Intel de 8^e génération pour ordinateur portable avec des i7, i9 et Xeon jusque six cœurs
Intel préparerait son GPU dédié, Arctic Sound et Jupyter Sound devraient arriver dès 2020, sous l'impulsion de Raja Koduri

[a028762]

Alors, attendre la prochaine génération de processeur, "garantie" anti-spectre ?
Ou appliquer les patchs et ramer (Racheter de la RAM)
Houlala !

[AndMax]

Alors, attendre la prochaine génération de processeur, "garantie" anti-spectre ?

Tu n'auras jamais de "garantie". Au mieux, tu auras une architecture, un microcode et un chipset ou BIOS ouvert, transparent, que tu pourrais faire auditer par les meilleurs spécialistes. Mais puisque c'est Intel, ce sera probablement fermé, dans la continuité de l’obscurantisme, et avec une porte dérobée au niveau ME, et sans solution réelle pour la désactiver.

Donc pour le moment, aucun changement concret, à part que tu peux attendre la prochaine faille sur la nouvelle génération qui aurait une "protection intégrée".

[MadScratchy]

...va se traduire en changement au niveau du silicium des futures puces du fondeur.

Je ne comprend pas cette phrase...

edit : corrigé

[crozet.magenta]

La faille Spectre elle affecte également les processeurs d’AMD et ceux basés sur l’architecture ARM, ce qui fait que chaque PC, smartphone et tablette livrés durant les dernières années sont affectés. Ces failles rendues publiques permettraient à un code malveillant de lire le contenu de la mémoire du noyau d'un ordinateur. Autrement dit, un acteur mal intentionné pourra accéder à des données sensibles comme les mots de passe.

Si je ne m'abuse, la faille spectre ne permet pas d'accéder à la mémoire noyau mais uniquement à la mémoire des autres programmes de même niveau.

[jlliagre]

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.

[Madmac]

Sans oublier les portes arrières pour la NSA qui peuvent être retourner par les hackers. Il est temps d'ouvrir la porte à de nouveau joueur. Les monopoles ne sont jamais bon pour les consommateurs.

[MikeRowSoft]

Il est temps d'ouvrir la porte à de nouveau joueur.

Avant c'était seulement les pros et quelques données persos des "clients" hébergé chez les pros (ou chez eux grâce à des services pros)...
Les webcams avec la technologie Intel RealSense en plus par exemple ?
Là ça va vraiment être chaud. "

Sinon, les plus grosses menaces (pour les entreprises) restent les ransomware ou eraseware...
(pour tous sur Internet c'est les fuites de mot de passe et coordonnées bancaires donc spyware/trojan et les négligences d'administration de Server ou Desktop ou Tower ou TabletPC, smartphone...)
Les virus sont justes un peu moins ennuyant...

Étrangement, la console de jeux est épargné...
Manquerait plus que le serveur officiel lui donne le malware pour être sur que le fromage existe bien depuis l'air des dinosaures...

[benjani13]

Spectre/Meltdown : de nouvelles vulnérabilités dans les processeurs dévoilées,
Elles permettent la lecture de registres internes, de la mémoire kernel et de la mémoire de l’hôte

En début d’année, plusieurs vulnérabilités affectant les processeurs depuis plusieurs années ont été dévoilées. Au nombre de trois « variantes », ces vulnérabilités exploitent des mécanismes internes aux processeurs. Elles sont souvent regroupées sous le nom de Spectre pour les variantes 1 et 2, et Meltdown pour la variante 3. Elles permettent de lire la mémoire kernel en tant que simple utilisateur, ou bien d’aller lire la mémoire de l’hôte depuis une machine virtuelle.
Hier, les détails de deux nouvelles variantes (3a, et 4) ont été publiés. Elles abusent des mécanismes d’exécution spéculative pour (3a) lire des registres internes des processeurs et (4) lire des données sensibles en mémoire.

Retour sur Spectre et Meltdown

Meltdown et Spectre abusent de certains mécanismes d’optimisations implémentés dans les processeurs, notamment celui dit d’exécution spéculative. Ce mécanisme permet au processeur d’exécuter certaines instructions en avance de phase afin de gagner du temps. Le processeur peut par exemple (variante 1) exécuter une série d’instructions se trouvant après une condition, sans savoir à ce moment-là si la condition sera remplie ou non. Si la condition n’est en fait pas remplie, le processeur revient à son état précédent l’exécution du bloc et tout se passe comme si rien ne s’était passé. Or il a été démontré que des traces de l’exécution erronée du bloc peuvent être retrouvées dans le cache du processeur, celui-ci n’étant pas remis dans son état original.

Ces vulnérabilités ont dû être patchées soit par la mise à jour du microcode des processeurs affectés, soit par la mise en place de mécanismes de protection au sein des systèmes d’exploitation. Néanmoins certaines de ces protections impliquent des baisses de performances, et certains patchs n’ont pas été totalement efficaces et ont subi plusieurs itérations avant d’être matures. AMD et Intel ont aussi pris en compte ces failles dans leurs futures architectures afin de livrer de nouveaux processeurs non vulnérables. Les fournisseurs d’infrastructure cloud, particulièrement impactés par ces vulnérabilités, ont aussi dû rapidement réagir en déployant des correctifs sur leurs serveurs. Aussi, des compilateurs ont implémenté des mécanismes pour contrer certaines variantes, et des guides de développement ont été publiés afin d’écrire du code moins sensible à ces attaques. Encore plus inattendu, les navigateurs web ont baissé la précision des timers JavaScript afin d’empêcher l’exploitation de ces failles depuis du code JavaScript.

Meltdown et Spectre ont donc été des vulnérabilités assez hors du commun, tant par le fait qu’elles attaquent les processeurs eux-mêmes, par leur impact très large (tous les OS étant concernés), et le travail qui a été nécessaire pour les corriger. En effet c’est toute l’industrie (fabricants de CPU, développeurs d’OS, fournisseurs d’infrastructure) qui a dû se coordonner, en secret, pendant plusieurs mois afin de fournir une réponse adaptée.


Nouvelles vulnérabilités

Il était pressenti que les chercheurs ayant découvert Meltdown et Spectre venaient d’ouvrir une porte sur tout un champ d’études encore très peu exploré et que d’autres variantes seraient découvertes. Le 21 mai 2018, deux nouvelles vulnérabilités mettant en jeu l’exécution spéculative ont été dévoilées.


Variante 3a : Rogue System Register Read (CVE-2018-3640)

Cette variante abuse des mécanismes d’exécution spéculative afin de récupérer les valeurs de certains registres internes des processeurs. Quelques données sensibles peuvent être récupérées suivant le processeur visé comme l’adresse physique de certaines structures de données et l’adresse de certains points d’entrée du kernel. Ces informations peuvent permettre d’outrepasser la protection KASLR (Kernel Address Space Randomization) en place dans les systèmes d’exploitation récents.

KASLR rend l’adresse de base du kernel (et donc de tout son contenu) aléatoire. Ainsi, si un attaquant exploite par exemple un driver kernel et se retrouve à pouvoir exécuter du code avec les mêmes droits, il ne pourra pas manipuler les informations du kernel, car il ne connaitra pas leurs adresses. Cette vulnérabilité peut paraitre minime mais réussir à contourner KASLR est une étape presque indispensable aujourd'hui pour réussir un exploit kernel.


Variante 4 : Spéculative store bypass (CVE-2018-3639)

Cette vulnérabilité abuse d’un mécanisme d’optimisation dans la lecture de la mémoire appelé « memory disambiguation ». En effet, les processeurs tentent de gagner du temps en réorganisant l’ordre des instructions à la volée. Si l’instruction 1 est jugée lente (lecture d’une donnée en RAM), le processeur peut démarrer l’exécution de l’instruction 2 si celle-ci est jugée rapide (lecture dans le cache). Bien sûr, pour que ce mécanisme se déclenche, il ne faut pas que l’instruction 2 dépende de l’instruction 1. Si l’instruction 1 écrit une valeur à l’adresse 3000 et que l’instruction 2 lit la valeur à l’adresse 3000, l’instruction 2 ne pourra pas être exécutée avant la 1. Ce mécanisme s’applique à plus que deux instructions bien sûr. Si l’instruction 2 consiste à charger une valeur, puis une troisième instruction incrémente cette valeur, c’est l’ensemble instructions 2 et 3 qui peut être exécuté avant l’instruction 1.
Il peut néanmoins arriver que le processeur se trompe, et qu’il se rende compte après coup que la seconde instruction était bien dépendante de la première. Dans ce cas-là, une fois que l’instruction 1 est terminée, le processeur revient en arrière et réexécute l’instruction 2 (et plus si besoin).

Tout comme les autres variantes, ce retour en arrière peut laisser des traces exploitables après coup, notamment dans le cache. En abusant de ce mécanisme, il est donc possible de tenter de faire charger des données sensibles et de les lire dans le cache, même si le processeur se rend compte de l’erreur et a effectué le retour en arrière.
Microsoft a annoncé que les patchs déjà publiés pour Windows corrigent une partie des scénarios exploitables avec cette variante. Microsoft précise qu’un travail est en cours avec les fabricants de CPU afin d’évaluer les solutions à implémenter au niveau des processeurs (firmware ou micro code).


En attendant d'autres variantes

Les recherches sur les vulnérabilités liées aux différents mécanismes d’exécution spéculatives se poursuivent et d'autres variantes seront sans doute découvertes. Bien que ces attaques peuvent paraitre peu signifiantes pour certains, il ne faut pas les sous-estimer, et le fait qu'elles forcent de nombreux acteurs de l'industrie à réagir démontre qu'il y a du souci à se faire. Cependant, ces failles de bas niveau sont difficiles à comprendre, et il n'est de fait pas aisé d'estimer l'impact de chaque variante. De plus les impacts de performances de certains patchs ont pu faire hésiter à les déployer. Il faudra néanmoins rester sur le qui-vive et être prêt à patcher dès que nécessaire, car c'est un nouveau pan de recherche qui s'est ouvert et nous pourrions encore être très surpris par ce qu'il se passe dans nos processeurs.


Sources et lectures complémentaires

• Google Project Zero (Variantes 1, 2 et 3) : https://googleprojectzero.blogspot.f...with-side.html
• Intel : Retpoline : A branch target injection mitigation : https://software.intel.com/sites/def...Mitigation.pdf
• Intel : Analysis of speculative execution side channels white paper : https://software.intel.com/sites/def...hite-Paper.pdf
• Microsoft Technet : Mitigating speculative execution : https://blogs.technet.microsoft.com/...lnerabilities/
• Google Project Zero : Variante 4 : Speculative store bypass : https://bugs.chromium.org/p/project-...detail?id=1528
• Microsoft Technet : Speculative store bypass : https://blogs.technet.microsoft.com/...cve-2018-3639/
• Microsoft : C++ Developer guidance for speculative execution side channels : https://docs.microsoft.com/en-us/cpp...tive-execution
• ARM : Détails de chaque variante et liste des processeurs ARM affectés : https://developer.arm.com/support/ar...-vulnerability
• ARM : Cache speculation side channels white paper : https://developer.arm.com/-/media/de...nnels-v2.0.pdf

Et vous ?

Que pensez-vous de ces nouvelles failles sur les processeurs ?

Voir aussi

Vulnérabilités Meltdown et Spectre : Intel devrait livrer ses premiers processeurs dotés de protections intégrées plus tard cette année

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

Vulnérabilités Meltdown et Spectre : état des lieux des navigateurs, Chrome, Mozilla et Edge face au vecteur d'exploitation JavaScript

[MikeRowSoft]

Rien, c'est pas cela qui fera toutes les entreprises et gouvernements utiliser le " bouton d'arrêt d'urgence ". (stop économique/financier et autres traitements)
Je pense que la crainte que les " extraterrestres " prennent le contrôle via une IA ou autre méthode n'est pas fondé.