Many in the media have talked about the possibility that VMware might use some so-called “shim layer” between Linux code and VMware's proprietary code. While, for decades, there has been much talk of various mechanisms of GPL obligation avoidance, Conservancy believes that merely modifying technical details of a combination's construction does not typically influence the legal analysis in a combined or derivative work scenario.

Furthermore, the technical details of VMware's alleged GPL violation do not even mirror the typical scenarios that have usually been called “shim layers”. Conservancy's analysis of VMware's ESXi product, in fact, indicates that VMware rather flagrantly combined Linux code in their own kernel, and evidence seems to indicate the work as a whole was developed by modifying Linux code in tandem with modifications to “vmkernel” in a tightly coupled manner.

No, in fact, as we say above, Conservancy doesn't think the phrase “shim layer” has any meaning, despite regular use of that phrase in the media. Conservancy generally doubts there is any technological manipulation that changes the outcome of a combined/derivative work analysis.

There are numerous examples available that show this. The details of alleged infringement specifically relating to Hellwig's contributions to Linux are of course the main matter of the allegations in the litigation, and Conservancy released the diagram above to exemplify that issue. Conservancy continues to hope VMware will agree to make public all court documents as a matter of public good, since the court documents discuss the specifics of alleged infringement on Hellwig's copyrights.

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 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.

Example of “vmkernel”'s combination with Linux code

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 6.0. A small excerpt from that file, found in the function LinuxPCIDeviceRemoved(), reads as follows:

#include <linux/pci.h>
[...]
/*
 * This function [...] is modelled after pci_remove_device, the function which would
 * be called in a linux system.
 */
static void
LinuxPCIDeviceRemoved(vmk_PCIDevice vmkDev)
{
   LinuxPCIDevExt *pciDevExt;
   struct pci_dev *linuxDev;
[...]
  if (unlikely(
    vmk_PCIGetDeviceName(vmkDev, vmkDevName, sizeof(vmkDevName)-1) != VMK_OK))
  {
      vmkDevName[0] = 0;
  }
[...]
VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
                        linuxDev->driver->remove,
                        linuxDev);

Combination of “vmkernel” code with “vmkdrivers”

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/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.

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:

0000000000000000         *UND*  0000000000000000 vmk_PCIGetDeviceName

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

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 module requires: (a) a definition of the vmk_PCIGetDeviceName() function to operate, but (b) that function is not defined inside vmklinux_9 itself.

The definition can however be found in binary-only software provided in 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 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’”. These findings strongly suggests this is an image of the “vmkernel” component. An objdump -x yields this “SYMBOL TABLE” section:

000041800033193c g     F .text  000000000000012e vmk_PCIGetDeviceName

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

Furthermore, after detailed searching, Conservancy found no evidence that any other code (other than modified Linux code) makes calls to vmk_PCIGetDeviceName. This provides a strong indication that this function's primary purpose is to combine Linux code with “vmkernel”. Conservancy also found other functions where similar analysis yields similar results as above.

Linux's struct pci combined with LinuxPCIDeviceRemoved()

Having established the direct and close combination of vmk_PCIGetDeviceName and LinuxPCIDeviceRemoved(), focus now on the quoted code from LinuxPCIDeviceRemoved(). That code, note that one of the local variables is struct pci_dev *linuxDev;. A definition of pci_dev is found in vmkdrivers/src_92/include/linux/pci.h (which is #include'd above) reads:

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 */
[...]
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) */
[...]
  };

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”.

In LinuxPCIDeviceRemoved(), we saw a macro called with a variable, linuxDev which was of type struct pci. Thus, the combination of code from Linux's pci.h and VMware's vmware/linux_pci.c is very tightly coupled and interdependent.

VMKAPI_MODULE_CALL_VOID macro calls driver's code

The 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):

#define VMKAPI_MODULE_CALL_VOID(moduleID, function, args...)  \
do {                                                    \
    vmk_ModInfoStack modStack;                          \
    vmk_ModulePushId(moduleID, function, &modStack);    \
    (function)(args);                                   \
    )                                                   \
    vmk_ModulePopId();                                  \
} while(0)

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 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 these mechanisms; one specific example is discussed next.

Combination of the tg3 driver with “vmkernel”

VMware includes a file vmkdrivers/src_9/drivers/net/tg3/tg3.c in their source release. This file appears to be Linux's tg3 driver. It includes a definition of the struct pci_dev for this device, which reads:

static struct pci_driver tg3_driver = {
[...]
        .remove         = __devexit_p(tg3_remove_one),

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) is tg3_remove_one(), which is found in tg3.c and comes directly from Linux.

(Note: __devexit_p is a straightforward macro found in vmkdrivers/src_92/include/linux/init.h (which also comes from Linux) that will simply expand to its first argument in this case.)

VMware distribution of binary version of tg3.c

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 6.0 installer ISO image). Conservancy has confirmed that file is a compiled version of tg3.c.

Conclusions

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

• vmklinux_9, a binary object, dynamically links with the binary objects: k.b00 and tg3 (the driver built from tg3.c's source). These three binary objects together form a single running binary (likely along with many other binary objects as well).
• That single running binary contains code licensed under the GPLv2 — namely the code derived from tg3.c and pci.h. Thus, the single running binary may be distributed in binary form only under permissions provided under GPLv2 — in particular GPLv2§2 and GPLv2§3.
• GPLv2§3(a–b) requires that complete corresponding machine-readable source code must accompany binary distributions such as these. GPLv2§3 further states that for an executable work, complete source code means all the source code for all modules it contains.
• The binary work in question contains modules from k.b00, vmlinux_9 and tg3.
• VMware did not provide source code for any modules found in k.b00.
• Therefore, VMware failed to comply with the GPLv2, as such compliance requires source code (or an offer therefor) for the material in k.b00.

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. Conservancy did a similar analysis for ESXi 5.0 as well as ESXi 5.5 Update 2 and found nearly identical results.