Connexion
Abonnez-vous

MDS : encore une importante faille dans les processeurs Intel, les premiers correctifs sont là

Paniquez, mais pas trop

MDS : encore une importante faille dans les processeurs Intel, les premiers correctifs sont là

Le 15 mai 2019 à 07h02

C'est reparti pour un tour : une nouvelle faille liée à l'exécution spéculative des processeurs Intel vient d'être dévoilée. Elle permet de récupérer des données sensibles directement depuis le CPU. Elle a été signalée en amont et les premiers correctifs sont déjà disponibles.

Après les révélations autour de Meltdown/Spectre et leurs nombreuses variantes, il s'agit encore « d'attaques par canal auxiliaire d’exécution spéculative ». Cette fois-ci, ce n'est pas le cache qui est ciblé, mais plusieurs mémoires tampons du processeur : Store buffers, Fill buffers et Load ports.

Le fondeur affirme que les brèches avaient été découvertes par ses chercheurs et partenaires, mais aussi par une équipe indépendante. 

Risque de vol de données personnelles

MDS, alias Microarchitectural Data Sampling, se compose en fait de quatre failles, aussi connues sous le nom de FalloutRIDL et Zombiload :

  • CVE-2018-12126 : Microarchitectural Store Buffer Data Sampling
  • CVE-2018-12130 : Microarchitectural Fill Buffer Data Sampling
  • CVE-2018-12127 : Microarchitectural Load Port Data Sampling
  • CVE-2019-11091 : Microarchitectural Data Sampling Uncacheable Memory

Le risque est réel puisque, comme l'explique Intel, « sous certaines conditions, MDS permet à un programme de potentiellement lire des données auxquelles il ne devrait pas avoir accès ».

Google en rajoute une couche dans un bulletin de sécurité : « Si des processus Chrome sont attaqués, les données sensibles peuvent inclure le contenu d'un site, ainsi que les mots de passe, les numéros de carte de crédit et les cookies ».

Des démonstrations en vidéo sont disponibles par ici.

MDS attaquesMDS attaques

Les processeurs Intel depuis 2008 touchés, sauf quelques modèles récents

Dans un document technique, le fondeur relativise tout de même les risques. Les mémoires tampons en question sont bien moins importants que le cache L1 pour les données (L1D) et contiennent donc moins d'informations, qui sont écrasées plus régulièrement.

Ce n'est pas tout : « il est également plus difficile d'utiliser MDS pour déduire des données associées à une adresse mémoire spécifique, ce qui peut obliger le pirate à collecter et analyser de grandes quantités de données pour récupérer des données protégées ». Bref, on peut paniquer, mais pas trop non plus.

Les processeurs Intel depuis 2008 sont touchés (génération Nehalem), à l'exception de certains Core de 8ème et 9ème génération, ainsi que les Xeon Scalable de seconde génération, affirme le fondeur. Intel s'attend à ce que l'ensemble de ses futurs processeurs soient protégés contre MDS.

De leurs côtés, AMD et ARM ne semblent pas concernées. Le Texan est du même avis que les chercheurs : « nous pensons que nos produits ne sont pas susceptibles d’être concernés par « Fallout », « RIDL » et « ZombieLoad Attack » et ce grâce aux mécanismes de protection matérielle au sein de nos architecture. Nous n’avons pas réussi à reproduire ces exploits sur les produits AMD et ne sommes pas au courant de tiers ayant réussi ».

La valse des mises à jour a commencé

La société de Santa Clara ne recommande pas de désactiver l'Hyper-Threading en bloc, d'autant plus « qu'il est important de comprendre que cela ne fournit pas à lui seul une protection contre MDS ». La situation doit être étudiée au cas par cas, en fonction des besoins en termes de sécurité et des logiciels utilisés par chacun. 

Dans tous les cas, Intel est en train de mettre à jour le microcode de ses processeurs avec, cette fois encore, une possible baisse des performances. Le fondeur propose quelques tests maison en essayant d'être rassurant. Suivant les cas, la chute peut atteindre 3 % pour le grand public lorsque l'Hyper-Threading reste activé, contre 9 % dans le cas contraire. Pour les datacenters, les baisses oscillent entre 14 % avec HT activé et 19 % dans le cas contraire.

Bien évidemment, de nombreuses mises à jour ont été publiées suite à la découverte et la publication des failles. Chez Apple, cela passe par macOS 10.14.5 publié en début de semaine. Microsoft profite de son patch Tuesday pour déployer des correctifs pour Windows et Windows Server. Ubuntu y va aussi de son correctif, tout comme Oracle, et les annonces devraient se multiplier au cours des prochains jours.

Pour Chrome OS, Google a décidé de désactiver par défaut l'Hyper-Threading. D'autres actions seront prises dans Chrome OS 75, sans plus de détail pour l'instant. Enfin, les services en ligne tels que Amazon AWS, Google Cloud et Microsoft Azure ont également annoncé avoir mis en place des correctifs.

Sachez enfin que les chercheurs à l'origine de cette découverte proposent un outil pour vérifier si sa machine est vulnérable. Il est disponible pour Windows et Linux, avec le code source disponible dans ce dépôt GitHub (Mozilla Public License 2.0).

MDS

Commentaires (50)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Quelqu’un saurait m’éclairer sur la façon dont le microcode est mis à jour par les màj de l’OS ?

Ça sous-entend que l’OS peut mettre à jour le firmware du CPU de façon transparente et ça m’étonne (mais j’y connais rien donc bon).

votre avatar







Edrae a écrit :





De mémoire les instructions sont divisés en 3 parties :





  • une partie immuable au cœur du processeur

  • une partie chargée par le BIOS à l’allumage

  • une partie chargée par le système d’exploitation



    Pour Spectre et Meltdown il y a eu des patchs côté OS et BIOS notamment.


votre avatar

How-To rapide pour l’outil proposé en fin d’article :



Sous Linux, il faut avoir CMake de disponible pour pouvoir construire le binaire. Globalement, ca se fait de la façon suivante :



git clone –recurse-submodules [email protected]:vusec/ridl.git

cd ridl

cmake .

make



Vous devriez avoir un binaire mdstool dans le répertoire courant après ça, qui vous donne la fenêtre présentée en screenshot une fois lancé.

votre avatar







PSXBH a écrit :



How-To rapide pour l’outil proposé en fin d’article :



Sous Linux, il faut avoir CMake de disponible pour pouvoir construire le binaire. Globalement, ca se fait de la façon suivante :



git clone –recurse-submodules [email protected]:vusec/ridl.git

cd ridl

cmake .

make



Vous devriez avoir un binaire mdstool dans le répertoire courant après ça, qui vous donne la fenêtre présentée en screenshot une fois lancé.





Ils fournissent le binaire :https://mdsattacks.com/files/mdstool-linux.zip


votre avatar







Edrae a écrit :



Quelqu’un saurait m’éclairer sur la façon dont le microcode est mis à jour par les màj de l’OS ?

Ça sous-entend que l’OS peut mettre à jour le firmware du CPU de façon transparente et ça m’étonne (mais j’y connais rien donc bon).





Il me semble qu’avec les BIOS UEFI toussa toussa, le microcode du processeur se charge sous la forme d’un driver, un peu comme une carte graphique. Driver => on peut passer par l’OS.

<img data-src=" />


votre avatar

Est-ce que cela a un rapport avec la faille SPOILER qui touche tous les CPU Intel Core ?

votre avatar



Les processeurs Intel depuis 2011 sont touchés



Le document d’intel mentionne Nehalem, donc 2008, pas 2011.

votre avatar

Une fork de ridl en ligne de commande est dispo. J’ai jeté un coup d’œil au code et ça fait bien ce que ça dit, c’est à dire du printf dans une console au lieux d’une interface graphique.

votre avatar

Donc si on cumule l’ensemble des baisses de performance de toutes ces failles sur, disons un Core i7 de 7ème génération, on est sur du -40%? Je suis super étonné que personne n’ait encore collé un procès à Intel, surtout les datacenters dont la facture d’électricité a dû atteindre des sommets à chaque correctif…

votre avatar

@Soraphiro @janiko



Merci ! J’en était resté au flash par disquette&nbsp;qui crame la machine une fois sur quatre.

votre avatar

Le microcode peut être chargé,




  • Soit directement dans le bios (l’idéal car le plus tôt possible)

  • Soit sous l’OS.



    Par exemple pour Linux, il peut être chargé soit par un applicatif, soit directement par le noyau (qui est le mieux si le bios n’est pas modifié car cela reste plus tôt que après le démarrage).

    L’outiliucode-tool permet de charger le microcode.



    À une époque, je m’étais même amusé à réintégrer le microcode de mes processeurs dans des bios AMI et AWARD pour avoir le dernier chargé au plus tôt. Mais c’était fait un peu à l’arrache donc je ne le conseille pas trop.

votre avatar







Gilbert_Gosseyn a écrit :



Est-ce que cela a un rapport avec la faille SPOILER qui touche tous les CPU Intel Core ?





Oui et non : toutes ces failles sont des “variantes” de Spectre et Meltdown, ou plutôt des failles de la même famille. L’idée de base est de lire ou prédire des données calculées en avance, au niveau du processeur, auxquelles on n’a normalement pas accès (grosso modo).



SPOILER est en réalité une exploitation d’une faille de ce type pour lire des infos en mémoire (RAM).


votre avatar

Si je comprends bien, pour que cette faille soit exploitée, il faut que les hackeurs aient déjà accès en local au serveurs ou PCs pour pouvoir exécuter un code malveillant qui lui va exploiter ce type de brèche ?

De plus, d’après l’article, l’exploitation de cette brèche est complexe :

“Practical exploitation of MDS is a very complex undertaking. MDS does not, by itself, provide an attacker with a way to choose the data that is leaked.”



Donc c’est comme au moment de spectre, est ce que l’on est prêt à perdre jusqu’à 20% de ressource processeur pour contrer cette faille qui aujourd’hui d’après Intel est complexe a exploiter ?

&nbsp;

Est ce qu’il n’est pas plus prudent de respecter les standards de sécurité et de faire attention que les équipements et antivirus soit à jour et correctement configurés ?…

votre avatar

Petit lapsus dans la news :

&nbsp;MDS, alias&nbsp;Microarchitectural Data Sampling, se compose en fait de&nbsp;quatre failles, aussi connues sous le nom de&nbsp;Fallout,&nbsp;RIDL&nbsp;et&nbsp;Zombiland&nbsp;Le dernier devrai plutot être zombieload…&nbsp;Sinon, ça serait intéressant de faire un benchmark intel avec failles vs intel sans failles vs amd, pour voir ce que vaux vraiment l’architecture une fois sécurisée.

votre avatar







ezekyl a écrit :



Si je comprends bien, pour que cette faille soit exploitée, il faut que les hackeurs aient déjà accès en local au serveurs […]





Pas forcément besoin d’un accès local, Spectre/Meltdown faisait peur à l’époque car on pouvait les exploiter avec du JS, ce qui avait obligé les développeurs de navigateurs de fortement brider la précision de l’horloge en JS pour éviter ça (ils ont réduit la précision du millième de seconde au dixième de mémoire).



Si le risque d’exécuter par inadvertance du code malveillant sur serveur est fortement réduit, ça n’empêche pas de prendre ses précautions, ça fait parti des standards de sécurité aussi. Le risque ne vient pas toujours de l’extérieur, il peut venir de l’intérieur aussi.


votre avatar

Autant je suis d’accord avec toi qu’au niveau des datacenters le risque est faible, autant niveau particuliers et même dans une certaine mesure les entreprises (toutes n’ont pas une infra info rigoureuse) le risque est réel principalement par l’effet de masse.



Sinon, c’est marrant, de mon oeil de néophyte, ça donne l’impression qu’en fait Intel était plus performant depuis des années parce qu’ils ont un poil survolé les tests de robustesse…



Je note cependant que, “bizarrement”, aucun site informatique n’a refait de tests comparatifs de processeurs (à l’époque de Meltdown déjà très peu de magazines avaient fait l’effort d’évoquer le sujet).

Prenons en compte également les améliorations de microcode d’AMD…



Serais-je le seul à apprécier si un magazine “au hasard” se permettait de refaire des comparatifs sous Linux (de préférence) et Windows (au pire) ? <img data-src=" />

votre avatar

Sous Linux, un script shell pour vérifier la vulnérabilité aux diverses failles, et quels contournements sont actifs :github.com GitHub

votre avatar

Je regarde merci&nbsp;<img data-src=" />

votre avatar







RedWave a écrit :



Donc si on cumule l’ensemble des baisses de performance de toutes ces failles sur, disons un Core i7 de 7ème génération, on est sur du -40%? Je suis super étonné que personne n’ait encore collé un procès à Intel, surtout les datacenters dont la facture d’électricité a dû atteindre des sommets à chaque correctif…





Non, on n’est pas du tout à -40%. Oserais-je préciser que 2 baisses successives de -20% ne font pas -40% mais -36%?&nbsp;

De plus, ce sont des baisses “maximales”, on en est loin pour le fonctionnement “générique”.

Les baisses maximales peuvent être atteintes sur des charges de BDD par exemple, mais a-t-on besoin de protéger un serveur BDD contre ces attaques si aucun code extérieur ne peut venir autrement qu’en SQL ou par des requêtes HTTP???


votre avatar

Je viens de vérifier avec l’outil, ma bécanne “loisirs” avec son i9 9900K est touchée par la faille.

La machine pour la boulot n’est pas non plus safe avec son vieillissant i7 4790K, time for AMD.

votre avatar







ezekyl a écrit :



Si je comprends bien, pour que cette faille soit exploitée, il faut que les hackeurs aient déjà accès en local au serveurs ou PCs pour pouvoir exécuter un code malveillant qui lui va exploiter ce type de brèche ?&nbsp;



A priori ils arrivent à déclencher des failles MDS en javascript depuis le navigateur

“First,RIDLattacks can be implemented even from linear execution with no invalid page faults, eliminating the need for exceptionsuppressionmechanismsandenablingsystem-wide attacks from arbitrary unprivileged code (including JavaScript in the browser).”



&nbsp;Je n’ai pas tout lu, mais si c’est confirmé, ça fait une attaque de plus menable depuis n’importe quel site ou macro ou script intégré dans un logiciel.



Donc n’importe quel ordi qui surfe sur internet serait vulnérable.







ezekyl a écrit :



Est ce qu’il n’est pas plus prudent de respecter les standards de sécurité et de faire attention que les équipements et antivirus soit à jour et correctement configurés ?…&nbsp;



La charge “active” étant très simple, pas sûr qu’une signature antivirus ne fasse pas énormément de faux positifs.



&nbsp;





Citan666 a écrit :



Sinon, c’est marrant, de mon oeil de néophyte, ça donne l’impression qu’en fait Intel était plus performant depuis des années parce qu’ils ont un poil survolé les tests de robustesse…



Je note cependant que, “bizarrement”, aucun site informatique n’a refait de tests comparatifs de processeurs (à l’époque de Meltdown déjà très peu de magazines avaient fait l’effort d’évoquer le sujet).&nbsp;



Je ne jette pas forcément la pierre à Intel, on trouvera certainement quelque chose sur les Ryzen. L’architecture Core est attaquée, mais elle est si vieille… Ils ont eu du temps pour chercher la faille et maintenant il creusent à fond.

Quand Zen aura 10ans, on verra bien si l’architecture a résisté.



Pour les test comparatifs, Phoronix fait régulièrement des test avec/sans les mesures de protection, mais c’est surtout pour tester les programmes recompilé avec des mesures de protection “logicielles” intégrées.



Enfin, en lisant le document sur RIDL, on voit bien tout le travail d’optimisation d’Intel: la “bande passante” de RIDL sur un 3770K, c’est moins de 100octets/s, à partir des i7-5xxx, on est à plus de 10ko/s.

Perfs x100 mini sur l’extraction parallèle des données! Super argument de vente!


votre avatar

Ah Shit, Here We Go Again ! <img data-src=" />

votre avatar

Eh oh, j’ai un 4790k, en principal, je te permets pas! <img data-src=" />

votre avatar

J’aimerais savoir comment s’assurer d’avoir un microcode à jour ainsi que la manière de le mettre à jour, si c’est possible, sous Windows. J’ai les dernières màj mais Asus n’as jamais mis à jour le BIOS de mon laptop (un N551VW) et comment simplement savoir quelle est la version du microcode utilisé, quelle est la dernière en date, etc …

votre avatar







brice.wernet a écrit :



Enfin, en lisant le document sur RIDL, on voit bien tout le travail d’optimisation d’Intel: la “bande passante” de RIDL sur un 3770K, c’est moins de 100octets/s, à partir des i7-5xxx, on est à plus de 10ko/s.

Perfs x100 mini sur l’extraction parallèle des données! Super argument de vente!





Ca doit être en partie lié à la taille des buffers, quand on litsoftware.intel.com Intel on voit qu’on est passé de 672 octets (voire moins sur les Atom) à 6Ko.


votre avatar

Dans ce cas là, c’est intel qui doit fournir le patch.

votre avatar

Hmm, après update et reboot, je suis apparemment toujours vulnérable…



(Ubuntu 18.04.2, i7-4790, microcode: 0x27)

votre avatar







dylem29 a écrit :



Eh oh, j’ai un 4790k, en principal, je te permets pas! <img data-src=" />





J’ai un 4590, et comme par hasard il semble que les 4XXX ont le plus souffert des patchs anti-spectre et compagnie avec des baisses de perfs supérieures aux autres générations.



Mon prochain achat sera un Zen 2. Je préviens, car il y aura forcément un comme par hasard qui surviendra <img data-src=" />



Mais bon, à force de trouver des failles et de cumuler les baisses de perfs, on finira par ressortir les bons vieux 486 DX <img data-src=" /> … au moins il n’y avait pas d’exécution spéculative.


votre avatar

Mon lecteur de disquettes avec windows 3.1 n’attends que toi sur le bon coin

<img data-src=" />

votre avatar

J ai aussi un Haswell sur mon PC principal (4570k) et attends aussi Zen2 pour un upgrade.



Quant au ‘ il semble que les 4XXX ont le plus souffert des patchs anti-spectre et compagnie’, cela reste encore ok sur Haswell.

La perte de perfs en % est encore plus marquée sur l archi Core2Duo comme l outil InSpectre suggérait.

La tendance est d avoir une chute de perf plus marquée plus le CPU est vieux!



Et les CPU sans HT comme nos i5 sont aussi moins affectés que ceux avec HT (i7)

votre avatar

je viens de lancer l outil, mais je ne comprends pas bien comment interpréter les résultats.



J ai pourtant eu les updates du microcode avec le patch de mai sous win10pro (https://support.microsoft.com/fr-ch/help/4494441/windows-10-update-kb4494441 ), mais il reste un paquet de lignes ‘vulnérable’ dans l outil.



Un 2nd article pour mieux expliquer ce qu on devrait avoir serais pas mal :)

votre avatar

Oh il ne faut pas rigoler avec Windows 3,tout le monde s’est étonné que certains parcs tournaient encore avec mais l’OS est tellement simple (et le hardware aussi) que c’est stable comme un RPi 😊

Et en fait on est moins embêtés par toutes ces failles, un pirate s’attend pas à trouver un Pentium MMX… ☺

votre avatar

Normal ces bots qui spam des sites à la con ?

votre avatar

Oui, c’est normal quand on ne protège pas son site contre les bots.



C’est très pénible quand comme moi, on parcourt la liste des articles et des brèves pour voir les nouveaux commentaires pour tomber ensuite sur ces SPAM.



Quelques pistes pour rendre le travail des bots plus difficile. À mettre en place pour la création de compte.

votre avatar

Et encore, pensez à ceux qui ont un 2600K en machine principale&nbsp;<img data-src=" />

votre avatar

Le 4790k est encore très véloce, je suis à peine bottleneck en 1080p avec une 1080 Ti. <img data-src=" />



Mais les problèmes de sécu, c’est un souci, vivement Zen 2.

votre avatar

Mon 2600K est tout aussi parfait pour du 1440p avec comme toi une 1080 Ti&nbsp;<img data-src=" />

Par contre le 2600K en 1080p et la Ti, je perdais trop de fps…



Vivement Zen 2 oui !

votre avatar

Perso, sous Win10_proc I7-3770K) , j’ai exactement les mêmes vulnérabilités (je viens de vérifier avec MDSTool) avant et après l’application du patch Tuesday…

C’est normal Docteur?

Je ne comprends même pas pourquoi Microsoft n’a pas pondu un patch plus tôt puisqu’ils sont censés avoir été prévenus depuis plus d’un an (par l’intermédiaire d’Intel?). Pourquoi attendre le jour de la divulgation publique de la faille pour mettre à jour Win10…

votre avatar

Sur Ubuntu, l’update microcode intel a éte deployé sur les dépôts, faites juste un update et un reboot.

votre avatar

Selongithub.com GitHub il y a un nouveau microcode 0x21 qui est sorti pour Ivy Bridge.

Si Windows l’a déployé (mdstool donne la version), je suppose que MD_CLEAR doit être marqué comme disponible (il n’y a pas le détail des changements CPU par CPU, donc peut-être que ça fait autre chose).

votre avatar







hwti a écrit :



Selongithub.com GitHub il y a un nouveau microcode 0x21 qui est sorti pour Ivy Bridge.

Si Windows l’a déployé (mdstool donne la version), je suppose que MD_CLEAR doit être marqué comme disponible (il n’y a pas le détail des changements CPU par CPU, donc peut-être que ça fait autre chose).





Merci de ta réponse.

Ben, en fait, concernant mon cas, le microcode est toujours 0x000000001f et MD_Clear est “not available”.

Je me suis même aperçu que l’hyper-threading était désactivé dans mon Bios… ça va rester comme ça puisque jusqu’à maintenant ça ne m’a pas trop manqué…


votre avatar

“Le fondeur&nbsp;affirme que les brèches avaient été découvertes par…”

Leur découverte n’est pas récente ?

“CVE-2018”

Voila qui répond en partie à ma question.

Vu les cadences atteintes aujourd’hui par les CPU, ne serait il pas possible de se passer complètement de “canal auxiliaire d’exécution spéculative” ?

votre avatar







Winderly a écrit :



“Le fondeur affirme que les brèches avaient été découvertes par…”

Leur découverte n’est pas récente ?

“CVE-2018”

Voila qui répond en partie à ma question.

Vu les cadences atteintes aujourd’hui par les CPU, ne serait il pas possible de se passer complètement de “canal auxiliaire d’exécution spéculative” ?





En gros, tu veux revenir à l’époque du 80486 ? (avec une fréquence d’horloge supérieure certes)


votre avatar

Oui :

Ce matin avant update, les syslog :

kernel: [&nbsp;&nbsp;&nbsp; 0.800527] microcode: sig=0x306a9, pf=0x10, revision=0x20

kernel: [&nbsp;&nbsp;&nbsp; 0.800644] microcode: Microcode Update Driver: v2.2.



Après mise à jour linux :

kernel: [&nbsp;&nbsp;&nbsp; 0.000000] microcode: microcode updated early to revision 0x21, date = 2019-02-13

kernel: [&nbsp;&nbsp;&nbsp; 0.788904] microcode: sig=0x306a9, pf=0x10, revision=0x21

kernel: [&nbsp;&nbsp;&nbsp; 0.789067] microcode: Microcode Update Driver: v2.2.



\o/

votre avatar

La fréquence plus élevée et le “canal auxiliaire…” seraient les seuls progrès des CPUs récents si on les compare à du 80486 ?

votre avatar

Les progrès, outre les nouvelles instructions, consistent à permettre l’exécution de plus en plus d’instructions en même temps (architecture superscalaire), et de les réordonner (out-of-order).



Sans exécution spéculative :




  • chaque branchement conditionnel devient une barrière qui empêche l’exécution en parallèle ou non ordonnée des instructions situées avant ou après (la prédiction de branchement ne sert plus à grand chose)

  • les accès mémoire indirects bloquent plus souvent car il faut attendre le dernier moment pour calculer l’adresse

  • les branchements indirects (pointeurs de fonctions, méthodes virtuelles), et les retours de fonction (lecture de l’adresse de retour sur la pile) sont plus lents à cause des deux raisons précédantes (difficile d’être sûr de l’adresse à l’avance, ce qui empêche d’exécuter des instructions situées après)


votre avatar

On fait comment avec le parc d’entreprise? Avec WSUS?

votre avatar

Le patch kernel pour Debian Buster&nbsp; n’est pas encore sorti. :-/ Dommage car pour le reste cette distro est vraiment beaucoup plus stable que Stretch, au moins sous KDE.

votre avatar

Très juste, j’ai tendance à oublier que Intel traîne la même archi depuis plus de 10 ans… Faut dire, ils font tellement d’efforts pour faire croire que leur nouvelle gen est révolutionnaire à chaque fois !! XD



On peut également noter qu’il y a certainement aussi un effet d’opportunité similaire à Windows/Linux, enfin je le suppose : tant qu’à bosser pour essayer de trouver des failles, autant se concentrer sur celui qui a le plus de parts de marché. :)

votre avatar

Intel est seul concerné ? Ou y’a une des variantes qui touchent AMD (ou une partie de gamme seulement) ?



Avec un FX, sur la partie MADS, tout est au vert. Le reste non par contre.



Mais si je passe Spectre & Meltdown Checker, tout ressort comme non vulnérable… il n’inclut pas certaines vérifications de MDS donc ?

MDS : encore une importante faille dans les processeurs Intel, les premiers correctifs sont là

  • Risque de vol de données personnelles

  • Les processeurs Intel depuis 2008 touchés, sauf quelques modèles récents

  • La valse des mises à jour a commencé

Fermer