Discussion :

[transgohan]

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

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

[jlliagre]

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

C'est vrai, mais au bout de 256 cycles, on commence à avoir une idée de la valeur qu'il y a dans le cache. Et au bout de N fois 256 cycles, on n'a plus de doute.

[liberal1]

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

Cela génère une exception/signal qui est récupérable sur la plupart des OS.

Bien sûr, aucune valeur lue illégalement ne sera fournie par le noyau au gestionnaire de signal, seulement l'adresse dont la lecture est interdite, donc la valeur fournie par le programme. Mais définir un gestionnaire évite que l'exécution du programme ne soit terminée.

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.

En fait les concepteurs de CPU ont tout fait pour pré-calculer le plus de choses possibles afin d'avoir déjà les résultats sous la main lors du commit. (Cela cause des lectures anticipées qui peuvent changer le comportement de programmes multi threads mal programmés.)

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.

À la base, il y a le partage du cache du CPU entre compartiments de sécurité différents. Intuitivement on voit tout le suite le danger potentiel, mais on pensait qu'il n'y avait aucune possibilité pratique d'extraire de l'information utile.

[jlliagre]

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.

[liberal1]

Oui enfin c'est surtout que techniquement c'est assez difficile à exploiter, il semble falloir analyser tous l'espace d'adressage pour réussir à déterminer des adresse noyau (et a priori faire planter son programme des millions de fois) et ensuite arriver à comprendre qu'est-ce qu'il y a derrière ces adresses... la pluspart des malware n'ont pas envie de se casser la tête avec ça, il y a d'autres failles à exploiter plus facilement avant. Récupérer les données bancaires leur suffit

Si les données bancaires sont dans des fichiers appartenant à l'utilisateur, alors il n'y a aucune faille à exploiter! Sauf s'ils sont chiffrés, et là il faut attendre que l'utilisateur entre le mdp.

Pièce jointe 339366

Ce schéma n'a rigoureusement aucun sens.

Tout l'article a besoin d'être refait.

Si tu parles de Meltdown, j'ai pas l'impression que la faille soit dur a exploiter, il suffit juste d'un programme en user-space. Si tu as des données un tant soit peu importante c'est stupide de ne pas appliquer le patch.

C'est largement pire, tu n'as pas besoin d'avoir le droit d'exécuter du code en mode user. Tu as juste besoin d'avoir la possibilité de faire exécuter une fonction (en Javascript ou n'importe quoi) par un programme correct (un navigateur sans bug ou n'importe quoi), qui soit performant (qui compile le code).

Je trouve cela vertigineux.

[LittleWhite]

Bonjour,

Pour tout ceux qui sont intéressés dans les bogues CPU et par les failles Meltdown et Spectre, je vous conseille la lecture de cet article.

[Kannagi]

Moi je suis content ça répond au moins comment fonctionne exactement les processeur OoO , vu que j'avais poser des questions la dessus mais personne en savait grand chose :p

Pour ma part je suis beaucoup plus a une utilisation in order , et de laisser le travail au compilo/programmeur (et non au CPU avec ces failles) , en plus ça allégerait énormément les processeurs et on pourrait espérer avoir des processeurs in order a 8-16 cœurs pour des prix et des fréquences tout a fait abordable

[chrtophe]

La version 7.3 de gcc intègre le support de Retpoline, une technique développée par les ingénieurs de Google pour atténuer la vulnérabilité Spectre.

[jlliagre]

Oui, mais elle n'a rien de reptilien ;-)

La technique s'appelle retpoline pour RETurn-tramPOLINE, le code "rebondit" sur une instruction "return".

[chrtophe]

Désolé pour l'erreur, elle provient de la source que j'ai citée, je vais rectifier.

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

[Patrick Ruiz]

Les processeurs Intel Xeon Cascade Lake vont inaugurer l’ère des protections intégrées contre Spectre
Sur les serveurs et les desktops

Il y a bientôt deux mois que la nouvelle selon laquelle Intel devrait livrer ses premiers processeurs équipés de protections intégrées contre les vulnérabilités Spectre a filtré sur cette plateforme. Dans une note d’information encore toute fraîche, le fondeur en dit plus à ce propos. Il annonce que les processeurs Intel Xeon de dernière génération – nommés Cascade Lake – vont inaugurer l’ère des protections intégrées contre les vulnérabilités Meltdown et Spectre. Le fondeur ajoute que les processeurs Intel Core de 8^e génération sont aussi concernés par cette mouvance.

Dans le cadre de la gestion de cette apocalypse numérique, le fondeur a, début février, procédé à la publication de microcodes mis à jour pour la microarchitecture SkyLake. Début mars, c’était le tour des microarchitectures Broadwell et Haswell ; la manœuvre faisait suite à la publication de correctifs pour Kaby Lake et Coffee Lake, ses processeurs de 7^e et 8^e génération. Le code rédigé par Intel, puis acheminé aux utilisateurs finals via les fabricants d’équipements d’origine et Microsoft, a vocation à atténuer les failles de façon logicielle.

Brian Krzanich est monté au créneau pour signaler que les Intel Xeon Cascade Lake et les Intel Core de 8^e génération seront munis de « partitions » pour les protéger contre la variante 2 de Spectre, ainsi que de Meltdown (pas de solution intégrée au hard en ce qui concerne la variante 1 de Spectre pour le moment). Sans trop s’étendre à ce sujet, le CEO d’Intel a déclaré que ces dernières permettraient de renforcer les murs de protection entre les applications et les niveaux d'utilisateurs privilégiés que Spectre et Meltdown peuvent permettre de violer en exploitant une faiblesse des techniques d'exécution spéculative.

« Meltdown utilise une faille de certains processeurs permettant de lire les adresses du noyau, l’attaque Spectre quant à elle ne s’appuie pas sur une faille, mais sur l’optimisation de prédiction et de cache pour pouvoir lire n’importe quelle valeur dans l’espace utilisateur d’un processus victime. L’idée de Spectre est d’entraîner le processeur à suivre un certain chemin lorsqu’une décision doit être prise en utilisant l’optimisation de prédiction, puis de profiter de cette prise de décision entraînée pour que le processeur prenne la branche voulue même si la condition n’est plus respectée », peut-on lire sur le site hackndo qui donne l’explication la plus simple pour un lecteur avec des notions de langage C.

Brian Krzanich n’a pas fait dans le détail en ce qui concerne les périodes précises de disponibilité des Intel Xeon de dernière génération. Les Intel Core de 8^e génération sont pour leur part attendus dans la deuxième moitié de 2018.

Source

Intel
hackndo

Votre opinion

Comment accueillez-vous la nouvelle de la disponibilité future de processeurs Intel dotés de protections intégrées contre Meltdown et Spectre ?

Voir aussi

Intel tente de sauver la face avec un programme de Bug Bounty primant jusqu'à 250 000 dollars afin d'éviter un nouvel épisode Meltdown