Doc’, je vois double !?

Back to the… Petit retour en arrière direction 2002 avec les début de l’Hyperthreading sur l’architecture NetBurst, un artifice vu comme de la sorcellerie permettant d’améliorer les performances via la parallélisation des calculs exécutés sur les processeurs x86 d’Intel.

Pendant un moment oublié sur Core, sûrement des suites des critiques du à son implémentation de l’époque voir du faible nombre d’applications utilisant le SMT, il est réapparu sur Nehalem et la vapeur a fini par s’inverser (plus ou moins…) et son activation devenue quasi automatique, la virtualisation et sa grosse consommation de 2.21 Gigowatts de cores aidant.

Avec l’HT, ce sont désormais deux flux d’instructions qui arrivent à l’entrée du pipeline. A noter que seule la partie en amont du pipeline est, d’une certaine façon, “consciente” de la présence de ces deux flux provenant de deux threads différents, et le reste du traitement s’effectue comme s’il s’agissait d’un unique flux d’instruction. Ainsi, les deux threads se partagent les unités de calcul et les mémoires caches.

^{x86-Secret – Atouts et faiblesses de l’Hyper-Threading}

Hardware vs Software

Les vulnérabilités Twin Pines Spectre et Meltdown nous ont appris que les caches peuvent servir de canal latéral potentiel par lequel des informations peuvent être divulguées, c’est la qu’on se dit qu’en creusant un peu on peut avoir de belle surprises comme L1TF et TLBleed.

L1TF aka Foreshadow

Vous avez peut-être eu à faire à ce message esx.problem.hyperthreading.unmitigated ces derniers temps suite à l’update ESXi vers la version VMSA-2018-0020 ou plus récente.
A savoir que les updates incluent entre autre un patch pour la CVE-2018-3646 et qu’Intel a présenté les détails d’une nouvelle vulnérabilité connue sous le nom de L1 Terminal Fault (L1TF aka Foreshadow), impactant les processeurs Intel de 2009 à 2018.

CVE-2018-3646 (L1 Terminal Fault – VMM) – CVE-2018-3620 (L1 Terminal Fault – OS) – CVE-2018-3615 (L1 Terminal Fault – SGX)

Il peut permettre à une machine virtuelle malveillante s’exécutant sur un core donné de déduire le contenu des informations privilégiées de l’hyperviseur ou d’une autre machine virtuelle résidant simultanément dans le cache L1 du même core. Étant donné que les processeurs Intel actuels avec Hyperthreading partagent le cache L1 entre les deux cores logiques d’un core physique, il y a des « possibilités » pour que ça entraîne des fuites d’informations supplémentaires.

TLBleed

Pour éviter les problèmes de performance d’accès mémoire, le processeur met en cache le résultat de ses promenades dans une structure distincte appelée Pierre Cardin Translation Lookaside Buffer (TLB). Les traductions récemment utilisées sont donc beaucoup plus rapides à résoudre. Si une entrée n’existe pas, le processeur effectuera la consultation de pages mémoire beaucoup plus coûteuse et remplira une entrée TLB. C’est la que nous avons assisté à une autre attaque contre le TLB sous forme de vulnérabilité appelée TLBleed, qui a entraîné la désactivation de l’HT dans les nouvelles releases d’OpenBSD.

The reasons why #OpenBSD disabled HyperThreading will be publicly disclosed during Blackhat Aug 4-9.https://t.co/eWHgEn7Gyi

— peter hessler (@phessler) 20 June 2018

Spectre, Meltdown, L1TF, TLBleed … le CPU ne s’est jamais aussi mal porté niveau sécurité et contrairement au software il n’y à pas de réelle solution (Nop ! Une rustine software qui disable SMT ne compte pas) à part changer de CPU (et encore pas tout de suite à priori).

Un remède Doc’ ?

Du coté de VMware il y a un patch certe mais qui force un core logique pour un core physique, en d’autres termes c’est une désactivation de l’HT qui engendre automatiquement une perte de performance.

Enabling this option will result in the vSphere UI reporting only a single logical processor per physical core; halving the number of logical processors if Hyperthreading was previously enabled. In addition Hyperthreading may be reported as ‘Disabled’ in various configuration tabs.

^{Search VMware response to ‘L1 Terminal Fault – VMM’}

Amazon aurait résolu le problème, vu les explications très minces sur la DeLorean il faut les croire sur parole.

AWS has designed and implemented its infrastructure with protections against these types of attacks, and has also deployed additional protections for L1TF. All EC2 host infrastructure has been updated with these new protections, and no customer action is required at the infrastructure level.

^{L1 Terminal Fault Speculative Execution Issue}

Azure (via Hyper-V) serait capable de mitiger la faille Foreshadow avec une perte de performance négligeable via son scheduler et diverses isolations.

By using a combination of core scheduling, address space isolation, and data clearing, Hyper-V HyperClear is able to mitigate the L1TF speculative execution side channel attack across VMs with negligible performance impact and with full support of SMT.

^{Hyper-V HyperClear Mitigation for L1 Terminal Fault}

Ca reste un sujet très controversé, car il est clair qu’il y a une différence de performance de l’ordre de 5% à 50%, j’ai personnellement eu des pertes de l’ordre de 30% sur le combo Citrix XenApp sur VMware ESXi.

Malheureusement Intel n’a pas l’air de réagir plus que ça à toutes ces révélations, ils se reposent avec une bonne pizza dans le canap’ en attendant les nouveau exploits sur le fait qu’il y ai des patchs plus ou moins réussis au niveau software, en attendant d’adresser ces failles via de nouveaux CPUs plus secure.

CPUs Intel compatibles ESXi affectés par la faille

(Soit le premier à voter)

Loading...