uefi/tianocore/edk2.git, branch mergify/configuration-deprecated-update

.mergify/config.yml: Explicitly set reporting_method to check-runs

2026-06-15T19:51:50+00:00

The default value of merge_protections_settings.reporting_method is changing from check-runs to deployments. This commit updates the mergify configuration to explicitly set check-runs to preserve current behavior. (deadline: 2026-07-31) --- This was originally auto-generated by the Mergify bot in a PR to the edk2 repo. That change did not comply with edk2 commit requirements and modified the line endings of the file. It is manually recreated here with the correct line endings and commit message format. Signed-off-by: Michael Kubacki

Maintainers.txt: Add Chris Fernald as maintainer to SecurityPkg

2026-06-15T18:02:10+00:00

Signed-off-by: Chris Fernald

CryptoPkg: Added lite version openssl library

2026-06-15T08:54:47+00:00

Lite version OpensslLib base on OpensslLibFull but no-camellia, no -ecx and no-dh. It save the size about ~192KB. REF: Signed-off-by: Lee LonghaoX

CryptoPkg: Log TLS handshake certificate verification error reason

2026-06-15T04:47:25+00:00

When the TLS error is `SSL_R_CERTIFICATE_VERIFY_FAILED`, the verification failure reason is reported by `SSL_get_verify_result`. Adding this reason to the debug logs is valuable to pin-point certificate rejection that are specific to EDK II. Signed-off-by: Jean-Tiare Le Bigot

MdeModulePkg: Display VID and DID using 4-digit hexadecimal number

2026-06-15T02:25:50+00:00

No functional change. Signed-off-by: Qihang Gao

OvmfPkg: Add WSMT ACPI table for SMM builds

2026-06-13T15:22:58+00:00

Windows uses the Windows SMM Security Mitigation Table to decide whether SMM firmware advertises the communication-buffer protections needed by VBS [1]. WSMT ProtectionFlags represent a pinky promise that the underlying firmware will implement various security practices [2]. Add a small DXE driver that installs a revision 1 WSMT table for the OvmfPkgIa32X64 and OvmfPkgX64 builds. WSMT ProtectionFlags are set to 0x3, asserting: EFI_WSMT_PROTECTION_FLAGS_FIXED_COMM_BUFFERS EFI_WSMT_PROTECTION_FLAGS_COMM_BUFFER_NESTED_PTR_PROTECTION Note, we are intentionally not asserting EFI_WSMT_PROTECTION_FLAGS_SYSTEM_RESOURCE_PROTECTION, as the QEMU side is not yet tuned up to enforce this protection. Note: when Windows Hypervisor Enforced Code Integrity is enabled, Windows msinfo -> Virtualization-based security Available Security Properties will NOT include "SMM Security Mitigations 1.0", due to the missing SYSTEM_RESOURCE_PROTECTION flag. Note, WSMT is required for default enablement of HVCI [3], so we're taking a step in the right direction here, but not yet 100% complete as of this patch. References: [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs [2] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-uefi-wsmt [3] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-hvci-enablement#check-results-of-memory-integrity-default-enablement Cc: Paolo Bonzini Signed-off-by: Jon Kohler

MdePkg: Update WSMT (Windows SMM Security Mitigation Table) Docs

2026-06-13T15:22:58+00:00

The WSMT table ProtectionFlags represent a pinky promise from the firmware that it will implement various secure processes and features, but we should know what that pinky promise actually represents with in-code documentation. Revise the documentation for the Windows SMM Security Mitigation Table to include detailed descriptions of the Protection Flags, which are directly drawn from Microsoft's docs. Update the stable URL to the latest Microsoft docs for cross reference. Cc: Paolo Bonzini Signed-off-by: Jon Kohler

EmbeddedPkg, OvmfPkg: Produce FV3 HOBs for Extracted FVs

2026-06-13T09:06:33+00:00

EmbeddedPkg's PrePiLib and OvmfPkg's PeilessStartupLib (which uses PrePiLib) only produce FV2 HOBs for extracted FVs. However, FV3 HOBs have superceded FV2 HOBs for describing extracted FVs. This commit updates both of these libs to also produce FV3 HOBs, following PEI's pattern of producing an FV, FV2, and FV3 HOB for each extracted FV. Eventually, only FV3 HOBs will be produced, so this paves the way for that. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny

OvmfPkg: PeilessStartupLib: Fix FV2 HOB Production

2026-06-13T09:06:33+00:00

PeilessStartupLib is incorrectly producing FV2 HOBs. The FvName field of the FV2 HOB is intended to be the parent FV's name. This way the HOB consumer phase can identify when an FV has already been extracted: if the file name of the extracted FV and the parent FV name match in the FV2 HOB. With the incorrect FvName, DXE will re-extract the already extracted FV, which can be a large performance hit (some platforms we have seen ~1 second). Signed-off-by: Oliver Smith-Denny

EmbeddedPkg, OvmfPkg: PrePiLib: Use Correct FvName in FV2 HOB Production

2026-06-13T09:06:33+00:00

PrePiLib is incorrectly producing FV2 HOBs. The FvName field of the FV2 HOB is intended to be the parent FV's name. This way the HOB consumer phase can identify when an FV has already been extracted: if the file name of the extracted FV and the parent FV name match in the FV2 HOB. With the incorrect FvName, DXE will re-extract the already extracted FV, which can be a large performance hit (some platforms we have seen ~1 second). This requires an update to FfsProcessFvFile to pass the parent FV handle through so the FV2 HOB can be correctly produced. OvmfPkg consumers are also updated. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny