Re: [HS] Virtualisation
Re,
On 22/07/2010 22:49, JF Straeten wrote:
> Re,
>
> On Thu, Jul 22, 2010 at 08:25:10PM +0200, Jean Baptiste FAVRE wrote:
>
>>> Mais as-tu vu quelque part les raisons du choix de Xen plutôt que KVM
>>> (je n'ai pas lu leur PDF...) ?
>
>> Donc, dans le principe, si tu parviens à compromettre l'OS de
>> gestion de KVM (appelé dom0 sous Xen), tu as immédiatement et
>> implicitement accès à l'hyperviseur. Pour Xen, compromettre le dom0
>> ne signifie pas compromettre l'hyperviseur.
>
>> Tout ceci est censé renforcer la sécurité de Xen par rapport à
>> d'autres soutions de virtualisation.
>
>> Mais ce n'est valable que tant qu'on n'aura pas démontré de faille
>> prouvant le contraire ;-)
>
> Hmm... le dom0, c'est Xen + un noyau dessus, non ?
En fait, pas exactement.
Xen, c'est l'hyperviseur, il est tout seul.
Il lance automatiquement un OS "classique" en machine virtuelle. Cette
machine est privilégiée, mais n'a pas d'autres accès à l'hyperviseur que
ceux qu'il veut bien exposer.
Par exemple, c'est comme cela que Qube OS parvient à séparer les
fonctions stockage et réseau: l'hyperviseur donne accès à la carte
réseau à une VM non privilégiée et au stockage à une autre.
Dans le cas de KVM, c'est un OS classique qui est lancé, OS auquel on
adjoint un mécanisme d'hypervision. Cette capacité est gérée par un
module du noyau. Donc, l'OS est l'hyperviseur, ce qui n'est pas le cas
de Xen.
De mémoire il y a en plus des histoires de ring des processeurs, mais je
ne maîtrise que peu cet aspect des choses, notamment pour KVM.
>
> Donc, si je ne dis pas de bêtise, l'ensemble du code Xen + noyau est
> plus important que le noyau tout seul qui contient KVM...
>
> Est-ce que ça n'augmente pas logiquement la probabilité d'une faille
> s'il y a plus de code ?
En fait non car dans le cas de KVM, il faudrait prendre en compte tout l'OS.
Mais je suis loin d'être un spécialiste en la matière. Je ne fais que
retranscrire ce que j'ai compris (ou cru comprendre) de mes lectures sur
le sujet ;-)
@+
JB
Reply to: