kexec uefi ramdisk support #2
Merged
+111
−11
Conversation
This file contains 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
|
This is a duplicate of chengchiehhuang#3 The 8d9629a patch should be replaced with the one that was merged into the main edk2 tree: tianocore@d0b6596 |
osresearch
force-pushed
the
kexec-ramdisk
branch
from
0fd7184 to
fdef7c4
Compare
|
Added sign-off messages and replaced ramdisk commit with the one from the upstream tream. |
Signed-off-by: Trammell Hudson <[email protected]>
…otocol REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3483 This patch initializes the linked list RegisteredRamDisks in RamDiskDxeEntryPoint before the registration of gEfiRamDiskProtocolGuid with InstallMultipleProtocolInterfaces, allowing ramdisks to be created via a callback installed with RegisterProtocolNotify as soon as the protocol is registered. Without this, calling RamDisk->Register() in the callback causes a crash: ASSERT [RamDiskDxe] MdePkg/Library/BaseLib/LinkedList.c(75): List->ForwardLink != ((void *) 0) Signed-off-by: Trammell Hudson <[email protected]> Cc: Daniel Schaefer <[email protected]> Cc: Jian J Wang <[email protected]> Cc: Hao A Wu <[email protected]> Cc: Ray Ni <[email protected]> Cc: Zhichao Gao <[email protected]> Reviewed-by: Hao A Wu <[email protected]>
Signed-off-by: Trammell Hudson <[email protected]>
…om kexec or other bootloader Signed-off-by: Trammell Hudson <[email protected]>
osresearch
force-pushed
the
kexec-ramdisk
branch
from
fdef7c4 to
76d653c
Compare
hugelgupf
pushed a commit
that referenced
this pull request
Jan 24, 2024
Root cause: 1. Before DisableReadonlyPageWriteProtect() is called, the return address (#1) is pushed in shadow stack. 2. CET is disabled. 3. DisableReadonlyPageWriteProtect() returns to #1. 4. Page table is modified. 5. EnableReadonlyPageWriteProtect() is called, but the return address (#2) is not pushed in shadow stack. 6. CET is enabled. 7. EnableReadonlyPageWriteProtect() returns to #2. #CP exception happens because the actual return address (#2) doesn't match the return address stored in shadow stack (#1). Analysis: Shadow stack will stop update after CET disable (DisableCet() in DisableReadOnlyPageWriteProtect), but normal smi stack will be continue updated with the function called and return (DisableReadOnlyPageWriteProtect & EnableReadOnlyPageWriteProtect), thus leading stack mismatch after CET re-enabled (EnableCet() in EnableReadOnlyPageWriteProtect). According SDM Vol 3, 6.15-Control Protection Exception: Normal smi stack and shadow stack must be matched when CET enable, otherwise CP Exception will happen, which is caused by a near RET instruction. CET is disabled in DisableCet(), while can be enabled in EnableCet(). This way won't cause the problem because they are implemented in a way that return address of DisableCet() is poped out from shadow stack (Incsspq performs a pop to increases the shadow stack) and EnableCet() doesn't use "RET" but "JMP" to return to caller. So calling EnableCet() and DisableCet() doesn't have the same issue as calling DisableReadonlyPageWriteProtect() and EnableReadonlyPageWriteProtect(). With above root cause & analysis, define below 2 macros instead of functions for WP & CET operation: WRITE_UNPROTECT_RO_PAGES (Wp, Cet) WRITE_PROTECT_RO_PAGES (Wp, Cet) Because DisableCet() & EnableCet() must be in the same function to avoid shadow stack and normal SMI stack mismatch. Note: WRITE_UNPROTECT_RO_PAGES () must be called pair with WRITE_PROTECT_RO_PAGES () in same function. Change-Id: I4e126697efcd8dbfb4887da034d8691bfca969e3 Cc: Eric Dong <[email protected]> Cc: Ray Ni <[email protected]> Cc: Zeng Star <[email protected]> Cc: Gerd Hoffmann <[email protected]> Cc: Rahul Kumar <[email protected]> Cc: Laszlo Ersek <[email protected]> Signed-off-by: Jiaxin Wu <[email protected]> Reviewed-by: Laszlo Ersek <[email protected]> Reviewed-by: Ray Ni <[email protected]> Reviewed-by: Eric Dong <[email protected]>
AjanZhong
pushed a commit
to AjanZhong/linuxboot-edk2
that referenced
this pull request
Oct 21, 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 tianocore#6 and tianocore#11 are the basic synchronization requirements for all cases. Steps linuxboot#1 is additional requirements if the MmCpuSyncModeTradition mode is selected. Steps linuxboot#1, linuxboot#2, linuxboot#3, linuxboot#4, tianocore#5, tianocore#7, tianocore#8, tianocore#9, and tianocore#10 are additional requirements if the system needs to configure the MTRR. Steps tianocore#9 and tianocore#10 are additional requirements if the system needs to support the mSmmDebugAgentSupport. Signed-off-by: Jiaxin Wu <[email protected]>
AjanZhong
pushed a commit
to AjanZhong/linuxboot-edk2
that referenced
this pull request
Oct 21, 2024
… func This patch is for PiSmmCpuDxeSmm driver to add one round wait/release sync for BSP and AP to perform the SMM CPU Platform Hook before executing MMI Handler: SmmCpuPlatformHookBeforeMmiHandler (). With the function, SMM CPU driver can perform the platform specific items after one round BSP and AP sync (to make sure all APs in SMI) and before the MMI handlers. After the change, steps linuxboot#1 and linuxboot#2 are additional requirements if the MmCpuSyncModeTradition mode is selected. Signed-off-by: Jiaxin Wu <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This patch adds support for creating a UEFI ramdisk by passing in the command line parameter ramdisk=base,len,type, where type is the UEFI memory type to be reserved (typically 5 for reserved memory). If the ramdisk is a GPT formatted partition image that contains an EFI System Partition, the BDS will boot from it without requiring an ESP on the local harddisk.
It also includes a fix for a bug in the RamDiskDxe that causes a crash if a ram disk is registered immediately after the protocol is registered due to an uninitialized linked list: https://bugzilla.tianocore.org/show_bug.cgi?id=3483