|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format |
Date: | Mon, 06 Sep 2010 11:38:52 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |