COMPTOIR
  
register

Composé par ————— —— 19294 vues

OpenBSD : Theo de Raadt convaincu que l'HyperThreading d'Intel est un danger

Décidément, 2018 est un vrai casse-tête pour le monde des processeurs en général, et pour Intel en particulier depuis la révélation au public des failles Meltdown et Spectre. Brian Krzanich doit certainement tout même être un peu soulagé de pouvoir désormais assister de loin au spectacle sans plus avoir à se salir les mains, car rares sont les mois qui se passent sans une nouvelle trouvaille. Certes, l'exploitabilité des failles est rarement des plus évidentes, mais leur existence seule suffit pour inquiéter, tout particulièrement ces milieux où la sécurité est une bataille de tous les instants. Le dernier trou en date est le L1 Terminal Fault, auquel OpenBSD avait déjà réagi un mois avant la publication des 3 vulnérabilités en supprimant l'HyperThreading de la version 6.4 d'OpenBSD !

 

intel pentium 4 hyperthreading

 L'HyperThreading, un long chemin depuis 2004 !

 

Il y a quelques jours, le fondateur d'OpenBSD, Theo de Raadt, est d'ailleurs revenu un peu sur le sujet. Il explique notamment que les mitigations via l'installation de patchs et de microcodes ne sont pas suffisantes pour garder les pirates à la porte, et réaffirme que les failles L1TF et TLBLeed obligent désormais également à la désactivation complète de l'HyperThreading. De plus,  malgré la difficulté d’implémentation de ces attaques par canaux auxiliaires, Theo est convaincu que des hackers découvriront tôt ou tard des méthodes d'exploitations fiables pour faire fuiter le kernel ou la mémoire commune lors de l'utilisation de virtualisation dans des conditions d'utilisations courantes !

En ce sens, le fondateur d'OpenBSD croit fermement que l'HyperThreading exacerbera au fil du temps la majorité des failles liées à l’exécution spéculative, d'où la nécessité de le désactiver sans détour. Simultanément, de Raadt critique aussi Intel pour son manque de transparence et d'assistance en matière de documentation et de recherche et développement pour les moyens et méthodes de mitigations. Histoire d'enfoncer le clou, Theo acheva son paragraphe par un "j'irai dépenser mon argent chez un vendeur plus fiable à l'avenir" assez peu équivoque...

 

Du haut de son château, Intel estime toutefois que la désactivation de l'HyperThreading n'est pas une nécessité, au moins tant que les autres techniques de mitigation ont bien été utilisées, à quelques exceptions près, par exemple lorsque les administrateurs et fournisseurs cloud ne peuvent garantir que leur matériel a bien été mis à jour. Hors virtualisation, les risques seraient par contre moindres dès lors que les mises à jour ont été correctement installées, toujours selon Intel. À condition bien sûr de pouvoir le faire, ce qui n'est forcement toujours le cas en fonction de l'assembleur ou constructeur, et aussi de l'âge du matériel.

En fin de compte, même s'il est encore difficile de jauger avec exactitude le niveau de danger que représentent ces failles, il est assez évident qu'il est de la responsabilité d'Intel - et des autres fabricants de microprocesseurs - d'assurer la sécurité complète de leurs produits auprès de la clientèle. (Source : Tom's)

 

theo de raadt openbsd

"J'suis pas content, ok !?".

Un poil avant ?

Gamotron • L'odyssée de l'espèce...

Un peu plus tard ...

Encore des prix pour les iX-9000K ? Cette fois-ci en Couronne Tchèque...

Les 23 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par La meilleure, l'EVO IX en Île-de-France, le Mercredi 29 Août 2018 à 17h52  
par Herbert lekonar de Bretagne le Mercredi 29 Août 2018 à 16h36
Ryzen , OoO ?
t'es sûr de ton coup là
Ah mince, je suis pas le seul à l'avoir remarqué... CHUT...

Tient, si t'as pas tout suivi ce qu'il a dit, il parle de "quelques éléments techniques, au niveau de l'organisation des caches notamment" pour parler des différences entre les architectures Zen et Core, alors que bon, les cores sont différents, le cache n'est pas du tout organisé de la même manière, l'organisation globale à l'intérieur du processeur n'est pas la même non plus... Des "détails" surement sans importance au final...

Puis entre nous, le SMT et l'HT sont plus ou moins équivalents dans la pratique (même si l'HT est plus performant, on va pas se le cacher), mais ce serait étonnant que les 2 technos soit si proches que ça d'un point de vue technique, surtout avec Intel qui arrive à garder des brevets qui ont je ne sais combien d'année, on ne sait pas trop comment...

Mais oui, tout comme toi à mon avis, j'ai relu plusieurs fois le Out of Order aussi...
par Herbert lekonar de Bretagne, le Mercredi 29 Août 2018 à 16h36  
Ryzen , OoO ?
t'es sûr de ton coup là
par Un alsacien à l'heure du Grand Est le Mercredi 29 Août 2018 à 09h27
Sans vouloir jouer les oiseaux de mauvais augure, Zen étant un processeur Out of Order et avec le SMT qui fonctionne comme l'Hyperthreading, il y a risque important que des failles similaires soient découvertes. L'architecture core est scrutée depuis des années celle de Zen depuis à peine plus d'un an. Il y a quelques éléments techniques, au niveau de l'organisation des caches notamment, qui font que ces failles seraient plus difficiles à exploiter mais ça ne veut pas dire qu'il n'y en a pas et que quelqu'un ne trouvera pas une méthode astucieuse pour les exploiter. Je crains que ce ne soit que le début chez Intel mais aussi chez AMD.
par Un ragoteur macagneur pas en Auvergne-Rhône-Alpes, le Mercredi 29 Août 2018 à 09h45  
par AntiZ le Mardi 28 Août 2018 à 11h30
Marc, on t'as reconnu !
Euh, non, désolé, mon prénom n'est pas "Marc"...
par Un alsacien à l'heure du Grand Est, le Mercredi 29 Août 2018 à 09h27  
Sans vouloir jouer les oiseaux de mauvais augure, Zen étant un processeur Out of Order et avec le SMT qui fonctionne comme l'Hyperthreading, il y a risque important que des failles similaires soient découvertes. L'architecture core est scrutée depuis des années celle de Zen depuis à peine plus d'un an. Il y a quelques éléments techniques, au niveau de l'organisation des caches notamment, qui font que ces failles seraient plus difficiles à exploiter mais ça ne veut pas dire qu'il n'y en a pas et que quelqu'un ne trouvera pas une méthode astucieuse pour les exploiter. Je crains que ce ne soit que le début chez Intel mais aussi chez AMD.
par Un médecin des ragots de Bretagne le Mercredi 29 Août 2018 à 05h05
avec toutes ces maj qui plombent les perfs
d'ici peu les ryzen seront 2x plus perfs que les coffee
par Un médecin des ragots de Bretagne, le Mercredi 29 Août 2018 à 05h05  
avec toutes ces maj qui plombent les perfs
d'ici peu les ryzen seront 2x plus perfs que les coffee

par AntiZ, le Mardi 28 Août 2018 à 11h35  
Y'a pas à dire, tout le monde se foutait de sa gueule. Et pourtant il avait raison.

En tout cas, OpenBSD ne démérite pas. Chapeau bas dans ce monde où la bêta en production et le rolling release est acceptable même au niveau professionel
par karmo le Mardi 28 Août 2018 à 07h59
Pas de soucis a se faire, intel retire l'HT sur ses i7
"Ce message vous a été envoyé depuis le fondement de Satan, avec les compliments de Saddam Hussein"

Par contre, il manque 2-3 smileys sur CDH, à quand les :vomi: :fouet: et autres ?
(Par pitié, rajoutez-les simplement, ne mettez pas ces cancers d'emojis qui traduisent très très mal les émotions ).
par AntiZ, le Mardi 28 Août 2018 à 11h30  
par Un ragoteur macagneur pas en Auvergne-Rhône-Alpes le Lundi 27 Août 2018 à 13h34
Les données de la RAM sont déjà brouillées ("scrambed" ) ; en gros, les lignes de données sont utilisées dans le désordre (par exemple, le bit 0 d'un mot de 64 bits de données va sur le bit 42 de la puce RAM, etc), mais c'est juste pour éviter les attaques du type "DRAM row hammering" ("martelage" des colonnes DRAM, qui permet de détériorer les données des colonnes adjacentes des cellules mémoire), voire parfois pour simplifier le routage des pistes des cartes mères (peu importe en effet quel bit de donnée va dans quelle cellule de mémoire, du moment qu'on écrit et lit le même bit à chaque fois: on peut alors utiliser les pattes des CPU et puces RAM qui se font face, même si les numéros des bits qu'elles représentent sont dans le désordre). Vu des programmes, les données ainsi "brouillées" restent néanmoins "en clair".

Le chiffrement (*) des données est cependant envisageable (et existe déjà ) pour assurer une isolation entre machines virtuelles. Mais il est aussi susceptible d'être attaqué: exemple d'attaque contre la solution d'AMD.

(*) Non, ce n'est ni du codage, ni du "cryptage", ce dernier n'existant d'ailleurs pas dans le vocabulaire Français du cryptologue: on décrypte des données dont ne connaît pas la clef de chiffrement, mais quand on a la clef, on "chiffre".
Marc, on t'as reconnu !
par Un ragoteur tout mignon en Nouvelle-Aquitaine le Mardi 28 Août 2018 à 04h07
Vivement la démocratisation de RISC-V
C'est clairement le futur de l'hardware, contrairement à ARM et ses bootloaders très dépendant des drivers...
par Dylem, le Mardi 28 Août 2018 à 10h56  
par Kronos embusqué le Lundi 27 Août 2018 à 11h44
Je ne vois pas pourquoi on essayerai pas de coder (crypter) les données sur la ram et qui sorte du cpu et c'est réglé.
Chiffrer !!
par karmo, le Mardi 28 Août 2018 à 07h59  
Pas de soucis a se faire, intel retire l'HT sur ses i7
par Un ragoteur tout mignon en Nouvelle-Aquitaine, le Mardi 28 Août 2018 à 04h07  
Vivement la démocratisation de RISC-V
par ArchitectureMIPSFANBOY! d'Occitanie, le Lundi 27 Août 2018 à 18h59  
96 ARM cores for life en 64-bit ARMv8 !
Parce que c'est la vie
par Loustic d'Occitanie, le Lundi 27 Août 2018 à 13h51  
Le bricolage qu'est L'HT d'Intel n'est pas et ne sera pas le dernier point d'entré de faille, on est qu'au le début des "découvertes".
Les CPU actuels X86 et autres ne sont pas conçu pour la sécurité, les soit disant prochain intel corrigés ne corrigeront presque rien. Il n'y a qu'un certitude: c'est qu'on a pas fini d'entendre parler de faille de ce type.