URL: https://linuxfr.org/users/davidmarec/journaux/rumeurs-sur-l-hyper-threading-tlbleed Title: Rumeurs sur l'hyper-threading - TLBleed Authors: David Marec Date: 2018年06月22日T23:22:37+02:00 License: CC By-SA Tags: theo_de_raadt, sécurité, spectre et tlb Score: 38 La peinture de la dépêche sur la faille [Lazy FPU save restore](https://linuxfr.org/news/faille-lazy-fpu-state-restore) n'étais pas encore sèche que je tombais sur de curieux messages conseillant de désactiver l'[Hyper-threading](https://www.intel.com/content/www/us/en/architecture-and-technology/hyper-threading/hyper-threading-technology.html). Suivis de conversations plus ou moins inquiétantes sur Twitter et dans les mailings list. Accroche toi au pinceau ======== Un _commit_ sur **OpenBSD** désactive l' _Hyper-treading_ par défaut. Le message associé est explicite:> « _Since many modern machines no longer provide the ability to disable Hyper-threading in the BIOS setup, provide a way to disable the use of additional processor threads in our scheduler. And since we suspect there are serious risks, we disable them by default_ »> Puisque les machines récentes ne donnent plus la possibilité de désactiver l' Hyper-threading depuis le BIOS, trouvez un moyen de désactiver l'utilisation des threads d'un processeur dans notre ordonnanceur.> Et comme on suspecte que le risque est sérieux, désactivons le par défaut. Pour faire plus court, j'avais lu auparavant un laconique:> ps deactivate Hyper-threading on your server > Désactivez l'_Hyper-threading_ sur vos serveurs ! Venant des équipes OpenBSD, il y a de quoi s'interroger. J'enlève l'échelle ============= La conférence [Black Hat](https://www.blackhat.com/us-18/) qui se déroulera en août prochain, propose au menu: * [quand protéger vos caches CPU n'est pas suffisant](https://www.blackhat.com/us-18/briefings.html#tlbleed-when-protecting-your-cpu-caches-is-not-enough):> « _This therefore bypasses several proposed CPU cache side-channel protections. Our TLBleed exploit successfully leaks a 256-bit EdDSA key from libgcrypt (used in e.g. GPG) with a 98% success rate after just a single observation of signing operation on a co-resident hyperthread and just 17 seconds of analysis time_ »> En outre, ceci court-circuite plusieurs protections sur le cache. Notre _exploit TLBeed_ a réussi à voler une clef 256-bit EdDSA depuis _ligcrypt_ (utilisée par **GPG** ) dans 98% des tentatives, après une simple observation des opérations de signature depuis un _thread_ tournant sur le même CPU en seulement 17 secondes d'analyse. * sans oublier le [petit message de remerciement](https://marc.info/?l=openbsd-cvs&m=152950505100759&w=2) du sieur de Raadt. Colin Percival, auteur en 2005 de: 1. un papier sur les attaques via les caches, [Cache Missing for Fun and Profit](http://www.daemonology.net/papers/htt.pdf) 2. un article qui cible plus particulièrement les risques liés à l'[Hyper-threading](http://www.daemonology.net/hyperthreading-considered-harmful/) en remet une couche:> « _I think it's worth mentioning that one of the big lessons from 2005 is that side channel attacks become *much* easier if you're executing on the same core as your victim_ »> Je pense qu'il est bon de rappeler cette grande leçon de 2005: une attaque en `side channel` est tellement plus facile si vous l'exécutez sur le même cœur que votre victime. Cuisine ========== Intel n'est jamais clairement impliqué; mais je précise, comme ça, en passant, que l'Hyper-Threading est une implémentation Intel du [Simultaneous Multi Threading](https://fr.wikipedia.org/wiki/Simultaneous_multithreading). Il s'agit de faire exécuter en parallèle, sur un même cœur, plusieurs unités fonctionnelles ou de calcul. Et pour rendre cette technique efficace et moins gourmande en ressource, cette implémentation partage aussi les caches mémoires.> Keep systems protected, efficient, and manageable while minimizing impact on productivity Conclusion ========== Toutes les solutions de sécurité aujourd’hui ne sont que des châteaux forts construit sur du sable. Si encore une fois, la désactivation de l'Hyper-threading pourrait même avoir des effets positifs sur les performances, autant en finir une fois pour toute. Retour aux origines: * un partage complet sans protection des ressources * plus de mode protégé * pas même de segmentation mémoire Vos machines iront encore plus vite. Enfin, j'espère.

AltStyle によって変換されたページ (->オリジナル) /