Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Sep 06, 2010 at 07:52:41AM -0500, Anthony Liguori wrote:
> On 09/06/2010 06:18 AM, Daniel P. Berrange wrote:
> >I agree with ditching compression, but encryption is an important
> >capability which cannot be satisfactorily added at other layers
> >in the stack. While block devices / local filesystems can layer
> >in dm-crypt in the host, this is not possible with network/cluster
> >filesystems which account for a non-trivial target audience.
> 
> ecryptfs should work with NFS these days.  If it still doesn't, it will 
> in the not too distant future.

Assuming it does work with NFS, IIUC, that still requires the user to
have root privileges to setup ecryptfs for the NFS mount in question.
So it takes care of the use case where the host admin doesn't trust
the network/remote fs admin, but doesn't work for the case of local
unprivileged users with NFS home dirs & a host admin who doesnt help.

> >  Adding
> >encryption inside the guest is sub-optimal because you cannot do
> >secure automation of guest startup. Either you require manaual
> >intervention to start every guest to enter the key, or if you
> >hardcode the key, then anyone who can access the guest disk image
> >can start the guest.
> 
> I think this belongs in the VFS level but from a format perspective, an 
> encryption feature would be easy to add.
> 
> >>+
> >>+        if ((s->header.compat_features&  QED_CF_BACKING_FORMAT)) {
> >>+            ret = qed_read_string(bs->file, s->header.backing_fmt_offset,
> >>+                                  s->header.backing_fmt_size,
> >>+                                  bs->backing_format,
> >>+                                  sizeof(bs->backing_format));
> >>+            if (ret<  0) {
> >>+                return ret;
> >>+            }
> >>+        }
> >>     
> >IMHO we should make the backing format compulsory with use of
> >the backing file. The only time probing is required is when
> >initially creating the child image, thereafter there's no
> >benefit to probing again.
> >   
> 
> Stefan originally made it mandatory but I asked to make it optional.
> 
> From a format specification perspective, backing_fmt introduces some 
> problems.  What does a backing_fmt of 'vmdk' mean outside of qemu?

As currently implemented the string refers to a QEMU block driver
which is perhaps not the best choice for a general purpose file
format, if we want this applicable to other non-QEMU apps. Perhaps
it would be better if we explicitly declared backing format as an
enumerated int that represents specific file formats, thus decoupling
it from a specific driver.

Another related idea is perhaps to specify that if backing_fmt is
omitted in the metadata, the backing file must be treated as a QED
format file, rather than probed. Arguably qemu's VMDK driver should
be treating all VMDK backing files as VMDK format rather than probing
since I'm not VMware has no idea of a backing file in qcow or any
other format.

> More importantly, humans to create image formats by hand.  Instead, they 
> use tools like qemu-img.  If you think we should for the specification 
> of a backing file format in qemu-img, that's the place we should do it.

Certainly qemu-img can always add a format, even if the specification
declared it optional, but I think its worth considering declaring it
it compulsory in the spec, to take that variable out of the equation
for apps using the images.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|