This is what the customer reports. Ignoring the CD-ROM, this is slightly
different from what I see on my VMWare Fusion installation, which reports
"VMware, " (with a comma and a space). Presumably this is an insignificant
difference?
Bruce

tail /sys/class/scsi_device/*/device/{vendor,model}
==> /sys/class/scsi_device/1:0:0:0/device/vendor <==
NECVMWar

==> /sys/class/scsi_device/2:0:0:0/device/vendor <==
VMware

==> /sys/class/scsi_device/1:0:0:0/device/model <==
VMware IDE CDR10

==> /sys/class/scsi_device/2:0:0:0/device/model <==
Virtual disk



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

> Bruce,
>
> The following should get some of the info needed:
> tail /sys/class/scsi_device/*/device/{vendor,model}
>
> --
> 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
>