Create SamplePrReview.txt #2

svenur · 2020-02-13T01:13:17Z

Hi Mike
I would like to contribute to your sandbox branch.
Thanks
Sumana

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

Signed-off-by: Michael D Kinney <[email protected]>

The AP vector consists of 2 parts: 1. the initial 16-bit code that should be under 1MB and page aligned. 2. the 32-bit/64-bit code that can be anywhere in the memory with any alignment. The need of part #2 is because the memory under 1MB is temporary "stolen" for use and will "give" back after all AP wake up. The range of memory is not marked as code page in page table. CPU may trigger exception as soon as NX is enabled. The part #2 memory allocation can be done in the MpInitLibInitialize. Signed-off-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 #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]>

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

Create SamplePrReview.txt

39c90a1

svenur closed this Feb 13, 2020

svenur deleted the CreatingSamplePrReview branch February 13, 2020 02:00

mdkinney added a commit that referenced this pull request Nov 13, 2021

Uncrustify Pass #2

657c743

Signed-off-by: Michael D Kinney <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create SamplePrReview.txt #2

Create SamplePrReview.txt #2

svenur commented Feb 13, 2020

Create SamplePrReview.txt #2

Create SamplePrReview.txt #2

Conversation

svenur commented Feb 13, 2020