qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] live snapshot wiki updated


From: Kevin Wolf
Subject: Re: [Qemu-devel] live snapshot wiki updated
Date: Fri, 22 Jul 2011 09:22:43 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11

Am 21.07.2011 17:01, schrieb Stefan Hajnoczi:
> On Thu, Jul 21, 2011 at 3:02 PM, Eric Blake <address@hidden> wrote:
>> Thank you for persisting - you've found another hole that needs to be
>> plugged.  It sounds like you are proposing that after a qemu process dies,
>> that libvirt re-reads the qcow2 metadata headers, and validates that the
>> backing file information has not changed in a manner unexpected by libvirt.
>>  If it has, then the qemu process that just died was compromised to the
>> point that restarting a new qemu process from the old image is now a
>> security risk.  So this is _yet another_ security aspect that needs to be
>> coded into libvirt as part of hardening sVirt.
> 
> The backing file information changes when image streaming completes.
> 
> Before: fedora.img <- my_vm.qed
> After: my_vm.qed (fedora.img is no longer referenced)
> 
> The image streaming operation copies data out of fedora.img and
> populates my_vm.qed.  When image streaming completes, the backing file
> is no longer needed and my_vm.qed is updated to drop the backing file.
> 
> I think we need to design carefully to prevent QEMU and libvirt making
> incorrect assumptions about who does what.  I really wish that all
> this image file business was outside QEMU and libvirt - that we had a
> separate storage management service which handled the details.  QEMU
> would only do block device operations (no image format manipulation),
> and libvirt would only delegate to the storage management service.

And how do you implement that in a way that works on all platforms, and
without root privileges? I can't see this happen unless it stays
completely optional.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]