From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56879 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZniC-0002Jy-Qx for qemu-devel@nongnu.org; Fri, 16 Jul 2010 12:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZniA-0006Qj-MI for qemu-devel@nongnu.org; Fri, 16 Jul 2010 12:24:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60210) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZniA-0006QN-Cl for qemu-devel@nongnu.org; Fri, 16 Jul 2010 12:24:30 -0400 Message-ID: <4C4087AE.1060003@redhat.com> Date: Fri, 16 Jul 2010 18:24:14 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Make default invocation of block drivers safer References: <1279123952-1576-1-git-send-email-aliguori@us.ibm.com> <20100714184311.GA9383@lst.de> <4C3E06DA.8080302@codemonkey.ws> <4C3F355E.3020800@codemonkey.ws> <4C4085DF.1080307@codemonkey.ws> In-Reply-To: <4C4085DF.1080307@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi , Christoph Hellwig Am 16.07.2010 18:16, schrieb Anthony Liguori: > On 07/16/2010 11:06 AM, Markus Armbruster wrote: >> Anthony Liguori writes: >>> To accomodate current use-cases with raw, let's introduce a new format >>> called "probed_raw". probed_raw's semantics will be the following: >>> >>> The signature of a probed_raw will be ~{'QFI\xfb', 'VMDK', 'COWD', >>> OOOM', ...}. If the signature is 'QRAW', then instead of reading the >>> first sector at offset 0, we read the first sector at offset LENGTH. >>> If the signature is 'QRAW', LENGTH is computed by calculating >>> FILE_SIZE - 512. >>> >>> For probed_raw, write requests to sector 0 are checked. If the first >>> four bytes is an invalid probed_raw signature or QRAW, we write a QRAW >>> signature to file offset 0 and copy the first sector to the end of the >>> file redirecting reads and writes to the end of file. >>> >> Doesn't this require an image that can grow? What about host block >> devices? >> > > I don't believe we probe host block devices. We assume they're raw > which means they would never be probed_raw. We do probe them. And yes, I know you love qcow2 on block devices. ;-) >>> An approach like this has the following properties: >>> >>> 1) We can make the bdrv_probe check 100% reliable and return a boolean. >>> 2) In the cases where we known format=raw, none of this code is ever >>> invoked. >>> 3) probed_raw images usually look exactly like raw images in most cases >>> 4) In the degenerate cases, probe_raw images are still mountable in >>> the normal way. >>> 5) Even after the QRAW signature is applied, if the guest writes a >>> valid signature, we can truncate the file and make it appear as a >>> normal raw image. >>> >>> Christoph/Markus/Stefan, does this seem like a more reasonable approach? >>> >> I'm not convinced it's a good idea. It's clearly a less bad idea, >> though :) >> >> It avoids guest-visible lossage, and that's good. >> >> There's still host-visible lossage: as soon as we redirect sector 0, the >> image isn't raw anymore, and accessing it with non-qemu tools (say >> losetup + kpartx) no longer works. You need to know what QEMU did to >> your no-longer-raw image to work around the lossage (say losetup -o >> 512). >> > > Yeah, but as previously discussed, we can't probe raw. So probed_raw > ends up being a compromise. > >>>> That they get an unsafe >>>> default that way is a big surprise to them. And I can't blame them! >>>> Users can reasonably expect programs not to trap them. >>>> >>>> If we want to let users define drives without having to specify the >>>> format, we can guess the format from the file name. >>>> >> I still think guessing the format from the file name is a better >> way to spare users from having to specify formats. >> > I think that would be true if we did it from day 1 but it would be a > huge impact to users if we did it today. I think I agree. Kevin