From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmMYd-0007lc-0A for qemu-devel@nongnu.org; Thu, 06 Nov 2014 07:53:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XmMYW-0004zg-Rw for qemu-devel@nongnu.org; Thu, 06 Nov 2014 07:52:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XmMYW-0004zW-KN for qemu-devel@nongnu.org; Thu, 06 Nov 2014 07:52:52 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA6Cqp9C028471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 6 Nov 2014 07:52:51 -0500 From: Markus Armbruster References: <87lhnq3iul.fsf@blackfin.pond.sub.org> <5459FCE8.2050007@redhat.com> Date: Thu, 06 Nov 2014 13:52:49 +0100 In-Reply-To: <5459FCE8.2050007@redhat.com> (Eric Blake's message of "Wed, 05 Nov 2014 11:33:12 +0100") Message-ID: <87oaskv6ce.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] Image probing: how it can be insecure, and what we could do about it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz Eric Blake writes: > On 11/04/2014 07:45 PM, Markus Armbruster wrote: >> I'll try to explain all solutions fairly. Isn't easy when you're as >> biased towards one of them as I am. Please bear with me. >> > > Thanks for this write-up. I'll probably reply again, but for now I'm > focusing on just one thing I think you missed that came up in the > related threads: > > >> = How can we better guard the trust boundary in QEMU? = >> >> The guest can violate the trust boundary only because >> >> (a) QEMU supports both raw images and image formats, and >> >> (b) QEMU guesses image format from raw image contents, and >> >> (c) given a raw image, guests can change its contents and control a >> future QEMU's format guess. >> >> We can attack one ore more of these three conditions: >> >> (a) Outlaw raw images >> >> (b) Don't guess format from untrusted image contents >> >> (c) Prevent "bad" guest writes > > (d) write metadata that records our guess before releasing data across a > trust boundary, so that we no longer need to probe on the next encounter > > While this won't work for top-level images, it is a possibility for > backing store. Any time we open a qcow2 file that has a backing file > without a format, we can rewrite the qcow2 metadata to record the type > that we ended up settling on, prior to allowing the guest to manipulate > the data. The initial open is "safe" (we haven't yet handed the data to > the guest - and the trust boundary is not broken until the point that > the guest has had a chance to overwrite data) and all subsequent opens > are now safe (because we rewrote the metadata, subsequent operations no > longer need to probe the backing file, but are guaranteed to use the > same format as the first open, whether or not those subsequent > operations are performed by a different qemu that would have probed a > different type). > > PRO: Plugs hole for backing files > > CON: Doesn't help for top-level images. In a chain "base <- mid <- top" > where neither mid nor top recorded backing type, it would require mid to > be temporarily opened read-write to update the metadata. I think we better distinguish two cases: 1. Freeze the backing format on create PRO: Plugs hole for backing files in new images CON: Incompatible change, but only for truly weird usage. 2. Freeze the backing format on writable open PRO: Plugs hole for this existing image's backing file CON: As above. I'm quite comfy with 1's CON, but 2's gives me a slightly queasy feeling. Not enough of it to actually object, though.