Comment 22 for bug 1371591

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
>