From mboxrd@z Thu Jan 1 00:00:00 1970 From: Akio Takebe Subject: Re: Why cannot HVM open a file as a floopy disk? Date: Fri, 19 Jun 2009 11:22:13 +0900 Message-ID: <4A3AF655.2080507@jp.fujitsu.com> References: <4A2F31FB.6040308@jp.fujitsu.com> <18999.46594.660042.463098@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <18999.46594.660042.463098@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson , Akio Takebe Cc: xen-devel List-Id: xen-devel@lists.xenproject.org Hi, Ian Ian Jackson wrote: > Akio Takebe writes ("[Xen-devel] Why cannot HVM open a file as a floopy disk?"): >> I found a issue which we cannot open a file as a floppy disk in HVM guest. >> If I specify fda="/dev/null", I can boot the HVM guest. >> But if I specify fda="/root/floppy.img", >> I cannot boot the HVM guest and xend hungs up. > > Unfortunately, it is not possible to autodetect raw formats safely. > >> Why did you need to change the line? >> If it's not necessary, is the following patch acceptable? > > Here is a description of the problem which my patch fixes: > > Consider a raw disk image file which is writeable by a guest. (This > is of course one very common usage model.) The guest can write > anything it likes to the image file, including anything to the start > of the file - where the cow header would be if it were a cow file. > > So it can, if it likes, write a cow header (qcow2 for example) to the > start of its `virtual disk image'. Qemu's cow headers contain the > pathname of the backing file, and the guest can of course name any > file it likes. > > If this image, which is supposedly a raw image, is then opened by any > tool which autoguesses the format, that tool will then spot the cow > header written by the guest and access the backing file (in the > context of the host) specified by the guest. > > Depending on the exact circumstances this can allow the guest to get > copies of or even complete read access to any data of its choice in > the host. > > Upstream qemu have fixed this problem in a half-hearted way and > evidently their qemu-img is still vulnerable. We have changed the > format-determination code in block.c so that any attempt to autodetect > a format never returns `raw'; that means that any vulnerable code > anywhere is instantly fixed although it may break some existing usages > in cases where we haven't properly plumbed through a specification of > the image format. > > Does anyone use Xen with non-raw floppy disk images in disk files ? > If not then we can fix the problem by having the floppy driver device > model explictly specify bdrv_raw to the block layer, eliminating the > format auto-gessing. > Thank you very much for your elaborating. We usually use /dev/floppy of dom0 as floppy disk of guest. So a raw format floppy disk is not important. The restriction is reasonable, but xend would need to be fixed because it hangup. Also I concern about a emulate ide disk of the raw format. Is it also vulnerable? Best Regards, Akio Takebe