The GPL violation at issue involves VMware's ESXi product. - Conservancy independently reviewed ESXi 5.5 and its incomplete + Conservancy independently reviewed ESXi and its incomplete CCS release as part of our GPL enforcement efforts described above.
@@ -243,12 +243,12 @@ Code, and for which (at least some) source code is provided. good, since the court documents discuss the specifics of alleged infringement on Hellwig's copyrights. -However, Conservancy examined VMware's ESXi 5.5 product in detail +
However, Conservancy examined VMware's ESXi product in detail even before Hellwig's enforcement action began. Below is one example among many where VMware's CCS was incomplete per GPLv2§2(c) and GPLv2§3(a). (One can verify these results by downloading and installing the binary and source - packages for VMware's ESXi 5.5 Update 2.) Note that this + packages for VMware's ESXi 6.0.) Note that this example below is not necessarily regarding Hellwig's copyrights; VMware incorporated Linux code copyrighted by many others as well into their kernel.
@@ -257,7 +257,7 @@ Code, and for which (at least some) source code is provided.Our example begins with examination of the file
called vmkdrivers/src_92/vmklinux_92/vmware/linux_pci.c,
which can be found in the “Open Source” release for
- ESXi 5.5.0 Update 2 (5.5U2). A small excerpt from that file, found in the
+ ESXi 6.0. A small excerpt from that file, found in the
function LinuxPCIDeviceRemoved(), reads as follows:
@@ -279,8 +279,8 @@ LinuxPCIDeviceRemoved(vmk_PCIDevice vmkDev)
vmkDevName[0] = 0;
}
[...]
-VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
- linuxDev->driver->remove,
+VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
+ linuxDev->driver->remove,
linuxDev);
@@ -288,8 +288,8 @@ VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
The function, vmk_PCIGetDeviceName() must be defined, with an
implementation, for this code above to work, or even compile.
- Inside BLD/build/HEADERS/vmkapi-current-all-public/vmkernel64/release/device/vmkapi_pci_incompat.h,
- found in the vmkdrivers package of ESXi 5.5U2, shows a
+ Inside BLD/build/HEADERS/vmkapi-current-all-public/generic/release/hardware/vmkapi_pci_incompat.h,
+ found in the vmkdrivers package of ESXi 6.0, shows a
function header definition for vmk_PCIGetDeviceName().
However, the source of its implementation is not provided there or
anywhere in the source release.
-00000000000327ff R_X86_64_PC32 vmk_PCIGetDeviceName+0xfffffffffffffffc -0000000000035318 R_X86_64_PC32 vmk_PCIGetDeviceName+0xfffffffffffffffc -00000000000387e1 R_X86_64_PC32 vmk_PCIGetDeviceName+0xfffffffffffffffc -000000000003cf40 R_X86_64_PC32 vmk_PCIGetDeviceName+0xfffffffffffffffc +0000000000032db3 R_X86_64_PC32 vmk_PCIGetDeviceName+0xfffffffffffffffc +00000000000333ea R_X86_64_PC32 vmk_PCIGetDeviceName+0xfffffffffffffffc +0000000000036644 R_X86_64_PC32 vmk_PCIGetDeviceName+0xfffffffffffffffc +000000000003986a R_X86_64_PC32 vmk_PCIGetDeviceName+0xfffffffffffffffc
The above two properties both suggest that the vmklinux_9
@@ -321,9 +321,9 @@ VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
inside vmklinux_9 itself.
The definition can however be found in binary-only software provided in
- ESXi 5.5U2 — specifically, inside a file named k.b00,
+ ESXi 6.0 — specifically, inside a file named k.b00,
which is located in partition 5 on a disk where ESXi has been installed (or
- in the ESXi 5.5U2 installer ISO image). Running file
+ in the ESXi 6.0 installer ISO image). Running file
after gunzip on this file yields “ELF 64-bit LSB shared
object”. Meanwhile, file k.b00 reports “gzip
compressed data, was ‘vmvisor64-vmkernel.stripped’”.
@@ -332,7 +332,7 @@ VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
“SYMBOL TABLE” section:
-000041800036a408 g F .text 0000000000000137 vmk_PCIGetDeviceName +000041800033193c g F .text 000000000000012e vmk_PCIGetDeviceName
… which indicated these binary file contains the function body
@@ -358,25 +358,27 @@ for vmk_PCIGetDeviceName.
struct pci_dev {
+[...]
+#if defined(__VMKLNX__)
+ /* 2008: Update from Linux source */
+ u8 revision; /* PCI revision, low byte of class word */
+#endif /* defined(__VMKLNX__) */
[...]
struct pci_driver *driver; /* which driver has allocated this device */
[...]
-truct pci_driver {
+struct pci_driver {
+ struct list_head node;
char *name;
[...]
void (*remove) (struct pci_dev *dev); /* Device removed (NULL if not a hot-plug capable driver) */
[...]
-#if defined(__VMKLNX__)
- /* 2008: Update from Linux source */
- u8 revision; /* PCI revision, low byte of class word */
-#endif /* defined(__VMKLNX__) */
};
These structures, and based on those from Linux itself (a similar version of this file can be seen in Linux 2.6.24), and as can - be seen above, have been modified to work with “vmkernel”
+ be seen above, have been modified to work with “vmkernel”.In LinuxPCIDeviceRemoved(), we saw a macro called with a
variable, linuxDev which was of type struct pci.
@@ -387,7 +389,7 @@ truct pci_driver {
VMKAPI_MODULE_CALL_VOID macro calls driver's codeThe
- file BLD/build/HEADERS/vmkapi-current-all-public/vmkernel64/release/base/vmkapi_module.h
+ file BLD/build/HEADERS/vmkapi-current-all-public/generic/release/base/vmkapi_module.h
contains the macro definition of VMKAPI_MODULE_CALL_VOID,
which is quoted below (with debug lines removed):
@@ -402,8 +404,8 @@ do { \
When the macro is expanded, it means that (function)(args) is
- actually expanded to linuxDev->driver->remove(linuxDev).
- Therefore, we see LinuxPCIDeviceRemoved(), makes directs calls
+ actually expanded to linuxDev->driver->remove(linuxDev).
+ Therefore, we see LinuxPCIDeviceRemoved() makes directs calls
to a driver's remove() function, by combining with Linux's struct
pci, and by VMware's introduction of this new calling code.
Conservancy has confirmed many drivers from Linux are incorporated via
@@ -423,8 +425,8 @@ static struct pci_driver tg3_driver = {
Therefore, when the code in LinuxPCIDeviceRemoved()
- calls linuxDev->driver->remove(linuxDev), the code ultimately
- called (in the case where a tg3 card is driven by the kernel)
+ calls linuxDev->driver->remove(linuxDev), the code
+ ultimately called (in the case where a tg3 card is driven by the kernel)
is tg3_remove_one(), which is found in tg3.c and
comes directly from Linux.
tg3.cVMware furthermore distributes a modified version of tg.c in
+
VMware furthermore distributes a modified version of tg3.c in
binary form. This can be found in usr/lib/vmware/vmkmod/tg3,
which is extracted by un-vmtar'ing the file net_tg3.v00 (found
- on the ESXi 5.5U2 installer ISO image). Conservancy has confirmed that
- file is a compiled version of tg3.c
tg3.c.
The above is but one piece of evidence among many, but hopefully it helps to explain some of the “combined work” violations found in - VMware's ESXi product.
+ VMware's ESXi product. Conservancy did a similar analysis for ESXi 5.0 + as well as ESXi 5.5 Update 2 and found nearly identical results.linux_pci.c,
these steps (no login is required):
VMware-ESX-550U2-ODP.iso.VMware-ESXI-600-ODP.iso.
vmkdrivers/src_92/vmklinux_92/vmware/linux_pci.c
- and BLD/build/HEADERS/vmkapi-current-all-public/vmkernel64/release/device/vmkapi_pci_incompat.h
+ and BLD/build/HEADERS/vmkapi-current-all-public/generic/release/hardware/vmkapi_pci_incompat.h
from vmkdrivers-gpl/vmkdrivers-gpl.tgz with tar and gzip.vmklinux_9 by following the steps
@@ -511,11 +514,11 @@ previously-mentioned linux_pci.c,
(Note: vmklinux_9 is also available pre-built on a running
ESXi system; see below for instructions on how to access it).VMware-TOOLCHAIN-550u2-ODP.iso and has a SHA-1 hash of
- f679e81ffb2f92729917bbc64c2d541cf75b5b94.VMware-TOOLCHAIN-600-ODP.iso and has a SHA-1 hash of
+ 9a68df4cbeb645c25002a02f11b1923f98d3d5b5.
linux_pci.c,
linux_pci.c,
VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64.iso.VMware-VMvisor-Installer-6.0.0-2494585.x86_64.iso.
k.b00 file in the root directory. Extract it
using zcat k.b00 > vmvisor64-vmkernel (or a similar command).