Tianocore/edk2.git/OvmfPkg/Sec, branch dependabot/github_actions/actions/setup-python-6

MdePkg: Move StackCheckLibStaticInit to StackCheckLib

2025-02-07T02:23:11+00:00

This commit oves StackCheckLib from a NULL lib to an instance of StackCheckLib. This requires every entry point to add a library dependency on StackCheckLib. It also requires every SEC module to have a dependency on StackCheckLib because there is no standard SEC entry point. It allows for greater flexibility for a platform to apply stack cookies and simplifies DSC logic. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny

OvmfPkg/Sec: Skip setup MTRR early in TD-Guest

2024-07-11T03:24:26+00:00

With the commit ce4c76e (“OvmfPkg/Sec: Setup MTRR early in the boot process.”), we find an unexpected #VE is triggered in TD-Guest. The background of importing the above commit is that: Before running lzma uncompress of the main firmware volume, if not correctly set MTRR, that would make the uncompress be extremely slow. Detailed discussion info can refer to below links: https://edk2.groups.io/g/devel/message/114202 https://edk2.groups.io/g/devel/message/114977 Refer to [intel-tdx-module-1.5-base-spec] Section 11.3 and section11.6.1, CR0.CD is enforced to 0 in TD-Guest. And refer to section 18.2.1.4, TDX module MTRR emulation enforces WB in VMM. Currently the initial MTRR are: - Td-Guest : MTRR disabled, Type is WB. - Non-Td-Guest : MTRR disabled, Type is UC. In DXE phase, OVMF/TDVF would check the MTRR Type for MMIO (in CpuSetMemoryAttributes -> MtrrGetMemoryAttribute -> MtrrGetMemoryAttributeworker: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MtrrLib/MtrrLib.c#L929 ). If MTRR is disabled, it always returns UC. Otherwise, it returns the actual value. If it checks that the type is not UC then the MTRR is programmed. It is required to disable cache by setting CR0.CD to 1. That will trigger an unexpected #VE in TD-Guest. Based on above analysis we propose to skip "Setup MTRR early" in TD-Guest because of: - TD-Guest doesn’t have the issue that lzma uncompress extremely slow. - This patch will trigger an unexpected #VE in TD-Guest. intel-tdx-module-1.5-base-spec: https://cdrdv2.intel.com/v1/dl/getContent/733575 Cc: Erdem Aktas Cc: Jiewen Yao Cc: Min Xu Cc: Gerd Hoffmann Cc: Elena Reshetova Signed-off-by: Ceping Sun

OvmfPkg/Sec: use cache type #defines from ArchitecturalMsr.h

2024-06-26T06:04:49+00:00

Signed-off-by: Gerd Hoffmann

OvmfPkg/Sec: Setup MTRR early in the boot process.

2024-06-26T06:04:49+00:00

Specifically before running lzma uncompress of the main firmware volume. This is needed to make sure caching is enabled, otherwise the uncompress can be extremely slow. Adapt the ASSERTs and MTRR setup in PlatformInitLib to the changes. Background: Depending on virtual machine configuration kvm may uses EPT memory types to apply guest MTRR settings. In case MTRRs are disabled kvm will use the uncachable memory type for all mappings. The vmx_get_mt_mask() function in the linux kernel handles this and can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/kvm/vmx/vmx.c?h=v6.7.1#n7580 In most VM configurations kvm uses MTRR_TYPE_WRBACK unconditionally. In case the VM has a mdev device assigned that is not the case though. Before commit e8aa4c6546ad ("UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0") kvm also ended up using MTRR_TYPE_WRBACK due to KVM_X86_QUIRK_CD_NW_CLEARED. After that commit kvm evaluates guest mtrr settings, which why setting up MTRRs early is important now. Signed-off-by: Gerd Hoffmann

OvmfPkg: Don't make APIC MMIO accesses with encryption bit set

2024-05-02T12:43:50+00:00

For the most part, OVMF will clear the encryption bit for MMIO regions, but there is currently one known exception during SEC when the APIC base address is accessed via MMIO with the encryption bit set for SEV-ES/SEV-SNP guests. In the case of SEV-SNP, this requires special handling on the hypervisor side which may not be available in the future[1], so make the necessary changes in the SEC-configured page table to clear the encryption bit for 4K region containing the APIC base address. [1] https://lore.kernel.org/lkml/20240208002420.34mvemnzrwwsaesw@amd.com/#t Suggested-by: Tom Lendacky Cc: Ard Biesheuvel Cc: Gerd Hoffmann Cc: Erdem Aktas Cc: Jiewen Yao Cc: Min Xu Cc: Tom Lendacky Cc: Jianyong Wu Cc: Anatol Belski Signed-off-by: Michael Roth Reviewed-by: Gerd Hoffmann

OvmfPkg: auto-generate (and fix) SEC ProcessLibraryConstructorList() decl

2024-03-08T09:09:22+00:00

declares a bogus ProcessLibraryConstructorList() for OVMF's SEC module. Rely on AutoGen for (properly) declaring ProcessLibraryConstructorList(). Update the call. Build-tested with: build -a X64 -b DEBUG -m OvmfPkg/Sec/SecMain.inf \ -p OvmfPkg/OvmfPkgX64.dsc -t GCC5 Cc: Ard Biesheuvel Cc: Erdem Aktas Cc: Gerd Hoffmann Cc: Jiewen Yao Cc: Michael Roth Cc: Min Xu Cc: Tom Lendacky Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4643 Signed-off-by: Laszlo Ersek Message-Id: <20240305113843.68812-3-lersek@redhat.com> Reviewed-by: Jiewen Yao Acked-by: Gerd Hoffmann

OvmfPkg: Update code to be more C11 compliant by using func

2023-04-10T14:19:57+00:00

__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout OvmfPkg. Signed-off-by: Rebecca Cran Reviewed-by: Michael D Kinney Reviewed-by: Ard Biesheuvel Reviewed-by: Sunil V L

OvmfPkg: Remove UefiCpuLib from module INFs.

2023-03-10T08:23:56+00:00

Because UefiCpuPkg/UefiCpuLib is merged to MdePkg/CpuLib, remove the dependency of UefiCpuLib. Cc: Ard Biesheuvel Cc: Jiewen Yao Cc: Jordan Justen Acked-by: Gerd Hoffmann Signed-off-by: Yu Pu Signed-off-by: Zhiguang Liu

OvmfPkg/OvmfPkgX64: Measure TdHob and Configuration FV in SecMain

2023-02-04T03:38:15+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243 TdHob and Configuration FV (Cfv) are external inputs from VMM. From the security perspective, they should be measured before they're consumed. This patch measures TdHob and Cfv and stores the measurement values in WorkArea. Cc: Erdem Aktas Cc: James Bottomley Cc: Jiewen Yao Cc: Gerd Hoffmann Cc: Tom Lendacky Cc: Michael Roth Acked-by: Gerd Hoffmann Reviewed-by: Jiewen Yao Signed-off-by: Min Xu

OvmfPkg: Refactor ProcessHobList

2023-02-04T03:38:15+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4243 ProcessHobList once was implemented in PlatformInitLib and it walks thru TdHob list and accept un-accepted memories. This patch moves the codes to SecTdxHelperLib and rename ProcessHobList as TdxHelperProcessTdHob After TdxHelperProcessTdHob is introduced, below changes are applied: - Call TdxHelperProcessTdHob instead of ProcessHobList in SecMain.c (in both OvmfPkgX64/Sec and IntelTdx/Sec). - Delete the duplicated codes in PlatformInitLib Cc: Erdem Aktas Cc: James Bottomley Cc: Jiewen Yao Cc: Gerd Hoffmann Cc: Tom Lendacky Cc: Michael Roth Acked-by: Gerd Hoffmann Reviewed-by: Jiewen Yao Signed-off-by: Min Xu

Tianocore/edk2.git/OvmfPkg/Sec, branch dependabot/github_actions/actions/setup-python-6

MdePkg: Move StackCheckLibStaticInit to StackCheckLib

OvmfPkg/Sec: Skip setup MTRR early in TD-Guest

OvmfPkg/Sec: use cache type #defines from ArchitecturalMsr.h

OvmfPkg/Sec: Setup MTRR early in the boot process.

OvmfPkg: Don't make APIC MMIO accesses with encryption bit set

OvmfPkg: auto-generate (and fix) SEC ProcessLibraryConstructorList() decl

OvmfPkg: Update code to be more C11 compliant by using __func__

OvmfPkg: Remove UefiCpuLib from module INFs.

OvmfPkg/OvmfPkgX64: Measure TdHob and Configuration FV in SecMain

OvmfPkg: Refactor ProcessHobList

OvmfPkg: Update code to be more C11 compliant by using func