Debian, VMware et bug Intel...
Le
David BERCOT
Hello,
J'imagine que vous avez suivi l'actualité et notamment la super faille
sur les processeurs Intel
Chaque éditeur (ou équivalent) travaille (voire à déjà fourni) un patch
pour ce bug.
Maintenant, la question que je me pose est la suivante : est-ce que,
quand VMware a corrigé cette faille, doit-on patcher les OS installés
au-dessus ?
Sachant que cette faille est matérielle, ça me semble pertinent ;-)
Merci d'avance pour les éléments que vous pourrez m'apporter.
Et meilleurs voeux à tous !!!
David.
J'imagine que vous avez suivi l'actualité et notamment la super faille
sur les processeurs Intel
Chaque éditeur (ou équivalent) travaille (voire à déjà fourni) un patch
pour ce bug.
Maintenant, la question que je me pose est la suivante : est-ce que,
quand VMware a corrigé cette faille, doit-on patcher les OS installés
au-dessus ?
Sachant que cette faille est matérielle, ça me semble pertinent ;-)
Merci d'avance pour les éléments que vous pourrez m'apporter.
Et meilleurs voeux à tous !!!
David.
Un article sur le sujet :
www.lemonde.fr/pixels/article/2018/01/05/meltdown-et-spectre-les-deux-faill es-critiques-decouvertes-dans-la-plupart-des-processeurs_5237712_4408996.ht ml
Le bug est hardware, il y a un correctif pour la faille Meltdown,
mais pas de correctif pour la faille Spectre, c'est inquiétant.
Pour Debian, un correctif pour Meltdown existe, mais que pour
la dernière version Stretch, j'ai pas vu pour Jessie...
Bonne soirée,
André
On 01/06/2018 07:05 PM, wrote:
Bulletin d'alerte Debian - DSA-4078 (1) :
Les autres vulnérabilités (nommées Spectre) publiées en même temps ne
sont pas traitées dans cette mise à jour et seront corrigé es dans une
mise à jour ultérieure.
On 01/06/2018 07:05 PM, wrote:
Même DSA :
Pour la distribution oldstable (Jessie), ce problème sera corrigé dans
une mise à jour séparée.
Pour la distribution stable (Stretch), ce problème a été c orrigé dans la
version 4.9.65-3+deb9u2.
On 01/06/2018 03:02 PM, David BERCOT wrote:
Si il s'agit de VM oui, elles ont leurs propres noyau, je dirais encore
plus si c'est de l’hypervision de type 1 (2 et 3).
Si il s'agit d'un conteneur (LXC, Docker...) le noyau est celui de
l'isolateur, donc la mise à jour sera à faire sur l'isolateur l ui même.
[1] : https://www.debian.org/security/2018/dsa-4078.fr.html
[2] : https://fr.wikipedia.org/wiki/Hyperviseur
[3] :
https://fr.wikipedia.org/wiki/Virtualisation#Diff%C3%A9rentes_techniques
Le 07/01/2018 à 12:00, Alban Vidal a écrit :
[...]
En effet, les VM ont leurs propres noyaux. Maintenant, le problème ne
vient pas du noyau mais bien du matériel. S'il n'y a plus de problème au
niveau matériel, il n'y a aucune raison de corriger le noyau...
Comme ce n'est pas le cas, il faut en effet patcher les noyaux.
Mais ma question portait plutôt sur le fait que, si l'hyperviseur était
patché et donc, potentiellement, le matériel "présenté" aux VM ne
présentait plus de faille, était-il nécessaire de patcher les OS de ces
dernières ?
Personnellement, je dirais non ;-)
David.
Si tu es en mode hyperviseur, c'est à dire avec des hypercalls,
effectivement, on doit peut-être pouvoir s'en passer. Donc cela implique
d'être sous Xen et non KVM et vraiment en mode hypercall...
Avec KVM par exemple, tu utilises la virtualisation matérielle du CPU
donc tu n'es pas protégé par l'hyperviseur.
gaby
--
Gabriel Moreau - IR CNRS http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto: tel:+33.476.825.015