Ceux qui ne se considèrent pas comme neuneus de la tech peuvent prendre la peine de lire la source de l’article…
1 « J'aime »
Le problème se situe sur tous les PC Intel des 10 dernières années, et AMD de moins de 4 ans. Il n’est pas question de serveurs ici, encore moins de VM.
Tu viens de dire encore une fois l’inverse 
sensible c’est l’inverse de drastique. Définition du Larousse : Drastique = D’une rigueur contraignante ; très rigoureux, draconien.
C’est bien l’inverse de sensible qui n’est pas contraignant, très rigoureux et draconien puisqu’il se fait peu ressentir.
Sauf que Clubic n’est pas un site élitiste et encore une fois, t’as la source et tout y est expliqué. Help yourself comme on dit.
les deux tiers du % restant
Les math c’est peut-être ton fort, mais la lecture, je ne serai pas aussi catégorique.
J’avoue, j’ai répondu un peu vite…
Si, il est question de tous les serveurs en Xeon notamment, ou des threadrippers récents par exemple.
On pourrait sur des sites en VPS mutualisés voler les infos des autres.
Il est vulnérable à certaines formes de variations de spectre/meltdown, tout ne dépend pas de l’hyperthreading. Dans le cas présent, l’hyperthreading ne semble pas obligatoire.
Il n’y a pas de magie: ces attaques ressemblent aux attaques de puces de cartes bleues: ils arrivent à savoir ce que fait la carte et quelles données elle manipule (les valeurs!!!) en analysant les micro évolutions de la consommation de la carte…
Un peu comme l’attaque de la mémoire dite de « hammering »: à force d’écrire, ils arrivent à induire un « bruit » qui va changer la valeur d’un autre emplacement mémoire…
On a aussi eu des POC sur des attaques sur la mémoire des cartes graphiques: ils détectaient des restes des images de navigateur et les extrayait car la mémoire graphique n’était pas forcément vidée totalement)
Bref, toutes les « optimisations » qui permettent de grapiller quelques précieux % de perfs permettant de faire remonter les ventes finissent pas être un problème de sécurité.
Je me rappelle le 1er document spectre/meltdown : sur un i5 3570K, le POC permettait d’extraire 40 octets à la seconde … Sur un skylake, 100ko/s: les optimisations avaient énormément optimisé les « failles ».
1 « J'aime »
Il a raison, c’est toi qui comprend mal le sens de la phrase :
« une baisse sensible » = « une baisse importante ».
C’est peu ou prou la meme chose.
Et « peu ou prou » veut dire « plus ou moins » : D
Un correctif engendrerait une chute des performances de nos CPU
Un chance que les processeurs sont de plus en plus puissant donc l’impacte ne devrait pas avoir trop d’importance .
alerte générale j’ai perdu un FPS dans mon jeu de Fortnite c’est inacceptable en 1080 p .
Quand on se retrouve devant un problème .
Ce n’est pas normale de le confronter pour le résoudre !
Je ne parlais pas uniquement de l’hyperthreading si vous voulez plus de détail :
« Tom Interviews Theo de Raadt of the OpenBSD Project » sur youtube en parle de manière accessible.
Bien sûr que les serveurs sont aussi concernés mais si tu fais la proportion serveurs / PC dans le monde, la menace est clairement côté PC. C’est évident que les serveurs seront patchés dans le cadre du patch management de l’entreprise si un correctif devait être disponible. Pas certain que tous les particuliers fassent la même démarche à moins de les y forcer.
Euh, allez dictionnaire.
Ah Zut, c’est pareil. Dans les 2 cas, il y a baisse
Sensible : qui se remarque
Drastique : non négligeable
Ah bah oui c’est pareil. Dingue cette affaire !
Tout a fait d’accord 
.
Ah je me suis coupé avec une feuille => supprimons le papier.
Ah il y a eu 1 accident grave en 40 ans sur une route en ligne droite. => allez on met un radar, des chicanes, on replante les platanes le long de la route et on fait des contrôles routiers pendant 3 mois pour sensibiliser
Euh, un peu excessif de toujours bosser en action/réaction.
Là il y a un risque « potentiel ». Ok, est ce que la solution doit forcément être matérielle, est ce qu’on n’arriverait pas à voir le comportement de la signature de l’attaque. Est-ce qu’on est obligé de boucher cette vulnérabilité pour tout le monde.
En voilà des questions avant de réagir de suite.
On vois le résultat avec spectre.
Et si on passait tous en ARM d’ici moins de 5 ans
Voir un saut dans l’inconnu avec du RISC (a l’échelle d’un PC) ou carrément sur une autre alternative encore nouvelle et expérimentale.
Les solutions de OpenBSD « améliorent » la protection en rendant plus rare les cas possible de copie de données, mais ce n’est pas impossible.
En gros, ils ont désactivé l’hyperthreading par défaut? On y perd en perf dans la majorité des cas. Séparer les tables de pages user/kernel? On se retrouve sur une structure mémoire proche de ce qu’on aurait avec un hyperviseur.
Guess what? L’attaque marche aussi sur les systèmes hypervisés et c’est bien le problème. OpenBSD a compliqué l’attaque car on peut difficilement déduire ce qu’on a lu comme données, mais on les a lues quand même.
La seule protection, c’est de ne pas mélanger dans les processus d’un serveur, qu’il soit sous Windows/Linux/OpenBSD/un hyperviseur: processus « vérifiés » et processus « non vérifiés »
Et sinon, t’exprimer sans être condescendant avec tout le monde, c’est quelque chose que tu sais faire ou non ?
PS : Mon message n’appelle pas de réponse, en revanche, j’apprécierais que tu arrives à t’exprimer avec plus de politesse à l’avenir.
Alors je ne répondrai pas…
#LoveBubbles
Sur openBSD il n’y a aussi pas de cross-SMT thread qui est la base de la faille dont fait objet l’article… Ca ressemblerai un peu à de la magie d’exploiter une faille sur un système qui ne comporte pas les éléments faillibles.
OK pour le cross SMT, mais le papier détaille 3 moyens, pas un seul. Et je disais juste que OpenBSD « bloque » certaines variantes, mais pas tout, comme les nouveaux schedulers bloquent ces variantes en ne permettant pas à des processus différents d’utiliser le même coeur sur 2 fils SMT sur d’autres OS et hyperviseurs (mais en conservant une partie du gain de perfs du SMT)