From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KStyj-00012d-NT for qemu-devel@nongnu.org; Tue, 12 Aug 2008 09:32:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KStyi-00011g-T0 for qemu-devel@nongnu.org; Tue, 12 Aug 2008 09:32:01 -0400 Received: from [199.232.76.173] (port=38436 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KStyi-00011P-JD for qemu-devel@nongnu.org; Tue, 12 Aug 2008 09:32:00 -0400 Received: from ag-out-0708.google.com ([72.14.246.246]:9474) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KStyi-0004Pe-Ga for qemu-devel@nongnu.org; Tue, 12 Aug 2008 09:32:00 -0400 Received: by ag-out-0708.google.com with SMTP id 31so785815agc.5 for ; Tue, 12 Aug 2008 06:31:59 -0700 (PDT) Message-ID: <48A190A9.1070902@codemonkey.ws> Date: Tue, 12 Aug 2008 08:31:21 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode References: <20080801102949.GN23993@redhat.com> <48932751.5040303@codemonkey.ws> <18579.16494.791024.25671@mariner.uk.xensource.com> <4893448C.1050508@codemonkey.ws> <18592.25422.257378.988970@mariner.uk.xensource.com> In-Reply-To: <18592.25422.257378.988970@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Ian Jackson wrote: > Anthony Liguori writes ("Re: [Qemu-devel] PATCH: v3 Allow control over drive file open mode"): > >> Ian Jackson wrote: >> >>> 4. qemu will take steps to try to ensure that bugs and missing >>> changes in the readonly implementation don't leave a security >>> hole where the >>> >> I'm not at all worried about this FWIW. >> > > Well, in the Xen world we have different priorities I think. Many > people are depending very heavily on the security properties of Xen > including the hardware emulations. So for us it is important that we > take all the measures we can to stop us from accidentally committing > bugs. > Which is fine, but you're missing my fundamental argument. Having a read-only flag exposed to the user should not translate to "open the underlying files O_RDONLY". That's an implementation detail. If that's what ends up happening, great. However, I'll make the argument also that for certain circumstances that's not actually what we want. > If this is something that qemu upstream doesn't want then we will have > to maintain it as a permanent delta in our `Xen' tree (along with the > mapcache, etc. etc.) > > It would be fine if there were in fact only one place where writes > take place. But actually there are multiple routes at pretty much all > levels: multiple entrypoints (aio and not, pwrite or not), multiple > block drivers, in cow devices multiple read/write paths depending on > whether the block is already present in the diffs and multiple writes > to the .img for each requested write, etc. > All writes end up going through the block-raw-posix write functions. >> qemu-system-x86_64 -drive file=foo.img -drive file=boo.img,read-only=on >> >> Down the road, you do a savevm. savevm has to create a checkpoint in >> all disk images. The checkpoint will be empty in boo.img but it still >> needs to create one. >> > > Perhaps I don't understand clearly enough how you imagine this > scenario. Surely when the snapshot is resumed it is sufficient for > the file boo.img to be identical ? > Not really. When the snapshot is restored, what do you do with boo.img? Do you just use the main L1 table if no properly named snapshots are available? That seems quite error prone to me. Another example is introducing a copy-on-read disk. This would be useful for image stream. Think a qcow2 file that backs an http block device. The perfect use-case for something like this is an ISO image which a user would want to export to the guest read-only. However, we need to modify the qcow2 image as the guest reads it (to do the copy-on-read). N.B. I've said before that there's no reason that a read-only disk cannot result in the file being opened O_RDONLY (for raw in particular) but that is a detail of each block device and I don't think it should be the case for qcow2. Regards, Anthony Liguori