From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51127 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5KdU-0007fZ-K7 for qemu-devel@nongnu.org; Mon, 11 Oct 2010 11:50:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5KdP-0007oc-Qp for qemu-devel@nongnu.org; Mon, 11 Oct 2010 11:50:00 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:53927) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5KdP-0007oW-Ob for qemu-devel@nongnu.org; Mon, 11 Oct 2010 11:49:55 -0400 Received: by qyk1 with SMTP id 1so3750873qyk.4 for ; Mon, 11 Oct 2010 08:49:55 -0700 (PDT) Message-ID: <4CB3321F.2060803@codemonkey.ws> Date: Mon, 11 Oct 2010 10:49:51 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification References: <1286552914-27014-1-git-send-email-stefanha@linux.vnet.ibm.com> <1286552914-27014-4-git-send-email-stefanha@linux.vnet.ibm.com> <4CB18549.3020206@redhat.com> <20101011100954.GA4078@stefan-thinkpad.transitives.com> <4CB30B43.2040706@redhat.com> <4CB32530.2070504@codemonkey.ws> <4CB32615.6030008@redhat.com> In-Reply-To: <4CB32615.6030008@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Christoph Hellwig , Stefan Hajnoczi , qemu-devel@nongnu.org On 10/11/2010 09:58 AM, Avi Kivity wrote: >> A leak is unacceptable. It means an image can grow to an unbounded >> size. If you are a server provider offering multitenancy, then a >> malicious guest can potentially grow the image beyond it's allotted >> size causing a Denial of Service attack against another tenant. > > > This particular leak cannot grow, and is not controlled by the guest. As the image gets moved from hypervisor to hypervisor, it can keep growing if given a chance to fill up the disk, then trim it all way. In a mixed hypervisor environment, it just becomes a numbers game. >> A freelist has to be a non-optional feature. When the freelist bit >> is set, an older QEMU cannot read the image. If the freelist is >> completed used, the freelist bit can be cleared and the image is then >> usable by older QEMUs. > > Once we support TRIM (or detect zeros) we'll never have a clean freelist. Zero detection doesn't add to the free list. A potential solution here is to treat TRIM a little differently than we've been discussing. When TRIM happens, don't immediately write an unallocated cluster entry for the L2. Leave the L2 entry in-tact. Don't actually write a UCE to the L2 until you actually allocate the block. This implies a cost because you'll need to do metadata syncs to make this work. However, that eliminates leakage. Regards, Anthony Liguori