Meltdown & Specter - L'application de correctifs au noyau invité d'un hyperviseur non corrigé empêche-t-elle les fuites de mémoire entre plusieurs machines virtuelles?

24 heures après la publication à grande échelle des vulnérabilités, Rackspace est silencieux sur Spectre et Meltdown. Ils n'ont pas de plan pour patcher tous leurs hyperviseurs Xen. Tous leurs serveurs de plate-forme plus récents sont des serveurs HVM, qui sont vulnérables. Les serveurs PV plus anciens ne sont pas vulnérables.

J'ai mis à jour le noyau Linux de mes invités HVM, mais Rackspace n'a mis à jour aucun de leurs hyperviseurs. La mise à jour du noyau invité sur un hyperviseur non corrigé empêchera-t-elle les machines virtuelles «malveillantes» d'accéder à la mémoire qui a fui de mon hôte corrigé?

D'après ce que je comprends des vulnérabilités, non - les attaques de mise en cache spéculative contournent toutes les protections du processeur contre un processus accaparant la mémoire à partir de n'importe quelle adresse arbitraire.

Je pense que cela inclurait les machines virtuelles voisines (même celles corrigées pour se protéger contre l'attaque elles-mêmes) ainsi que l'espace mémoire du noyau de l'hyperviseur - mais même s'il y a quelque chose qui me manque qui protégerait contre la divulgation directe de la mémoire, il y a aussi un potentiel que l'attaquant pourrait utiliser leur accès à la mémoire du noyau pour obtenir un accès plus complet à l'hyperviseur.

Vous ne voulez certainement pas risquer d'exécuter une charge de travail sensible sur un hyperviseur non corrigé de quelque nature que ce soit si vous ne faites pas confiance à toutes les machines virtuelles qui s'exécutent dessus.

Spectre et fusion.

Où allons-nous commencer? un mauvais, je veux dire un très mauvais communiqué de presse de quelque chose qui peut ou non affecter votre ordinateur, poste de travail, serveur ou serveur dans le cloud. Oui, tout à fait, mais vous devez avoir un accès local au processeur associé, qui peut être un PC ou un téléphone, semble-t-il, Apple a été un exemple mais laisse penser son processeur ARM, donc c'est chaque plate-forme mobile qui prend en charge la (fonctionnalité / exposition au microcode / trop de contrôle sur le CPU à partir du système d'exploitation / etc / etc)

L'application doit être exécutée sur le processeur de l'appareil, donc je pense que l'accès à la console, ou au moins l'utilisateur distant qui accède au système, l'accès au périphérique d'entrée ....

À l'heure actuelle, la seule façon connue d'exploiter ces vulnérabilités est d'accéder localement / directement au processeur (encore une fois, vous pouvez être distant une fois que vous avez SSH / VNC, etc.)

Voici les correctifs que j'ai trouvés jusqu'à présent.

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

Maintenant, cela doit être la meilleure réponse au problème en ce moment

Qu'ont dit nos amis BSD?

Mauvais google; (

un chèque Powershell pour la même chose;)

Le noyau Linux D'accord, nous avons eu une semaine intéressante, et maintenant tout le monde sait pourquoi nous avons fusionné tous ces correctifs d'isolement des tables de pages x86 sans suivre toutes les règles normales de calendrier de publication.

Je pourrai / reviendrai et modifierai ce message. Je suis sûr que le non-problème (jusque dans la nature) ne sera pas un vrai problème à long terme. Google aurait vraiment dû suivre les dates de publication des divulgations ici! -1 pour Google