-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xen ACPI tables support in OVMF #1
Closed
Closed
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 was committed in svn |
jljusten
added a commit
that referenced
this pull request
Sep 12, 2012
I. There are at least three locations in OvmfPkg that manipulate the PMBA and related PIIX4 registers. 1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c] module type: PEIM -- Pre-EFI Initialization Module (a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6] 2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c] module type: BASE -- probably callable anywhere after PEI (a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6] (b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0 (c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0 3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] module type: DXE_DRIVER -- Driver eXecution Environment (a) sets SCI_EN, which depends on correct PMBA setting from earlier ( The relative order of #1 and #3 is dictated minimally by their module types. Said relative order can be verified with the boot log: 27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580 PlatformPei.efi 28 Platform PEIM Loaded 1259 PlatformBdsInit 1270 PlatformBdsPolicyBehavior Line 28 is printed by InitializePlatform() [OvmfPkg/PlatformPei/Platform.c] which is the entry point of that module. The other two lines are printed by the corresponding functions in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c". ) Currently #2 (AcpiTimerLibConstructor()) is called in a random spot (whenever it gets loaded from the firmware image) and masks the insufficient setup in #1. We shouldn't depend on that, PEI should finish with IO space being fully accessibe. In addition, PEI should program the same PMBA value as AcpiTimerLib. II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and ensure proper PM configuration for itself (either by confirming or by doing). III. Considering a possible cleanup/unification of #2 and #3: timer functions relying on AcpiTimerLibConstructor(), - MicroSecondDelay() - NanoSecondDelay() - GetPerformanceCounter() - GetPerformanceCounterProperties() - GetTimeInNanoSecond() may be called before #3 is reached (in Boot Device Selection phase), so we should not move the initialization from #2 to #3. (Again, AcpiTimerLib should contain its own setup.) We should also not move #3 to an earlier phase -- SCI_EN is premature unless we're about to boot real soon ("enable generation of SCI upon assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits"). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
referenced
this pull request
in jljusten/edk2
May 28, 2013
…tions in __aeabi_uread4 Change __aeabi_uread4 from: ldrb r2, [r0, #1] ldrb r1, [r0] (...) to: ldrb r1, [r0] ldrb r2, [r0, #1] (...) This change is a workaround to handle correctly __aeabi_uread4 on ARM Versatile Express RTSM. It should not have any major consequence on the other ARM platforms. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12481 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
referenced
this pull request
in jljusten/edk2
May 28, 2013
I. There are at least three locations in OvmfPkg that manipulate the PMBA and related PIIX4 registers. 1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c] module type: PEIM -- Pre-EFI Initialization Module (a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6] 2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c] module type: BASE -- probably callable anywhere after PEI (a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6] (b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0 (c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0 3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c] module type: DXE_DRIVER -- Driver eXecution Environment (a) sets SCI_EN, which depends on correct PMBA setting from earlier ( The relative order of #1 and tianocore#3 is dictated minimally by their module types. Said relative order can be verified with the boot log: 27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580 PlatformPei.efi 28 Platform PEIM Loaded 1259 PlatformBdsInit 1270 PlatformBdsPolicyBehavior Line 28 is printed by InitializePlatform() [OvmfPkg/PlatformPei/Platform.c] which is the entry point of that module. The other two lines are printed by the corresponding functions in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c". ) Currently tianocore#2 (AcpiTimerLibConstructor()) is called in a random spot (whenever it gets loaded from the firmware image) and masks the insufficient setup in #1. We shouldn't depend on that, PEI should finish with IO space being fully accessibe. In addition, PEI should program the same PMBA value as AcpiTimerLib. II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and ensure proper PM configuration for itself (either by confirming or by doing). III. Considering a possible cleanup/unification of tianocore#2 and tianocore#3: timer functions relying on AcpiTimerLibConstructor(), - MicroSecondDelay() - NanoSecondDelay() - GetPerformanceCounter() - GetPerformanceCounterProperties() - GetTimeInNanoSecond() may be called before tianocore#3 is reached (in Boot Device Selection phase), so we should not move the initialization from tianocore#2 to tianocore#3. (Again, AcpiTimerLib should contain its own setup.) We should also not move tianocore#3 to an earlier phase -- SCI_EN is premature unless we're about to boot real soon ("enable generation of SCI upon assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits"). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
pushed a commit
that referenced
this pull request
Jul 31, 2014
… issues came up related to vs2013 build and caused the build to fail. Vs2013 issue #1: warning message about uninitialized variables or pointers like this: s:\incbld\ia32\intelframeworkmodulepkg\bus\isa\isabusdxe\isabus.c(395) : warning C4701: potentially uninitialized local variable 'DevicePathData' used s:\incbld\ia32\intelframeworkmodulepkg\bus\isa\isabusdxe\isabus.c(395) : warning C4703: potentially uninitialized local pointer variable 'DevicePathData' used LINK : fatal error LNK1257: code generation failed The following online messages shows discussions related to this vs2013 issue and how Microsoft engineer responded. They suggest a work around by adding the initialization for the variables. https://connect.microsoft.com/VisualStudio/feedback/details/816730/bogus-warning-from-vs-2013 Vs2013 issue #2: C:\Program Files\Windows Kits\8.1\include\um\winnt.h(5105) : error C2220: warning treated as error - no 'object' file generated C:\Program Files\Windows Kits\8.1\include\um\winnt.h(5105) : warning C4005: 'InterlockedCompareExchange64' : macro redefinition This happened for Nt32Pkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wang, Yu <yu.wang@intel.com> Reviewed-by: Gao, Liming <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15722 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
pushed a commit
that referenced
this pull request
Aug 22, 2014
Example: Shell> echo "You are ^#1!" # Testing echo You are #1! Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chris Phillips <chrisp@hp.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15871 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
pushed a commit
that referenced
this pull request
Oct 29, 2014
XenStore is a key/value database, which is running on another virtual machine. It can be accessed through shared memory. This is a client implementation. Change in V3: - moving xs_wire.h from patch #1 to this patch - fix return value of XenStoreListDirectory - Use a timeout to print a debug message if the other side of the xenstore ring does not notify through the event channel. This is done with the new XenStoreWaitForEvent function. - Have XenStoreReadReply check status of XenStoreProcessMessage and return an error if needed. - Have XenStoreTalkv return the status of XenStoreReadReply. - Have a loop to check for the quiescent of the response ring in the XenStoreInitComms function. (with a timeout of 5 seconds) - use the recently introduced XenStore 'closing' feature. Change in V2: - Change comment style, from freebsd to ovmf - Fix type of EventChannel - Fix debug print, no more cast - Implement XenStoreDeinit. - Clean up comments - Fix few codding style issue - Add FAIL xenstore status value. Origin: FreeBSD 10.0 License: This patch adds several files under the MIT licence. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16267 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
pushed a commit
that referenced
this pull request
Feb 25, 2015
Some compilers requires an empty line at the end of the file. ARM compiler version 5 is one of these compilers: error #1-D: last line of file ends without a newline Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Feng Tian <feng.tian@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16918 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
pushed a commit
that referenced
this pull request
Mar 3, 2015
Some compilers requires an empty line at the end of the file. ARM compiler version 5 is one of these compilers: error #1-D: last line of file ends without a newline (Sync patch r16918 from main trunk.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Feng Tian <feng.tian@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/branches/UDK2014.SP1@16996 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
pushed a commit
that referenced
this pull request
Jul 9, 2015
PeiCore hang when loads a PEIM whose section alignment requirement is 0x40 but the actual base address is 0x20 aligned. The issue is caused by the following facts, in order: 1. GCC49 requires the section alignment of .data to be 0x40. So a new link script gcc4.9-ld-script was added for GCC49 to specify the 0x40 alignment. 2. GenFw tool was enhanced to sync ELF's section alignment to PE header. Before the enhancement, the section alignment of converted PE image always equals to 0x20. If only with #1 change, GCC49 build image won't hang in PeiCore because the converted PE image still claims 0x20 section alignment which is aligned to the align setting set in FDF file. But later with #2 change, the converted PE image starts to claims 0x40 section alignment, while build tool still puts the PEIM in 0x20 aligned address, resulting the PeCoffLoaderLoadImage() reports IMAGE_ERROR_INVALID_SECTION_ALIGNMENT error. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17902 6f19259b-4bc3-4df7-8a09-765794883524
jljusten
pushed a commit
that referenced
this pull request
Sep 9, 2015
There is a hidden bug for below code: (1 << BaseAddressAlignment) & *BlockEntrySize From disassembly code, we can see the literal number 1 will be treated as INT32 by compiler by default, and we'll get 0xFFFFFFFF80000000 when BaseAddressAlignment is equal to 31. So we will always get 31 when alignment is larger than 31. if ((1 << BaseAddressAlignment) & *BlockEntrySize) { 5224: f9404be0 ldr x0, [sp,#144] 5228: 2a0003e1 mov w1, w0 522c: 52800020 mov w0, #0x1 // #1 5230: 1ac12000 lsl w0, w0, w1 5234: 93407c01 sxtw x1, w0 The bug can be replayed on QEMU AARCH64; by adding some debug print, we can see lots of level 1 tables created (for block of 1GB) even when the region is large enough to use 512GB block size. Use LowBitSet64() in BaseLib instead to fix the bug. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18423 6f19259b-4bc3-4df7-8a09-765794883524
jiaxinwu
added a commit
that referenced
this pull request
Aug 18, 2016
IpSb->Reconfig should not be set to TRUE to focal the reconfiguration during the policy changes from Static to DHCP. It's redundancy because the default router table and default addresses have been freed ahead ( Detailed see Ip4Config2OnPolicyChanged() function). Otherwise, the potential failure will appear if UseDefaultAddress configured. Reproduce steps see below: #1. Set policy to DHCP. #2. If DHCP process is not complete yet, then run one APP to invoke UDP4 Configure with "UseDefaultAddress = TRUE" (loop to call UDP4 Configure until Ip4Mode.IsConfigured changes to TRUE). #3. Even DHCP succeed but Ip4Mode.IsConfigured flag never set to TRUE Concrete analysis is as follows: In #1, the policy will be set to DHCP, and then Ip4Config2OnPolicyChanged() will be called. In this function, if "IpSb->Reconfig" flag is set to TRUE, the original "IpSb->DefaultInterface" will be abandoned/freed once the DHCP process finished. In #2, UDP4 Configure with "UseDefaultAddress = TRUE" is called, that means the default interface (IpSb->DefaultInterface) will be selected as current instance's interface. In #3, when DHCP process finished, the original DefaultInterface will be abandoned/freed because "IpSb->Reconfig" flag is true. Meanwhile, one new interface is assigned to "IpSb->DefaultInterface". This new interface is different to the original one assigned to the UDP4 Configured instance. So, even DHCP process succeed, the up caller will never have the chance to get it's truly status. Cc: Cohen Eugene <eugene@hp.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Tested-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
jiaxinwu
added a commit
that referenced
this pull request
Aug 18, 2016
*v2: update the commit log and refine the code comments. There are three kinds of IKE Exchange process: #1. Initial Exchange #2. CREATE_CHILD_SA_Exchange #3. Information Exchange The IKE header "FLAG" update is incorrect in #2 and #3 exchange, which may cause the continue session failure. This patch is used to correct the updates of IKE header "FLAG" according the RFC4306 section 3.1. Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Zhang Lubo <lubo.zhang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
niruiyu
added a commit
that referenced
this pull request
Aug 25, 2016
This reverts commit 95fc5a8. The above commit causes several regression of "echo" command: 1. Double quotes are not being stripped from the final text. UEFI Shell 2.2 section 3.4.5 chops out the quotes. 2. Output redirection is not working as expected. Text is being redirected, but the ‘> …’ text should not be. 3. Inconsistent special character handling. For example, comments with # seem to be parsed out correctly, but handing of ^ is incorrect. In summary, ‘echo “You are ^#1” > t.txt’ results in the below content in t.txt: “You are ^#1” > t.txt Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
niruiyu
added a commit
that referenced
this pull request
Aug 25, 2016
This reverts commit 0fcf8d4. The above commit causes several regression of "echo" command: 1. Double quotes are not being stripped from the final text. UEFI Shell 2.2 section 3.4.5 chops out the quotes. 2. Output redirection is not working as expected. Text is being redirected, but the ‘> …’ text should not be. 3. Inconsistent special character handling. For example, comments with # seem to be parsed out correctly, but handing of ^ is incorrect. In summary, ‘echo “You are ^#1” > t.txt’ results in the below content in t.txt: “You are ^#1” > t.txt Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
niruiyu
added a commit
that referenced
this pull request
Aug 25, 2016
…mmandLib" This reverts commit c0bcd34. The above commit causes several regression of "echo" command: 1. Double quotes are not being stripped from the final text. UEFI Shell 2.2 section 3.4.5 chops out the quotes. 2. Output redirection is not working as expected. Text is being redirected, but the ‘> …’ text should not be. 3. Inconsistent special character handling. For example, comments with # seem to be parsed out correctly, but handing of ^ is incorrect. In summary, ‘echo “You are ^#1” > t.txt’ results in the below content in t.txt: “You are ^#1” > t.txt Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
MrChromebox
referenced
this pull request
in MrChromebox/edk2
Nov 7, 2016
This reverts commit 95fc5a8. The above commit causes several regression of "echo" command: 1. Double quotes are not being stripped from the final text. UEFI Shell 2.2 section 3.4.5 chops out the quotes. 2. Output redirection is not working as expected. Text is being redirected, but the ‘> …’ text should not be. 3. Inconsistent special character handling. For example, comments with # seem to be parsed out correctly, but handing of ^ is incorrect. In summary, ‘echo “You are ^#1” > t.txt’ results in the below content in t.txt: “You are ^#1” > t.txt Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
MrChromebox
referenced
this pull request
in MrChromebox/edk2
Nov 7, 2016
This reverts commit 0fcf8d4. The above commit causes several regression of "echo" command: 1. Double quotes are not being stripped from the final text. UEFI Shell 2.2 section 3.4.5 chops out the quotes. 2. Output redirection is not working as expected. Text is being redirected, but the ‘> …’ text should not be. 3. Inconsistent special character handling. For example, comments with # seem to be parsed out correctly, but handing of ^ is incorrect. In summary, ‘echo “You are ^#1” > t.txt’ results in the below content in t.txt: “You are ^#1” > t.txt Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
MrChromebox
referenced
this pull request
in MrChromebox/edk2
Nov 7, 2016
…mmandLib" This reverts commit c0bcd34. The above commit causes several regression of "echo" command: 1. Double quotes are not being stripped from the final text. UEFI Shell 2.2 section 3.4.5 chops out the quotes. 2. Output redirection is not working as expected. Text is being redirected, but the ‘> …’ text should not be. 3. Inconsistent special character handling. For example, comments with # seem to be parsed out correctly, but handing of ^ is incorrect. In summary, ‘echo “You are ^#1” > t.txt’ results in the below content in t.txt: “You are ^#1” > t.txt Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Tapan Shah <tapandshah@hpe.com>
lersek
referenced
this pull request
in lersek/edk2
Apr 25, 2017
Commit bd3fc81 ("ShellPkg/App: Fix memory leak and save resources.", 2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the RunSplitCommand(), right after the same shell file was closed with CloseFile(). The argument was: > 1) RunSplitCommand() allocates the initial SplitStdOut via > CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix > the memory leak. There is no memory leak actually, and the FreePool() call in question constitutes a double-free: (a) This is how the handle is established: ConvertEfiFileProtocolToShellHandle ( CreateFileInterfaceMem (Unicode), NULL ); CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and populates it fully. ConvertEfiFileProtocolToShellHandle() allocates some administrative structures and links the EFI_FILE_PROTOCOL_MEM object into "mFileHandleList". (b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the SHELL_FILE_HANDLE and to release all associated data. Accordingly, near the end of RunSplitCommand(), we have: EfiShellClose() ShellFileHandleRemove() // // undoes the effects of ConvertEfiFileProtocolToShellHandle() // ConvertShellHandleToEfiFileProtocol() // // note that this does not adjust the pointer value; it's a pure // type cast // FileHandleClose() FileInterfaceMemClose() // // tears down EFI_FILE_PROTOCOL_MEM completely, undoing the // effects of CreateFileInterfaceMem () // The FreePool() call added by bd3fc81 conflicts with SHELL_FREE_NON_NULL(This); in FileInterfaceMemClose(), so remove it. This error can be reproduced for example with: > Shell> map | more > 'more' is not recognized as an internal or external command, operable > program, or script file. which triggers: > ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature with the following stack dump: > #0 0x000000007f6dc094 in CpuDeadLoop () at > MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > #1 0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0 > "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624, > Description=0x7f6ed9d8 "CR has Bad Signature") at > OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153 > #2 0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624 > tianocore#3 0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529 > tianocore#4 0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at > MdeModulePkg/Core/Dxe/Mem/Pool.c:552 > tianocore#5 0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at > MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818 > tianocore#6 0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398, > StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813 > tianocore#7 0x000000007d487d59 in ProcessNewSplitCommandLine > (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121 > tianocore#8 0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018, > CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670 > tianocore#9 0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at > ShellPkg/Application/Shell/Shell.c:2732 > tianocore#10 0x000000007d4867c8 in DoShellPrompt () at > ShellPkg/Application/Shell/Shell.c:1349 > tianocore#11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898, > SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631 Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Marvin Häuser <Marvin.Haeuser@outlook.com> Cc: Qiu Shumin <shumin.qiu@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
lersek
added a commit
that referenced
this pull request
Apr 26, 2017
Commit bd3fc81 ("ShellPkg/App: Fix memory leak and save resources.", 2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the RunSplitCommand(), right after the same shell file was closed with CloseFile(). The argument was: > 1) RunSplitCommand() allocates the initial SplitStdOut via > CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix > the memory leak. There is no memory leak actually, and the FreePool() call in question constitutes a double-free: (a) This is how the handle is established: ConvertEfiFileProtocolToShellHandle ( CreateFileInterfaceMem (Unicode), NULL ); CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and populates it fully. ConvertEfiFileProtocolToShellHandle() allocates some administrative structures and links the EFI_FILE_PROTOCOL_MEM object into "mFileHandleList". (b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the SHELL_FILE_HANDLE and to release all associated data. Accordingly, near the end of RunSplitCommand(), we have: EfiShellClose() ShellFileHandleRemove() // // undoes the effects of ConvertEfiFileProtocolToShellHandle() // ConvertShellHandleToEfiFileProtocol() // // note that this does not adjust the pointer value; it's a pure // type cast // FileHandleClose() FileInterfaceMemClose() // // tears down EFI_FILE_PROTOCOL_MEM completely, undoing the // effects of CreateFileInterfaceMem () // The FreePool() call added by bd3fc81 conflicts with SHELL_FREE_NON_NULL(This); in FileInterfaceMemClose(), so remove it. This error can be reproduced for example with: > Shell> map | more > 'more' is not recognized as an internal or external command, operable > program, or script file. which triggers: > ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature with the following stack dump: > #0 0x000000007f6dc094 in CpuDeadLoop () at > MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > #1 0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0 > "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624, > Description=0x7f6ed9d8 "CR has Bad Signature") at > OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153 > #2 0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624 > #3 0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529 > #4 0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at > MdeModulePkg/Core/Dxe/Mem/Pool.c:552 > #5 0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at > MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818 > #6 0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398, > StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813 > #7 0x000000007d487d59 in ProcessNewSplitCommandLine > (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121 > #8 0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018, > CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670 > #9 0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at > ShellPkg/Application/Shell/Shell.c:2732 > #10 0x000000007d4867c8 in DoShellPrompt () at > ShellPkg/Application/Shell/Shell.c:1349 > #11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898, > SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631 Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Marvin Häuser <Marvin.Haeuser@outlook.com> Cc: Qiu Shumin <shumin.qiu@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Marvin Häuser <Marvin.Haeuser@outlook.com>
niruiyu
pushed a commit
that referenced
this pull request
May 4, 2017
Commit bd3fc81 ("ShellPkg/App: Fix memory leak and save resources.", 2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the RunSplitCommand(), right after the same shell file was closed with CloseFile(). The argument was: > 1) RunSplitCommand() allocates the initial SplitStdOut via > CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix > the memory leak. There is no memory leak actually, and the FreePool() call in question constitutes a double-free: (a) This is how the handle is established: ConvertEfiFileProtocolToShellHandle ( CreateFileInterfaceMem (Unicode), NULL ); CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and populates it fully. ConvertEfiFileProtocolToShellHandle() allocates some administrative structures and links the EFI_FILE_PROTOCOL_MEM object into "mFileHandleList". (b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the SHELL_FILE_HANDLE and to release all associated data. Accordingly, near the end of RunSplitCommand(), we have: EfiShellClose() ShellFileHandleRemove() // // undoes the effects of ConvertEfiFileProtocolToShellHandle() // ConvertShellHandleToEfiFileProtocol() // // note that this does not adjust the pointer value; it's a pure // type cast // FileHandleClose() FileInterfaceMemClose() // // tears down EFI_FILE_PROTOCOL_MEM completely, undoing the // effects of CreateFileInterfaceMem () // The FreePool() call added by bd3fc81 conflicts with SHELL_FREE_NON_NULL(This); in FileInterfaceMemClose(), so remove it. This error can be reproduced for example with: > Shell> map | more > 'more' is not recognized as an internal or external command, operable > program, or script file. which triggers: > ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature with the following stack dump: > #0 0x000000007f6dc094 in CpuDeadLoop () at > MdePkg/Library/BaseLib/CpuDeadLoop.c:37 > #1 0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0 > "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624, > Description=0x7f6ed9d8 "CR has Bad Signature") at > OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153 > #2 0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624 > #3 0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98, > PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529 > #4 0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at > MdeModulePkg/Core/Dxe/Mem/Pool.c:552 > #5 0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at > MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818 > #6 0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398, > StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813 > #7 0x000000007d487d59 in ProcessNewSplitCommandLine > (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121 > #8 0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018, > CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670 > #9 0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at > ShellPkg/Application/Shell/Shell.c:2732 > #10 0x000000007d4867c8 in DoShellPrompt () at > ShellPkg/Application/Shell/Shell.c:1349 > #11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898, > SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631 Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Marvin Häuser <Marvin.Haeuser@outlook.com> Cc: Qiu Shumin <shumin.qiu@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Marvin Häuser <Marvin.Haeuser@outlook.com> (cherry picked from commit 227fe49)
jiaxinwu
added a commit
to jiaxinwu/edk2
that referenced
this pull request
Nov 10, 2023
Root cause: 1. Before DisableReadonlyPageWriteProtect() is called, the return address (tianocore#1) is pushed in shadow stack. 2. CET is disabled. 3. DisableReadonlyPageWriteProtect() returns to tianocore#1. 4. Page table is modified. 5. EnableReadonlyPageWriteProtect() is called, but the return address (tianocore#2) is not pushed in shadow stack. 6. CET is enabled. 7. EnableReadonlyPageWriteProtect() returns to tianocore#2. #CP exception happens because the actual return address (tianocore#2) doesn't match the return address stored in shadow stack (tianocore#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 <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
mergify bot
pushed a commit
that referenced
this pull request
Nov 10, 2023
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 <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Flickdm
pushed a commit
to Flickdm/edk2
that referenced
this pull request
Jan 24, 2024
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534 Bug Details: PixieFail Bug tianocore#1 CVE-2023-45229 CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N CWE-125 Out-of-bounds Read Change Overview: Introduce Dhcp6SeekInnerOptionSafe which performs checks before seeking the Inner Option from a DHCP6 Option. > > EFI_STATUS > Dhcp6SeekInnerOptionSafe ( > IN UINT16 IaType, > IN UINT8 *Option, > IN UINT32 OptionLen, > OUT UINT8 **IaInnerOpt, > OUT UINT16 *IaInnerLen > ); > Lots of code cleanup to improve code readability. 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>
Flickdm
pushed a commit
to Flickdm/edk2
that referenced
this pull request
Jan 25, 2024
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534 Bug Details: PixieFail Bug tianocore#1 CVE-2023-45229 CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N CWE-125 Out-of-bounds Read Change Overview: Introduce Dhcp6SeekInnerOptionSafe which performs checks before seeking the Inner Option from a DHCP6 Option. > > EFI_STATUS > Dhcp6SeekInnerOptionSafe ( > IN UINT16 IaType, > IN UINT8 *Option, > IN UINT32 OptionLen, > OUT UINT8 **IaInnerOpt, > OUT UINT16 *IaInnerLen > ); > Lots of code cleanup to improve code readability. 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>
patchew-importer
pushed a commit
to patchew-project/edk2
that referenced
this pull request
Jan 25, 2024
--_000_MN6PR11MB82443B73244CEF84481629F08C7A2MN6PR11MB8244namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This mail is to bring another approach to solve the stack-overflow due to n= ested interrupts. Michael solved this problem in OVMF through NestedInterru= ptTplLib. I made a draft patch as attached "DxeCore.diff". The patch simply to avoid = the interrupt in enable state when TPL is dropped to the interrupted TPL. T= he interrupt will be enabled later through "IRET". So, a timer driver has two ways to implement its timer interrupt handler: 1. Do raise/restore TPL in the TimerInterruptHandler(). But call the A= PIs in NestedInterruptTplLib. 2. Do not raise/restore TPL in the TimerInterruptHandler(). So that on= ly DxeCore restores the TPL. And when DxeCore restores the TPL, the interru= pt is not enabled when TPL is dropped to the interrupted TPL (as it will be= enabled later by "IRET"). Implementing the logic in DxeCore does not prevent the TimerInterruptHandle= r() from implementing the way tianocore#1. Agree on the draft patch? My 2nd question is can we set a rule that TimerInterruptHandler() should NO= T restore TPL so that way tianocore#2 (changing DxeCore) is enough to solve the stac= k overflow issue due to nested interrupts. I was aware of the discussion between Laszlo and Michael in end of 2022 but= never dig deeply as today into this problem. I really appreciate the long discussion in the bugzilla (https://bugzilla.t= ianocore.org/show_bug.cgi?id=3D4162) and comments in NestedInterruptTplLib.= I learned a lot from them and they are quite interesting! Thanks, Ray -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114369): https://edk2.groups.io/g/devel/message/114369 Mute This Topic: https://groups.io/mt/103950154/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076= /xyzzy [importer@patchew.org] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:DengXian; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Aptos;} @font-face {font-family:DengXian; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ligatures:standardcontextual;} a:link, span.MsoHyperlink {mso-style-priority:99; color:#0563C1; text-decoration:underline;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin:0cm; text-indent:21.0pt; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ligatures:standardcontextual;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:11.0pt; font-family:"Calibri",sans-serif;} /* Page Definitions */ @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1439645819; mso-list-type:hybrid; mso-list-template-ids:-972123134 722654836 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:18.0pt; text-indent:-18.0pt;} @list l0:level2 {mso-level-number-format:alpha-lower; mso-level-text:"%2\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:44.0pt; text-indent:-22.0pt;} @list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:66.0pt; text-indent:-22.0pt;} @list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:88.0pt; text-indent:-22.0pt;} @list l0:level5 {mso-level-number-format:alpha-lower; mso-level-text:"%5\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:110.0pt; text-indent:-22.0pt;} @list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:132.0pt; text-indent:-22.0pt;} @list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; margin-left:154.0pt; text-indent:-22.0pt;} @list l0:level8 {mso-level-number-format:alpha-lower; mso-level-text:"%8\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:176.0pt; text-indent:-22.0pt;} @list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; margin-left:198.0pt; text-indent:-22.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> </head> <body lang="ZH-CN" link="#0563C1" vlink="#954F72" style="word-wrap:break-word;text-justify-trim:punctuation"> <div class="WordSection1"> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">All,<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">This mail is to bring another approach to solve the stack-overflow due to nested interrupts. Michael solved this problem in OVMF through NestedInterruptTplLib.<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">I made a draft patch as attached “DxeCore.diff”. The patch simply to avoid the interrupt in enable state when TPL is dropped to the interrupted TPL. The interrupt will be enabled later through “IRET”.<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">So, a timer driver has two ways to implement its timer interrupt handler:<o:p></o:p></span></p> <p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1"> <![if !supportLists]><span lang="EN-US" style="font-size:10.5pt"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang="EN-US" style="font-size:10.5pt">Do raise/restore TPL in the TimerInterruptHandler(). But call the APIs in NestedInterruptTplLib.<o:p></o:p></span></p> <p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1"> <![if !supportLists]><span lang="EN-US" style="font-size:10.5pt"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang="EN-US" style="font-size:10.5pt">Do not raise/restore TPL in the TimerInterruptHandler(). So that only DxeCore restores the TPL. And when DxeCore restores the TPL, the interrupt is not enabled when TPL is dropped to the interrupted TPL (as it will be enabled later by “IRET”).<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">Implementing the logic in DxeCore does not prevent the TimerInterruptHandler() from implementing the way tianocore#1.<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">Agree on the draft patch?<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">My 2<sup>nd</sup> question is can we set a rule that TimerInterruptHandler() should NOT restore TPL so that way tianocore#2 (changing DxeCore) is enough to solve the stack overflow issue due to nested interrupts.<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">I was aware of the discussion between Laszlo and Michael in end of 2022 but never dig deeply as today into this problem.<o:p></o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">I really appreciate the long discussion in the bugzilla (<a href="https://bugzilla.tianocore.org/show_bug.cgi?id=4162">https://bugzilla.tianocore.org/show_bug.cgi?id=4162</a>) and comments in NestedInterruptTplLib. I learned a lot from them and they are quite interesting!<o:p></o:p></span></p> <div> <p class="MsoNormal"><span lang="EN-US" style="font-family:"Aptos",sans-serif;color:black;mso-ligatures:none"><o:p> </o:p></span></p> <p class="MsoNormal"><span lang="EN-US" style="font-family:"Aptos",sans-serif;color:black;mso-ligatures:none">Thanks,<o:p></o:p></span></p> </div> <p class="MsoNormal"><span lang="EN-US" style="font-family:"Aptos",sans-serif;color:black;mso-ligatures:none">Ray</span><span lang="EN-US"><o:p></o:p></span></p> </div> </body> </html> <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links:<p> You receive all messages sent to this group. <p> <a target="_blank" href="https://edk2.groups.io/g/devel/message/114369">View/Reply Online (#114369)</a> | | <a target="_blank" href="https://groups.io/mt/103950154/1787277">Mute This Topic</a> | <a href="https://edk2.groups.io/g/devel/post">New Topic</a> <br> <a href="https://edk2.groups.io/g/devel/editsub/1787277">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy">Unsubscribe</a> [importer@patchew.org]<br> <div width="1" style="color:white;clear:both">_._,_._,_</div> Message-Id: <MN6PR11MB82443B73244CEF84481629F08C7A2@MN6PR11MB8244.namprd11.prod.outlook.com>
Flickdm
pushed a commit
to Flickdm/edk2
that referenced
this pull request
Jan 25, 2024
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534 Bug Details: PixieFail Bug tianocore#1 CVE-2023-45229 CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N CWE-125 Out-of-bounds Read Change Overview: Introduce Dhcp6SeekInnerOptionSafe which performs checks before seeking the Inner Option from a DHCP6 Option. > > EFI_STATUS > Dhcp6SeekInnerOptionSafe ( > IN UINT16 IaType, > IN UINT8 *Option, > IN UINT32 OptionLen, > OUT UINT8 **IaInnerOpt, > OUT UINT16 *IaInnerLen > ); > Lots of code cleanup to improve code readability. 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>
Flickdm
pushed a commit
to Flickdm/edk2
that referenced
this pull request
Jan 25, 2024
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534 Bug Details: PixieFail Bug tianocore#1 CVE-2023-45229 CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N CWE-125 Out-of-bounds Read Change Overview: Introduce Dhcp6SeekInnerOptionSafe which performs checks before seeking the Inner Option from a DHCP6 Option. > > EFI_STATUS > Dhcp6SeekInnerOptionSafe ( > IN UINT16 IaType, > IN UINT8 *Option, > IN UINT32 OptionLen, > OUT UINT8 **IaInnerOpt, > OUT UINT16 *IaInnerLen > ); > Lots of code cleanup to improve code readability. 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>
Flickdm
pushed a commit
to Flickdm/edk2
that referenced
this pull request
Jan 25, 2024
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534 Bug Details: PixieFail Bug tianocore#1 CVE-2023-45229 CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N CWE-125 Out-of-bounds Read Change Overview: Introduce Dhcp6SeekInnerOptionSafe which performs checks before seeking the Inner Option from a DHCP6 Option. > > EFI_STATUS > Dhcp6SeekInnerOptionSafe ( > IN UINT16 IaType, > IN UINT8 *Option, > IN UINT32 OptionLen, > OUT UINT8 **IaInnerOpt, > OUT UINT16 *IaInnerLen > ); > Lots of code cleanup to improve code readability. 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>
mergify bot
pushed a commit
that referenced
this pull request
Feb 6, 2024
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4534 Bug Details: PixieFail Bug #1 CVE-2023-45229 CVSS 6.5 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N CWE-125 Out-of-bounds Read Change Overview: Introduce Dhcp6SeekInnerOptionSafe which performs checks before seeking the Inner Option from a DHCP6 Option. > > EFI_STATUS > Dhcp6SeekInnerOptionSafe ( > IN UINT16 IaType, > IN UINT8 *Option, > IN UINT32 OptionLen, > OUT UINT8 **IaInnerOpt, > OUT UINT16 *IaInnerLen > ); > Lots of code cleanup to improve code readability. 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>
3 tasks
Merged
zer0def
pushed a commit
to zer0def/edk2
that referenced
this pull request
Jul 13, 2024
This could be a lot better, but it's good enough for writing a timer arch protocol that will use the HDEC. Fixes Issue tianocore#1. Introduces Issue tianocore#11 Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
3 tasks
mmisono
pushed a commit
to mmisono/edk2
that referenced
this pull request
Aug 30, 2024
Root cause: 1. Before DisableReadonlyPageWriteProtect() is called, the return address (tianocore#1) is pushed in shadow stack. 2. CET is disabled. 3. DisableReadonlyPageWriteProtect() returns to tianocore#1. 4. Page table is modified. 5. EnableReadonlyPageWriteProtect() is called, but the return address (tianocore#2) is not pushed in shadow stack. 6. CET is enabled. 7. EnableReadonlyPageWriteProtect() returns to tianocore#2. #CP exception happens because the actual return address (tianocore#2) doesn't match the return address stored in shadow stack (tianocore#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 <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
3 tasks
kraxel
added a commit
to kraxel/edk2
that referenced
this pull request
Sep 10, 2024
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
jiaxinwu
added a commit
to jiaxinwu/edk2
that referenced
this pull request
Oct 12, 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 tianocore#1 and tianocore#2 are additional requirements if the MmCpuSyncModeTradition mode is selected. Steps tianocore#1, tianocore#2, tianocore#3, tianocore#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 <jiaxin.wu@intel.com>
jiaxinwu
added a commit
to jiaxinwu/edk2
that referenced
this pull request
Oct 12, 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 tianocore#1 and tianocore#2 are additional requirements if the MmCpuSyncModeTradition mode is selected. Steps tianocore#1, tianocore#2, tianocore#3, tianocore#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 <jiaxin.wu@intel.com>
jiaxinwu
added a commit
to jiaxinwu/edk2
that referenced
this pull request
Oct 12, 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 tianocore#1 is additional requirements if the MmCpuSyncModeTradition mode is selected. Steps tianocore#1, tianocore#2, tianocore#3, tianocore#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 <jiaxin.wu@intel.com>
jiaxinwu
added a commit
to jiaxinwu/edk2
that referenced
this pull request
Oct 12, 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 tianocore#1 and tianocore#2 are additional requirements if the MmCpuSyncModeTradition mode is selected. Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
jiaxinwu
added a commit
to jiaxinwu/edk2
that referenced
this pull request
Oct 12, 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 tianocore#1 is additional requirements if the MmCpuSyncModeTradition mode is selected. Steps tianocore#1, tianocore#2, tianocore#3, tianocore#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 <jiaxin.wu@intel.com>
jiaxinwu
added a commit
to jiaxinwu/edk2
that referenced
this pull request
Oct 12, 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 tianocore#1 and tianocore#2 are additional requirements if the MmCpuSyncModeTradition mode is selected. Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
mergify bot
pushed a commit
that referenced
this pull request
Oct 12, 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>
mergify bot
pushed a commit
that referenced
this pull request
Oct 12, 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 #1 and #2 are additional requirements if the MmCpuSyncModeTradition mode is selected. Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
ishih1
pushed a commit
to ishih1/edk2
that referenced
this pull request
Nov 11, 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 tianocore#1 is additional requirements if the MmCpuSyncModeTradition mode is selected. Steps tianocore#1, tianocore#2, tianocore#3, tianocore#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 <jiaxin.wu@intel.com>
ishih1
pushed a commit
to ishih1/edk2
that referenced
this pull request
Nov 11, 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 tianocore#1 and tianocore#2 are additional requirements if the MmCpuSyncModeTradition mode is selected. 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
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.
Xen ACPI tables support in OVMF. Code files modified are :
AcpiPlatformDxe/AcpiPlatform.c
AcpiPlatformDxe/Xen.c