To Zero or not to Zero, that is the question…

Introduction

A question that has been coming up quite a bit lately is related to the relative security of the different VMDK formats available for use within VMware vSphere. As most of you know, vSphere offers 3 basic disk formats.

  1. Lazy Zeroed Thick
    This is the standard format used by thick disks. Space is allocated at the time the VMDK is created but the underlying physical blocks are not zeroed. Zeroing of each block occurs as the first write to that block takes place
  2. Thin
    With a Thin disk physical blocks are not allocated at time of creation. Instead they are allocated as the virtual machine writes to the disk and consumes space. Again, the physical blocks are not pre-zeroed. They are allocated and zeroed on first write.
  3. Eager Zeroed Thick
    Eager Zeroed Thick disks have space allocated and all underlying blocks zeroed at the time the VMDK is created.

While Eager Zeroed Thick disks raise tend not to raise any questions, the fact that Thin and Lazy Zeroed Thick disks are not zeroed at the time of creation have caused some concerns in terms of a newly provisioned virtual machine being able to read ‘stale’ data that might have been left behind when an old VM is deleted or relocated to another datastore. If the blocks aren’t zeroed at creation time, how do we prevent that VM from reading the old data that might still reside on the physical blocks underlying the VMDK?

VMDK Metadata

A VMDK doesn’t just contain the data contained within the virtual disk. It also contains a metadata area that describes the attributes of the VMDK, including something called the Grain Table. The physical blocks/sectors backing the vmdk blocks are referred to as ‘grains’ and the details of each grain are recorded in the Grain Entry Table within the VMDK metadata. Each record in the table details the offset address of the physical locations backing the grain. Each record is referred to as a Grain Table Entry. (GTE)

What happens when a VM tries to access data stored within the VMDK?

When a VM tries to read a block of data within a VMDK, the following process takes place within the storage subsystem of the VMKernel:

We first read the GTE for that block

  • If the GTE has a value of 0 (zero) it indicates that no grain has been allocated. On reading a value of 0 the storage subsystem automatically returns zeros for the contents of the VMDK block being read.
  • If the GTE has a value of 1 it indicates that, while a grain has been allocated, nothing has ever been written to it so the value returned for the grain content is zeros again.
  • If the GTE is >1 it indicates that we have a physical block backing the VMDK grain and that it’s ok to read from and write to it. We use the GTE to determine the offset address of the physical blocks backing the grain.

You can see from the above that in the cases where blocks haven’t been allocated in a thin disk or blocks have never been written on a lazy thick disk we don’t even return an offset so it’s impossible for anything inside the guest to even determine the physical location of the block, let alone read any ‘stale’ data.

The process described above applies to disks where there are no linked clones, snapshots etc. Where these exist the process gets a little more complicated but the same basic protections are in place.

Summary

Whether you deploy a VMDK in Thin, Lazy Zero Thick or Eager Zero Thick format, the VMkernel storage subsystem has been designed in such a way that accessing stale data from within a guest is not possible. Any command executed within the guest cannot even determine the physical location of unwritten blocks, let alone access any stale data left behind by a previous VMDK. So in summary, you can use any of the virtual disk formats with complete peace of mind that it will not be possible to access old data on the underlying physical storage.

 

For more information you can refer to the Virtual Disk Format 5.0 Technical Note at https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf

Leave a comment

1 Comment

  1. Storage Links » Welcome to vSphere-land!

Leave a Reply

Your email address will not be published. Required fields are marked *