From b59142e32c80a6b25b0f660492d1e9dcb867d5cb 2015-03-12 17:09:27 From: Bradley M. Kuhn Date: 2015-03-12 17:09:27 Subject: [PATCH] Merge branch 'master' from upstream changes. --- diff --git a/www/conservancy/static/linux-compliance/vmware-lawsuit-faq.html b/www/conservancy/static/linux-compliance/vmware-lawsuit-faq.html index b418dff76e98e84d75bbf65a9062955c40aad190..88a4ab15cf0f3b941da014b33ff1ecedbfb1ee86 100644 --- a/www/conservancy/static/linux-compliance/vmware-lawsuit-faq.html +++ b/www/conservancy/static/linux-compliance/vmware-lawsuit-faq.html @@ -139,7 +139,7 @@

The GPL violation at issue involves VMware's ESXi product. Conservancy independently reviewed ESXi 5.5 and its incomplete - CCS + CCS release as part of our GPL enforcement efforts described above.

Conservancy's preliminary investigation indicated that the operating @@ -148,14 +148,14 @@

  • the proprietary component “vmkernel”, which is released in binary form only,
  • the kernel module “vmklinux”, which contains modified Linux -Code, and for which (at least some) source code for which is provided. +Code, and for which (at least some) source code is provided.
  • other kernel modules with device drivers, most of which are modified Linux drivers, and for which (at least some) source code is provided.
  • Conservancy examined the incomplete CCS alongside the - binary “vmkernel” component. Such examination indicates that function + binary “vmkernel” component. Such examination indicates that functions in “vmkernel” do make function calls to Linux's kernel code in the usual way for a single program written in C.

    @@ -208,7 +208,8 @@ Code, and for which (at least some) source code for which is provided. 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 - function LinuxPCIDeviceRemoved(), reads as follows: + function LinuxPCIDeviceRemoved(), reads as follows:

    +
     if (unlikely(
       /* NOTE: vmk_PCIGetDeviceName is defined in vmvisor64-vmkernel */
    @@ -222,7 +223,7 @@ VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
                             linuxDev->driver->remove,
                             linuxDev);
     
    -

    +

    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, @@ -234,13 +235,16 @@ VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,

    Further evidence that the implementation of this function occurs elsewhere can by found by running objdump -x on the un-vmtar'ed vmklinux_9 module. Note the following output in the “SYMBOL - TABLE” section: + TABLE” section:

    +
     0000000000000000         *UND*  0000000000000000 vmk_PCIGetDeviceName
     
    +

    …and the following lines found in the “RELOCATION RECORDS FOR [.text]” section: +

     00000000000327ff R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc
    @@ -248,7 +252,6 @@ VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
     00000000000387e1 R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc
     000000000003cf40 R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc
     
    -

    The above two properties both suggest that the vmklinux_9 module requires: (a) a definition of the vmk_PCIGetDeviceName() @@ -264,12 +267,13 @@ VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID, compressed data, was ‘vmvisor64-vmkernel.stripped’”. These findings strongly suggests this is an image of the “vmkernel” component. An objdump -x yields this - “SYMBOL TABLE” section: + “SYMBOL TABLE” section:

    +
     000041800036a408 g     F .text  0000000000000137 vmk_PCIGetDeviceName
     
    -… which indicated these binary file contains the function body +

    … which indicated these binary file contains the function body for vmk_PCIGetDeviceName.

    Finally, after detailed searching, Conservancy found no evidence that any @@ -280,7 +284,7 @@ for vmk_PCIGetDeviceName.

    yields similar results as above.

    Given this evidence and related contextual clues, the only logical - conclusions are: + conclusions are:

    -

    The above is but one piece of evidence among many, but hopefully it helps to explain the types of “combined work” violations found in VMware's ESXi product.

    @@ -313,7 +316,7 @@ previously-mentioned linux_pci.c, vmkapi_pci_incompat.h, and k.b00 files, as well as vmklinux_9 and the source code that builds the latter.

    -

    To obtain the source components, follow these steps (no login is required): +

    To obtain the source components, follow these steps (no login is required):

    1. Visit https://my.vmware.com/web/vmware/details?downloadGroup=ESXI55U2_OSS&productId=353.
    2. @@ -344,9 +347,8 @@ previously-mentioned linux_pci.c, f679e81ffb2f92729917bbc64c2d541cf75b5b94.
    -

    -

    To obtain the binary components, follow these steps (a login is required): +

    To obtain the binary components, follow these steps (a login is required):

    1. Register for an account at https://my.vmware.com/web/vmware/registration.
    2. @@ -395,9 +397,8 @@ at bin/vmtar inside sb.v00, similar to misc_dri.v00 above.
    -

    -

    Note that VMware may present you with EULAs and ToS when you download +

    Note that VMware may present you with EULAs and ToS when you download software from VMware's website. Conservancy strongly suggests that you review these terms in great detail with the assistance of your own legal counsel before downloading the software and/or engaging in the process that Conservancy