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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
andre_debian
On Saturday 06 January 2018 15:02:14 David BERCOT wrote:
J'imagine que vous avez suivi l'actualité et notamment la super fail le 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.
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 Saturday 06 January 2018 15:02:14 David BERCOT wrote:
J'imagine que vous avez suivi l'actualité et notamment la super fail le
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.
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...
On Saturday 06 January 2018 15:02:14 David BERCOT wrote:
J'imagine que vous avez suivi l'actualité et notamment la super fail le 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.
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é
Alban Vidal
Bonjour, On 01/06/2018 07:05 PM, wrote:
Le bug est hardware, il y a un correctif pour la faille Meltdown, mais pas de correctif pour la faille Spectre, c'est inquiéta nt.
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:
Pour Debian, un correctif pour Meltdown existe, mais que pour la dernière version Stretch, j'ai pas vu pour Jessie...
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:
Maintenant, la question que je me pose est la suivante : est-ce que, quand VMware a corrigé cette faille, doit-on patcher les OS instal lés au-dessus ? Sachant que cette faille est matérielle, ça me semble pertine nt
On 01/06/2018 07:05 PM, andre_debian@numericable.fr wrote:
Le bug est hardware, il y a un correctif pour la faille Meltdown,
mais pas de correctif pour la faille Spectre, c'est inquiéta nt.
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, andre_debian@numericable.fr wrote:
Pour Debian, un correctif pour Meltdown existe, mais que pour
la dernière version Stretch, j'ai pas vu pour Jessie...
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:
Maintenant, la question que je me pose est la suivante : est-ce que,
quand VMware a corrigé cette faille, doit-on patcher les OS instal lés
au-dessus ?
Sachant que cette faille est matérielle, ça me semble pertine nt
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.
Le bug est hardware, il y a un correctif pour la faille Meltdown, mais pas de correctif pour la faille Spectre, c'est inquiéta nt.
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:
Pour Debian, un correctif pour Meltdown existe, mais que pour la dernière version Stretch, j'ai pas vu pour Jessie...
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:
Maintenant, la question que je me pose est la suivante : est-ce que, quand VMware a corrigé cette faille, doit-on patcher les OS instal lés au-dessus ? Sachant que cette faille est matérielle, ça me semble pertine nt
Bonjour Alban, Le 07/01/2018 à 12:00, Alban Vidal a écrit : [...]
On 01/06/2018 03:02 PM, David BERCOT wrote:
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
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 lui même.
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.
Bonjour Alban,
Le 07/01/2018 à 12:00, Alban Vidal a écrit :
[...]
On 01/06/2018 03:02 PM, David BERCOT wrote:
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
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 lui même.
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 ;-)
Bonjour Alban, Le 07/01/2018 à 12:00, Alban Vidal a écrit : [...]
On 01/06/2018 03:02 PM, David BERCOT wrote:
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
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 lui même.
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.
Gabriel Moreau
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;-)
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
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;-)
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:Gabriel.Moreau@legi.grenoble-inp.fr tel:+33.476.825.015
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;-)
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
