OvmfPkg/Library/TdxStartupLib: Add lazy memory accept to the TDVF. #9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gaojiaqi7
force-pushed
the
tdvf_dev
branch
5 times, most recently
from
f7e0986 to
e4da6c9
Compare
Add unaccepted memory type to several structures and macro definitions to indicate the unaccepted memory. SEC Phase: Modify the Hob process function to partially accept memory. Modify the Hob transfer function to build different types of system memory Hobs for DXE phase, system memory is split to type of system memory and unaccepted memory. DXE Phase: Add case of unaccepted memory in the GCD memory service process and memory map.
Kernel/Initrd image size maybe significant so we cannot decide the memory size to be accepted at build-time. In SEC, we read the size of kernel/initrd image from QEMU and accept memory used for them additionally.
gaojiaqi7
force-pushed
the
tdvf_dev
branch
3 times, most recently
from
7c0c52c to
47627d1
Compare
Memory usage may exceed the amount accepted at the begining (SEC), TDVF need to accept memory dynamically when OUT_OF_RESOURCE occurs. EfiMemoryAcceptProtocol is defined in MdePkg and there's an implementation in the TdxDxe for Intel TDX memory acceptance. When DXE memory service need more memory to be accepted, it can call the interface installed by TdxDxe. Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com>
When CoreAllocatePages()/CoreAllocatePool() meets error of EFI_OUT_OF_RESOURCES, locate the EfiMemoryAcceptProtocol and accept extra memory. Firstly, find the unaccpeted memory region with enough size in GCD entries. Then locate the EfiMemoryAcceptProtocol and accept the memory. Finally, update the GCD memory and gMemoryMap entries. After updating the memory infomation, CoreInternalAllocatePages()/ CoreInternalAllocatePool() will be recalled to allocate pages/pool. To do (existing issue): 1. CoreAddMemorySpace() should not be called directly in AcceptMemoryResource() until gMemoryMap is updated because it will try to allocate another piece of memory for GCD map entry. 2. AcceptMemoryResource() is called in both CoreAllocatePool() and CoreAllocatePages(). Refine this by changing FindFreePages() and the CoreConvertPagesEx() to handle *AllocateAddress* case. Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com>
mxu9
pushed a commit
that referenced
this pull request
Jul 11, 2024
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4542 Bug Overview: PixieFail Bug #9 CVE-2023-45237 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) Use of a Weak PseudoRandom Number Generator Change Overview: Updates all Instances of NET_RANDOM (NetRandomInitSeed ()) to either > > EFI_STATUS > EFIAPI > PseudoRandomU32 ( > OUT UINT32 *Output > ); > or (depending on the use case) > > EFI_STATUS > EFIAPI > PseudoRandom ( > OUT VOID *Output, > IN UINTN OutputLength > ); > This is because the use of Example: The following code snippet PseudoRandomU32 () function is used: > > UINT32 Random; > > Status = PseudoRandomU32 (&Random); > if (EFI_ERROR (Status)) { > DEBUG ((DEBUG_ERROR, "%a failed to generate random number: %r\n", __func__, Status)); > return Status; > } > This also introduces a new PCD to enable/disable the use of the secure implementation of algorithms for PseudoRandom () and instead depend on the default implementation. This may be required for some platforms where the UEFI Spec defined algorithms are not available. > > PcdEnforceSecureRngAlgorithms > If the platform does not have any one of the UEFI defined secure RNG algorithms then the driver will assert. Cc: Saloni Kasbekar <saloni.kasbekar@intel.com> Cc: Zachary Clark-williams <zachary.clark-williams@intel.com> Signed-off-by: Doug Flick [MSFT] <doug.edk2@gmail.com> Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
mxu9
pushed a commit
that referenced
this pull request
Nov 4, 2024
This patch does not impact functionality. It aims to clarify the synchronization flow between the BSP and APs to enhance code readability and understanding: Steps #6 and #11 are the basic synchronization requirements for all cases. Steps #1 is additional requirements if the MmCpuSyncModeTradition mode is selected. Steps #1, #2, #3, #4, #5, #7, #8, #9, and #10 are additional requirements if the system needs to configure the MTRR. Steps #9 and #10 are additional requirements if the system needs to support the mSmmDebugAgentSupport. Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add unaccepted memory type to several structure and macro definition to
indicate the unaccepted memory.
SEC Phase: Modify the Hob process function to partially accept the memory.
Modify the Hob transfer funtion to build different types of system memory
Hobs for DXE phase, system memory is split to type of system memory and
unaccepted memory.
DXE Phase: Add case of unaccepted memory in the GCD memory service process
and memory map.