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

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/06/2010 08:35 AM, Daniel P. Berrange wrote:
> 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.
>    

There's talk of moving ecryptfs from a stackable file system to a VFS 
feature.  Among other things, this would make it usable by 
non-privileged users since there's really no reason for it to not be.

Let's take a step back though as I'd like to point out two things.  The 
first has feature support which means that if it's just a matter of 
adding something to the header and encrypting blocks, then it's super 
easy to add.  Furthermore, you get graceful detection of failure when 
using an encrypted image with a version of QEMU that doesn't support 
encryption in QED.  When creating new images that aren't encrypted with 
the new QEMU, the images still work with old QEMUs.

So really, there's little rush to add encryption (or any feature) to 
QED.  The main focus ATM is making we achieve good performance and good 
reliability.

But encryption is never simple.  If you want anymore more than a toy, 
you really need to integrate into a key ring system, make use of a 
crypto API to leverage cryptographic accelerators, etc.  This is why 
relying on the a filesystem (or VFS feature) makes so much sense.

> 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.
>    

That's one of the reasons I made this an optional feature.  I think 
we're going to have to revisit the backing format in the future to be 
something more meaningful.

For the purposes of the spec, I was going to say that backing_fmt was a 
suggestion to an implementation on how to interpret backing_file and 
leave it at that.

It terms of making something that's strictly enforced, I would suggest 
not specifying the format but rather having something like 
is_backing_raw.  IOW, a boolean that would be set if the backing file 
was raw (and not probe-able).  Otherwise, the backing format can be 
safely probed.

I would then say that backing file cannot be raw unless that bit is set 
or something like that.

> 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.

!raw would be a better way of specifying it but yeah, I think it's a 
reasonable idea.

Regards,

Anthony Liguori

>> 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
>