Debian Patches
Status for edk2/2025.02-4
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-NetworkPkg-IScsiDxe-Fix-for-Remote-Memory-Exposure-i.patch | [PATCH] NetworkPkg/IScsiDxe:Fix for Remote Memory Exposure in ISCSI bz4206 Used SafeUint32Add to calculate and validate OutTransferLength with boundary check in IScsiOnR2TRcvd to avoid integer overflow diff --git a/NetworkPkg/IScsiDxe/IScsiProto.c b/NetworkPkg/IScsiDxe/IScsiProto.c index ef587649a0..fb48e6304d 100644 |
Madhavan <madavtechy@gmail.com> | yes | debian upstream | https://github.com/tianocore/edk2/commit/17cdc512f02a2dfd1b9e24133da56fdda099abda | 2025-03-14 |
| 0001-OvmfPkg-Use-user-specified-opt-ovmf-X-PciMmio64Mb-va.patch | [PATCH] OvmfPkg: Use user-specified opt/ovmf/X-PciMmio64Mb value unconditionally Prior to this change, OVMF considers opt/ovmf/X-PciMmio64Mb the minimum aperture size, allowing us to force the window to be larger but not smaller than what PlatformDynamicMmioWindow calculates. Adjust OVMF so that a smaller value for the aperture is honored. Context: Due to an inefficiency in the way older host kernels manage pfnmaps for guest VM memory ranges [0], guests with large-BAR GPUs passed-through have a very long (multiple minutes) initialization time when the MMIO window advertised by OVMF is sufficiently sized for the passed-through BARs (i.e., the correct OVMF behavior). However, on older distro series such as Ubuntu Jammy, users have benefited from fast guest boot times when OVMF advertised an MMIO window that was too small to accommodate the full BAR, since this resulted in the long PCI initialization process being skipped (and retried later, if pci=realloc pci=nocrs were set). While the root cause is being fully addressed in the upstream kernel [1], the solution relies on huge pfnmap support, which is a substantial series with many ABI changes that is unlikely to land in many LTS and legacy distro kernels, including those of Ubuntu Noble. As a result, the only kernel improvement supported on those kernels is this patch [2], which reduces the extra boot time by about half. Unfortunately, that boot time is still an average of 1-3 minutes longer per-VM-boot than what can be achieved when the host is running a version of OVMF without PlatformDynamicMmioWindow (PDMW) support (introduced in [3]) Since there is no way to force the use of the classic MMIO window size[4] in any version of OVMF after [3], and since we have a use case for such functionality on legacy distro kernels that would yield significant, recurring compute time savings across all impacted VMs, this change to this knob's behavior seems appropriate. [0]: https://lore.kernel.org/all/CAHTA-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@mail.gmail.com/ [1]: https://lore.kernel.org/all/20250205231728.2527186-1-alex.williamson@redhat.com/ [2]: https://lore.kernel.org/all/20250111210652.402845-1-alex.williamson@redhat.com/ [3]: ecb778d [4]: https://edk2.groups.io/g/devel/topic/109651206?p=Created,,,20,1,0,0 diff --git a/OvmfPkg/Include/Library/PlatformInitLib.h b/OvmfPkg/Include/Library/PlatformInitLib.h index 57b18b94d9..ce5af42e09 100644 |
Mitchell Augustin <mitchell.augustin@canonical.com> | no | 2025-03-15 | ||
| ArmVirtPkg-disable-the-EFI_MEMORY_ATTRIBUTE-protocol.patch | ArmVirtPkg: Disable the EFI memory attributes protocol Temporarily disable the EFI_MEMORY_ATTRIBUTE_PROTOCOL to workaround a bug in shim until distributions have had a chance to fix it. |
dann frazier <dannf@debian.org> | no | debian | 2025-03-01 | |
| brotlicompress-disable.diff | Do not attempt to compile removed BrotliCompress source BrotliCompress is not currently used, and including an embedded copy of its source could cause false-positives when scanning for security issues. This code is stripped from our orig.tar (at the request of the Ubuntu security team), so we also need to disable the build. |
dann frazier <dannf@debian.org> | not-needed | 2023-03-09 | ||
| no-stack-protector-all-archs.diff | pass -fno-stack-protector to all GCC toolchains The upstream build rules inexplicably pass -fno-stack-protector only when building for i386 and amd64. Add this essential argument to the generic rules for gcc 4.8 and later. |
Steve Langasek <steve.langasek@ubuntu.com> | no | |||
| Revert-ArmVirtPkg-make-EFI_LOADER_DATA-non-executabl.patch | Revert "ArmVirtPkg: make EFI_LOADER_DATA non-executable" The versions of GRUB most distros are shipping still depend on executable EFI_LOADER_DATA. Revert this upstream change until the necessary fixes are more generally available. |
dann frazier <dannf@debian.org> | yes | debian | 2023-07-21 | |
| x64-baseline-abi.patch | Explicitly target generic x86-64 ABI The system compiler may be configured to target a higher x86-64 psABI by default, so explicitly target the generic psABI to retain compatibility with older machine types. |
dann frazier <dannf@debian.org> | yes | 2024-11-24 |
Showing 1 to 7 of 7 entries
All known versions for source package 'edk2'
- 2025.02-4 (sid, trixie)
- 2022.11-6+deb12u2 (bookworm)
- 2022.11-6+deb12u1 (bookworm-security)
- 2020.11-2+deb11u2 (bullseye-security, bullseye)