depot/third_party/nixpkgs/pkgs/build-support/xen/patches.nix

# Patching Xen? Check the XSAs at https://xenbits.xen.org/xsa/
# and try applying all the ones we haven't gotten around to
# yet, if any are necessary. Patches from other downstreams
# are also welcome if they fix important issues with vanilla Xen.

{ lib, fetchpatch }:

let
  inherit (builtins) concatStringsSep;
  inherit (lib.strings) optionalString concatMapStrings;

  xsaPatch =
    {
      id,
      title,
      description,
      type ? "xsa",
      hash ? "",
      cve ? null,
    }:
    (fetchpatch {
      name = "XSA-" + id + optionalString (cve != null) ("-" + concatStringsSep "+" cve);
      url = "https://xenbits.xen.org/xsa/xsa${id}.patch";
      inherit hash;
      passthru = {
        xsa = id;
        inherit type;
      };
      meta = {
        description = title;
        longDescription =
          description
          + "\n"
          + (
            if (cve == null) then
              # Why the two spaces preceding these CVE messages?
              # This is parsed by writeAdvisoryDescription in generic.nix,
              # and doing this was easier than messing with lib.strings even more.
              "  _No CVE was assigned to this XSA._"
            else
              "  Fixes:${
                  concatMapStrings (x: "\n  * [" + x + "](https://www.cve.org/CVERecord?id=" + x + ")") cve
                }"
          );
        homepage = "https://xenbits.xenproject.org/xsa/advisory-${id}.html";
      };
    });
  qubesPatch =
    {
      name,
      tag,
      type ? "qubes",
      hash ? "",
    }:
    (fetchpatch {
      inherit name;
      url = "https://raw.githubusercontent.com/QubesOS/qubes-vmm-xen/v${tag}/${name}.patch";
      inherit hash;
      passthru.type = type;
    });
in
{
  # Example patches:
  #
  # "XSA_100" = xsaPatch {
  #   id = "100";
  #   title = "Verbatim Title of XSA";
  #   description = ''
  #     Verbatim description of XSA.
  #   '';
  #   cve = [ "CVE-1999-0001" "CVE-1999-0002" ]; # Not all XSAs have CVEs. This attribute is optional.
  #   hash = "sha256-0000000000000000000000000000000000000000000000000000";
  # };
  #
  # "QUBES_libxl-fix-all-issues" = qubesPatch {
  #   name = "1000-libxl-fix-all-issues";
  #   tag = "4.20.0-1";
  #   hash = "sha256-0000000000000000000000000000000000000000000000000000";
  # };

  # Build reproducibility patches for Xen.
  # Qubes OS has not updated them to later versions of Xen yet,
  # but they appear to work on Xen 4.17.4 - 4.19.0.
  QUBES_REPRODUCIBLE_BUILDS = [
    (qubesPatch {
      name = "1100-Define-build-dates-time-based-on-SOURCE_DATE_EPOCH";
      tag = "4.17.4-5";
      hash = "sha256-OwKA9oPTwhRcSmiOb+PxzifbO/IG8IHWlvddFh/nP6s=";
    })
    (qubesPatch {
      name = "1101-docs-rename-DATE-to-PANDOC_REL_DATE-and-allow-to-spe";
      tag = "4.17.4-5";
      hash = "sha256-BUtYt0mM3bURVaGv4oDznzxx1Wo4sfOpGV5GB8qc5Ns=";
    })
    (qubesPatch {
      name = "1102-docs-xen-headers-use-alphabetical-sorting-for-incont";
      tag = "4.17.4-5";
      hash = "sha256-mQUp2w9lUb7KDq5MuPQjs6y7iuMDeXoZjDjlXfa5z44=";
    })
  ];

  # Xen Security Advisory #460: (4.16.6 - 4.19.0)
  "XSA_460" = xsaPatch {
    id = "460";
    title = "Error handling in x86 IOMMU identity mapping";
    description = ''
      Certain PCI devices in a system might be assigned Reserved Memory
      Regions (specified via Reserved Memory Region Reporting, "RMRR") for
      Intel VT-d or Unity Mapping ranges for AMD-Vi.  These are typically used
      for platform tasks such as legacy USB emulation.
      Since the precise purpose of these regions is unknown, once a device
      associated with such a region is active, the mappings of these regions
      need to remain continuouly accessible by the device.  In the logic
      establishing these mappings, error handling was flawed, resulting in
      such mappings to potentially remain in place when they should have been
      removed again.  Respective guests would then gain access to memory
      regions which they aren't supposed to have access to.
    '';
    cve = [ "CVE-2024-31145" ];
    hash = "sha256-3q4nAP2xGEptX6BIpSlALOt2r0kjj1up5pF3xCFp+l0=";
  };
  # Xen Security Advisory #461: (4.16.6 - 4.19.0)
  "XSA_461" = xsaPatch {
    id = "461";
    title = "PCI device pass-through with shared resources";
    description = ''
      When multiple devices share resources and one of them is to be passed
      through to a guest, security of the entire system and of respective
      guests individually cannot really be guaranteed without knowing
      internals of any of the involved guests.  Therefore such a configuration
      cannot really be security-supported, yet making that explicit was so far
      missing.
    '';
    cve = [ "CVE-2024-31146" ];
    hash = "sha256-JQWoqf47hy9WXNkVC/LgmjUhkxN0SBF6w8PF4aFZxhM=";
  };
  # Xen Security Advisory #462: (4.16.6 - 4.19.0)
  "XSA_462" = xsaPatch {
    id = "462";
    title = "x86: Deadlock in vlapic_error()";
    description = ''
      In x86's APIC (Advanced Programmable Interrupt Controller) architecture,
      error conditions are reported in a status register.  Furthermore, the OS
      can opt to receive an interrupt when a new error occurs.
      It is possible to configure the error interrupt with an illegal vector,
      which generates an error when an error interrupt is raised.
      This case causes Xen to recurse through vlapic_error().  The recursion
      itself is bounded; errors accumulate in the the status register and only
      generate an interrupt when a new status bit becomes set.
      However, the lock protecting this state in Xen will try to be taken
      recursively, and deadlock.
    '';
    cve = [ "CVE-2024-45817" ];
    hash = "sha256-01lzjaT2f69UfEdTUCkm92DDOmd+Mo8sNPZsHJfgJEM=";
  };
}