Re: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification

[Anthony Liguori]

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