Skip to content
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
wants to merge 7 commits into from

Conversation

GavinGuan
Copy link

Xen ACPI tables support in OVMF. Code files modified are :
AcpiPlatformDxe/AcpiPlatform.c
AcpiPlatformDxe/Xen.c

@jljusten
Copy link
Member

This was committed in svn

@jljusten jljusten closed this Aug 28, 2012
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>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt">I made a draft patch as attached &#8220;DxeCore.diff&#8221;. 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
 &#8220;IRET&#8221;.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p>&nbsp;</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 &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</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 &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</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 &#8220;IRET&#8221;).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt"><o:p>&nbsp;</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>&nbsp;</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>&nbsp;</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:&quot;Aptos&quot;,sans-serif;color:black;mso-ligatures:none"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:&quot;Aptos&quot;,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:&quot;Aptos&quot;,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>
@tlendacky tlendacky mentioned this pull request Jun 2, 2024
3 tasks
@kraxel kraxel mentioned this pull request Jun 13, 2024
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>
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>
kraxel added a commit to kraxel/edk2 that referenced this pull request Sep 10, 2024
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
@kraxel kraxel mentioned this pull request Sep 10, 2024
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants