TLBleed : Seeing double?

Les plus vieux d’entres nous se souviennent surement encore des débuts chaotiques (en environment serveur) de l’Hyper-Threading en 2002, cet artifice qui permettait de compenser les problèmes de l’architecture NetBurst d’Intel.

Compte tenu de son implementation de l’époque (très bien décrite, en Francais, par nos amis d’x86-secret), il était souvent recommandé de désactiver l’HT. Au fil des évolutions des CPU mais aussi des versions d’ESX, la situation a fini par s’inverser et le grand débat de l’HT pouvait prendre fin…

Internal testing shows that the recent generation of HT processors displays a higher performance gain from utilizing both logical processors. This means that the potential performance loss by letting some hyper-threads idle for a fairness reason becomes non trivial.

[...]

On vSphere 5.x, such a benefit is recognized and more CPU time is charged when both logical processors are busy. The implication of this newer charging model on HT is that a vCPU which is lagging behind can catch up more quickly even on a partial core, making it less necessary to use only the whole core.

…Ou pas, car comme l’a décrit x86-secret il y a 16 ans (!) :

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.

Et guess what, une équipe d’un centre de recherche hollandais dit avoir été capable d’exploiter cette faiblesse connue depuis de années (mais c’était avant AWS & Co) maintenant baptisée TLBleed. En pleine “crise” Spectre/Meltdown, Intel semble ne pas avoir l’intention d’adresser cette faille mais les choses pourraient bien changer au moment de la publication d’ici le mois d’Août. Et oui, AMD est potentiellement impacté aussi :)

Et surprise, l’équipe des devs du projet OpenBSD (“As of February 2018, only two remote vulnerabilities have ever been found in the default install, in a period of almost 22 years) a décidé de désactiver l’HT dans les nouvelles releases. Et c’est d’ailleurs pour ca que toute l’histoire est remonté à la surface.

On notera au passage que l’ANSSI recommandait déjà de désactiver l’HT depuis 2015 au moins, pour les mêmes raisons.

C’est donc le moment de sortir les popcorn’s. Quand on se souvient de l’affaire du salage de TPS pour des histoires de differences de latences de cache en environnement contrôlé, on se régale de la com VMware qui justifiera la désactivation d’HT dans ESX.

vExpert & vExpert VSAN 2018

Comme chaque année, c’est avec honneur que nous rejoignons les rangs des VMware vExpert et, plus récemment, ceux du vExpert VSAN progam. Une fois de plus nous tenons à remerciez VMware et tout ceux qui nous soutiennent.

Tags:

VMXNET3 = 10GbE ?

Nous nous décidons à écrire ce billet après avoir entendu par la millième fois “Le réseau est lent dans ma VM, on peut pas mettre une carte vmxnet3 pour avoir du 10 giga?”. Je sais c’est dur à lire mais c’est la triste vérité.

Donc pour donner une url plutôt que de retaper une fois de plus l’explication, voici l’extrait du VMware Virtual Networking Concepts qui fait foi :

The speed and duplex settings found in physical networking are not relevant in the virtual network, because all the data transfer takes place in the host system’s RAM, nearly instantaneously and without the possibility of collisions or other signaling-related errors.

Et si vous en aviez encore besoin, en voici la preuve :

iperf win64 entre 2 cartes e1000 "bridée" à 100Mo

iperf entre 2 cartes vmxnet3

Tags: ,

VIX & Kerberos Double Hop

Lors d’une petite session de PowerCLI avec les célèbres (mais bientôt deprecated) VIX APIs, nous nous sommes heurté à une limite de sécurité bien connue des admins Microsoft: le Kerberos Double Hop.

Pour résumer, nous avions besoin d’exécuter un script situé sur un share depuis un ensemble de VM et nous avons bien évidement tenté de profiter du fait que VIX supporte le SSO, comme des gros fainéants. Et là, c’est le drame:

When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a security measure kicks in and doesn’t allow your site to access resources on any network servers.  This includes access to a UNC path directly from IIS or SQL Server using Windows authentication.

Il nous a suffit de passer les credentials à l’Invoke-VMScript pour que l’UNC devienne accessible:

Tags: , , ,

RegisterVM_task onliner

Raiders Of The Lost VMX est l’un des plus vieux et des plus célèbres script de Luc Dekens. Pour rappel il permet, entre autres, d’enregistrer en masse des vmx “perdus”. Très pratique pour les tests de Disaster Recovery en mode artisanal…

Apres un crash de carte SD de boot, sans backup du state.tgz (sinon c’est pas drôle), nous devions ré-enregistrer les VM présentent sur ce host en standalone. Ces VM étant des replicas Veeam, nous ne pouvions pas risquer de perdre le MoRef, donc obligation de les enregistrer en direct sur l’ESX fraichement redeployé. Et comme il y en avait plus de 150, pas question de le faire à la main donc pourquoi ne pas utiliser le script de Luc ? Oui pourquoi ? Et bien parce que nous voulions le faire avec un oneliner bien sur !

Voici donc un oneliner qui va chercher les fichiers vmx dans le datastore datastore1 (à changer au début du oneliner) et les enregistrer avec leur nom original (DisplayName dans le vmx) sur l’ESX.

Get-View -ViewType Datastore -Property Name,Browser -Filter @{"Name" = "^datastore1$"}|%{(Get-View $_.Browser).SearchDatastoreSubFolders($("[" + $_.Name + "]"),(New-Object VMware.Vim.HostDatastoreBrowserSearchSpec -Property @{matchPattern=("*.vmx")}))}|%{(Get-View -ViewType Folder -Property Name -Filter @{"Name" = "^vm"}).GetType().GetMethod("RegisterVM_Task").Invoke($(Get-View -ViewType Folder -Property Name -Filter @{"Name" = "^vm"}),@($($_.FolderPath + "/" + $_.File.Path),$null,$false,(Get-View -ViewType ResourcePool -Property Name -Filter @{"Name" = "Resources"}).MoRef,$null))}

1ere chose importante, ce onliner doit impérativement être exécuté depuis l’ESX et non le vcenter pour ne pas perde le MoRef des vm, si toute fois elles existent déjà dans le vCenter. Donc c’est un connect-viserver sur l’ESX qu’il convient d’exécuter dans votre console PowerCLI.

2eme chose, la difficulté de ce oneliner à été de faire passer un $null pour le paramètre “name” à la method RegisterVM_Task :

If this parameter is not set, the displayName configuration parameter of the virtual machine is used

Ca a l’air de rien mais en l’état c’est impossible et c’est grâce à un vieux post de Luc (encore lui !) qui retranscrit une solution provenant du support VMware :

VMware Support came up with a solution.
Big thanks to Jain

The problem was basically how to “not set” the name parameter from within PowerShell.

Nous avons donc pu intégrer ce bout de script au notre. Enjoy!