public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Wang, Jian J" <jian.j.wang@intel.com>
To: "Zeng, Star" <star.zeng@intel.com>,
	Laszlo Ersek <lersek@redhat.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Ni, Ruiyu" <ruiyu.ni@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>
Subject: Re: [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs
Date: Wed, 19 Sep 2018 09:13:41 +0000	[thread overview]
Message-ID: <D827630B58408649ACB04F44C510003624E36A40@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103BBBAFDA@shsmsx102.ccr.corp.intel.com>

If no more new comments, I'll do following changes in v2, including review
comments got so far:

a. change ToEnableExecuteDisableFeature() to EnableNonExec()
b. remove the ASSERT and DEBUG in current ToEnableExecuteDisableFeature()
c. update dec/uni file to clarify the usage of following PCDs
    PcdNxSetForStack
        TRUE  - Apply NX to stack memory
        FALSE - Don't care of protection of stack memory
    PcdImageProtectionPolicy
         1 - Apply NX to data section of image from the corresponding origin
         0 - Don't care of the protection of data section of image from the corresponding origin
    PcdDxeNxMemoryProtectionPolicy
         1 - Apply NX to corresponding type of memory
         0 - Don't care of the protection of corresponding type of memory

Regards,
Jian


> -----Original Message-----
> From: Zeng, Star
> Sent: Tuesday, September 18, 2018 4:47 PM
> To: Wang, Jian J <jian.j.wang@intel.com>; Laszlo Ersek <lersek@redhat.com>;
> edk2-devel@lists.01.org
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Ni, Ruiyu <ruiyu.ni@intel.com>;
> Yao, Jiewen <jiewen.yao@intel.com>; Zeng, Star <star.zeng@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs
> 
> I totally agree adding more clear documentation in dec and uni.
> My only concern is that the warning message (by checking the combinations) to
> explain in c may bring more confusion.
> Anyway, if we can have the warning message to make the things more clear, I
> definitely agree it. :)
> 
> 
> Thanks,
> Star
> -----Original Message-----
> From: Wang, Jian J
> Sent: Tuesday, September 18, 2018 9:22 AM
> To: Laszlo Ersek <lersek@redhat.com>; Zeng, Star <star.zeng@intel.com>; edk2-
> devel@lists.01.org
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Ni, Ruiyu <ruiyu.ni@intel.com>;
> Yao, Jiewen <jiewen.yao@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs
> 
> I have no strong opinion for this proposal. But if we decide to do it finally, I'd
> suggest to add some warning messages for any probably surprising setting
> combinations.
> 
> Regards,
> Jian
> 
> 
> > -----Original Message-----
> > From: Laszlo Ersek [mailto:lersek@redhat.com]
> > Sent: Monday, September 17, 2018 6:14 PM
> > To: Zeng, Star <star.zeng@intel.com>; Wang, Jian J
> > <jian.j.wang@intel.com>; edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Ni, Ruiyu
> > <ruiyu.ni@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> > Subject: Re: [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs
> >
> > On 09/17/18 07:57, Zeng, Star wrote:
> > > How about we see the problem in another way?
> > >
> > > If my understanding is correct, current discussion and patches think
> > > FALSE/0
> > means disable/clear NX, but that is not the fact.
> > > According to the code implementation, FALSE/0 seems mean *AS IS* to
> > > do
> > thing (no code to disable/clear NX).
> > >
> > > PcdSetNxForStack
> > > TRUE: Set NX for stack.
> > > FALSE: No code to clear NX for stack.
> > >
> > > PcdDxeNxMemoryProtectionPolicy
> > > BITX 1: Set NX for that memory type.
> > > BITX 0: No code to clear NX for that memory type.
> > >
> > > PcdImageProtectionPolicy
> > > BITX 1: Set NX for the image data section.
> > > BITX 0: Not code to clear NX for the image data section.
> > >
> > > So, how about we think one PCD just works for itself and it does not
> > > impact
> > other PCDs to protect?
> > > That means TRUE/1 is to protect and FALSE/0 is *AS IS* to do nothing.
> > > The description of these PCDs could be enhancement if we think it is
> > > a good
> > way to see the problem.
> >
> > Sure, that too could work for me, but then the documentation in the
> > DEC / UNI files has to be really clear.
> >
> > The initial worry for the current discussion was that some platform
> > might
> > - protect e.g. BootServicesData type memory,
> > - not set PcdSetNxForStack,
> > - expect the stack to remain executable.
> >
> > The actual results might surprise the platform owner.
> >
> > If the documentation dispelled any possible misconceptions, I think
> > your idea could work too (and it would be a lot easier to code).
> >
> > Thanks
> > Laszlo
> >
> >
> > >
> > >
> > > Thanks,
> > > Star
> > > -----Original Message-----
> > > From: Wang, Jian J
> > > Sent: Monday, September 17, 2018 10:11 AM
> > > To: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org
> > > Cc: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
> > <ard.biesheuvel@linaro.org>; Ni, Ruiyu <ruiyu.ni@intel.com>; Yao,
> > Jiewen <jiewen.yao@intel.com>
> > > Subject: RE: [PATCH] MdeModulePkg/DxeIpl: support more NX related
> > > PCDs
> > >
> > > Laszlo,
> > >
> > > Thanks for the comments.
> > >
> > > Regards,
> > > Jian
> > >
> > >> -----Original Message-----
> > >> From: Laszlo Ersek [mailto:lersek@redhat.com]
> > >> Sent: Friday, September 14, 2018 5:51 PM
> > >> To: Wang, Jian J <jian.j.wang@intel.com>; edk2-devel@lists.01.org
> > >> Cc: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
> > >> <ard.biesheuvel@linaro.org>; Ni, Ruiyu <ruiyu.ni@intel.com>; Yao,
> > >> Jiewen <jiewen.yao@intel.com>
> > >> Subject: Re: [PATCH] MdeModulePkg/DxeIpl: support more NX related
> > >> PCDs
> > >>
> > >> I've got some comments on the code as well:
> > >>
> > >> On 09/14/18 07:13, Jian J Wang wrote:
> > >>>  BZ#1116: https://bugzilla.tianocore.org/show_bug.cgi?id=1116
> > >>>
> > >>>  Currently IA32_EFER.NXE is only set against PcdSetNxForStack.
> > >>> This
> > >>>  confuses developers because following two other PCDs also need
> > >>> NXE
> > >>>  to be set, but actually not.
> > >>>
> > >>>      PcdDxeNxMemoryProtectionPolicy
> > >>>      PcdImageProtectionPolicy
> > >>>
> > >>>  This patch solves this issue by adding logic to enable
> > >>> IA32_EFER.NXE
> > >>>  if any of those PCDs have anything enabled.
> > >>>
> > >>>  Due to the fact that NX memory type of stack (enabled by
> > >>> PcdSetNxForStack)
> > >>>  and image data section (enabled by PcdImageProtectionPolicy) are
> > >>> also
> > >>>  part of PcdDxeNxMemoryProtectionPolicy, this patch also add more
> > >>> checks
> > >>>  to warn (ASSERT) users any unreasonable setting combinations. For
> > >>> example,
> > >>>
> > >>>      PcdSetNxForStack == FALSE &&
> > >>>        (PcdDxeNxMemoryProtectionPolicy & (1
> > >>> <<EfiBootServicesData)) != 0
> > >>>
> > >>>      PcdImageProtectionPolicy == 0 &&
> > >>>        (PcdDxeNxMemoryProtectionPolicy & (1 <<
> > >>> EfiRuntimeServicesData)) != 0
> > >>>
> > >>>      PcdImageProtectionPolicy == 0 &&
> > >>>        (PcdDxeNxMemoryProtectionPolicy & (1
> > >>> <<EfiBootServicesData)) != 0
> > >>>
> > >>>      PcdImageProtectionPolicy == 0 &&
> > >>>        (PcdDxeNxMemoryProtectionPolicy & (1 <<EfiLoaderData)) != 0
> > >>>
> > >>>  In other words, PcdSetNxForStack and PcdImageProtectionPolicy
> > >>> have
> > >>>  priority over PcdDxeNxMemoryProtectionPolicy.
> > >>>
> > >>>  Cc: Star Zeng <star.zeng@intel.com>
> > >>>  Cc: Laszlo Ersek <lersek@redhat.com>
> > >>>  Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > >>>  Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> > >>>  Cc: Jiewen Yao <jiewen.yao@intel.com>
> > >>>  Contributed-under: TianoCore Contribution Agreement 1.1
> > >>>  Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
> > >>>  ---
> > >>>   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf          |  2 +
> > >>>   MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  4 +-
> > >>>   MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 55
> > >>> +++++++++++
> > ++
> > >> ++++++++++-
> > >>>   MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 33
> > >>> +++++++++++
> > ++
> > >> +
> > >>>   4 files changed, 91 insertions(+), 3 deletions(-)
> > >>>
> > >>>  diff --
> > >> git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> > >> b/MdeModulePkg/Core/DxeIp lPeim/DxeIpl.inf
> > >>>  index fd82657404..068e700074 100644
> > >>>  --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> > >>>  +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> > >>>  @@ -117,6 +117,8 @@
> > >>>
> > >>>   [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
> > >>>     gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
> > >>> ## SOMETIM
> > >> ES_CONSUMES
> > >>>  +  gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolic
> y
> > ##
> > >> SOMETIMES_CONSUMES
> > >>>  +  gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy
> > >>> ## SOME
> > >> TIMES_CONSUMES
> > >>>
> > >>>   [Depex]
> > >>>     gEfiPeiLoadFilePpiGuid AND gEfiPeiMasterBootModePpiGuid
> > >>>  diff --
> > >>
> >
> git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c b/MdeModulePkg/
> > >> Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> > >>>  index d28baa3615..9a97205ef8 100644
> > >>>  --- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> > >>>  +++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> > >>>  @@ -245,7 +245,7 @@ ToBuildPageTable (
> > >>>       return TRUE;
> > >>>     }
> > >>>
> > >>>  -  if (PcdGetBool (PcdSetNxForStack) &&
> > >>> IsExecuteDisableBitAvailable
> > >>> ()) {
> > >>>  +  if (ToEnableExecuteDisableFeature ()) {
> > >>>       return TRUE;
> > >>>     }
> > >>>
> > >>>  @@ -436,7 +436,7 @@ HandOffToDxeCore (
> > >>>       BuildPageTablesIa32Pae = ToBuildPageTable ();
> > >>>       if (BuildPageTablesIa32Pae) {
> > >>>         PageTables = Create4GPageTablesIa32Pae (BaseOfStack,
> > >>> STACK_SIZE);
> > >>>  -      if (IsExecuteDisableBitAvailable ()) {
> > >>>  +      if (ToEnableExecuteDisableFeature ()) {
> > >>>           EnableExecuteDisableBit();
> > >>>         }
> > >>>       }
> > >>>  diff --
> > >>
> >
> git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c b/MdeModulePkg
> > >> /Core/DxeIplPeim/X64/VirtualMemory.c
> > >>>  index 496e219913..253fe84223 100644
> > >>>  --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > >>>  +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> > >>>  @@ -106,6 +106,56 @@ IsNullDetectionEnabled (
> > >>>     return ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0)
> > >>> != 0);
> > >>>   }
> > >>>
> > >>>  +/**
> > >>>  +  Check if Execute Disable Bit (IA32_EFER.NXE) should be enabled or not.
> > >>>  +
> > >>>  +  @retval TRUE    IA32_EFER.NXE should be enabled.
> > >>>  +  @retval FALSE   IA32_EFER.NXE should not be enabled.
> > >>>  +
> > >>>  +**/
> > >>>  +BOOLEAN
> > >>>  +ToEnableExecuteDisableFeature (
> > >>>  +  VOID
> > >>>  +  )
> > >>
> > >> I think we're over-complicating the name of this function. First, "To"
> > >> looks unnecessary. Second, "Enable Execute Disable" is just an
> > >> engineer's way to say "Disable Execution". Can we say right that:
> > >> DisableExec()?
> > >>
> > >> Or at least, if we consider "NX" a word in its own right, "EnableNX()"?
> > >
> > > I prefer more general one. Let's use DisableExec().
> > >
> > >>
> > >>>  +{
> > >>>  +  if (!IsExecuteDisableBitAvailable ()) {
> > >>>  +    return FALSE;
> > >>>  +  }
> > >>>  +
> > >>>  +  //
> > >>>  +  // Normally stack is type of EfiBootServicesData. Disabling NX
> > >>> for stack
> > >>>  +  // but enabling NX for EfiBootServicesData doesn't make any sense.
> > >>>  +  //
> > >>
> > >> This comment is good.
> > >>
> > >>>  +  if (PcdGetBool (PcdSetNxForStack) == FALSE &&
> > >>
> > >> Please don't compare PcdGetBool() against TRUE or FALSE, just say
> > >> PcdGetBool(), or !PcdGetBool().
> > >>
> > >>>  +      (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) &
> > >>> STACK_MEMORY_TYPE)
> > >>  != 0) {
> > >>>  +    DEBUG ((DEBUG_ERROR,
> > >>>  +            "ERROR: NX for stack is disabled but NX for its
> > >>> memory type is enabled
> > >> !\r\n"));
> > >>>  +    ASSERT(!(PcdGetBool (PcdSetNxForStack) == FALSE &&
> > >>>  +             (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) &
> > >>> STACK_MEMORY_T
> > >> YPE) != 0));
> > >>>  +  }
> > >>
> > >> Please drop both the explicit "if", and the DEBUG message. Just
> > >> keep the comment (which is already fine) and the ASSERT(). The
> > >> ASSERT() will tell people where to look, and the comment will
> > >> explain the assertion. Also, in a RELEASE build, the check should
> > >> be eliminated entirely, but that might not work for the explicit
> > >> "if" (dependent on compilers and/or fixed vs. dynamic PCDs).
> > >>
> > >> Furthermore, keeping the logical negation operator as the outermost
> > >> operator makes the code a lot harder to read. It's much better to
> > >> just assert what we actually require, which is:
> > >>
> > >>   (DxeNxMemoryProtectionPolicy covers BSD) --> SetNxForStack
> > >>
> > >> put differently,
> > >>
> > >>   NOT(DxeNxMemoryProtectionPolicy covers BSD) OR SetNxForStack
> > >>
> > >> in C:
> > >>
> > >>   ASSERT (
> > >>     (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & STACK_MEMORY_TYPE)
> > ==
> > >> 0 ||
> > >>     PcdGetBool (PcdSetNxForStack)
> > >>     );
> > >>
> > >
> > > I don't have strong opinions on these. So let's do it your way.
> > >
> > >>>  +
> > >>>  +  //
> > >>>  +  // Image data section could be type of EfiLoaderData,
> > >>> EfiBootServicesData
> > >>>  +  // or EfiRuntimeServicesData. Disabling NX for image data but
> > >>> enabling NX
> > >>>  +  // for any those memory types doesn't make any sense.
> > >>>  +  //
> > >>
> > >> The comment is good, I just suggest extending it with the origin of
> > >> the
> > >> image: "Disabling NX for image data (regardless of image origin)
> > >> for any those memory types ...".
> > >>
> > >
> > > Sure. I'll add it.
> > >
> > >>>  +  if (PcdGet32 (PcdImageProtectionPolicy) == 0 &&
> > >>>  +      (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) &
> > >>> IMAGE_DATA_MEM
> > OR
> > >> Y_TYPE) != 0) {
> > >>>  +    DEBUG ((DEBUG_ERROR,
> > >>>  +            "ERROR: NX for image data is disabled but NX for its
> > >>> memory type(s) is
> > >> enabled!\r\n"));
> > >>>  +    ASSERT (!(PcdGet32 (PcdImageProtectionPolicy) == 0 &&
> > >>>  +              (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) &
> > >>> IMAGE_DATA_ME
> > >> MORY_TYPE) != 0));
> > >>>  +  }
> > >>
> > >> Summarizing my points from before, here we should have:
> > >>
> > >>   ASSERT (
> > >>     (PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & IMAGE_DATA_MEMOR
> Y
> > _TY
> > >> PE) == 0 ||
> > >>     PcdGet32 (PcdImageProtectionPolicy) == 3
> > >>     );
> > >>
> > >> That is,
> > >>
> > >> - If we disable DxeNxMemoryProtectionPolicy for all of
> > >> EfiLoaderData,
> > >>   EfiBootServicesData, and EfiRuntimeServicesData, then any
> > >>   ImageProtectionPolicy is fine.
> > >>
> > >> - If we enable  DxeNxMemoryProtectionPolicy for any of
> > >> EfiLoaderData,
> > >>   EfiBootServicesData, and EfiRuntimeServicesData, then we require
> > >> the
> > >>   platform to set ImageProtectionPolicy regardless of image origin.
> > >>
> > >> Thanks
> > >> Laszlo
> > >>
> > >
> > > Good catch. I missed that part. Thanks.
> > >
> > >>>  +
> > >>>  +  //
> > >>>  +  // XD flag (BIT63) in page table entry is only valid if IA32_EFER.NXE is se
> t.
> > >>>  +  // Features controlled by Following PCDs need this feature to be enable
> d.
> > >>>  +  //
> > >>>  +  return (PcdGetBool (PcdSetNxForStack) ||
> > >>>  +          PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0 ||
> > >>>  +          PcdGet32 (PcdImageProtectionPolicy) != 0);
> > >>>  +}
> > >>>  +
> > >>>   /**
> > >>>     Enable Execute Disable Bit.
> > >>>
> > >>>  @@ -755,7 +805,10 @@ CreateIdentityMappingPageTables (
> > >>>     //
> > >>>     EnablePageTableProtection ((UINTN)PageMap, TRUE);
> > >>>
> > >>>  -  if (PcdGetBool (PcdSetNxForStack)) {
> > >>>  +  //
> > >>>  +  // Set IA32_EFER.NXE if necessary.
> > >>>  +  //
> > >>>  +  if (ToEnableExecuteDisableFeature ()) {
> > >>>       EnableExecuteDisableBit ();
> > >>>     }
> > >>>
> > >>>  diff --
> > >>
> >
> git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h b/MdeModulePkg
> > >> /Core/DxeIplPeim/X64/VirtualMemory.h
> > >>>  index 85457ff937..9f152e6531 100644
> > >>>  --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> > >>>  +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> > >>>  @@ -179,6 +179,39 @@ typedef struct {
> > >>>     UINTN           FreePages;
> > >>>   } PAGE_TABLE_POOL;
> > >>>
> > >>>  +//
> > >>>  +// Bit field repsentations of some EFI_MEMORY_TYPE, for page
> > >>> table initializ
> > >> ation.
> > >>>  +//
> > >>>  +#define STACK_MEMORY_TYPE           (1 << EfiBootServicesData)
> > >>> /* 0x10 */
> > >>>  +#define IMAGE_DATA_MEMORY_TYPE      ((1 << EfiLoaderData)
> > >>> |
> > >>> /* 0x04
> > >> */\
> > >>>  +                                     (1 << EfiBootServicesData)
> > >>> |
> > >>> /* 0x10 */\
> > >>>  +                                     (1 <<
> > >>> EfiRuntimeServicesData)/* 0x40 */\
> > >>>  +                                    )
> > >>> /* 0x54 */
> > >>>  +
> > >>>  +/**
> > >>>  +  Check if Execute Disable Bit (IA32_EFER.NXE) should be enabled or not.
> > >>>  +
> > >>>  +  @retval TRUE    IA32_EFER.NXE should be enabled.
> > >>>  +  @retval FALSE   IA32_EFER.NXE should not be enabled.
> > >>>  +
> > >>>  +**/
> > >>>  +BOOLEAN
> > >>>  +ToEnableExecuteDisableFeature (
> > >>>  +  VOID
> > >>>  +  );
> > >>>  +
> > >>>  +/**
> > >>>  +  The function will check if Execute Disable Bit is available.
> > >>>  +
> > >>>  +  @retval TRUE      Execute Disable Bit is available.
> > >>>  +  @retval FALSE     Execute Disable Bit is not available.
> > >>>  +
> > >>>  +**/
> > >>>  +BOOLEAN
> > >>>  +IsExecuteDisableBitAvailable (
> > >>>  +  VOID
> > >>>  +  );
> > >>>  +
> > >>>   /**
> > >>>     Enable Execute Disable Bit.
> > >>>
> > >>>


  reply	other threads:[~2018-09-19  9:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14  5:13 [PATCH] MdeModulePkg/DxeIpl: support more NX related PCDs Jian J Wang
2018-09-14  5:46 ` Wang, Jian J
2018-09-14  6:04 ` Ard Biesheuvel
2018-09-14  6:50   ` Wang, Jian J
2018-09-14  9:27     ` Laszlo Ersek
2018-09-17  1:00       ` Wang, Jian J
2018-09-14  9:50 ` Laszlo Ersek
2018-09-17  2:11   ` Wang, Jian J
2018-09-17  5:57     ` Zeng, Star
2018-09-17 10:13       ` Laszlo Ersek
2018-09-18  1:21         ` Wang, Jian J
2018-09-18  8:46           ` Zeng, Star
2018-09-19  9:13             ` Wang, Jian J [this message]
2018-09-19 11:39               ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D827630B58408649ACB04F44C510003624E36A40@SHSMSX103.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox