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 <1371...@bugs.launchpad.net> 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 > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1371591 Title: file not initialized to 0s under some conditions on VMWare To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1371591/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
