BaseTools/Source/C/GNUmakefile: Added a condition for handling invalid A... #2

mjwade · 2014-03-01T01:27:06Z

BaseTools/Source/C/GNUmakefile: Added a condition for handling invalid ARCH values.

If a user has ARCH already set to x86_64, then the makefile would fail. In the new code, a check is inserted to ensure that ARCH is set to X64 or IA32. If it's not, then notify the user of the problem detected and exit.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mike Wade [email protected]

…d ARCH values. If a user has ARCH already set to x86_64, then the makefile would fail. In the new code, a check is inserted to ensure that ARCH is set to X64 or IA32. If it's not, then notify the user of the problem detected and exit. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Mike Wade <[email protected]>

… 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 <[email protected]> Reviewed-by: Gao, Liming <[email protected]> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15722 6f19259b-4bc3-4df7-8a09-765794883524

Hikey: boot linux in UEFI mode

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 <[email protected]> Reviewed-by: Liming Gao <[email protected]> Reviewed-by: Laszlo Ersek <[email protected]> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17902 6f19259b-4bc3-4df7-8a09-765794883524

jljusten · 2015-07-26T00:32:21Z

I think if ARCH is set to x86_64 or amd64, we can re-export it as X64 for the BaseTools build.

The lines on your commit message are too long:
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

Can you review BaseTools/Contributions.txt and post your patch to edk2-devel? (We can't use pull requests at this time.)

Before the merger of the authenticated and non-authenticated variable drivers (commit fa0737a), we had to match the varstore header GUID in "OvmfPkg/VarStore.fdf.inc" to SECURE_BOOT_ENABLE, because the opposite GUID would cause either driver to fail an assertion. The header structures for individual variables residing in the varstore were different (VARIABLE_HEADER vs. AUTHENTICATED_VARIABLE_HEADER), and each driver could only handle its own, so this GUID enforcement was necessary. Since the unification of the variable driver however, it treats (a) variable store format, and (b) AuthVariableLib instance as independent characteristics; it can always manipulate variable stores with both header types. All variations boot now; the difference is whether authenticated variables, and special variables computed from them (like SecureBoot) are supported at runtime: variable store non-auth auth and SB header GUID AuthVariableLib variables variables -- --------------------- ------------------- -> --------- ----------- 1 Variable SecurityPkg/... supported unsupported 2 Variable AuthVariableLibNull supported unsupported 3 AuthenticatedVariable SecurityPkg/... supported supported 4 AuthenticatedVariable AuthVariableLibNull supported unsupported At the moment, SECURE_BOOT_ENABLE selects between cases #2 (FALSE) and #3 (TRUE). That is, it controls both the varstore header GUID in "OvmfPkg/VarStore.fdf.inc", and the AuthVariableLib resolution in the DSC files. Exploiting the unified driver's flexibility, we can simplify "OvmfPkg/VarStore.fdf.inc" by picking the AuthenticatedVariable GUID as a constant, and letting SECURE_BOOT_ENABLE control only the AuthVariableLib resolution. This amounts to SECURE_BOOT_ENABLE choosing between cases #3 (TRUE) and #4 (FALSE), with identical results as before. Cc: Jordan Justen <[email protected]> Cc: Star Zeng <[email protected]> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/7319/focus=7344 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Star Zeng <[email protected]>

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 <[email protected]> Cc: Ye Ting <[email protected]> Cc: Fu Siyuan <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <[email protected]> Tested-by: Eugene Cohen <[email protected]> Reviewed-by: Ye Ting <[email protected]>

*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 <[email protected]> Cc: Fu Siyuan <[email protected]> Cc: Zhang Lubo <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <[email protected]> Reviewed-by: Ye Ting <[email protected]>

Fix two bugs: - Erroneous shift of 2 in a bytes to bits conversion. - Use reverse subtract rather than negate for value that is subsequently used as operand #2 in a shift operation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-by: Liming Gao <[email protected]>

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 <[email protected]> Cc: Marvin Häuser <[email protected]> Cc: Qiu Shumin <[email protected]> Cc: Ruiyu Ni <[email protected]> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <[email protected]>

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 <[email protected]> Cc: Marvin Häuser <[email protected]> Cc: Qiu Shumin <[email protected]> Cc: Ruiyu Ni <[email protected]> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <[email protected]> Reviewed-by: Jaben Carsey <[email protected]> Reviewed-by: Marvin Häuser <[email protected]>

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 <[email protected]> Cc: Marvin Häuser <[email protected]> Cc: Qiu Shumin <[email protected]> Cc: Ruiyu Ni <[email protected]> Fixes: bd3fc81 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <[email protected]> Reviewed-by: Jaben Carsey <[email protected]> Reviewed-by: Marvin Häuser <[email protected]> (cherry picked from commit 227fe49)

…operation The current implementation was making assumption that AllocateBuffer() returns a buffer with C-bit cleared. Hence when we were asked to Map() with BusMasterCommonBuffer, we do not change the C-bit on host buffer. In previous patch, we changed the AllocateBuffer() to not clear C-bit during allocation. The patch adds support for handling the BusMasterCommonBuffer operations when SEV is active. A typical DMA Bus master Common Operation follows the below step: 1. Client calls AllocateBuffer() to allocate a common buffer 2. Client fill some data in common buffer (optional) 3. Client calls Map() with BusMasterCommonBuffer 4. Programs the DMA bus master with the device address returned by Map() 5. The common buffer can now be accessed equally by the processor and the DMA bus master. 6. Client calls Unmap() 7. Client calls FreeBuffer() In order to handle steps tianocore#2 (in which common buffer may contain data), we perform in-place encryption to ensure that device address returned by the Map() contains the correct data after we clear the C-bit during Map(). In my measurement I do not see any noticable perform degradation when performing in-place encryption/decryption on common buffer. Suggested-by: Laszlo Ersek <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <[email protected]> Cc: Jordan Justen <[email protected]> Signed-off-by: Brijesh Singh <[email protected]>

As part of commit 5f82e02, ActiveRecordInDb was introduced as a copy of RecordInDb as latter may be freed by the callback function. This commit replaces an access of RecordInDb after the callback function has been executed with an access to ActiveRecordInDb. Cc: Michael D Kinney <[email protected]> Cc: Kelly Steele <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser <[email protected]> Reviewed-by: Michael D Kinney <[email protected]>

The new algorithm converts the problem calculating optimal MTRR settings (using least MTRR registers) to the problem finding the shortest path in a graph. The memory required in extreme but rare case can be up to 256KB, so using local stack buffer is impossible considering current DxeIpl only allocates 128KB stack. The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and MtrrSetMemoryAttribute() to use the 4-page stack buffer for calculation. The two APIs return BUFFER_TOO_SMALL when the buffer is too small for calculation. The patch adds a new API MtrrSetMemoryAttribute*s*InMtrrSettings() to set multiple-range attributes in one function call. Since every call to MtrrSetMemoryAttributeInMtrrSettings (without-s) or MtrrSetMemoryAttribute() requires to calculate the MTRRs for the whole physical memory, combining multiple calls in one API can significantly reduce the calculation time. In theory, if N times of call to without-s API costs N seconds, the new API only costs 1 second. The new API uses the buffer supplied from caller to calculate MTRRs and returns BUFFER_TOO_SMALL when the buffer is too small for calculation. Test performed: 1. Random test a. Generate random memory settings, use the new algorithm to calculate the MTRRs. b. Read back the MTRRs and check the memory settings match the desired memory settings. c. Repeat the above #1 and #2 100000 times. 2. OVMF 32PEI + 64DXE boot to shell. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <[email protected]> Cc: Michael D Kinney <[email protected]> Cc: Eric Dong <[email protected]> Reviewed-by: Jiewen Yao <[email protected]>

PerformancePkg contains following components: 1. TscTimerLib 2. Dp_App 3. Header files. #1 has already been deprecated. #2 can be removed because DpApp was added to ShellPkg. #3 Header files are not used by DpApp and MdeModulePkg/PerformanceLib instances. In summary, this package is no longer useful. All related platforms have been updated to remove the references. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <[email protected]> Cc: Jaben Carsey <[email protected]> Cc: Daryl McDaniel <[email protected]> Reviewed-by: Jaben Carsey <[email protected]>

v2: * Refine the commit log. There are two place to close the ISCSI ExitBootServiceEvent: #1.IScsiOnExitBootService(), which is the callback function of ExitBootServiceEvent. #2.IScsiCleanDriverData(), which will be invoked by ISCSI driver binding stop(). So, the ExitBootServiceEvent will be closed and freed when exit boot server is triggered. But it may be closed and freed again in ISCSI driver binding stop(), which will result in the issue recorded at https://bugzilla.tianocore.org/show_bug.cgi?id=742. This patch is to resolve the issue. Cc: Ye Ting <[email protected]> Cc: Fu Siyuan <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <[email protected]> Reviewed-by: Fu Siyuan <[email protected]>

v2: * Refine the commit log. There are two place to close the ISCSI ExitBootServiceEvent: #1.IScsiOnExitBootService(), which is the callback function of ExitBootServiceEvent. #2.IScsiCleanDriverData(), which will be invoked by ISCSI driver binding stop(). So, the ExitBootServiceEvent will be closed and freed when exit boot server is triggered. But it may be closed and freed again in ISCSI driver binding stop(), which will result in the issue recorded at https://bugzilla.tianocore.org/show_bug.cgi?id=742. This patch is to resolve the issue. Cc: Ye Ting <[email protected]> Cc: Fu Siyuan <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <[email protected]> Reviewed-by: Fu Siyuan <[email protected]> (cherry picked from commit d321598)

v2: * Refine the commit log. There are two place to close the ISCSI ExitBootServiceEvent: #1.IScsiOnExitBootService(), which is the callback function of ExitBootServiceEvent. #2.IScsiCleanDriverData(), which will be invoked by ISCSI driver binding stop(). So, the ExitBootServiceEvent will be closed and freed when exit boot server is triggered. But it may be closed and freed again in ISCSI driver binding stop(), which will result in the issue recorded at https://bugzilla.tianocore.org/show_bug.cgi?id=742. This patch is to resolve the issue. Cc: Ye Ting <[email protected]> Cc: Fu Siyuan <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <[email protected]> Reviewed-by: Fu Siyuan <[email protected]> (cherry picked from commit a37c60b)

1) Add a new file Common/caching.py a. Allows for automated caching of repeated class functions, class properties, and non-class functions b. When called the first time the value is cached and if called a second time, the cached result is called, not the function. c. When used, this saves lots of memory since the actual function pointers are replaced with smaller data elements. d. note that not all features are used yet. 2) Fix AutoGen/GenMake and AutoGen/GetC to not call into private member variables of ModuleAutoGen class a. use the existing accessor properties for the data 3) Change AutoGen classes to remove a exception for duplicate members in __new__ and use ?in? testing to speed up 4) Work on ModuleAutoGen class a. Change all properties that use caching to use @caching_property (see #1 above) b. Change all properties that do not use caching to use standard python decorator "@Property" c. Change all cases where a dictionary/set/list/object was created and then immediately updated to use constructor parameters d. Refactor each property function to remove the internal variable that is no longer needed (this helps find items like #2 above) e. Refactor _ApplyBuildRule with optional parameter to work around circular dependency with BinaryFileList. Note that 4e was almost certainly unintended as the functions were acting on incomplete information since they were directly accessing private instance variables at the same time another function on the stack was creating the same private isntance data. This overall changes behavior slightly, but makes the codebase smaller and easier to read. Cc: Liming Gao <[email protected]> Cc: Yonghong Zhu <[email protected]> Cc: Bob Feng <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jaben Carsey <[email protected]> Reviewed-by: Yonghong Zhu <[email protected]>

> v3 changes: > a. split from tianocore#2 patch of v2 > b. refine the commit message > c. refine the title Non-stop mode was introduced / explained in commit 8f26136 ("MdeModulePkg/MdeModulePkg.dec: add new settings for PCDs", 2018-08-30). The macro HEAP_GUARD_NONSTOP_MODE was added to CpuDxe in commit dcc0262 ("UefiCpuPkg/CpuDxe: implement non-stop mode for uefi", 2018-08-30). Another instance of the macro HEAP_GUARD_NONSTOP_MODE was added to PiSmmCpuDxeSmm -- with BIT1|BIT0 replaced with BIT3|BIT2 -- in commit 09afd9a ("UefiCpuPkg/PiSmmCpuDxeSmm: implement non-stop mode for SMM", 2018-08-30) Since the freed-memory guard is for UEFI-only. This patch only updates HEAP_GUARD_NONSTOP_MODE in "UefiCpuPkg/CpuDxe/CpuDxe.h" (add BIT4). Cc: Laszlo Ersek <[email protected]> Cc: Star Zeng <[email protected]> Cc: Michael D Kinney <[email protected]> Cc: Jiewen Yao <[email protected]> Cc: Ruiyu Ni <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <[email protected]>

> v3 changes: > a. split from tianocore#2 patch > b. refine the commit message and title > c. remove "else" branch The freed-memory guard feature will cause an recursive calling of InitializePageTablePool(). This is due to a fact that AllocateAlignedPages() is used to allocate page table pool memory. This function will most likely call gBS->FreePages to free unaligned pages and then cause another round of page attributes change, like below (freed pages will be always marked not-present if freed-memory guard is enabled) FreePages() <===============| => CpuSetMemoryAttributes() | => <if out of page table> | => InitializePageTablePool() | => AllocateAlignedPages() | => FreePages() ================| The solution is add a global variable as a lock in page table pool allocation function and fail any other requests if it has not been done. Since this issue will only happen if free-memory guard is enabled, it won't affect CpuSetMemoryAttributes() in default build of a BIOS. If free-memory guard is enabled, it only affect the pages (failed to mark them as not-present) freed in AllocateAlignedPages(). Since those freed pages haven't been used yet (their addresses not yet exposed to code outside AllocateAlignedPages), it won't compromise the freed-memory guard feature. This change will just fail the CpuSetMemoryAttributes() called from FreePages() but it won't fail the FreePages(). So the error status won't be propagated upper layer of code. Cc: Laszlo Ersek <[email protected]> Cc: Star Zeng <[email protected]> Cc: Michael D Kinney <[email protected]> Cc: Jiewen Yao <[email protected]> Cc: Ruiyu Ni <[email protected]> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <[email protected]>

MpInitLib sets X2ApicEnable in two places. 1. CollectProcessorCount() This function is called when MpInitLibInitialize() hasn't been called before. It sets X2ApicEnable and later in the same function it configures all CPUs to operate in X2 APIC mode. 2. MpInitLibInitialize() The X2ApicEnable setting happens when this function is called in second time. But after that setting, no code consumes that flag. With the above analysis and with the purpose of simplifying the code, the X2ApicEnable in #1 is changed to local variable and the #2 can be changed to remove the setting of X2ApicEnable. Signed-off-by: Ray Ni <[email protected]> Reviewed-by: Eric Dong <[email protected]> Reviewed-by: Laszlo Ersek <[email protected]>

* Rip out hack-around for old broken behavior This hack effectively limits the guest to one device path lookup at a time, always returning the same address- presumably for the mentioned damage control on older FreeBSD fixed in r285246. Rip out now- it's quite limiting and not great behavior. * Also remove DEBUG() mentioning that we're overriding HandleProtocol

MpInitLib contains a function MicrocodeDetect() which is called by all threads as an AP procedure. Today this function contains below code: if (CurrentRevision != LatestRevision) { AcquireSpinLock(&CpuMpData->MpLock); DEBUG (( EFI_D_ERROR, "Updated microcode signature [0x%08x] does not match \ loaded microcode signature [0x%08x]\n", CurrentRevision, LatestRevision )); ReleaseSpinLock(&CpuMpData->MpLock); } When the if-check is passed, the code may call into PEI services: 1. AcquireSpinLock When the PcdSpinTimeout is not 0, TimerLib GetPerformanceCounterProperties() is called. And some of the TimerLib implementations would get the information cached in HOB. But AP procedure cannot call PEI services to retrieve the HOB list. 2. DEBUG Certain DebugLib relies on ReportStatusCode services and the ReportStatusCode PPI is retrieved through the PEI services. DebugLibSerialPort should be used. But when SerialPortLib is implemented to depend on PEI services, even using DebugLibSerialPort can still cause AP calls PEI services resulting hang. It causes a lot of debugging effort on the platform side. There are 2 options to fix the problem: 1. make sure platform DSC chooses the proper DebugLib and set the PcdSpinTimeout to 0. So that AcquireSpinLock and DEBUG don't call PEI services. 2. remove the AcquireSpinLock and DEBUG call from the procedure. Option #2 is preferred because it's not practical to ask every platform DSC to be written properly. Following option #2, there are two sub-options: 2.A. Just remove the if-check. 2.B. Capture the CurrentRevision and ExpectedRevision in the memory for each AP and print them together from BSP. The patch follows option 2.B. Signed-off-by: Ray Ni <[email protected]> Reviewed-by: Eric Dong <[email protected]> Acked-by: Laszlo Ersek <[email protected]> Cc: Rahul Kumar <[email protected]>

## Description Ensures LIBRARY_CLASS as specified in the library override INF defines section is the same value as the library class specified in the override line. ## Example of mismatch ``` cmd ERROR - EDK2 tianocore#2 from c:\src\mu_tiano_platforms\Platforms\QemuQ35Pkg\QemuQ35Pkg.dsc(...): LIBRARY_CLASS for override: [c:\src\mu_tiano_platforms\MU_BASECORE\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf] does not match the library class being overridden: [DevicePathLib] ``` closes tianocore#314 For each item, place an "x" in between `[` and `]` if true. Example: `[x]`. _(you can also check items in the GitHub UI)_ - [ ] Impacts functionality? - **Functionality** - Does the change ultimately impact how firmware functions? - Examples: Add a new library, publish a new PPI, update an algorithm, ... - [ ] Impacts security? - **Security** - Does the change have a direct security impact on an application, flow, or firmware? - Examples: Crypto algorithm change, buffer overflow fix, parameter validation improvement, ... - [] Breaking change? - **Breaking change** - Will anyone consuming this change experience a break in build or boot behavior? - Examples: Add a new library class, move a module to a different repo, call a function in a new library class in a pre-existing module, ... - [ ] Includes tests? - **Tests** - Does the change include any explicit test code? - Examples: Unit tests, integration tests, robot tests, ... - [ ] Includes documentation? - **Documentation** - Does the change contain explicit documentation additions outside direct code modifications (and comments)? - Examples: Update readme file, add feature readme file, link to documentation on an a separate Web page, ... ## How This Was Tested Ensured mismatched library override was caught, and INF's with multiple LIBRARY_CLASS definitions will not raise an error if one of the definitions matches. ## Integration Instructions N/A

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 <[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]>

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 <[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]>

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 <[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]>

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]>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535 Bug Details: "PixieFail Bug tianocore#2" CVE-2023-45230 CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer Changes Overview: > -UINT8 * > +EFI_STATUS > Dhcp6AppendOption ( > - IN OUT UINT8 *Buf, > - IN UINT16 OptType, > - IN UINT16 OptLen, > - IN UINT8 *Data > + IN OUT EFI_DHCP6_PACKET *Packet, > + IN OUT UINT8 **PacketCursor, > + IN UINT16 OptType, > + IN UINT16 OptLen, > + IN UINT8 *Data > ); Dhcp6AppendOption() and variants can return errors now. All callsites are adapted accordingly. It gets passed in EFI_DHCP6_PACKET as additional parameter ... > + // > + // Verify the PacketCursor is within the packet > + // > + if ( (*PacketCursor < Packet->Dhcp6.Option) > + || (*PacketCursor >= Packet->Dhcp6.Option + (Packet->Size - sizeof (EFI_DHCP6_HEADER)))) > + { > + return EFI_INVALID_PARAMETER; > + } ... so it can look at Packet->Size when checking buffer space. Also to allow Packet->Length updates. Lots of checks added. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535 Bug Details: PixieFail Bug tianocore#2 CVE-2023-45230 CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer Changes Overview: > -UINT8 * > +EFI_STATUS > Dhcp6AppendOption ( > - IN OUT UINT8 *Buf, > - IN UINT16 OptType, > - IN UINT16 OptLen, > - IN UINT8 *Data > + IN OUT EFI_DHCP6_PACKET *Packet, > + IN OUT UINT8 **PacketCursor, > + IN UINT16 OptType, > + IN UINT16 OptLen, > + IN UINT8 *Data > ); Dhcp6AppendOption() and variants can return errors now. All callsites are adapted accordingly. It gets passed in EFI_DHCP6_PACKET as additional parameter ... > + // > + // Verify the PacketCursor is within the packet > + // > + if ( (*PacketCursor < Packet->Dhcp6.Option) > + || (*PacketCursor >= Packet->Dhcp6.Option + (Packet->Size - sizeof (EFI_DHCP6_HEADER)))) > + { > + return EFI_INVALID_PARAMETER; > + } ... so it can look at Packet->Size when checking buffer space. Also to allow Packet->Length updates. Lots of checks added. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]>

@font-face

--_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: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076= /xyzzy [[email protected]] -=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></style> </head> <body lang="ZH-CN" link="#0563C1" vlink="#954F72" style="word-wrap:break-word;text-justify-trim:punctuation"> <div class="WordSection1"> All,<o:p></o:p> 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> <o:p> </o:p> 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> <o:p> </o:p> So, a timer driver has two ways to implement its timer interrupt handler:<o:p></o:p> <![if !supportLists]>1.      <![endif]>Do raise/restore TPL in the TimerInterruptHandler(). But call the APIs in NestedInterruptTplLib.<o:p></o:p> <![if !supportLists]>2.      <![endif]>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> <o:p> </o:p> <o:p> </o:p> Implementing the logic in DxeCore does not prevent the TimerInterruptHandler() from implementing the way tianocore#1.<o:p></o:p> Agree on the draft patch?<o:p></o:p> <o:p> </o:p> My 2nd 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> <o:p> </o:p> 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> 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> <div> <o:p> </o:p> Thanks,<o:p></o:p> </div> Ray<o:p></o:p> </div> </body> </html> <div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links: You receive all messages sent to this group. <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> <a href="https://edk2.groups.io/g/devel/editsub/1787277">Your Subscription</a> | <a href="mailto:[email protected]">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy">Unsubscribe</a> [[email protected]] <div width="1" style="color:white;clear:both">_._,_._,_</div> Message-Id: <MN6PR11MB82443B73244CEF84481629F08C7A2@MN6PR11MB8244.namprd11.prod.outlook.com>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535 Bug Details: PixieFail Bug #2 CVE-2023-45230 CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer Changes Overview: > -UINT8 * > +EFI_STATUS > Dhcp6AppendOption ( > - IN OUT UINT8 *Buf, > - IN UINT16 OptType, > - IN UINT16 OptLen, > - IN UINT8 *Data > + IN OUT EFI_DHCP6_PACKET *Packet, > + IN OUT UINT8 **PacketCursor, > + IN UINT16 OptType, > + IN UINT16 OptLen, > + IN UINT8 *Data > ); Dhcp6AppendOption() and variants can return errors now. All callsites are adapted accordingly. It gets passed in EFI_DHCP6_PACKET as additional parameter ... > + // > + // Verify the PacketCursor is within the packet > + // > + if ( (*PacketCursor < Packet->Dhcp6.Option) > + || (*PacketCursor >= Packet->Dhcp6.Option + (Packet->Size - sizeof (EFI_DHCP6_HEADER)))) > + { > + return EFI_INVALID_PARAMETER; > + } ... so it can look at Packet->Size when checking buffer space. Also to allow Packet->Length updates. Lots of checks added. Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]> Reviewed-by: Saloni Kasbekar <[email protected]>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4535 Bug Details: PixieFail Bug tianocore#2 CVE-2023-45230 CVSS 8.3 : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer Changes Overview: > -UINT8 * > +EFI_STATUS > Dhcp6AppendOption ( > - IN OUT UINT8 *Buf, > - IN UINT16 OptType, > - IN UINT16 OptLen, > - IN UINT8 *Data > + IN OUT EFI_DHCP6_PACKET *Packet, > + IN OUT UINT8 **PacketCursor, > + IN UINT16 OptType, > + IN UINT16 OptLen, > + IN UINT8 *Data > ); Dhcp6AppendOption() and variants can return errors now. All callsites are adapted accordingly. It gets passed in EFI_DHCP6_PACKET as additional parameter ... > + // > + // Verify the PacketCursor is within the packet > + // > + if ( (*PacketCursor < Packet->Dhcp6.Option) > + || (*PacketCursor >= Packet->Dhcp6.Option + (Packet->Size - sizeof (EFI_DHCP6_HEADER)))) > + { > + return EFI_INVALID_PARAMETER; > + } ... so it can look at Packet->Size when checking buffer space. Also to allow Packet->Length updates. Lots of checks added. Bug 4457168 Cc: Saloni Kasbekar <[email protected]> Cc: Zachary Clark-williams <[email protected]> Signed-off-by: Doug Flick [MSFT] <[email protected]> Reviewed-by: Saloni Kasbekar <[email protected]> Change-Id: Icd0135ce27dabed9e426dac845d9ef9f66bb5b56 Reviewed-on: https://git-master.nvidia.com/r/c/3rdparty/edk2/+/3073479 Reviewed-by: svcacv <[email protected]> Reviewed-by: svc-sw-mobile-l4t <[email protected]> Reviewed-by: Jeff Brasen <[email protected]> GVS: Gerrit_Virtual_Submit <[email protected]> Tested-by: Jeff Brasen <[email protected]>

- working HDEC-based TimerDxe - TB-based TimerLib - Shell needed the unicode collation driver. - set correct PcdShellFile to have the shell be recognised by BDS - TB frequency set in Ipl today through the Pcr, at some point this should be set through a PCD by a FDT-parsing DXE. Fixes issue tianocore#2 Closes Milestone UEFI Shell Boot Signed-off-by: Andrei Warkentin <[email protected]>

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 <[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]>

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 <[email protected]>

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 <[email protected]>

… 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 <[email protected]>

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 <[email protected]>

… 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 <[email protected]>

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 <[email protected]>

… 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 <[email protected]>

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 <[email protected]>

… 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 <[email protected]>

vchong pushed a commit to linaro-swg/edk2 that referenced this pull request Jun 9, 2015

Merge pull request tianocore#2 from koenkooi/hikey-efi-mode

eccdd98

Hikey: boot linux in UEFI mode

jljusten closed this Jul 26, 2015

ZhichaoGao mentioned this pull request Aug 13, 2020

MdeModulePkg/PartitionDxe: Make the parition driver match the spec #874

Merged

niruiyu mentioned this pull request Mar 17, 2021

UefiCpuPkg/MpInitLib: avoid printing debug messages in AP #1498

Merged

jyao1 mentioned this pull request Apr 26, 2023

Fixes for SEV-SNP CC blob and CPUID table handling #4313

Merged

jiaxinwu mentioned this pull request Nov 10, 2023

Fix CP Exception when CET enable #4867

Merged

mdkinney mentioned this pull request Feb 14, 2024

Bug 4683 unit test unexpected exception may be seen as PASS condition #5345

Merged

shenbagadevir mentioned this pull request May 6, 2024

ShellPkg: Changes to print Type17 in Smbiosview #5620

Merged

kraxel mentioned this pull request Jun 13, 2024

AMD SEV Debugswap #5594

Merged

kraxel mentioned this pull request Sep 2, 2024

OvmfPkg: Use TdHob instead of e820tables to get memory info in TDVF #6114

Merged

3 tasks

niruiyu mentioned this pull request Oct 10, 2024

Smmcpu platform hook Before MMI Handler #6183

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

BaseTools/Source/C/GNUmakefile: Added a condition for handling invalid A... #2

BaseTools/Source/C/GNUmakefile: Added a condition for handling invalid A... #2

mjwade commented Mar 1, 2014

jljusten commented Jul 26, 2015

BaseTools/Source/C/GNUmakefile: Added a condition for handling invalid A... #2

BaseTools/Source/C/GNUmakefile: Added a condition for handling invalid A... #2

Conversation

mjwade commented Mar 1, 2014

jljusten commented Jul 26, 2015