Thanks Chris.

I take it from the other thread that bubbling the setting up from the lower
layer to the dm-* layer won't be possible.

Do you know if this patch will fix it for ESXi as well as for the VMWare
desktop products? I don't have access to ESXi, but the issue was originally
reported to us by a customer running ESXi. I could ask them to try the
patched kernel, but maybe we could do a simpler check first. Is there a way
to determine the vendor id for their virtual SCSI disks on a running system
so we can verify that the vendor id is the same?

Thanks,
Bruce

On Wed, Sep 24, 2014 at 10:00 AM, Chris J Arges <email address hidden>
wrote:

> https://lkml.org/lkml/2014/9/23/509
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1371591
>
> Title:
>   file not initialized to 0s under some conditions on VMWare
>
> Status in “linux” package in Ubuntu:
>   In Progress
> Status in “linux” source package in Trusty:
>   New
>
> Bug description:
>   Under some conditions, after fallocate() the file is observed not to
>   be completely initilized to 0s: some 4KB pages have left-over data
>   from previous files that occupied those pages. Note that in addition
>   to causing functional problems for applications expecting files to be
>   initialized to 0s, this is a security issue because it allows data to
>   "leak" from one file to another, bypassing file access controls.
>
>   The problem has been seen running under the following VMWare-based
> virtual environments:
>   Fusion 6.0.2
>   ESXi 5.1.0
>
>   And under the following versions of Ubuntu:
>   Ubuntu 12.04, 3.11.0-26-generic
>   Ubuntu 14.04.1, 3.13.0-32-generic
>   Ubuntu 14.04.1, 3.13.0-35-generic
>
>   But did not reproduce under the following version:
>   Ubuntu 10.04, 2.6.32-38-server
>
>   The problem reproduced under LVM, but did not reproduce without LVM.
>
>   I reproduced the problem as follows under VMWare Fusion:
>   set up custom VM with default disk size (20 GB) and memory size (1 GB)
>   attach Ubuntu 14.04.1 ISO to CDROM, set it as boot device, boot up
>   select all defaults during installation _including_ LVM
>   install gcc
>   unpack the attached repro.tgz
>   run repro.sh
>
>   what it does:
>   * fills the disk with a file containing bytes of 0xcc then deletes it
>   * repeatedly runs the repro program which creates two files and accesses
> them in a certain pattern
>   * checks the file f0 with hexdump; it should contain all 0s, but if
> pages 0x1000-0x7000 contain 0xcc you have reproduced the problem
>
>   If the problem does not appear to reproduce, please try waiting a bit
>   and checking the f0 files with hexdump again. This behavior was
>   observed by a customer reproducing the problem under ESXi. I since
>   added an sync after the running the repro binary which I think will
>   fix that.
>
>   If you still can't reproduce the problem please let me know if there's
>   anything I can do to help. For example can we trace the disk accesses
>   at the SCSI level to verify whether the appropriate SCSI commands are
>   being sent? This may help determine whether the problem is in Linux or
>   in VMWare.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+subscriptions
>