)]}'
{
  "commit": "212c3a35009dedfc0c100fdcdc76b19e37928210",
  "tree": "49f928e45a45b6b146c86aec598d119ee970d50b",
  "parents": [
    "8ab9bdca4f3aa5dbd6c277e5340b4071b952e061"
  ],
  "author": {
    "name": "Michael Brown",
    "email": "mcb30@ipxe.org",
    "time": "Thu Jun 08 11:29:07 2023 +0100"
  },
  "committer": {
    "name": "Michael Brown",
    "email": "mcb30@ipxe.org",
    "time": "Thu Jun 08 11:29:07 2023 +0100"
  },
  "message": "[efi] Veto the VMware UefiPxeBcDxe driver\n\nThe EDK2 UefiPxeBcDxe driver includes some remarkably convoluted and\nunsafe logic in its driver binding protocol Start() and Stop() methods\nin order to support a pair of nominally independent driver binding\nprotocols (one for IPv4, one for IPv6) sharing a single dynamically\nallocated data structure.  This PXEBC_PRIVATE_DATA structure is\ninstalled as a dummy protocol on the NIC handle in order to allow both\nIPv4 and IPv6 driver binding protocols to locate it as needed.\n\nThe error handling code path in the UefiPxeBcDxe driver\u0027s Start()\nmethod may attempt to uninstall the dummy protocol but fail to do so.\nThis failure is ignored and the containing memory is subsequently\nfreed anyway.  On the next invocation of the driver binding protocol,\nit will find and use the already freed block of memory.  At some point\nanother memory allocation will occur, the PXEBC_PRIVATE_DATA structure\nwill be corrupted, and some undefined behaviour will occur.\n\nThe UEFI firmware used in VMware ESX 8 includes some proprietary\nchanges which attempt to install copies of the EFI_LOAD_FILE_PROTOCOL\nand EFI_PXE_BASE_CODE_PROTOCOL instances from the IPv4 child handle\nonto the NIC handle (along with a VMware-specific protocol with GUID\n5190120d-453b-4d48-958d-f0bab3bc2161 and a NULL instance pointer).\nThis will inevitably fail with iPXE, since the NIC handle already\nincludes an EFI_LOAD_FILE_PROTOCOL instance.\n\nThese VMware proprietary changes end up triggering the unsafe error\nhandling code path described above.  The typical symptom is that an\nattempt to exit from iPXE back to the UEFI firmware will crash the VM\nwith a General Protection fault from within the UefiPxeBcDxe driver:\nthis happens when the UefiPxeBcDriver\u0027s Stop() method attempts to call\nthrough a function pointer in the (freed) PXEBC_PRIVATE_DATA\nstructure, but the function pointer has been overwritten by UCS-2\ncharacter data from a separate memory allocation.\n\nWork around this failure by adding the VMware UefiPxeBcDxe driver to\nthe driver veto list.\n\nSigned-off-by: Michael Brown \u003cmcb30@ipxe.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b616539d369b9422d919bc5497f61277c5d10ec4",
      "old_mode": 33188,
      "old_path": "src/interface/efi/efi_veto.c",
      "new_id": "19e529af60cf47906dbe6248ee978266971eea59",
      "new_mode": 33188,
      "new_path": "src/interface/efi/efi_veto.c"
    }
  ]
}