Open Stack

On 10/23/2014 04:24 PM, Preston L. Bannister wrote:
> On Thu, Oct 23, 2014 at 3:04 PM, John Griffith <john.griffith8 at gmail.com
> <mailto:john.griffith8 at gmail.com>> wrote:
>
>         The debate about whether to wipe LV's pretty much massively
>         depends on the intelligence of the underlying store. If the
>         lower level storage never returns accidental information ...
>         explicit zeroes are not needed.
>
>     On Thu, Oct 23, 2014 at 3:44 PM, Preston L. Bannister
>     <preston at bannister.us <mailto:preston at bannister.us>> wrote:
>
>
>         Yes, that is pretty much the key.
>
>         Does LVM let you read physical blocks that have never been
>         written? Or zero out virgin segments on read? If not, then "dd"
>         of zeroes is a way of doing the right thing (if *very* expensive).
>
>     Yeah... so that's the crux of the issue on LVM (Thick).  It's quite
>     possible for a new LV to be allocated from the VG and a block from a
>     previous LV can be allocated.  So in essence if somebody were to sit
>     there in a cloud env and just create volumes and read the blocks
>     over and over and over they could gather some previous or other
>     tenants data (or pieces of it at any rate).  It's def the "right"
>     thing to do if you're in an env where you need some level of
>     security between tenants.  There are other ways to solve it of
>     course but this is what we've got.
>
>
>
> Has anyone raised this issue with the LVM folk? Returning zeros on
> unwritten blocks would require a bit of extra bookkeeping, but a lot
> more efficient overall.

For Cinder volumes, I think that if you have new enough versions of 
everything you can specify "lvm_type = thin" and it will use thin 
provisioning.  Among other things this should improve snapshot 
performance and also avoid the need to explicitly wipe on delete (since 
the next user of the storage will be provided zeros for a read of any 
page it hasn't written).

As far as I know this is not supported for ephemeral storage.

Chris