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
