Re: [edk2-devel] The OVMF packages can not work properly when it was compiled with "-D SECURE_BOOT_ENABLE=TRUE"

[wojiaohanliyang@163.com]

[-- Attachment #1: Type: text/plain, Size: 5351 bytes --]

The root cause of these issues are that the following patchset rename the function from TdxValidateCfv() to PlatformInitEmuVariableNvStore().

39596c41c8 OvmfPkg: Add build-flag SECURE_BOOT_FEATURE_ENABLED
3abaa281d3 OvmfPkg/TdxDxe: Set PcdEmuVariableNvStoreReserved
70165fa6e2 OvmfPkg/NvVarsFileLib: Shortcut ConnectNvVarsToFileSystem in secure-boot
ee91d9ef24 OvmfPkg: Reserve and init EmuVariableNvStore in Pei-less Startup
*58eb8517ad OvmfPkg/PlatformPei: Update ReserveEmuVariableNvStore*
*4f173db8b4 OvmfPkg/PlatformInitLib: Add functions for EmuVariableNvStore*
*0e72e8762a OvmfPkg/PeilessStartupLib: Delete TdxValidateCfv*
fb008dbe01 EmbeddedPkg: Add AllocateRuntimePages in PrePiMemoryAllocationLib
7cc7c52670 OvmfPkg: Set default Pci PCDs in Tdx guest
1b1c58ab32 OvmfPkg: Update CcProbeLib to DxeCcProbeLib
c4bc1a9498 OvmfPkg: Add SecPeiCcProbeLib

Before the patchset is merged, the TdxValidateCfv() is invoked only in Tdx guest. After the patchset is merged, the PlatformInitEmuVariableNvStore() becomes a common code and is invoked in any guest. The code path is as below.
PlatformPei/InitializePlatform()
-> ReserveEmuVarabileNvStore()
*-> PlatformInitEmuVariableNvStore() if 'SECURE_BOOT_ENABLE=TRUE'*
*-> PlatformValidateNvVarStore()*

The function PlatformValidateNvVarStore() will access the OvmfFlashNvStorage which is mapped in the address range specified by 'PcdOvmfFlashNvStorageVariableBase' (typically 0xFFC00000) and 'PcdFlashNvStorageVariableSize' (typically 0x40000). But the function PlatformValidateNvVarStore() doesn't consider any combination of OVMF files and Non-CoCo/CoCo guest.

*1.* *When we boot a Qemu VM with only OVMF_CODE.fd but not OVMF_VARS.fd,* the address range specified by 'PcdOvmfFlashNvStorageVariableBase' (typically 0xFFC00000) and '2 * PcdFlashNvStorageFtwSpareSize' (typically 0x84000) is mmio address range but without corresponding device.
a. If the VM is a non-encrypted VM, the 0x0 is returned when PlatformValidateNvVarStore() read from the mmio address range,  this will cause validation of OvmfFlashNvStorage to fail and trigger ASSERT (FALSE).
b. If the VM is a SEV VM, the PlatformValidateNvVarStore() calls IsZeroBuffer() which execute instruction scasX to check that first 16 bytes of the OvmfFlashNvStorage are all zeros. On Linux host side, KVM will inject #PF when it emulate scasX on MMIO address range, when VmEnter the guest, the guest will trigger shutdown event because the exception handler can't deal with #PF at this time.
c. If the VM is a SEV-ES VM, the PlatformValidateNvVarStore() calls IsZeroBuffer() which execute instruction scasX to check that first 16 bytes of the OvmfFlashNvStorage are all zeros. The instruction scasX will trigger #VC handler to handle MMIO NPF event, the #VC handler can't decode scasX and trigger ASSERT (FALSE).

*2. When we boot a Qemu VM with OVMF.fd ( the OVMF_VARS.fd part is included in OVMF.fd),* the address range specified by 'PcdOvmfFlashNvStorageVariableBase' (typically 0xFFC00000) and '2 * PcdFlashNvStorageFtwSpareSize' (typically 0x84000) is mmio address range and the KVM will mapping the mmio address range to system physical memory with read-only attribute in the NPT when guest read from this address range.
a. If the VM is a SEV/SEV-ES VM, the PlaformValidateNvVarStore() can return as expected, because at this time, the guest can direct read system physical memory for data in the mmio address range. But in this situation, PlatformValidateNvVarStore() only initialize the first part (this part is specified by 'PcdFlashNvStorageVariableSize' in length) of EmuVariableNvStore buffer, *the Fault Tolerant Write part of EmuVariableNvStore buffer isn't initialized at this time*. If the first part of EmuVariableNvStore is initilaized at here, then VariableRuntimeDxe will not initialize EmuVariableNvStore, and FaultTolerantWriteDxe will get garble data from Fault Tolerant Write part of EmuVariableNvStore, the FaultTolerantWriteDxe read data from the address specified by the garble data will cause invalid access and crash.

*3. When boot a Qemu VM with OVMF_CODE.fd and OVMF_VARS.fd,* the address range specified by 'PcdOvmfFlashNvStorageVariableBase' (typically 0xFFC00000) and '2 * PcdFlashNvStorageFtwSpareSize' (typically 0x84000) is mmio address range and the KVM will mapping the mmio address range to system physical memory with read-only attribute in the NPT when guest read from this address range.
a. If the VM is a SEV/SEV-ES VM, the PlatformValidateNvVarStore() invokes IsZeroBuffer() and find the first 16 bytes of the OvmfFlashNvStorage are not all zeros, and then trigger ASSERT (FALSE). In this situation, the OvmfFlashNvStorage is OVMF_VARS.fd，the OVMF_VARS.fd is plaintext on the host side, while at this time, the guest mapping these address range with C-bit (i.e. mapping as encrypted). The guest get garble data when it read the first 16 bytes of the OvmfFlashNvStorage,  the validation will fail.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119888): https://edk2.groups.io/g/devel/message/119888
Mute This Topic: https://groups.io/mt/107157379/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 6615 bytes --]