Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Sorry guys. I did update the title but v5 is still missing. A new one will be 
sent out.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Friday, November 10, 2017 8:42 AM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Yao, Jiewen ;
> Dong, Eric 
> Subject: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
> memory map
> 
> > v5:
> >Coding style clean-up
> 
> > v4:
> > a. Remove DoUpdate and check attributes mismatch all the time to avoid
> >a logic hole
> > b. Add warning message if failed to update capability
> > c. Add local variable to hold new attributes to make code cleaner
> 
> > v3:
> > a. Add comment to explain more on updating memory capabilities
> > b. Fix logic hole in updating attributes
> > c. Instead of checking illegal memory space address and size, use return
> >status of gDS->SetMemorySpaceCapabilities() to skip memory block which
> >cannot be updated with new capabilities.
> 
> > v2
> > a. Fix an issue which will cause setting capability failure if size is 
> > smaller
> >than a page.
> 
> More than one entry of RT_CODE memory might cause boot problem for some
> old OSs. This patch will fix this issue to keep OS compatibility as much
> as possible.
> 
> More detailed information, please refer to
> https://bugzilla.tianocore.org/show_bug.cgi?id=753
> 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 69 +--
> -
>  1 file changed, 50 insertions(+), 19 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index d312eb66f8..61537838b7 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -789,8 +789,7 @@ RefreshGcdMemoryAttributesFromPaging (
>UINT64  BaseAddress;
>UINT64  PageStartAddress;
>UINT64  Attributes;
> -  UINT64  Capabilities;
> -  BOOLEAN DoUpdate;
> +  UINT64  NewAttributes;
>UINTN   Index;
> 
>//
> @@ -802,9 +801,8 @@ RefreshGcdMemoryAttributesFromPaging (
> 
>GetCurrentPagingContext ();
> 
> -  DoUpdate  = FALSE;
> -  Capabilities  = 0;
>Attributes= 0;
> +  NewAttributes = 0;
>BaseAddress   = 0;
>PageLength= 0;
> 
> @@ -813,6 +811,34 @@ RefreshGcdMemoryAttributesFromPaging (
>continue;
>  }
> 
> +//
> +// Sync the actual paging related capabilities back to GCD service first.
> +// As a side effect (good one), this can also help to avoid unnecessary
> +// memory map entries due to the different capabilities of the same type
> +// memory, such as multiple RT_CODE and RT_DATA entries in memory map,
> +// which could cause boot failure of some old Linux distro (before v4.3).
> +//
> +Status = gDS->SetMemorySpaceCapabilities (
> +MemorySpaceMap[Index].BaseAddress,
> +MemorySpaceMap[Index].Length,
> +MemorySpaceMap[Index].Capabilities |
> +EFI_MEMORY_PAGETYPE_MASK
> +);
> +if (EFI_ERROR (Status)) {
> +  //
> +  // If we cannot udpate the capabilities, we cannot update its
> +  // attributes either. So just simply skip current block of memory.
> +  //
> +  DEBUG ((
> +DEBUG_WARN,
> +"Failed to update capability: [%lu] %016lx - %016lx (%016lx -> 
> %016lx)\r\n",
> +(UINT64)Index, BaseAddress, BaseAddress + Length - 1,
> +MemorySpaceMap[Index].Capabilities,
> +MemorySpaceMap[Index].Capabilities | EFI_MEMORY_PAGETYPE_MASK
> +));
> +  continue;
> +}
> +
>  if (MemorySpaceMap[Index].BaseAddress >= (BaseAddress + PageLength)) {
>//
>// Current memory space starts at a new page. Resetting PageLength will
> @@ -826,7 +852,9 @@ RefreshGcdMemoryAttributesFromPaging (
>PageLength -= (MemorySpaceMap[Index].BaseAddress - BaseAddress);
>  }
> 
> -// Sync real page attributes to GCD
> +//
> +// Sync actual page attributes to GCD
> +//
>  BaseAddress   = MemorySpaceMap[Index].BaseAddress;
>  MemorySpaceLength = MemorySpaceMap[Index].Length;
>  while (MemorySpaceLength > 0) {
> @@ -842,23 +870,26 @@ RefreshGcdMemoryAttributesFromPaging (
>  PageStartAddress  = (*PageEntry) &
> (UINT64)PageAttributeToMask(PageAttribute);
>  PageLength= PageAttributeToLength (PageAttribute) - 
> (BaseAddress -
> PageStartAddress);
>  

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Hi Laszlo,

The memory range is FED0 - FED003FF. Actually I don't 
know if it's for MMIO or not. I might be mess it with other things.

Thanks,
Jian
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, November 08, 2017 10:17 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> On 11/08/17 01:10, Wang, Jian J wrote:
> > Hi Laszlo,
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Wednesday, November 08, 2017 1:14 AM
> >> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> >> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> >> Subject: Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> >> RT_CODE in memory map
> >>
> >> sorry about the late response
> >>
> >> On 11/03/17 01:57, Jian J Wang wrote:
> >>>> v2
> >>>> a. Fix an issue which will cause setting capability failure if size is 
> >>>> smaller
> >>>>than a page.
> >>>
> >>> More than one entry of RT_CODE memory might cause boot problem for
> >> some
> >>> old OSs. This patch will fix this issue to keep OS compatibility as much
> >>> as possible.
> >>>
> >>> More detailed information, please refer to
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=753
> >>>
> >>> Cc: Eric Dong <eric.d...@intel.com>
> >>> Cc: Jiewen Yao <jiewen@intel.com>
> >>> Cc: Laszlo Ersek <ler...@redhat.com>
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> >>> ---
> >>>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 18 ++
> >>>  1 file changed, 14 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> >> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> >>> index d312eb66f8..4a7827ebc9 100644
> >>> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> >>> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> >>> @@ -809,7 +809,9 @@ RefreshGcdMemoryAttributesFromPaging (
> >>>PageLength= 0;
> >>>
> >>>for (Index = 0; Index < NumberOfDescriptors; Index++) {
> >>> -if (MemorySpaceMap[Index].GcdMemoryType ==
> >> EfiGcdMemoryTypeNonExistent) {
> >>> +if (MemorySpaceMap[Index].GcdMemoryType ==
> >> EfiGcdMemoryTypeNonExistent
> >>> +|| (MemorySpaceMap[Index].BaseAddress & EFI_PAGE_MASK) != 0
> >>> +|| (MemorySpaceMap[Index].Length & EFI_PAGE_MASK) != 0) {
> >>>continue;
> >>>  }
> >>
> >> When exactly do the new conditions match?
> >>
> >> I thought the base addresses and the lengths in the GCD memory space map
> >> are all page aligned. Is that not the case?
> >>
> >> If these conditions are just a sanity check (i.e. we never expect them
> >> to fire), then should we perpahs turn them into ASSERT()s?
> >>
> >
> > I found that there's a mmio entry in memory map on OVMF which has size
> > less than a page. I didn't encounter this before. Maybe some recent changes
> > in other part of EDKII caused this situation. So ASSERT is not enough.
> 
> Can you describe the base address and size of this MMIO entry?
> 
> I don't see how it is possible to add such an entry in the first place
> -- if you try to add it in PEI, via a HOB, then IIRC HobLib will
> ASSERT(). If you try to add it with gDS->AddMemorySpace() in DXE, then
> the call should fail.
> 
> I believe it might be useful to investigate this entry more closely.
> Knowing the base address could help us.
> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, November 08, 2017 10:37 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Yao, Jiewen <jiewen@intel.com>
> Subject: Re: [PATCH v3] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
> memory map
> 
> On 11/08/17 11:52, Jian J Wang wrote:
> >> v3:
> >> a. Add comment to explain more on updating memory capabilities
> >> b. Fix logic hole in updating attributes
> >> c. Instead of checking illegal memory space address and size, use return
> >>status of gDS->SetMemorySpaceCapabilities() to skip memory block which
> >>cannot be updated with new capabilities.
> >
> >> v2
> >> a. Fix an issue which will cause setting capability failure if size is 
> >> smaller
> >>than a page.
> >
> > More than one entry of RT_CODE memory might cause boot problem for
> some
> > old OSs. This patch will fix this issue to keep OS compatibility as much
> > as possible.
> >
> > More detailed information, please refer to
> > https://bugzilla.tianocore.org/show_bug.cgi?id=753
> >
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 48
> +++-
> >  1 file changed, 38 insertions(+), 10 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index d312eb66f8..455c713dfc 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -789,7 +789,6 @@ RefreshGcdMemoryAttributesFromPaging (
> >UINT64  BaseAddress;
> >UINT64  PageStartAddress;
> >UINT64  Attributes;
> > -  UINT64  Capabilities;
> >BOOLEAN DoUpdate;
> >UINTN   Index;
> >
> > @@ -803,7 +802,6 @@ RefreshGcdMemoryAttributesFromPaging (
> >GetCurrentPagingContext ();
> >
> >DoUpdate  = FALSE;
> > -  Capabilities  = 0;
> >Attributes= 0;
> >BaseAddress   = 0;
> >PageLength= 0;
> > @@ -813,6 +811,27 @@ RefreshGcdMemoryAttributesFromPaging (
> >continue;
> >  }
> >
> > +//
> > +// Sync the actual paging related capabilities back to GCD service 
> > first.
> > +// As a side effect (good one), this can also help to avoid unnecessary
> > +// memory map entries due to the different capabilities of the same 
> > type
> > +// memory, such as multiple RT_CODE and RT_DATA entries in memory
> map,
> > +// which could cause boot failure of some old Linux distro (before 
> > v4.3).
> > +//
> > +Status = gDS->SetMemorySpaceCapabilities (
> > +MemorySpaceMap[Index].BaseAddress,
> > +MemorySpaceMap[Index].Length,
> > +MemorySpaceMap[Index].Capabilities |
> > +EFI_MEMORY_PAGETYPE_MASK
> > +);
> > +if (EFI_ERROR (Status)) {
> > +  //
> > +  // If we cannot udpate the capabilities, we cannot update its
> > +  // attributes either. So just simply skip current block of memory.
> > +  //
> 
> (1) Can you perhaps add a DEBUG_WARN here?

Sure.

> 
> > +  continue;
> > +}
> > +
> >  if (MemorySpaceMap[Index].BaseAddress >= (BaseAddress + PageLength)) {
> >//
> >// Current memory space starts at a new page. Resetting PageLength 
> > will
> > @@ -826,7 +845,9 @@ RefreshGcdMemoryAttributesFromPaging (
> >PageLength -= (MemorySpaceMap[Index].BaseAddress - BaseAddress);
> >  }
> >
> > -// Sync real page attributes to GCD
> > +//
> > +// Sync actual page attributes to GCD
> > +//
> >  BaseAddress   = MemorySpaceMap[Index].BaseAddress;
> >  MemorySpaceLength = MemorySpaceMap[Index].Length;
> >  while (MemorySpaceLength > 0) {
> > @@ -845,8 +866,6 @@ RefreshGcdMemoryAttributesFromPaging (
> >
> >  if (Attributes != (MemorySpaceMap[In

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Some updates below

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Wednesday, November 08, 2017 8:11 AM
> To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> Hi Laszlo,
> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Wednesday, November 08, 2017 1:14 AM
> > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> > Subject: Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> > RT_CODE in memory map
> >
> > sorry about the late response
> >
> > On 11/03/17 01:57, Jian J Wang wrote:
> > >> v2
> > >> a. Fix an issue which will cause setting capability failure if size is 
> > >> smaller
> > >>than a page.
> > >
> > > More than one entry of RT_CODE memory might cause boot problem for
> > some
> > > old OSs. This patch will fix this issue to keep OS compatibility as much
> > > as possible.
> > >
> > > More detailed information, please refer to
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=753
> > >
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Cc: Jiewen Yao <jiewen@intel.com>
> > > Cc: Laszlo Ersek <ler...@redhat.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > > ---
> > >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 18 ++
> > >  1 file changed, 14 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > index d312eb66f8..4a7827ebc9 100644
> > > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > @@ -809,7 +809,9 @@ RefreshGcdMemoryAttributesFromPaging (
> > >PageLength= 0;
> > >
> > >for (Index = 0; Index < NumberOfDescriptors; Index++) {
> > > -if (MemorySpaceMap[Index].GcdMemoryType ==
> > EfiGcdMemoryTypeNonExistent) {
> > > +if (MemorySpaceMap[Index].GcdMemoryType ==
> > EfiGcdMemoryTypeNonExistent
> > > +|| (MemorySpaceMap[Index].BaseAddress & EFI_PAGE_MASK) != 0
> > > +|| (MemorySpaceMap[Index].Length & EFI_PAGE_MASK) != 0) {
> > >continue;
> > >  }
> >
> > When exactly do the new conditions match?
> >
> > I thought the base addresses and the lengths in the GCD memory space map
> > are all page aligned. Is that not the case?
> >
> > If these conditions are just a sanity check (i.e. we never expect them
> > to fire), then should we perpahs turn them into ASSERT()s?
> >
> 
> I found that there's a mmio entry in memory map on OVMF which has size
> less than a page. I didn't encounter this before. Maybe some recent changes
> in other part of EDKII caused this situation. So ASSERT is not enough.
> 

I changed my original fix in v2 to not check the Address and Size. Instead,
I'll use the Status of gDS->SetMemorySpaceCapabilities() to skip those memory
block which cannot be updated with new capabilities. This can avoid the 
assumption that only the address and size will cause the calling failure. And I
found a logic hole in code. You'll find new changes in v3 patch.

> > >
> > > @@ -829,6 +831,15 @@ RefreshGcdMemoryAttributesFromPaging (
> > >  // Sync real page attributes to GCD
> > >  BaseAddress   = MemorySpaceMap[Index].BaseAddress;
> > >  MemorySpaceLength = MemorySpaceMap[Index].Length;
> > > +Capabilities  = MemorySpaceMap[Index].Capabilities |
> > > +EFI_MEMORY_PAGETYPE_MASK;
> > > +Status = gDS->SetMemorySpaceCapabilities (
> > > +BaseAddress,
> > > +MemorySpaceLength,
> > > +Capabilities
> > > +);
> > > +ASSERT_EFI_ERROR (Status);
> > > +
> >
> > OK, so I guess we simply add EFI_MEMORY_PAGETYPE_MASK to the
> > capabilities of all memory space map entries that have a type different
> > from non-existent. We discussed it before and 

Re: [edk2] [PATCH v4 2/7] MdeModulePkg/SmmMemoryAttribute.h: Add new protocol definitions

[Wang, Jian J]

Good catch. "EFI" should be removed and "IN" should be "OUT". Thanks for the 
feedback.

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, November 09, 2017 1:13 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Ni,
> Ruiyu <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH v4 2/7] MdeModulePkg/SmmMemoryAttribute.h: Add new
> protocol definitions
> 
> Suggest to use " SMM Memory Attribute Protocol " instead of " EFI SMM
> Memory Attribute Protocol " in the comments.
> 
> Should "+  IN  UINT64  *Attributes" be "+  OUT  
> UINT64
> *Attributes" for EDKII_SMM_GET_MEMORY_ATTRIBUTES?
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Friday, October 27, 2017 2:12 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Yao,
> Jiewen <jiewen@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [PATCH v4 2/7] MdeModulePkg/SmmMemoryAttribute.h: Add new
> protocol definitions
> 
> The new protocol gEdkiiSmmMemoryAttributeProtocolGuid is intended for
> PiSmmCore to be able to change memory page attributes for the sake of heap
> guard feature.
> 
> This protocol provides three interfaces to get/set/clear page attribute.
> 
> struct _EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL {
>   EDKII_SMM_GET_MEMORY_ATTRIBUTES   GetMemoryAttributes;
>   EDKII_SMM_SET_MEMORY_ATTRIBUTES   SetMemoryAttributes;
>   EDKII_SMM_CLEAR_MEMORY_ATTRIBUTES ClearMemoryAttributes;
> };
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Suggested-by: Ayellet Wolman <ayellet.wol...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> ---
>  MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h | 136
> +
>  1 file changed, 136 insertions(+)
>  create mode 100644 MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h
> 
> diff --git a/MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h
> b/MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h
> new file mode 100644
> index 00..20e145c2dc
> --- /dev/null
> +++ b/MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h
> @@ -0,0 +1,136 @@
> +/** @file
> +  EFI SMM Memory Attribute Protocol provides retrieval and update
> +service
> +  for memory attributes in EFI SMM environment.
> +
> +  Copyright (c) 2017, Intel Corporation. All rights reserved.  This
> + program and the accompanying materials  are licensed and made
> + available under the terms and conditions of the BSD License  which
> + accompanies this distribution.  The full text of the license may be
> + found at  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __SMM_MEMORYATTRIBUTE_H__
> +#define __SMM_MEMORYATTRIBUTE_H__
> +
> +//{69B792EA-39CE-402D-A2A6-F721DE351DFE}
> +#define EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL_GUID \
> +  { \
> +0x69b792ea, 0x39ce, 0x402d, { 0xa2, 0xa6, 0xf7, 0x21, 0xde, 0x35,
> +0x1d, 0xfe } \
> +  }
> +
> +typedef struct _EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL
> +EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL;
> +
> +/**
> +  This function set given attributes of the memory region specified by
> +  BaseAddress and Length.
> +
> +  @param  This  The EDKII_SMM_MEMORY_ATTRIBUTE_PROTOCOL
> instance.
> +  @param  BaseAddress   The physical address that is the start address of
> +a memory region.
> +  @param  LengthThe size in bytes of the memory region.
> +  @param  AttributesThe bit mask of attributes to set for the memory
> +region.
> +
> +  @retval EFI_SUCCESS   The attributes were set for the memory 
> region.
> +  @retval EFI_INVALID_PARAMETER Length is zero.
> +Attributes specified an illegal combination 
> of
> +attributes that cannot be set together.
> +  @retval EFI_UNSUPPORTED   The processor does not support one or more
> +bytes of the memory resource range specified
> +b

Re: [edk2] [PATCH v3 2/3] ShellPkg: Fix misuses of AllocateCopyPool

[Wang, Jian J]

You're right StrCpyS is better for this case. Since the patch has checked in,
maybe we can refine those code in another patch. Thanks for the comment.

> -Original Message-
> From: Carsey, Jaben
> Sent: Wednesday, November 08, 2017 11:50 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Bi, Dandan <dandan...@intel.com>
> Subject: RE: [PATCH v3 2/3] ShellPkg: Fix misuses of AllocateCopyPool
> 
> Why not use the StrCpy_s function to copy strings?  CopyMem and StrSize feels
> odd to me.
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Tuesday, November 07, 2017 6:12 PM
> > To: edk2-devel@lists.01.org
> > Cc: Carsey, Jaben <jaben.car...@intel.com>; Ni, Ruiyu
> > <ruiyu...@intel.com>; Bi, Dandan <dandan...@intel.com>
> > Subject: [PATCH v3 2/3] ShellPkg: Fix misuses of AllocateCopyPool
> > Importance: High
> >
> > > v3:
> > >   No update
> >
> > > v2:
> > > a. Use ReallocatePool instead of allocating then copying wherever
> > applicable
> >
> > AllocateCopyPool(AllocationSize, *Buffer) will copy "AllocationSize" bytes 
> > of
> > memory from old "Buffer" to new allocated one. If "AllocationSize" is bigger
> > than size of "Buffer", heap memory overflow occurs during copy.
> >
> > One solution is to allocate pool first then copy the necessary bytes to new
> > memory. Another is using ReallocatePool instead if old buffer will be freed
> > on spot.
> >
> > Cc: Jaben Carsey <jaben.car...@intel.com>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Bi Dandan <dandan...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  ShellPkg/Application/Shell/Shell.c | 4 +++-
> >  ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c | 7
> > +--
> >  2 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/ShellPkg/Application/Shell/Shell.c
> > b/ShellPkg/Application/Shell/Shell.c
> > index 5471930ba1..656206fdce 100644
> > --- a/ShellPkg/Application/Shell/Shell.c
> > +++ b/ShellPkg/Application/Shell/Shell.c
> > @@ -1646,7 +1646,7 @@ ShellConvertVariables (
> >//
> >// now do the replacements...
> >//
> > -  NewCommandLine1 = AllocateCopyPool(NewSize, OriginalCommandLine);
> > +  NewCommandLine1 = AllocateZeroPool (NewSize);
> >NewCommandLine2 = AllocateZeroPool(NewSize);
> >ItemTemp= AllocateZeroPool(ItemSize+(2*sizeof(CHAR16)));
> >if (NewCommandLine1 == NULL || NewCommandLine2 == NULL ||
> > ItemTemp == NULL) {
> > @@ -1655,6 +1655,8 @@ ShellConvertVariables (
> >  SHELL_FREE_NON_NULL(ItemTemp);
> >  return (NULL);
> >}
> > +  CopyMem (NewCommandLine1, OriginalCommandLine, StrSize
> > (OriginalCommandLine));
> > +
> >for (MasterEnvList = EfiShellGetEnv(NULL)
> >  ;  MasterEnvList != NULL && *MasterEnvList != CHAR_NULL
> >  ;  MasterEnvList += StrLen(MasterEnvList) + 1
> > diff --git
> > a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> > b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> > index 1122c89b8b..ee3db63358 100644
> > ---
> > a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> > +++
> > b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> > @@ -143,10 +143,11 @@ UpdateOptionalData(
> >  OriginalOptionDataSize += (*(UINT16*)(OriginalData + sizeof(UINT32)));
> >  OriginalOptionDataSize -= OriginalSize;
> >  NewSize = OriginalSize - OriginalOptionDataSize + DataSize;
> > -NewData = AllocateCopyPool(NewSize, OriginalData);
> > +NewData = AllocatePool(NewSize);
> >  if (NewData == NULL) {
> >Status = EFI_OUT_OF_RESOURCES;
> >  } else {
> > +  CopyMem (NewData, OriginalData, OriginalSize -
> > OriginalOptionDataSize);
> >CopyMem(NewData + OriginalSize - OriginalOptionDataSize, Data,
> > DataSize);
> >  }
> >}
> > @@ -1120,11 +1121,13 @@ BcfgAddOpt(
> >  // Now we know how many EFI_INPUT_KEY structs we need to attach to
> > the end of the EFI_KEY_OPTION struct.
> >  // Re-allocate with the added information.
> >  //
> > -KeyOptionBuffer = AllocateCopyPool(sizeof(EFI_KEY_OPTION) +
> > (sizeof(EF

Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Great. Glad to know my memory is still good enough.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 09, 2017 9:49 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>
> Subject: RE: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> FED0 is HPET region. It is MMIO.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 9, 2017 8:42 AM
> > To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> > Subject: RE: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> > RT_CODE in memory map
> >
> > Hi Laszlo,
> >
> > The memory range is FED0 - FED003FF. Actually I
> don't
> > know if it's for MMIO or not. I might be mess it with other things.
> >
> > Thanks,
> > Jian
> > > -Original Message-
> > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > Sent: Wednesday, November 08, 2017 10:17 PM
> > > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> > > Subject: Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> > > RT_CODE in memory map
> > >
> > > On 11/08/17 01:10, Wang, Jian J wrote:
> > > > Hi Laszlo,
> > > >
> > > >> -Original Message-
> > > >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > >> Sent: Wednesday, November 08, 2017 1:14 AM
> > > >> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > > >> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric
> <eric.d...@intel.com>
> > > >> Subject: Re: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries
> of
> > > >> RT_CODE in memory map
> > > >>
> > > >> sorry about the late response
> > > >>
> > > >> On 11/03/17 01:57, Jian J Wang wrote:
> > > >>>> v2
> > > >>>> a. Fix an issue which will cause setting capability failure if size 
> > > >>>> is smaller
> > > >>>>than a page.
> > > >>>
> > > >>> More than one entry of RT_CODE memory might cause boot problem
> for
> > > >> some
> > > >>> old OSs. This patch will fix this issue to keep OS compatibility as 
> > > >>> much
> > > >>> as possible.
> > > >>>
> > > >>> More detailed information, please refer to
> > > >>> https://bugzilla.tianocore.org/show_bug.cgi?id=753
> > > >>>
> > > >>> Cc: Eric Dong <eric.d...@intel.com>
> > > >>> Cc: Jiewen Yao <jiewen@intel.com>
> > > >>> Cc: Laszlo Ersek <ler...@redhat.com>
> > > >>> Contributed-under: TianoCore Contribution Agreement 1.1
> > > >>> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > > >>> ---
> > > >>>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 18 ++
> > > >>>  1 file changed, 14 insertions(+), 4 deletions(-)
> > > >>>
> > > >>> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > >> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > >>> index d312eb66f8..4a7827ebc9 100644
> > > >>> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > >>> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > >>> @@ -809,7 +809,9 @@ RefreshGcdMemoryAttributesFromPaging (
> > > >>>PageLength= 0;
> > > >>>
> > > >>>for (Index = 0; Index < NumberOfDescriptors; Index++) {
> > > >>> -if (MemorySpaceMap[Index].GcdMemoryType ==
> > > >> EfiGcdMemoryTypeNonExistent) {
> > > >>> +if (MemorySpaceMap[Index].GcdMemoryType ==
> > > >> EfiGcdMemoryTypeNonExistent
> > > >>> +|| (MemorySpaceMap[Index].BaseAddress &
> > EFI_PAGE_MASK) != 0
> > > >>> +|| (MemorySpaceMap[Index].Length & EFI_PAGE_MASK) != 0)
> > {
> > > >>>continue;
> > > >>>

Re: [edk2] [PATCH v4 0/7] Implement heap guard feature

[Wang, Jian J]

Just a friendly reminder.

The recent commits have fixed two blocking issues for checking in heap guard 
feature.

  6fe575d052e36b243657a5885b5457decac41f03 (BaseCryptLib memory overflow)
  cf8197a39d07179027455421a182598bd698
  5df73e2cc8e39da97d56da058667607f1c43acac (AllocateCopyPool memory 
overflow)
  2a6ede28fd8efd3051794e1f2727a692d2725fe9
  469293f8ee406f2b0bad2cf3bbbc510b2a1364eb

Please give your r-b if no more comments. I'd be happy to check in this patch 
soon.

Thanks,
Jian

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Friday, October 27, 2017 2:12 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v4 0/7] Implement heap guard feature
> 
> > Path V4 changes:
> > a. Change names of gEdkiiSmmMemoryAttributeProtocolGuid related
> >definitions from EFI_ to EDKII_
> > b. Coding style cleanup
> > c. Split patches in a more reasonable order and groups
> 
> > Patch V3 changes:
> > a. Add new protocol gEdkiiSmmMemoryAttributeProtocolGuid to do
> >memory attributes update instead of doing it directly in SmmCore
> > b. Fix GCC build error
> 
> > Patch V2 changes:
> > a. Remove local variable initializer with memory copy from globals
> > b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
> >message
> > c. Fix malfunction in 32-bit boot mode
> > d. Add comment for the use of mOnGuarding
> > e. Change name of function InitializePageTableLib to
> >InitializePageTableGlobals
> > f. Add code in 32-bit code to bypass setting page table to read-only
> > g. Coding style clean-up
> >
> 
> This feature makes use of paging mechanism to add a hidden (not present)
> page just before and after the allocated memory block. If the code tries
> to access memory outside of the allocated part, page fault exception will
> be triggered.
> 
> This feature is disabled by default and is not recommended to enable it
> in production build of BIOS.
> 
> This patch has passed following validations:
> 
>   a. Boot to shell (OVMF, Intel real platform)(32/64)
>   b. Boot to Fedora 25 (64)
> 
> NT32 emulation platform was not validated with this feature enabled
> due to the fact that it doesn't support paging which is needed for
> this feature to work. But all are validated with feature is disabled.
> 
> Suggested-by: Ayellet Wolman 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> 
> Jian J Wang (7):
>   MdeModulePkg/MdeModulePkg.dec,.uni: Add Protocol, PCDs and string
> tokens
>   MdeModulePkg/SmmMemoryAttribute.h: Add new protocol definitions
>   UefiCpuPkg/CpuDxe: Reduce debug message
>   MdeModulePkg/DxeIpl: Enable paging for heap guard
>   MdeModulePkg/DxeCore: Implement heap guard feature for UEFI
>   UefiCpuPkg/PiSmmCpuDxeSmm: Add SmmMemoryAttribute protocol
>   MdeModulePkg/PiSmmCore: Implement heap guard feature for SMM mode
> 
>  MdeModulePkg/Core/Dxe/DxeMain.inf  |4 +
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c  | 1182
> 
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.h  |  394 ++
>  MdeModulePkg/Core/Dxe/Mem/Imem.h   |   38 +-
>  MdeModulePkg/Core/Dxe/Mem/Page.c   |  130 +-
>  MdeModulePkg/Core/Dxe/Mem/Pool.c   |  154 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|1 +
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   36 +-
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.c| 1467
> 
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.h|  398 ++
>  MdeModulePkg/Core/PiSmmCore/Page.c |   52 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c|7 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h|   81 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |8 +
>  MdeModulePkg/Core/PiSmmCore/Pool.c |   81 +-
>  MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h |  136 ++
>  MdeModulePkg/MdeModulePkg.dec  |   60 +
>  MdeModulePkg/MdeModulePkg.uni  |   58 +
>  UefiCpuPkg/CpuDxe/CpuPageTable.c   |5 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |   10 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |   20 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |   98 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |2 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c |  163 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|   10 +-
>  25 files changed, 4496 insertions(+), 99 deletions(-)
>  create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
>  create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.h
>  create mode 100644 MdeModulePkg/Core/PiSmmCore/HeapGuard.c
>  create mode 100644 MdeModulePkg/Core/PiSmmCore/HeapGuard.h
>  create mode 100644 

Re: [edk2] [PATCH v4 0/7] Implement heap guard feature

[Wang, Jian J]

Jiewen,

Thanks for the comments.

1) I agree.
2) I forgot to remove them since we added new SMM protocol to do the same thing 
instead.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 09, 2017 10:53 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Zeng, Star <star.z...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek
> <ler...@redhat.com>; Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH v4 0/7] Implement heap guard feature
> 
> That is great.
> 
> I have minor suggestion below:
> 1) Since StaticPaging and HeapGuard are conflicted feature, I suggest we use
> ASSERT to tell the end user, instead of disable StaticPaging silently.
> 
> +  //
> +  // Don't mark page table as read-only if heap guard is enabled.
> +  //
> +  //  BIT2: SMM page guard enabled
> +  //  BIT3: SMM pool guard enabled
> +  //
> +  if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> +return ;
> +  }
> +
> 
> 2) I do not think we need add below in
> MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf. Would you please double
> confirm?
> 
> +  CpuLib
> 
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
> ## CONSUMES
> 
> 
> With ASSERT added and cleanup in PiSmmCore.inf, reviewed-by:
> jiewen@intel.com
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 9, 2017 10:00 AM
> > To: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> > Zeng, Star <star.z...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Laszlo
> Ersek
> > <ler...@redhat.com>; Kinney, Michael D <michael.d.kin...@intel.com>
> > Cc: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > Subject: RE: [edk2] [PATCH v4 0/7] Implement heap guard feature
> >
> > Just a friendly reminder.
> >
> > The recent commits have fixed two blocking issues for checking in heap guard
> > feature.
> >
> >   6fe575d052e36b243657a5885b5457decac41f03 (BaseCryptLib memory
> > overflow)
> >   cf8197a39d07179027455421a182598bd698
> >   5df73e2cc8e39da97d56da058667607f1c43acac (AllocateCopyPool
> memory
> > overflow)
> >   2a6ede28fd8efd3051794e1f2727a692d2725fe9
> >   469293f8ee406f2b0bad2cf3bbbc510b2a1364eb
> >
> > Please give your r-b if no more comments. I'd be happy to check in this 
> > patch
> > soon.
> >
> > Thanks,
> > Jian
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jian J
> > > Wang
> > > Sent: Friday, October 27, 2017 2:12 PM
> > > To: edk2-devel@lists.01.org
> > > Subject: [edk2] [PATCH v4 0/7] Implement heap guard feature
> > >
> > > > Path V4 changes:
> > > > a. Change names of gEdkiiSmmMemoryAttributeProtocolGuid related
> > > >definitions from EFI_ to EDKII_
> > > > b. Coding style cleanup
> > > > c. Split patches in a more reasonable order and groups
> > >
> > > > Patch V3 changes:
> > > > a. Add new protocol gEdkiiSmmMemoryAttributeProtocolGuid to do
> > > >memory attributes update instead of doing it directly in SmmCore
> > > > b. Fix GCC build error
> > >
> > > > Patch V2 changes:
> > > > a. Remove local variable initializer with memory copy from globals
> > > > b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
> > > >message
> > > > c. Fix malfunction in 32-bit boot mode
> > > > d. Add comment for the use of mOnGuarding
> > > > e. Change name of function InitializePageTableLib to
> > > >InitializePageTableGlobals
> > > > f. Add code in 32-bit code to bypass setting page table to read-only
> > > > g. Coding style clean-up
> > > >
> > >
> > > This feature makes use of paging mechanism to add a hidden (not present)
> > > page just before and after the allocated memory block. If the code tries
> > > to access memory outside of the allocated part, page fault exception will
> > > be triggered.
> > >
> > > This feature is disabled by default and is not recommended to enable it
> > > in production build of BIOS.
> > >
> > > This patch has passed following validations:
> > >
> > >

Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Move ClearFirst4KPage/IsNullDetectionEnabled definition

[Wang, Jian J]

Looks good to me.

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>

> -Original Message-
> From: Zeng, Star
> Sent: Friday, December 08, 2017 11:03 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>
> Subject: [PATCH] MdeModulePkg DxeIpl: Move
> ClearFirst4KPage/IsNullDetectionEnabled definition
> 
> Move ClearFirst4KPage/IsNullDetectionEnabled definition from DxeIpl.h to
> VirtualMemory.h as they are implemented in VirtualMemory.c and only used
> in IA32/X64 ARCH.
> 
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng <star.z...@intel.com>
> ---
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 27 
> +---
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 26
> ++-
>  2 files changed, 26 insertions(+), 27 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> index f3aabdb7e0f0..6f8e13d21335 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> @@ -2,7 +2,7 @@
>Master header file for DxeIpl PEIM. All source files in this module should
>include this file for common definitions.
> 
> -Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -240,29 +240,4 @@ Decompress (
>OUT   UINTN   *OutputSize
>);
> 
> -/**
> -  Clear legacy memory located at the first 4K-page.
> -
> -  This function traverses the whole HOB list to check if memory from 0 to 
> 4095
> -  exists and has not been allocated, and then clear it if so.
> -
> -  @param HobStart The start of HobList passed to DxeCore.
> -
> -**/
> -VOID
> -ClearFirst4KPage (
> -  IN  VOID *HobStart
> -  );
> -
> -/**
> -  Return configure status of NULL pointer detection feature.
> -
> -  @return TRUE   NULL pointer detection feature is enabled
> -  @return FALSE  NULL pointer detection feature is disabled
> -**/
> -BOOLEAN
> -IsNullDetectionEnabled (
> -  VOID
> -  );
> -
>  #endif
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> index 7c9bb49e3e2c..26a2100f0b80 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> @@ -7,7 +7,7 @@
>  3) IA-32 Intel(R) Architecture Software Developer's Manual Volume 
> 3:System
> Programmer's Guide, Intel
>  4) AMD64 Architecture Programmer's Manual Volume 2: System
> Programming
> 
> -Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
>  Copyright (c) 2017, AMD Incorporated. All rights reserved.
> 
>  This program and the accompanying materials
> @@ -227,5 +227,29 @@ AsmGetVectorTemplatInfo (
>OUT   VOID  **TemplateBase
>);
> 
> +/**
> +  Clear legacy memory located at the first 4K-page.
> +
> +  This function traverses the whole HOB list to check if memory from 0 to 
> 4095
> +  exists and has not been allocated, and then clear it if so.
> +
> +  @param HobStart The start of HobList passed to DxeCore.
> +
> +**/
> +VOID
> +ClearFirst4KPage (
> +  IN  VOID *HobStart
> +  );
> +
> +/**
> +  Return configure status of NULL pointer detection feature.
> +
> +  @return TRUE   NULL pointer detection feature is enabled
> +  @return FALSE  NULL pointer detection feature is disabled
> +**/
> +BOOLEAN
> +IsNullDetectionEnabled (
> +  VOID
> +  );
> 
>  #endif
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/4] Enable page table write protection

[Wang, Jian J]

That means we can't share page table pool between DxeIpl and CpuDxe. If this is
acceptable, I can remove them.

> -Original Message-
> From: Zeng, Star
> Sent: Monday, December 04, 2017 5:11 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; Dong,
> Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH v2 0/4] Enable page table write protection
> 
> Recommend to not introduce the new header file and PCDs as new interfaces,
> but handle the page table pool separately in DxeIpl and CpuDxe.
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Monday, December 4, 2017 4:36 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v2 0/4] Enable page table write protection
> 
> > v2 changes:
> >  a. Enable protection on any newly added page table after DxeIpl.
> >  b. Introduce page table pool concept to make page table allocation
> > and protection easier and error free.
> 
> Write Protect feature (CR0.WP) is always enabled in driver UefiCpuPkg/CpuDxe.
> But the memory pages used for page table are not set as read-only in the 
> driver
> DxeIplPeim, after the paging is setup. This might jeopardize the page table
> integrity if there's buffer overflow occured in other part of system.
> 
> This patch series will change this situation by clearing R/W bit in page 
> attribute
> of the pages used as page table.
> 
> Validation works include booting Windows (10/server 2016) and Linux
> (Fedora/Ubuntu) on OVMF and Intel real platform.
> 
> Jian J Wang (4):
>   MdeModulePkg/MdeModulePkg.dec: Add new PCDs and Guid
>   MdeModulePkg/PageTablePool.h: Page table pool GUID definition file
>   MdeModulePkg/DxeIpl: Mark page table as read-only
>   UefiCpuPkg/CpuDxe: Enable protection for newly added page table
> 
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|  34 +++
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |   3 +
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |   8 +-
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 315
> +-
> MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  15 ++
>  MdeModulePkg/Include/Guid/PageTablePool.h|  53 
>  MdeModulePkg/MdeModulePkg.dec|  28 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.c   |  17 +-
>  UefiCpuPkg/CpuDxe/CpuDxe.h   |   2 +
>  UefiCpuPkg/CpuDxe/CpuDxe.inf |   3 +
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 329
> ++-
>  UefiCpuPkg/CpuDxe/CpuPageTable.h |  22 ++
>  12 files changed, 816 insertions(+), 13 deletions(-)  create mode 100644
> MdeModulePkg/Include/Guid/PageTablePool.h
> 
> --
> 2.14.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 00/11] Implement stack guard feature

[Wang, Jian J]

I missed that part. I'll add it. Thanks.

Regards,
Jian

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, December 07, 2017 4:17 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH v4 00/11] Implement stack guard feature
> 
> Thanks. I still think we should add version field, just in case we need add 
> more in
> this CPU_EXCEPTION_INIT_DATA.
> 
> With version field added, reviewed-by: jiewen@intel.com
> 
> I suggest CpuModulePkg can double check the patch.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian
> J
> > Wang
> > Sent: Wednesday, December 6, 2017 4:50 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH v4 00/11] Implement stack guard feature
> >
> > > v4:
> > >  a. Change name of new data structure from
> CPU_EXCEPTION_INIT_DATA_EX
> > > to CPU_EXCEPTION_INIT_DATA
> > >  b. Add "size" field for all "buffer" fields in CPU_EXCEPTION_INIT_DATA
> > >  c. Add separate fields for IA32 and X64 in CPU_EXCEPTION_INIT_DATA
> > >  d. Change related code per changes in CPU_EXCEPTION_INIT_DATA
> >
> > > v3:
> > >  a. Change new API InitializeCpuExceptionStackSwitchHandlers() to
> > > InitializeCpuExceptionHandlersEx(). Related code are updated
> > accordingly.
> > >  b. Move EXCEPTION_STACK_SWITCH_DATA to CpuExceptionHandlerLib.h
> > > and change the name to CPU_EXCEPTION_INIT_DATA_EX for the sake
> > > of the API name change.
> > >  c. Add more general macros in BaseLib.h.
> > >  d. Add dummy implementation of InitializeCpuExceptionHandlersEx for
> > > SEC, PEI and SMM but implement a full version for DXE.
> > >  e. Add dummy InitializeCpuExceptionHandlersEx for ARM's
> > CpuExceptionHandlerLib
> > > and NULL version of CpuExceptionHandlerLib
> > >  f. Call InitializeCpuExceptionHandlersEx() in DxeMain instead of
> > > InitializeCpuExceptionHandlers().
> >
> >
> > > v2:
> > >  a. Introduce and implement new API
> > InitializeCpuExceptionStackSwitchHandlers().
> > >  b. Add stack switch related general definitions of IA32 in BaseLib.h.
> > >  c. Add two new PCDs to configure exception vector list and stack size.
> > >  d. Add code to save/restore GDTR, IDTR and TR for AP.
> > >  e. Refactor exception handler code for stack switch.
> > >  f. Add code to setup stack switch for AP besides BSP.
> >
> > Stack guard feature makes use of paging mechanism to monitor if there's a
> > stack overflow occurred during boot. A new PCD PcdCpuStackGuard is added
> to
> > enable/disable this feature. PCD PcdCpuStackSwitchExceptionList and
> > PcdCpuKnownGoodStackSize are introduced to configure the required
> > exceptions
> > and stack size.
> >
> > If this feature is enabled, DxeIpl will setup page tables and set page where
> > the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page
> > Fault exception will be triggered.
> >
> > In order to make sure exception handler works normally even when the stack
> > is corrupted, stack switching is implemented in exception library.
> >
> > Due to the mechanism behind Stack Guard, this feature is only avaiable for
> > UEFI drivers (memory avaiable). That also means it doesn't support NT32
> > emulated platform (paging not supported).
> >
> > Jian J Wang (11):
> >   MdeModulePkg/metafile: Add PCD PcdCpuStackGuard
> >   UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch
> >   MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API
> > InitializeCpuExceptionHandlersEx
> >   MdePkg/BaseLib: Add stack switch related definitions for IA32
> >   UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
> >   MdeModulePkg/CpuExceptionHandlerLibNull: Add new API implementation
> >   ArmPkg/ArmExceptionLib: Add implementation of new API
> >   UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data
> >   UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> >   MdeModulePkg/Core/Dxe: Call new API InitializeCpuExceptionHandlersEx
> > instead
> >   MdeModulePkg/DxeIpl: Enable paging for Stack Guard
> >
> >  ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c   |  33 ++
> >  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c|   2 +-
> >  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   5 +-
> >  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c| 

Re: [edk2] [PATCH v2 1/3] IntelFrameworkPkg/LegacyBios.h: Add a macro to guarantee page 0 access

[Wang, Jian J]

Thanks for the comment. The {} will be added.

Sincerely,
Jian


> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, December 07, 2017 3:00 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>
> Subject: Re: [PATCH v2 1/3] IntelFrameworkPkg/LegacyBios.h: Add a macro to
> guarantee page 0 access
> 
> On 12/7/2017 1:40 PM, Jian J Wang wrote:
> >> v2:
> >> a. Fix a typo in expression in the macro ACCESS_PAGE0_CODE
> >> b. Fix GCC49 build error
> >
> > ue to the introduction of NULL pointer detection feature, page 0 will be
> > disabled if the feature is enabled, which will cause legacy code failed to
> > update legacy data in page 0. This macro is introduced to make sure the
> > page 0 is enabled before those code and restore the original status of it
> > afterwards.
> >
> > Another reason to introduce this macro is to eliminate the dependency on
> > the PcdNullPointerDetectionPropertyMask. Because this is a new PCD, it
> > could cause some backward compatibility issue for some old packages.
> >
> > This macro will simply check if the page 0 is disabled or not. If it's
> > disabled, it will enable it before code updating page 0 and disable it
> > afterwards. Otherwise, this macro will do nothing to page 0.
> >
> > The usage of the macro will be look like (similar to DEBUG_CODE macro):
> >
> >  ACCESS_PAGE0_CODE(
> >
> >  );
> >
> > Cc: Liming Gao <liming@intel.com>
> > Cc: Michael D Kinney <michael.d.kin...@intel.com>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >   IntelFrameworkPkg/Include/Protocol/LegacyBios.h | 34
> +
> >   1 file changed, 34 insertions(+)
> >
> > diff --git a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > index 641f101bce..6a5f5464e7 100644
> > --- a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > +++ b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > @@ -1518,6 +1518,40 @@ struct _EFI_LEGACY_BIOS_PROTOCOL {
> > EFI_LEGACY_BIOS_BOOT_UNCONVENTIONAL_DEVICE
> BootUnconventionalDevice;
> >   };
> >
> > +//
> > +// Legacy BIOS needs to access memory in page 0 (0-4095), which is disabled
> if
> > +// NULL pointer detection feature is enabled. Following macro can be used 
> > to
> > +// enable/disable page 0 before/after accessing it.
> > +//
> > +#define ACCESS_PAGE0_CODE(statements)   \
> > +  do {  \
> > +EFI_STATUSStatus_;  \
> > +EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc_;\
> > +\
> > +Desc_.Attributes = 0;   \
> > +Status_ = gDS->GetMemorySpaceDescriptor (0, _);\
> > +ASSERT_EFI_ERROR (Status_); \
> > +if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) {  \
> > +  Status_ = gDS->SetMemorySpaceAttributes ( \
> > +  0,\
> > +  EFI_PAGES_TO_SIZE(1), \
> > +  Desc_.Attributes & ~(UINT64)EFI_MEMORY_RP \
> > +  );\
> > +  ASSERT_EFI_ERROR (Status_);   \
> > +}   \
> > +\
> > +statements; \
> 
> It's better to surrounded statements with {}.
> So that when statements contains variable declaration, C compiler
> doesn't complain.
> 
> > +\
> > +if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) {  \
> > +  Status_ = gDS->SetMemorySpaceAttributes ( \
> > +  0,\
> > +  EFI_PAGES_TO_SIZE(1), \
> > +  Desc_.Attributes  \
> > +  );\
> > +  ASSERT_EFI_ERROR (Status_);   \
> > +}   \
> > +  } while (FALSE)
> > +
> >   extern EFI_GUID gEfiLegacyBiosProtocolGuid;
> >
> >   #endif
> >
> 
> With the above suggested changes,
>Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>
> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 0/2] Enable page table write protection

[Wang, Jian J]

Hi Laszlo,

Thanks for the test.

Jian
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, December 06, 2017 4:05 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v3 0/2] Enable page table write protection
> 
> On 12/05/17 09:16, Jian J Wang wrote:
> >> v3 changes:
> >>  a. According to code review comments, remove the public definitions of
> >> page table pool. Now the DxeIpl and CpuDxe will have their own page
> >> table pool but in the same mechanism. Related PCDs, GUDI and headers
> >> are also removed.
> >>  b. Apply protection to all page tables, including new ones added in
> >> CpuDxe driver.
> >>  c. Code/comments cleanup.
> >
> >> v2 changes:
> >>  a. Enable protection on any newly added page table after DxeIpl.
> >>  b. Introduce page table pool concept to make page table allocation
> >> and protection easier and error free.
> >
> > Write Protect feature (CR0.WP) is always enabled in driver
> UefiCpuPkg/CpuDxe.
> > But the memory pages used for page table are not set as read-only in the
> driver
> > DxeIplPeim, after the paging is setup. This might jeopardize the page table
> > integrity if there's buffer overflow occured in other part of system.
> >
> > This patch series will change this situation by clearing R/W bit in page 
> > attribute
> > of the pages used as page table.
> >
> > Validation works include booting Windows (10/server 2016) and Linux
> (Fedora/Ubuntu)
> > on OVMF and Intel real platform.
> >
> > Jian J Wang (2):
> >   MdeModulePkg/DxeIpl: Mark page table as read-only
> >   UefiCpuPkg/CpuDxe: Enable protection for newly added page table
> >
> >  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|  34 +++
> >  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |   8 +-
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 301
> ++-
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  26 ++
> >  UefiCpuPkg/CpuDxe/CpuDxe.c   |  17 +-
> >  UefiCpuPkg/CpuDxe/CpuDxe.h   |   2 +
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 226 -
> >  UefiCpuPkg/CpuDxe/CpuPageTable.h |  34 +++
> >  8 files changed, 635 insertions(+), 13 deletions(-)
> >
> 
> series
> Regression-tested-by: Laszlo Ersek <ler...@redhat.com>
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/3] IntelFrameworkModulePkg/LegacyBiosDxe: Use macro to enable/disable page 0

[Wang, Jian J]

You're right that {} are not necessary. I'm wondering why I can't pass build 
without them before.
They'll be removed in v2.

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, December 06, 2017 5:32 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>
> Subject: Re: [edk2] [PATCH 2/3] IntelFrameworkModulePkg/LegacyBiosDxe: Use
> macro to enable/disable page 0
> 
> On 12/6/2017 3:31 PM, Jian J Wang wrote:
> > Current implementation uses following two methods
> >
> >  EnableNullDetection()
> >  DisableNullDetection()
> >
> > to enable/disable page 0. These two methods will check PCD
> > PcdNullPointerDetectionPropertyMask to know if the page 0 is disabled or 
> > not.
> > This is due to the fact that old GCD service doesn't provide paging related
> > attributes of memory block. Since this issue has been fixed, GCD services
> > can be used to determine the paging status of page 0. This is also make it
> > possible to just use a new macro
> >
> >  ACCESS_PAGE0_CODE(
> >{
> >
> >}
> >  );
> >
> > to replace above methods to do the same job, which also makes code more
> > readability.
> >
> > Cc: Liming Gao <liming@intel.com>
> > Cc: Michael D Kinney <michael.d.kin...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >   .../Csm/LegacyBiosDxe/LegacyBda.c  |  53 
> >   .../Csm/LegacyBiosDxe/LegacyBios.c | 135 
> > ++---
> >   .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|   1 -
> >   .../Csm/LegacyBiosDxe/LegacyBiosInterface.h|  16 ---
> >   .../Csm/LegacyBiosDxe/LegacyBootSupport.c  |  80 ++--
> >   .../Csm/LegacyBiosDxe/LegacyPci.c  |  72 ++-
> >   IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  |  51 
> >   7 files changed, 135 insertions(+), 273 deletions(-)
> >
> > diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
> b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
> > index c6670febee..9667dc2a0f 100644
> > --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
> > +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBda.c
> > @@ -34,37 +34,36 @@ LegacyBiosInitBda (
> > BDA_STRUC *Bda;
> > UINT8 *Ebda;
> >
> > -  DisableNullDetection ();
> > -
> > Bda   = (BDA_STRUC *) ((UINTN) 0x400);
> > Ebda  = (UINT8 *) ((UINTN) 0x9fc00);
> >
> > -  ZeroMem (Bda, 0x100);
> > +  ACCESS_PAGE0_CODE ({
> > +ZeroMem (Bda, 0x100);
> > +//
> > +// 640k-1k for EBDA
> > +//
> > +Bda->MemSize= 0x27f;
> > +Bda->KeyHead= 0x1e;
> > +Bda->KeyTail= 0x1e;
> > +Bda->FloppyData = 0x00;
> > +Bda->FloppyTimeout  = 0xff;
> > +
> > +Bda->KeyStart   = 0x001E;
> > +Bda->KeyEnd = 0x003E;
> > +Bda->KeyboardStatus = 0x10;
> > +Bda->Ebda   = 0x9fc0;
> > +
> > +//
> > +// Move LPT time out here and zero out LPT4 since some SCSI OPROMS
> > +// use this as scratch pad (LPT4 is Reserved)
> > +//
> > +Bda->Lpt1_2Timeout  = 0x1414;
> > +Bda->Lpt3_4Timeout  = 0x1400;
> > +
> > +  });
> > +
> > ZeroMem (Ebda, 0x400);
> > -  //
> > -  // 640k-1k for EBDA
> > -  //
> > -  Bda->MemSize= 0x27f;
> > -  Bda->KeyHead= 0x1e;
> > -  Bda->KeyTail= 0x1e;
> > -  Bda->FloppyData = 0x00;
> > -  Bda->FloppyTimeout  = 0xff;
> > -
> > -  Bda->KeyStart   = 0x001E;
> > -  Bda->KeyEnd = 0x003E;
> > -  Bda->KeyboardStatus = 0x10;
> > -  Bda->Ebda   = 0x9fc0;
> > -
> > -  //
> > -  // Move LPT time out here and zero out LPT4 since some SCSI OPROMS
> > -  // use this as scratch pad (LPT4 is Reserved)
> > -  //
> > -  Bda->Lpt1_2Timeout  = 0x1414;
> > -  Bda->Lpt3_4Timeout  = 0x1400;
> > -
> > -  *Ebda   = 0x01;
> > -
> > -  EnableNullDetection ();
> > +  *Ebda = 0x01;
> >
> > return EFI_SUCCESS;
> >   }
> > diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> b/IntelFramew

Re: [edk2] [PATCH 1/3] IntelFrameworkPkg/LegacyBios.h: Add a macro to guarantee page 0 access

[Wang, Jian J]

Good catch. I think it's a typo not on purpose. Many thanks!

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, December 06, 2017 5:31 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>
> Subject: Re: [edk2] [PATCH 1/3] IntelFrameworkPkg/LegacyBios.h: Add a macro
> to guarantee page 0 access
> 
> On 12/6/2017 3:31 PM, Jian J Wang wrote:
> > Due to the introduction of NULL pointer detection feature, page 0 will be
> > disabled if the feature is enabled, which will cause legacy code failed to
> > update legacy data in page 0. This macro is introduced to make sure the
> > page 0 is enabled before those code and restore the original status of it
> > afterwards.
> >
> > Another reason to introduce this macro is to eliminate the dependency on
> > the PcdNullPointerDetectionPropertyMask. Because this is a new PCD, it
> > could cause some backward compatibility issue for some old packages.
> >
> > This macro will simply check if the page 0 is disabled or not. If it's
> > disabled, it will enable it before code updating page 0 and disable it
> > afterwards. Otherwise, this macro will do nothing to page 0.
> >
> > The usage of the macro will be look like (similar to DEBUG_CODE macro):
> >
> >  ACCESS_PAGE0_CODE(
> >{
> >
> >}
> >  );
> >
> > Cc: Liming Gao <liming@intel.com>
> > Cc: Michael D Kinney <michael.d.kin...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >   IntelFrameworkPkg/Include/Protocol/LegacyBios.h | 34
> +
> >   1 file changed, 34 insertions(+)
> >
> > diff --git a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > index 641f101bce..f77c92ba21 100644
> > --- a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > +++ b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > @@ -1518,6 +1518,40 @@ struct _EFI_LEGACY_BIOS_PROTOCOL {
> > EFI_LEGACY_BIOS_BOOT_UNCONVENTIONAL_DEVICE
> BootUnconventionalDevice;
> >   };
> >
> > +//
> > +// Legacy BIOS needs to access memory in page 0 (0-4095), which is disabled
> if
> > +// NULL pointer detection feature is enabled. Following macro can be used 
> > to
> > +// enable/disable page 0 before/after accessing it.
> > +//
> > +#define ACCESS_PAGE0_CODE(statements)   \
> > +  do {  \
> > +EFI_STATUSStatus_;  \
> > +EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc_;\
> > +\
> > +Status_ = gDS->GetMemorySpaceDescriptor (0, _);\
> > +if (!EFI_ERROR (Status_)) { \
> > +  if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) {\
> > +Status_ = gDS->SetMemorySpaceAttributes (   \
> > +0,  \
> > +EFI_PAGES_TO_SIZE(1),   \
> > +Desc_.Attributes &= ~EFI_MEMORY_RP  \
> 
> &= is used here so Desc_.Attributes is updated to have RP cleared.
> Then the below if will be always FALSE.
> 
> > +);  \
> > +ASSERT_EFI_ERROR (Status_); \
> > +  } \
> > +\
> > +  statements;   \
> > +\
> > +  if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) {\
> > +Status_ = gDS->SetMemorySpaceAttributes (   \
> > +0,  \
> > +EFI_PAGES_TO_SIZE(1),   \
> > +Desc_.Attributes\
> > +);  \
> > +ASSERT_EFI_ERROR (Status_); \
> > +  } \
> > +}   \
> > +  } while (FALSE)
> > +
> >   extern EFI_GUID gEfiLegacyBiosProtocolGuid;
> >
> >   #endif
> >
> 
> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 1/2] MdeModulePkg/DxeIpl: Mark page table as read-only

[Wang, Jian J]

Hi,

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, December 06, 2017 6:05 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH v3 1/2] MdeModulePkg/DxeIpl: Mark page table as
> read-only
> 
> On 12/5/2017 4:16 PM, Jian J Wang wrote:
> >> v3:
> >> Remove the public definition of PAGE_TABLE_POOL_HEADER but keep
> similar
> >> concept locally. CpuDxe has its own page table pool.
> >
> >> v2:
> >> Introduce page table pool to ease the page table memory allocation and
> >> protection, which replaces the direct calling of AllocatePages().
> >
> > This patch will set the memory pages used for page table as read-only
> > memory after the paging is setup. CR0.WP must set to let it take into
> > effect.
> >
> > A simple page table memory management mechanism, page table pool
> concept,
> > is introduced to simplify the page table memory allocation and protection.
> > It will also help to reduce the potential recursive "split" action during
> > updating memory paging attributes.
> >
> > The basic idea is to allocate a bunch of continuous pages of memory in
> > advance as one or more page table pools, and all future page tables
> > consumption will happen in those pool instead of system memory. If the page
> > pool is reserved at the boundary of 2MB page and with same size of 2MB page,
> > there's no page granularity "split" operation will be needed, because the
> > memory of new page tables (if needed) will be usually in the same page as
> > target page table you're working on.
> >
> > And since we have centralized page tables (a few 2MB pages), it's easier
> > to protect them by changing their attributes to be read-only once and for
> > all. There's no need to apply the protection for new page tables any more
> > as long as the pool has free pages available.
> >
> > Once current page table pool has been used up, one can allocate another 2MB
> > memory pool and just set this new 2MB memory block to be read-only instead
> of
> > setting the new page tables one page by one page.
> >
> > Two new PCDs PcdPageTablePoolUnitSize and PcdPageTablePoolAlignment
> are used
> > to specify the size and alignment for page table pool. For IA32 processor
> > 0x20 (2MB) is the only choice for both of them to meet the requirement
> of
> > page table pool.
> >
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >   MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|  34 +++
> >   MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |   8 +-
> >   MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 301
> ++-
> >   MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  26 ++
> >   4 files changed, 365 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> > index f3aabdb7e0..9dc80b1508 100644
> > --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> > +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> > @@ -265,4 +265,38 @@ IsNullDetectionEnabled (
> > VOID
> > );
> >
> > +/**
> > +  Prevent the memory pages used for page table from been overwritten.
> > +
> > +  @param[in] PageTableBaseBase address of page table (CR3).
> > +
> > +**/
> > +VOID
> > +EnablePageTableProtection (
> > +  IN  UINTN PageTableBase,
> > +  IN  BOOLEAN   Level4Paging
> > +  );
> > +
> > +/**
> > +  This API provides a way to allocate memory for page table.
> > +
> > +  This API can be called more than once to allocate memory for page tables.
> > +
> > +  Allocates the number of 4KB pages and returns a pointer to the allocated
> > +  buffer. The buffer returned is aligned on a 4KB boundary.
> > +
> > +  If Pages is 0, then NULL is returned.
> > +  If there is not enough memory remaining to satisfy the request, then 
> > NULL is
> > +  returned.
> > +
> > +  @param  Pages The number of 4 KB pages to allocate.
> > +
> > +  @return A pointer to the allocated buffer or N

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Please see my comments below. Thanks.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, October 25, 2017 8:51 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> On 10/25/17 03:33, Wang, Jian J wrote:
> > Hi Laszlo,
> >
> > Thanks for the feedback. I'd like to explain a bit more here first and
> > will update the commit message later.
> >
> > The multiple RT_CODE entries issue was reported by LUV test suite from
> > https://01.org/linux-uefi-validation
> >
> > You're right this issue is caused by my commit c1cab54ce57c, which
> > tried to fix the GCD issue in which you can't set paging related
> > memory attributes through GCD service API. The reasons are that GCD
> > will filter out all paging related memory attributes and also, the CPU
> > driver didn't sync the paging attributes back to GCD. Sorry I don't
> > know why GCD and cpu driver are implemented that way.
> >
> > My previous commit c1cab54ce57c fixed above issues but didn't make
> > sure that all memory blocks share the same capabilities because I just
> > added paging related memory capabilities to those memory block having
> > some paging attributes set. This will in turn cause more than one
> > RT_CODE entries in memory map because GCD reports memory to OS based
> > on the memory block capability.
> >
> > Why multiple RT_CODE matters? It's because that Linux kernel would
> > misplace the runtime service code segment and its data segment. What I
> > know is this Linux issue had been fixed. That's why recent Linux
> > distro won't encounter problems even if we report multiple RT_CODE
> > memory to kernel.
> 
> Ah, OK, I remember now.
> 
> The point is that separate entries in the UEFI memmap may be mapped by
> the OS to discontiguous virtual address ranges.
> 
> However, if we take the UEFI memmap entries that belong to a single
> runtime DXE driver, and unintentionally split those entries up (by
> setting distinct capabilities for a subset of their pages), then the
> runtime driver will break, because the linear address range that the
> driver expects (from its original loading and relocation) will not be
> kept linear by the OS.
> 
> > I'm sorry that I cannot find the specific version of kernel which has
> > such problem and I can't find any discussion related. Maybe Jiewen can
> > provide more detailed information.
> 
> It would be really helpful if you guys could name a guest kernel version
> (or a GNU/Linux distro release) that is affected by this problem.
> 

It seems following log history which mentioned the problem.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=0ce3cc008ec04258b6a6314b09f1a6012810881a

> Are there perhaps any conditions that this issue depends on, such as
> PCDs for example? In other words, is it possible that various edk2
> platform settings (in the DSC) can mask this issue?
> 

In current code base, following PCDs may cause memory page attribute changes

  PcdImageProtectionPolicy
  PcdDxeNxMemoryProtectionPolicy

Once the heap guard feature is checked in (you may notice my recent patches),
there're three more PCDs:

  PcdHeapGuardPropertyMask
  PcdHeapGuardPoolType
  PcdHeapGuardPageType

> Can you maybe present UEFI memmaps (dumped in the UEFI shell, or in
> Linux) that show the problem, compared to this fix?
> 

Before this patch (after c1cab54ce57c), the memory map looks like

RT_DataBE20F000-BE38EFFF 0180 800F
RT_CodeBE38F000-BE46 00E1 800F
RT_CodeBE47-BE470FFF 0001 8000400F
RT_CodeBE471000-BE472FFF 0002 8002000F
RT_CodeBE473000-BE476FFF 0004 8000400F
RT_CodeBE477000-BE478FFF 0002 8002000F
RT_CodeBE479000-BE47CFFF 0004 8000400F
RT_CodeBE47D000-BE47 0003 8002000F
RT_CodeBE48-BE483FFF 0004 8000400F
RT_CodeBE484000-BE485FFF 0002 8002000F
RT_CodeBE486000-BE489FFF 0004 8000400F
RT_CodeBE48A000-BE48BFFF 0002 8002000F
RT_CodeBE48C000-BE48EFFF 0003 8000400F

You may notice that there're one RT_Data with 12 RT_Code entries

Re: [edk2] [PATCH v3 0/6] Implement heap guard feature

[Wang, Jian J]

Thanks for the feedback. I'll change the patch order in v4.

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, October 26, 2017 2:53 PM
> To: Yao, Jiewen <jiewen....@intel.com>; Wang, Jian J <jian.j.w...@intel.com>;
> edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> <ayellet.wol...@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng, Star
> <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH v3 0/6] Implement heap guard feature
> 
> I suggest putting [3/6] at the first patch as it adds definitions that are 
> used by
> other patches.
> 
> Thanks,
> Star
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, October 26, 2017 2:49 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> <ayellet.wol...@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng, Star
> <star.z...@intel.com>; Yao, Jiewen <jiewen@intel.com>
> Subject: RE: [edk2] [PATCH v3 0/6] Implement heap guard feature
> 
> That is great work. Jian.
> 
> Some suggestion for your consideration:
> 
> 0) I suggest add Laszlo to review SMM part, and add Ruiyu to review
> SMM_MEMORY_ATTRIBUTE_PROTOCOL.
> 
> 1) Would you please mention what test we have done for this feature?
> Such as OVMF/realPlatform? IA32/X64?
> 
> Have you validated NT32? Or try to enable protection? :-)
> 
> 2) Is that any dependency of this patch?
> I think there is OPENSSL wrapper reallocate() issue not resolved yet.
> 
> I suggest we check in all dependent patch at first, then check in this one.
> 
> 3) If you need submit V4, please separate
> MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h from 2/6 to be a
> standalone patch. In general, an interface and an implementation are 
> separated.
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, October 25, 2017 9:48 AM
> > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> > <ayellet.wol...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Dong,
> > Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > Subject: RE: [edk2] [PATCH v3 0/6] Implement heap guard feature
> >
> > Hi,
> >
> > Just a warm reminding. I didn't see any feedbacks on the v3 patch.
> > If no more comments, I'll check in the patch soon.
> >
> > Thanks,
> > Jian
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Jian J Wang
> > > Sent: Monday, October 23, 2017 8:51 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> > > <ayellet.wol...@intel.com>; Yao, Jiewen <jiewen@intel.com>;
> > > Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > > Subject: [edk2] [PATCH v3 0/6] Implement heap guard feature
> > >
> > > > Patch V3 changes:
> > > > a. Add new protocol gEdkiiSmmMemoryAttributeProtocolGuid to do
> > > >memory attributes update instead of doing it directly in
> > > > SmmCore b. Fix GCC build error
> > >
> > > > Patch V2 changes:
> > > > a. Remove local variable initializer with memory copy from globals
> > > > b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
> > > >message
> > > > c. Fix malfunction in 32-bit boot mode d. Add comment for the use
> > > > of mOnGuarding e. Change name of function InitializePageTableLib
> > > > to
> > > >InitializePageTableGlobals
> > > > f. Add code in 32-bit code to bypass setting page table to
> > > > read-only g. Coding style clean-up
> > > >
> > >
> > > This feature makes use of paging mechanism to add a hidden (not
> > > present) page just before and after the allocated memory block. If
> > > the code tries to access memory outside of the allocated part, page
> > > fault exception will be triggered.
> > >
> > > This feature is disabled by default and is not recommended to enable
> > > it in production build of BIOS.
> > >
> > > Cc: Star Zeng <star.z...@intel.com>
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Cc: Jiewen Yao <jiewen@inte

Re: [edk2] [PATCH v3 5/6] UefiCpuPkg/PiSmmCpuDxeSmm: Disable page table protection

[Wang, Jian J]

Thanks for the feedback. I'll change them in v4.

> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, October 26, 2017 3:18 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Laszlo Ersek <ler...@redhat.com>
> Subject: RE: [edk2] [PATCH v3 5/6] UefiCpuPkg/PiSmmCpuDxeSmm: Disable
> page table protection
> 
> Jian,
> 1. For protocol not defined in Spec, please use EDKII prefix, instead of EFI 
> prefix.
> 2. Could you please add more comments for BIT3 and BIT2 check?
> 3. Better to separate the protocol definition to a single commit.
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, October 26, 2017 2:20 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> > Laszlo Ersek <ler...@redhat.com>; Ni, Ruiyu <ruiyu...@intel.com>
> > Subject: RE: [edk2] [PATCH v3 5/6] UefiCpuPkg/PiSmmCpuDxeSmm: Disable
> > page table protection
> >
> > Laszlo and Ruiyu,
> >
> > Could you please take a look at this part? There's a new protocol 
> > introduced.
> >
> > Thanks,
> > Jian
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > > Jian J Wang
> > > Sent: Monday, October 23, 2017 8:51 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric
> > > <eric.d...@intel.com>
> > > Subject: [edk2] [PATCH v3 5/6] UefiCpuPkg/PiSmmCpuDxeSmm: Disable
> > page
> > > table protection
> > >
> > > > v3
> > > > According to Jiewen's feedback, implement new protocol
> > > > gEdkiiSmmMemoryAttributeProtocolGuid
> > > > to change memory attributes.
> > >
> > > > v2
> > > > According to Eric's feedback:
> > > > a. Enclose bit-or with parentheses
> > > > b. Add code in 32-bit code to bypass setting page table to read-only
> > >
> > > Heap guard feature will update page attributes frequently. The page
> > > table should not set to be read-only if heap guard feature is enabled
> > > for SMM mode. Otherwise this feature cannot work.
> > >
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Cc: Jiewen Yao <jiewen@intel.com>
> > > Suggested-by: Ayellet Wolman <ayellet.wol...@intel.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > > ---
> > >  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |   7 +
> > >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |  20 +++
> > >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  98
> > > +
> > >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |   2 +
> > >  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 163
> > > +
> > >  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|   3 +-
> > >  6 files changed, 292 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > > b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > > index f295c2ebf2..27c11f1b8d 100644
> > > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > > @@ -184,6 +184,13 @@ SetPageTableAttributes (
> > >BOOLEAN   IsSplitted;
> > >BOOLEAN   PageTableSplitted;
> > >
> > > +  //
> > > +  // Don't mark page table as read-only if heap guard is enabled.
> > > +  //
> > > +  if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> > > +return ;
> > > +  }
> > > +
> > >DEBUG ((DEBUG_INFO, "SetPageTableAttributes\n"));
> > >
> > >//
> > > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > > b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > > index 282d2e6981..8635f2d2c8 100755
> > > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c
> > > @@ -76,6 +76,15 @@ EFI_SMM_CPU_PROTOCOL  mSmmCpu  = {
> > >SmmWriteSaveState
> > >  };
> > >
> > > +///
> > > +/// SMM Memory Attribute Protocol instance ///
> > > +

Re: [edk2] [PATCH v3 0/6] Implement heap guard feature

[Wang, Jian J]

Thanks for the feedback.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, October 26, 2017 2:49 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> <ayellet.wol...@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng, Star
> <star.z...@intel.com>; Yao, Jiewen <jiewen@intel.com>
> Subject: RE: [edk2] [PATCH v3 0/6] Implement heap guard feature
> 
> That is great work. Jian.
> 
> Some suggestion for your consideration:
> 
> 0) I suggest add Laszlo to review SMM part, and add Ruiyu to review
> SMM_MEMORY_ATTRIBUTE_PROTOCOL.
> 

Ok, already pinged them.

> 1) Would you please mention what test we have done for this feature?
> Such as OVMF/realPlatform? IA32/X64?
> 

I did following test:

Boot to shell (OVMF/Intel platform) (both IA32 and X64)
Boot to Fedora 25 (64 only)

Windows 10 boot loader has a limit of 512-memory-descriptor, which will
cause boot failure. This is due to a fact that enabling this feature will cause
more memory fragments (pool memory). Since this is a debug feature, I suppose
this is an acceptable result.

> Have you validated NT32? Or try to enable protection? :-)
> 

I did before first round of patch but not after. Let me check it again. Enabling
protection in NT32 is a challenge because Windows API has some limitations
which may need a huge changes to our memory management code. I'd suggest
to leave NT32 alone or create a separate task for it.

> 2) Is that any dependency of this patch?
> I think there is OPENSSL wrapper reallocate() issue not resolved yet.
> 
> I suggest we check in all dependent patch at first, then check in this one.
> 

You're right.

> 3) If you need submit V4, please separate
> MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h from 2/6 to be a
> standalone patch. In general, an interface and an implementation are 
> separated.
> 

Sure. 

> 
> Thank you
> Yao Jiewen
> 
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, October 25, 2017 9:48 AM
> > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> > <ayellet.wol...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Dong,
> Eric
> > <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > Subject: RE: [edk2] [PATCH v3 0/6] Implement heap guard feature
> >
> > Hi,
> >
> > Just a warm reminding. I didn't see any feedbacks on the v3 patch.
> > If no more comments, I'll check in the patch soon.
> >
> > Thanks,
> > Jian
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jian J
> > > Wang
> > > Sent: Monday, October 23, 2017 8:51 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> > > <ayellet.wol...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Dong,
> Eric
> > > <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > > Subject: [edk2] [PATCH v3 0/6] Implement heap guard feature
> > >
> > > > Patch V3 changes:
> > > > a. Add new protocol gEdkiiSmmMemoryAttributeProtocolGuid to do
> > > >memory attributes update instead of doing it directly in SmmCore
> > > > b. Fix GCC build error
> > >
> > > > Patch V2 changes:
> > > > a. Remove local variable initializer with memory copy from globals
> > > > b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
> > > >message
> > > > c. Fix malfunction in 32-bit boot mode
> > > > d. Add comment for the use of mOnGuarding
> > > > e. Change name of function InitializePageTableLib to
> > > >InitializePageTableGlobals
> > > > f. Add code in 32-bit code to bypass setting page table to read-only
> > > > g. Coding style clean-up
> > > >
> > >
> > > This feature makes use of paging mechanism to add a hidden (not present)
> > > page just before and after the allocated memory block. If the code tries
> > > to access memory outside of the allocated part, page fault exception will
> > > be triggered.
> > >
> > > This feature is disabled by default and is not recommended to enable it
> > > in production build of BIOS.
> > >
> > > Cc: Star Zeng <star.z...@intel.com>
> > > Cc: Eric Dong <eric.d...@intel.com

Re: [edk2] [PATCH v3 0/6] Implement heap guard feature

[Wang, Jian J]

Hi,

Just a warm reminding. I didn't see any feedbacks on the v3 patch.
If no more comments, I'll check in the patch soon.

Thanks,
Jian

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Monday, October 23, 2017 8:51 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Wolman, Ayellet
> ; Yao, Jiewen ; Dong, Eric
> ; Zeng, Star 
> Subject: [edk2] [PATCH v3 0/6] Implement heap guard feature
> 
> > Patch V3 changes:
> > a. Add new protocol gEdkiiSmmMemoryAttributeProtocolGuid to do
> >memory attributes update instead of doing it directly in SmmCore
> > b. Fix GCC build error
> 
> > Patch V2 changes:
> > a. Remove local variable initializer with memory copy from globals
> > b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
> >message
> > c. Fix malfunction in 32-bit boot mode
> > d. Add comment for the use of mOnGuarding
> > e. Change name of function InitializePageTableLib to
> >InitializePageTableGlobals
> > f. Add code in 32-bit code to bypass setting page table to read-only
> > g. Coding style clean-up
> >
> 
> This feature makes use of paging mechanism to add a hidden (not present)
> page just before and after the allocated memory block. If the code tries
> to access memory outside of the allocated part, page fault exception will
> be triggered.
> 
> This feature is disabled by default and is not recommended to enable it
> in production build of BIOS.
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Michael Kinney 
> Cc: Ayellet Wolman 
> Suggested-by: Ayellet Wolman 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> 
> Jian J Wang (6):
>   MdeModulePkg/DxeCore: Implement heap guard feature for UEFI
>   MdeModulePkg/PiSmmCore: Implement heap guard feature for SMM mode
>   MdeModulePkg/MdeModulePkg.dec,.uni: Add Protocol, PCDs and string
> tokens
>   UefiCpuPkg/CpuDxe: Reduce debug message
>   UefiCpuPkg/PiSmmCpuDxeSmm: Disable page table protection
>   MdeModulePkg/DxeIpl: Enable paging for heap guard
> 
>  MdeModulePkg/Core/Dxe/DxeMain.inf  |4 +
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c  | 1184
> 
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.h  |  380 +
>  MdeModulePkg/Core/Dxe/Mem/Imem.h   |   38 +-
>  MdeModulePkg/Core/Dxe/Mem/Page.c   |  130 +-
>  MdeModulePkg/Core/Dxe/Mem/Pool.c   |  154 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|1 +
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   29 +-
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.c| 1469
> 
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.h|  399 ++
>  MdeModulePkg/Core/PiSmmCore/Page.c |   51 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c|7 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h|   81 +-
>  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf  |8 +
>  MdeModulePkg/Core/PiSmmCore/Pool.c |   81 +-
>  MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h |  136 ++
>  MdeModulePkg/MdeModulePkg.dec  |   60 +
>  MdeModulePkg/MdeModulePkg.uni  |   58 +
>  UefiCpuPkg/CpuDxe/CpuPageTable.c   |5 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |7 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c |   20 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |   98 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |2 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c |  163 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|3 +-
>  25 files changed, 4472 insertions(+), 96 deletions(-)
>  create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
>  create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.h
>  create mode 100644 MdeModulePkg/Core/PiSmmCore/HeapGuard.c
>  create mode 100644 MdeModulePkg/Core/PiSmmCore/HeapGuard.h
>  create mode 100644 MdeModulePkg/Include/Protocol/SmmMemoryAttribute.h
> 
> --
> 2.14.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Hi Laszlo,

Thanks for the feedback. I'd like to explain a bit more here first and will
update the commit message later.

The multiple RT_CODE entries issue was reported by LUV test suite from
https://01.org/linux-uefi-validation

You're right this issue is caused by my commit c1cab54ce57c, which tried to
fix the GCD issue in which you can't set paging related memory attributes
through GCD service API. The reasons are that GCD will filter out all paging
related memory attributes and also, the CPU driver didn't sync the paging
attributes back to GCD. Sorry I don't know why GCD and cpu driver are
implemented that way.

My previous commit c1cab54ce57c fixed above issues but didn't make sure that
all memory blocks share the same capabilities because I just added paging
related memory capabilities to those memory block having some paging
attributes set. This will in turn cause more than one RT_CODE entries in
memory map because GCD reports memory to OS based on the memory block
capability.

Why multiple RT_CODE matters? It's because that Linux kernel would misplace
the runtime service code segment and its data segment. What I know is this
Linux issue had been fixed. That's why recent Linux distro won't encounter
problems even if we report multiple RT_CODE memory to kernel.

I'm sorry that I cannot find the specific version of kernel which has such
problem and I can't find any discussion related. Maybe Jiewen can provide
more detailed information.

This patch will make sure that all memory block share the same paging
capabilities. Because all memory are actually paged in current EDK2 (at least
IA processors), technically we're capable of setting any page of memory to
read-only and/or non-executable. I think this fix is not only trying to avoid
multiple RT_CODE memory map entries but also trying to make sure the memory
capabilities in GCD service to reflect complete status of the real world.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, October 24, 2017 8:20 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> On 10/23/17 08:50, Jian J Wang wrote:
> > More than one entry of RT_CODE memory might cause boot problem for
> some
> > old OSs. This patch will fix this issue to keep OS compatibility as much
> > as possible.
> >
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> Can you please explain in the commit message; what OSes are affected by
> this issue, to your knowledge?
> 
> Also, the code being patched seems to originate from commit c1cab54ce57c
> ("UefiCpuPkg/CpuDxe: Fix out-of-sync issue in page attributes",
> 2017-09-16). I vaguely recall that this commit was related to your "page
> 0 protection" work.
> 
> Can you please explain, in the commit message, under what circumstances
> (PCD settings etc) the issue arises, and how we end up with multiple
> RT_CODE entries in the memory map?
> 
> (BTW, multiple RT_CODE entries in the memmap should be perfectly
> normal... So I'm extra curious about the OSes that are not compatible
> with that.)
> 
> Thanks,
> Laszlo
> 
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index d312eb66f8..0802464b9d 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -829,6 +829,15 @@ RefreshGcdMemoryAttributesFromPaging (
> >  // Sync real page attributes to GCD
> >  BaseAddress   = MemorySpaceMap[Index].BaseAddress;
> >  MemorySpaceLength = MemorySpaceMap[Index].Length;
> > +Capabilities  = MemorySpaceMap[Index].Capabilities |
> > +EFI_MEMORY_PAGETYPE_MASK;
> > +Status = gDS->SetMemorySpaceCapabilities (
> > +BaseAddress,
> > +MemorySpaceLength,
> > +Capabilities
> > +);
> > +ASSERT_EFI_ERROR (Status);
> > +
> >  while (MemorySpaceLength > 0) {
> >if (PageLength == 0) {
> >  PageEntry = GetPageTableEntry (, BaseAddress,
> );
> > @@ -846,7 +855,6 @@ RefreshGcdMemoryAttributesFromPaging (
> >  if (Attributes != (MemorySpaceMap[Index].Attributes &
> EF

Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

Hi Jeff,

Thanks for the feedback. Are you suggesting to fix Bugzilla 109 in this patch?

Thanks,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Wednesday, November 01, 2017 10:33 AM
To: Yao, Jiewen <jiewen@intel.com>; Wang, Jian J <jian.j.w...@intel.com>; 
edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Dong, Eric 
<eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: 答复: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch 
support

Per https://bugzilla.tianocore.org/show_bug.cgi?id=109, TR should be setup 
(Such as in DxeIplPeim) even though NULL Cpu Exception Handler instance is 
chosen.

For long term, I agree we need to move AsmWriteTr, IA32_TASK_STATE_SEGMENT, 
IA32_TSS_DESCRIPTOR to MdePkg(Such as BaseLib)
For this patch, I have no strong opinion.


发件人: Yao, Jiewen<mailto:jiewen@intel.com>
发送时间: 2017年11月1日 9:56
收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Kinney, Michael D<mailto:michael.d.kin...@intel.com>; Dong, 
Eric<mailto:eric.d...@intel.com>; Zeng, Star<mailto:star.z...@intel.com>
主题: Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch 
support

Hi Jian
Thanks for the patch.

Can we move all IA32 defined data structure or function to MdePkg?
Such as: AsmWriteTr, IA32_TASK_STATE_SEGMENT, IA32_TSS_DESCRIPTOR

I am also curious why we use different policy for other boot mode.
Can we use consistent policy?
> +  if (PcdGetBool (PcdCpuStackGuard)) {
> +//
> +// Stack Guard works with the support of page table established and
> +// memory management. So we have to exclude those boot modes
> without
> +// them.
> +//
> +switch (GetBootModeHob()) {
> +case BOOT_ON_FLASH_UPDATE:
> +case BOOT_IN_RECOVERY_MODE:
> +case BOOT_ON_S3_RESUME:
> +  break;
> +
> +default:
> +  ArchSetupExcpetionStack (IdtTable);
> +  break;
> +}
> +  }


Thank you
Yao Jiewen


> -Original Message-
> From: Wang, Jian J
> Sent: Tuesday, October 31, 2017 10:24 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
> <eric.d...@intel.com<mailto:eric.d...@intel.com>>; Yao,
> Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Kinney, Michael D
> <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
> Subject: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> support
>
> If Stack Guard is enabled and there's really a stack overflow happened during
> boot, a Page Fault exception will be triggered. Because the stack is out of
> usage, the exception handler, which shares the stack with normal UEFI driver,
> cannot be executed and cannot dump the processor information.
>
> Without those information, it's very difficult for the BIOS developers locate
> the root cause of stack overflow. And without a workable stack, the developer
> cannot event use single step to debug the UEFI driver with JTAG debugger.
>
> In order to make sure the exception handler to execute normally after stack
> overflow. We need separate stacks for exception handlers in case of unusable
> stack.
>
> IA processor allows to switch to a new stack during handling interrupt and
> exception. But X64 and IA32 provides different ways to make it. X64 provides
> interrupt stack table (IST) to allow maximum 7 different exceptions to have
> new stack for its handler. IA32 doesn't have IST mechanism and can only use
> task gate to do it since task switch allows to load a new stack through its
> task-state segment (TSS).
>
> Note: Stack switch needs to allocate memory pages to be new stacks. So this
>   functionality works only in the boot phases capable of memory
>   allocation (besides the paging, for the sake of Stack Guard). In
>   other words, only DXE phase can supports Stack Guard with stack switch.
>
> Cc: Star Zeng <star.z...@intel.com<mailto:star.z...@intel.com>>
> Cc: Eric Dong <eric.d...@intel.com<mailto:eric.d...@intel.com>>
> Cc: Jiewen Yao <jiewen@intel.com<mailto:jiewen@intel.com>>
> Cc: Michael Kinney 
> <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
> Suggested-by: Ayellet Wolman 
> <ayellet.wol...@intel.com<mailto:ayellet.wol...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>
> ---
>  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  22 ++
>  .../Dxe

Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

Jeff,

Stack guard will still work. But the developer cannot know what’s going on 
without exception dumping message when stack overflow occurs.

Thanks,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Wednesday, November 01, 2017 10:59 AM
To: Wang, Jian J <jian.j.w...@intel.com>; Yao, Jiewen <jiewen@intel.com>; 
edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Dong, Eric 
<eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: 答复: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch 
support

Jian,

No. I suggest to fix #109 in another separate patch.

But to fix #109, we have to makes sure AsmWriteTr() and some definitions are in 
MdePkg.
But I have no strong opinion to add them into MdePkg in this patch.

I have another question: If NULL CPU exception handler instance is chosen, 
could Stack Switch work if PCD PcdCpuStackGuard is set to TRUE.

Thanks!
Jeff

发件人: Wang, Jian J<mailto:jian.j.w...@intel.com>
发送时间: 2017年11月1日 10:48
收件人: Fan Jeff<mailto:vanjeff_...@hotmail.com>; Yao, 
Jiewen<mailto:jiewen@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Kinney, Michael D<mailto:michael.d.kin...@intel.com>; Dong, 
Eric<mailto:eric.d...@intel.com>; Zeng, Star<mailto:star.z...@intel.com>
主题: RE: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

Hi Jeff,

Thanks for the feedback. Are you suggesting to fix Bugzilla 109 in this patch?

Thanks,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Wednesday, November 01, 2017 10:33 AM
To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Wang, Jian 
J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Zeng, Star 
<star.z...@intel.com<mailto:star.z...@intel.com>>
Subject: 答复: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch 
support

Per https://bugzilla.tianocore.org/show_bug.cgi?id=109, TR should be setup 
(Such as in DxeIplPeim) even though NULL Cpu Exception Handler instance is 
chosen.

For long term, I agree we need to move AsmWriteTr, IA32_TASK_STATE_SEGMENT, 
IA32_TSS_DESCRIPTOR to MdePkg(Such as BaseLib)
For this patch, I have no strong opinion.


发件人: Yao, Jiewen<mailto:jiewen@intel.com>
发送时间: 2017年11月1日 9:56
收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Kinney, Michael D<mailto:michael.d.kin...@intel.com>; Dong, 
Eric<mailto:eric.d...@intel.com>; Zeng, Star<mailto:star.z...@intel.com>
主题: Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch 
support

Hi Jian
Thanks for the patch.

Can we move all IA32 defined data structure or function to MdePkg?
Such as: AsmWriteTr, IA32_TASK_STATE_SEGMENT, IA32_TSS_DESCRIPTOR

I am also curious why we use different policy for other boot mode.
Can we use consistent policy?
> +  if (PcdGetBool (PcdCpuStackGuard)) {
> +//
> +// Stack Guard works with the support of page table established and
> +// memory management. So we have to exclude those boot modes
> without
> +// them.
> +//
> +switch (GetBootModeHob()) {
> +case BOOT_ON_FLASH_UPDATE:
> +case BOOT_IN_RECOVERY_MODE:
> +    case BOOT_ON_S3_RESUME:
> +  break;
> +
> +default:
> +  ArchSetupExcpetionStack (IdtTable);
> +  break;
> +}
> +  }


Thank you
Yao Jiewen


> -Original Message-
> From: Wang, Jian J
> Sent: Tuesday, October 31, 2017 10:24 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
> <eric.d...@intel.com<mailto:eric.d...@intel.com>>; Yao,
> Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Kinney, Michael D
> <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
> Subject: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> support
>
> If Stack Guard is enabled and there's really a stack overflow happened during
> boot, a Page Fault exception will be triggered. Because the stack is out of
> usage, the exception handler, which shares the stack with normal UEFI driver,
> cannot be executed and cannot dump the processor information.
>
> Without those information, it's very difficult for the BIOS developers locate
> the root cause of stack overflow. And without a workable stack, the developer
> cannot event use single step to debug the UEFI driver with JTAG debugger.
>
> In order to make sure t

Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

Jeff,

Sorry for the misunderstanding. I think stack switch cannot work with NULL 
exception handler. But without exception handler, what do we need stack switch 
for?

Thanks,
Jian

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Wednesday, November 01, 2017 11:09 AM
> To: Fan Jeff <vanjeff_...@hotmail.com>; Yao, Jiewen <jiewen@intel.com>;
> edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> Jeff,
> 
> Stack guard will still work. But the developer cannot know what’s going on
> without exception dumping message when stack overflow occurs.
> 
> Thanks,
> Jian
> 
> From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
> Sent: Wednesday, November 01, 2017 10:59 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; Yao, Jiewen <jiewen@intel.com>;
> edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: 答复: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> Jian,
> 
> No. I suggest to fix #109 in another separate patch.
> 
> But to fix #109, we have to makes sure AsmWriteTr() and some definitions are 
> in
> MdePkg.
> But I have no strong opinion to add them into MdePkg in this patch.
> 
> I have another question: If NULL CPU exception handler instance is chosen,
> could Stack Switch work if PCD PcdCpuStackGuard is set to TRUE.
> 
> Thanks!
> Jeff
> 
> 发件人: Wang, Jian J<mailto:jian.j.w...@intel.com>
> 发送时间: 2017年11月1日 10:48
> 收件人: Fan Jeff<mailto:vanjeff_...@hotmail.com>; Yao,
> Jiewen<mailto:jiewen@intel.com>; edk2-devel@lists.01.org<mailto:edk2-
> de...@lists.01.org>
> 抄送: Kinney, Michael D<mailto:michael.d.kin...@intel.com>; Dong,
> Eric<mailto:eric.d...@intel.com>; Zeng, Star<mailto:star.z...@intel.com>
> 主题: RE: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> support
> 
> Hi Jeff,
> 
> Thanks for the feedback. Are you suggesting to fix Bugzilla 109 in this patch?
> 
> Thanks,
> Jian
> 
> From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
> Sent: Wednesday, November 01, 2017 10:33 AM
> To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>;
> Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; edk2-
> de...@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Kinney, Michael D
> <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Dong, Eric
> <eric.d...@intel.com<mailto:eric.d...@intel.com>>; Zeng, Star
> <star.z...@intel.com<mailto:star.z...@intel.com>>
> Subject: 答复: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> Per https://bugzilla.tianocore.org/show_bug.cgi?id=109, TR should be setup
> (Such as in DxeIplPeim) even though NULL Cpu Exception Handler instance is
> chosen.
> 
> For long term, I agree we need to move AsmWriteTr,
> IA32_TASK_STATE_SEGMENT, IA32_TSS_DESCRIPTOR to MdePkg(Such as
> BaseLib)
> For this patch, I have no strong opinion.
> 
> 
> 发件人: Yao, Jiewen<mailto:jiewen@intel.com>
> 发送时间: 2017年11月1日 9:56
> 收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; edk2-
> de...@lists.01.org<mailto:edk2-devel@lists.01.org>
> 抄送: Kinney, Michael D<mailto:michael.d.kin...@intel.com>; Dong,
> Eric<mailto:eric.d...@intel.com>; Zeng, Star<mailto:star.z...@intel.com>
> 主题: Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> Hi Jian
> Thanks for the patch.
> 
> Can we move all IA32 defined data structure or function to MdePkg?
> Such as: AsmWriteTr, IA32_TASK_STATE_SEGMENT, IA32_TSS_DESCRIPTOR
> 
> I am also curious why we use different policy for other boot mode.
> Can we use consistent policy?
> > +  if (PcdGetBool (PcdCpuStackGuard)) {
> > +//
> > +// Stack Guard works with the support of page table established and
> > +// memory management. So we have to exclude those boot modes
> > without
> > +// them.
> > +//
> > +switch (GetBootModeHob()) {
> > +case BOOT_ON_FLASH_UPDATE:
> > +case BOOT_IN_RECOVERY_MODE:
> > +case BOOT_ON_S3_RESUME:
> > +  break;
> > +
> > +default:
> > +  ArchSetupExcpetionStack (IdtTable);
> > +  break;
> > +}
&g

Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

Hi Jiewen,

Thanks for the feedback. 

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, November 01, 2017 9:57 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: RE: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> support
> 
> Hi Jian
> Thanks for the patch.
> 
> Can we move all IA32 defined data structure or function to MdePkg?
> Such as: AsmWriteTr, IA32_TASK_STATE_SEGMENT, IA32_TSS_DESCRIPTOR
> 

Sure we can.

> I am also curious why we use different policy for other boot mode.
> Can we use consistent policy?
> > +  if (PcdGetBool (PcdCpuStackGuard)) {
> > +//
> > +// Stack Guard works with the support of page table established and
> > +// memory management. So we have to exclude those boot modes
> > without
> > +// them.
> > +//
> > +switch (GetBootModeHob()) {
> > +case BOOT_ON_FLASH_UPDATE:
> > +case BOOT_IN_RECOVERY_MODE:
> > +case BOOT_ON_S3_RESUME:
> > +  break;
> > +
> > +default:
> > +  ArchSetupExcpetionStack (IdtTable);
> > +  break;
> > +}
> > +  }
> 

As far as I'm aware of, those boot modes cannot provide both paging and
memory management, which are needed by stack guard to work. Let me know
if I'm wrong.

> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Tuesday, October 31, 2017 10:24 PM
> > To: edk2-devel@lists.01.org
> > Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Yao,
> > Jiewen <jiewen@intel.com>; Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > Subject: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> > support
> >
> > If Stack Guard is enabled and there's really a stack overflow happened 
> > during
> > boot, a Page Fault exception will be triggered. Because the stack is out of
> > usage, the exception handler, which shares the stack with normal UEFI 
> > driver,
> > cannot be executed and cannot dump the processor information.
> >
> > Without those information, it's very difficult for the BIOS developers 
> > locate
> > the root cause of stack overflow. And without a workable stack, the 
> > developer
> > cannot event use single step to debug the UEFI driver with JTAG debugger.
> >
> > In order to make sure the exception handler to execute normally after stack
> > overflow. We need separate stacks for exception handlers in case of unusable
> > stack.
> >
> > IA processor allows to switch to a new stack during handling interrupt and
> > exception. But X64 and IA32 provides different ways to make it. X64 provides
> > interrupt stack table (IST) to allow maximum 7 different exceptions to have
> > new stack for its handler. IA32 doesn't have IST mechanism and can only use
> > task gate to do it since task switch allows to load a new stack through its
> > task-state segment (TSS).
> >
> > Note: Stack switch needs to allocate memory pages to be new stacks. So this
> >   functionality works only in the boot phases capable of memory
> >   allocation (besides the paging, for the sake of Stack Guard). In
> >   other words, only DXE phase can supports Stack Guard with stack 
> > switch.
> >
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Michael Kinney <michael.d.kin...@intel.com>
> > Suggested-by: Ayellet Wolman <ayellet.wol...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  22 ++
> >  .../DxeCpuExceptionHandlerLib.inf  |   5 +
> >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  19 +
> >  .../Ia32/ArchExceptionHandler.c| 135 +++
> >  .../Ia32/ArchInterruptDefs.h   | 136 +++
> >  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> > +
> >  .../PeiCpuExceptionHandlerLib.inf  |   1 +
> >  .../SecPeiCpuExceptionHandlerLib.inf   |   3 +
> >  .../SmmCpuExceptionHandlerLib.inf  |   1 +
> >  .../X64/ArchExceptionHandler.c | 108 ++
> >  .

Re: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

Hi Jeff,

Thanks for the feedback.

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Wednesday, November 01, 2017 10:37 AM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Yao, Jiewen 
<jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng, Star 
<star.z...@intel.com>
Subject: 答复: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack 
switch support


1.  Should add EFIAPI for the following function.
+VOID
+AsmWriteTr (
+  UINT16 Selector
+  );


2.  Should not add EFIAPI for the following function.
+VOID
+EFIAPI
+ArchSetupExcpetionStack (
+  IN IA32_IDT_GATE_DESCRIPTOR   *IdtTable
+  )

发件人: Jian J Wang<mailto:jian.j.w...@intel.com>
发送时间: 2017年10月31日 22:26
收件人: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Michael Kinney<mailto:michael.d.kin...@intel.com>; Jiewen 
Yao<mailto:jiewen@intel.com>; Eric Dong<mailto:eric.d...@intel.com>; Star 
Zeng<mailto:star.z...@intel.com>
主题: [edk2] [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch 
support

If Stack Guard is enabled and there's really a stack overflow happened during
boot, a Page Fault exception will be triggered. Because the stack is out of
usage, the exception handler, which shares the stack with normal UEFI driver,
cannot be executed and cannot dump the processor information.

Without those information, it's very difficult for the BIOS developers locate
the root cause of stack overflow. And without a workable stack, the developer
cannot event use single step to debug the UEFI driver with JTAG debugger.

In order to make sure the exception handler to execute normally after stack
overflow. We need separate stacks for exception handlers in case of unusable
stack.

IA processor allows to switch to a new stack during handling interrupt and
exception. But X64 and IA32 provides different ways to make it. X64 provides
interrupt stack table (IST) to allow maximum 7 different exceptions to have
new stack for its handler. IA32 doesn't have IST mechanism and can only use
task gate to do it since task switch allows to load a new stack through its
task-state segment (TSS).

Note: Stack switch needs to allocate memory pages to be new stacks. So this
  functionality works only in the boot phases capable of memory
  allocation (besides the paging, for the sake of Stack Guard). In
  other words, only DXE phase can supports Stack Guard with stack switch.

Cc: Star Zeng <star.z...@intel.com<mailto:star.z...@intel.com>>
Cc: Eric Dong <eric.d...@intel.com<mailto:eric.d...@intel.com>>
Cc: Jiewen Yao <jiewen@intel.com<mailto:jiewen@intel.com>>
Cc: Michael Kinney 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Suggested-by: Ayellet Wolman 
<ayellet.wol...@intel.com<mailto:ayellet.wol...@intel.com>>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>
---
 .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  22 ++
 .../DxeCpuExceptionHandlerLib.inf  |   5 +
 .../Library/CpuExceptionHandlerLib/DxeException.c  |  19 +
 .../Ia32/ArchExceptionHandler.c| 135 +++
 .../Ia32/ArchInterruptDefs.h   | 136 +++
 .../Ia32/ExceptionTssEntryAsm.nasm | 398 +
 .../PeiCpuExceptionHandlerLib.inf  |   1 +
 .../SecPeiCpuExceptionHandlerLib.inf   |   3 +
 .../SmmCpuExceptionHandlerLib.inf  |   1 +
 .../X64/ArchExceptionHandler.c | 108 ++
 .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |  40 +++
 .../X64/ExceptionHandlerAsm.S  |  12 +
 .../X64/ExceptionHandlerAsm.asm|  12 +
 .../X64/ExceptionHandlerAsm.nasm   |  12 +
 14 files changed, 904 insertions(+)
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
index 740a58828b..fd4a26a458 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 

 #define  CPU_EXCEPTION_NUM  32
 #define  CPU_INTERRUPT_NUM 256
@@ -288,5 +289,26 @@ CommonExceptionHandlerWorker (
   IN EXCEPTION_HANDLER_DATA  *ExceptionHandlerData
   );

+/**
+  Load given selector into TR register
+
+  @param Selector Task segment selector
+**/
+VOID
+AsmWriteTr (
+  UINT16 Selector
+  );
+
+/**
+  Setup separate stack for specific exceptions.
+
+  @param[in] IdtTableIDT table base.
+**/
+VOID
+EFIAPI
+ArchSetupEx

Re: [edk2] [PATCH] MdeModulePkg/MdeModulePkg.dec: Clarify usage of PcdHeapGuardPropertyMask

[Wang, Jian J]

Thanks. .uni file will be updated accordingly.

Regards,
Jian

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, December 21, 2017 1:15 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/MdeModulePkg.dec: Clarify usage of
> PcdHeapGuardPropertyMask
> 
> Please also the *.uni file accordingly, with that, Reviewed-by: Star Zeng
> <star.z...@intel.com>
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, December 21, 2017 1:08 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: [PATCH] MdeModulePkg/MdeModulePkg.dec: Clarify usage of
> PcdHeapGuardPropertyMask
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> ---
>  MdeModulePkg/MdeModulePkg.dec | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index 8efad57766..d134ec798a 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -939,13 +939,17 @@
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType|0x0|UINT64|0x30
> 001053
> 
>## This mask is to control Heap Guard behavior.
> +  # Note that due to the limit in pool memory implementation and the
> alignment
> +  # requirement of UEFI spec, BIT7 is a try-best setting which cannot 
> guarantee
> +  # that the returned pool is exactly adjacent to head guard page or tail 
> guard
> +  # page.
>#   BIT0 - Enable UEFI page guard.
>#   BIT1 - Enable UEFI pool guard.
>#   BIT2 - Enable SMM page guard.
>#   BIT3 - Enable SMM pool guard.
>#   BIT7 - The direction of Guard Page for Pool Guard.
> -  #  0 - The returned pool is adjacent to the bottom guard page.
> -  #  1 - The returned pool is adjacent to the top guard page.
> +  #  0 - The returned pool is near the tail guard page.
> +  #  1 - The returned pool is near the head guard page.
># @Prompt The Heap Guard feature mask
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask|0x0|UINT8|0
> x30001054
> 
> --
> 2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

[Wang, Jian J]

Hi Laszlo,

Thank you very much for such thorough review. I'd like to explain a bit in 
advance.

Putting aside the specific coding issues in my patch, one thing is clear that 
SMM mode
has its own page table. CpuDxe should not touch it even if its public interface 
is called
via gBS services, because it has no knowledge of SMM internal things and it 
might
jeopardize SMM operation if it does. But current CpuDxe doesn't take this into 
account.
I think it should be fixed anyway, even there's no Heap Guard feature, since 
current
design allows SMM to touch memory owned by DXE but not vice versa.

The basic idea of this patch is, if we want to access DXE page table in SMM 
mode, we
cannot do this via CR3 register (it has been reloaded by SMM) directly but via 
a stored
value in a global. This is feasible because page table is just a chunk of 
normal memory.
All we need is an entry address pointer. When exiting SMM mode back to DXE, the
updated page table will take effect immediately once CR3 is restored to DXE 
version.
That means we can change DXE page table attributes even in SMM mode.

Please see my other responses below.

Regards,
Jian

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, June 11, 2018 8:18 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Yao, Jiewen ; Dong,
> Eric 
> Subject: Re: [edk2] [PATCH 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE)
> page table in SMM mode
> 
> Hi Jian,
> 
> On 06/11/18 09:08, Jian J Wang wrote:
> > The SMM version of MemoryAllocationLib allows to free memory allocated
> > in DXE (before EndOfDxe). This is done by checking the memory range and
> > calling gBS services to do real operation if the memory to free is out
> > of SMRAM. This would cause problem if some memory related features, like
> > Heap Guard, have to update page table to change memory attributes.
> > Because page table in SMM mode is different from DXE mode, gBS memory
> > services cannot get the correct attributes of DXE memory from SMM page
> > table and then cause incorrect memory manipulations.
> 
> (1) I think this description makes sense, but it does not highlight the
> involvement of CpuDxe.
> 
> (1a) Please reference "MdePkg/Library/SmmMemoryAllocationLib" specifically.
> 
> (1b) The SmmMemoryAllocationLib instance implies that the call chain
> starts with a DXE_SMM_DRIVER calling FreePool() or FreePages().
> 
> DXE_SMM_DRIVERs can only call boot services, and protocols located with
> boot services, in their entry point functions.
> 
> CpuDxe is a DXE_DRIVER and it provides the CPU arch protocol (and the MP
> services protocol). Thus, our call chain can only occur if:
> 
> - a DXE_SMM_DRIVER calls the FreePool() or FreePages() library API,
> 
> - in its entry point function,
> 
> - releasing memory that's not SMRAM,
> 
> - and the heap guard feature is enabled, so the FreePool() or
>   FreePages() boot service ends up calling
>   EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes().
> 
> Please include this information in the commit message.
> 

Sure. I'll add it. Thanks.

> (2) Can you remind me how the SMM page tables map non-SMRAM memory?
> 
> Because, I assume that, after a FreePages() libary API call, the freed
> memory should not be accessible to either SMM code or normal DXE code.
> This seems to imply that both sets of page tables should be modified.
> What am I missing?
> 

For both SMM and DXE, we just do 1:1 full memory mapping in paging but in
different page tables. As far as I know, there's no such rules that freed pages
should not be accessible. I think it's just implementation dependent.

> >
> > The solution in this patch is to store the DXE page table information
> > (e.g. value of CR0, CR3 registers, etc.) in a global variable of CpuDxe
> > driver. If CpuDxe detects it's in SMM mode, it will use this global
> > variable to access page table instead of current processor registers.
> >
> > Change-Id: If810bb1828160b8bdd8cb616d86df2859c74971f
> 
> (3) I think this comes from Gerrit. Do you really need the "Change-Id"
> tag in the commit message? It doesn't say anything to the upstream edk2
> users.
> 
> If you really need it, I don't mind it though; just please let's not add
> it due to oversight.
> 

Sorry, it's added by our internal tool automatically. It can be deleted.

> (4) Please make sure that you don't *push* the patch with Gerrit. Gerrit
> does bad things to git metadata. Please see
> <http://mid.mail-
> archive.com/4A89E2EF3DFEDB4C8BFDE51014F606A14E22344D@SHSMSX104.c
> cr.corp.intel.com>.
> 

Sure.

> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Jiewen Yao 
> > Cc: Ruiyu Ni 
> > Co

Re: [edk2] [PATCH v2 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode

[Wang, Jian J]

Hi Laszlo,

Regards,
Jian

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, June 13, 2018 11:10 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Yao, Jiewen ; Dong,
> Eric 
> Subject: Re: [edk2] [PATCH v2 1/2] UefiCpuPkg/CpuDxe: allow accessing (DXE)
> page table in SMM mode
> 
> Hi Jian,
> 
> I have three comments:
> 
> On 06/13/18 07:35, Jian J Wang wrote:
> >> v2:
> >>   a. add more specific explanations in commit message
> >>   b. add more comments in code
> >>   c. remove redundant logic in IsInSmm()
> >>   d. fix a logic hole in GetCurrentPagingContext()
> >>   e. replace meanless constant macro with meaning ones
> >
> > The MdePkg/Library/SmmMemoryAllocationLib, used only by
> DXE_SMM_DRIVER,
> > allows to free memory allocated in DXE (before EndOfDxe). This is done
> > by checking the memory range and calling gBS services to do real
> > operation if the memory to free is out of SMRAM. If some memory related
> > features, like Heap Guard, are enabled, gBS interface will turn to
> > EFI_CPU_ARCH_PROTOCOL.SetMemoryAttributes(), provided by
> > DXE driver UefiCpuPkg/CpuDxe, to change memory paging attributes. This
> > means we have part of DXE code running in SMM mode in certain
> > circumstances.
> >
> > Because page table in SMM mode is different from DXE mode and CpuDxe
> > always uses current registers (CR0, CR3, etc.) to get memory paging
> > attributes, it cannot get the correct attributes of DXE memory in SMM
> > mode from SMM page table. This will cause incorrect memory manipulations,
> > like fail the releasing of Guard pages if Heap Guard is enabled.
> >
> > The solution in this patch is to store the DXE page table information
> > (e.g. value of CR0, CR3 registers, etc.) in a global variable of CpuDxe
> > driver. If CpuDxe detects it's in SMM mode, it will use this global
> > variable to access page table instead of current processor registers.
> > This can avoid retrieving wrong DXE memory paging attributes and changing
> > SMM page table attributes unexpectedly.
> >
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Jiewen Yao 
> > Cc: Ruiyu Ni 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  UefiCpuPkg/CpuDxe/CpuDxe.inf |   1 +
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 159
> ++-
> >  2 files changed, 123 insertions(+), 37 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > index 3c938cee53..ce2bd3627c 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > +++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > @@ -66,6 +66,7 @@
> >  [Protocols]
> >gEfiCpuArchProtocolGuid   ## PRODUCES
> >gEfiMpServiceProtocolGuid ## PRODUCES
> > +  gEfiSmmBase2ProtocolGuid  ## CONSUMES
> 
> (1) In my v1 review, I suggested "SOMETIMES_CONSUMES" for this hint.
> 
> And that's because CpuDxe can be included in platform builds that don't
> include the SMM driver stack at all; in that case,
> gEfiSmmBase2ProtocolGuid will not be available and will not be consumed.
> In other words, we cannot say that the protocol is always consumed.
> 

Make sense.

> >
> >  [Guids]
> >gIdleLoopEventGuid## CONSUMES   ## 
> > Event
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index e2595b4d89..b7e75922b6 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -23,10 +23,21 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >
> >  #include "CpuDxe.h"
> >  #include "CpuPageTable.h"
> >
> > +///
> > +/// Paging registers
> > +///
> > +#define CR0_WP  BIT16
> > +#define CR0_PG  BIT31
> > +#define CR4_PSE BIT4
> > +#define CR4_PAE BIT5
> 
> (2a) I think the BITxx -> CRx_xx macro replacements should have been
> split to a separate patch.
> 

Sure.

> > +
> >  ///
> >  /// Page Table Entry
> >  ///
> > @@ -87,7 +98,46 @@ PAGE_ATTRIBUTE_TABLE mPageAttributeTable[] = {
> >{Page1G,  SIZE_1GB, PAGING_1G_ADDRESS_MASK_64},
> >  };
> >
> > -PAGE_TABLE_POOL   *mPageTablePool = NULL;
> > +PAGE_TABLE_POO

Re: [edk2] [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard feature for SMM mode

[Wang, Jian J]

I took a look at current available protocols and found that we have already 
gEfiSmmCpuProtocolGuid and gEfiSmmCpuServiceProtocolGuid. Just like 
gEfiCpuArchProtocolGuid which provides the API to update memory attributes 
(MTRR and paging), how about we add new interfaces to gEfiSmmCpuProtocolGuid or 
gEfiSmmCpuServiceProtocolGuid (I'm not sure which is more appropriate for this 
situation)?

gEfiSmmCpuProtocolGuid is defined in MdePkg. I would assume it's spec related. 
gEfiSmmCpuServiceProtocolGuid is defined in UefiCpuPkg, which looks like to be 
a better candidate.

From: Yao, Jiewen
Sent: Wednesday, October 18, 2017 1:55 PM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Kinney, 
Michael D <michael.d.kin...@intel.com>
Subject: RE: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard 
feature for SMM mode

I do not think there is interface *change*.
We can define a *new* interface in MdeModulePkg\Include\Protocol.

Thank you
Yao Jiewen

From: Wang, Jian J
Sent: Wednesday, October 18, 2017 1:52 PM
To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: RE: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard 
feature for SMM mode

Yes, we can. But that also means public interfaces changes, which might affect 
internal/external users. Any formal procedure required to make such kind of 
changes?

From: Yao, Jiewen
Sent: Wednesday, October 18, 2017 1:07 PM
To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: RE: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard 
feature for SMM mode

Hi
I am a little worried about adding page table management in PiSmmCore directly.

Can we define an interface between PiSmmCore and PiSmmCpu driver to set memory 
attribute? Like what we did in DxeCore and DxeCpu driver.

Thank you
Yao Jiewen

From: Wang, Jian J
Sent: Tuesday, October 17, 2017 9:29 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Yao, Jiewen 
<jiewen@intel.com<mailto:jiewen@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard feature 
for SMM mode

> According to Eric's feedback:
> a. Remove local variable initializer with memory copy from globals
> b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
>message
> c. Remove unnecessary debug code
> d. Change name of function InitializePageTableLib to
>InitializePageTableGlobals
>
> Other changes:
> e. Fix issues in 32-bit boot mode
> f. Coding style cleanup

This feature makes use of paging mechanism to add a hidden (not present)
page just before and after the allocated memory block. If the code tries
to access memory outside of the allocated part, page fault exception will
be triggered.

This feature is controlled by three PCDs:

gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType

BIT2 and BIT3 of PcdHeapGuardPropertyMask can be used to enable or disable
memory guard for SMM page and pool respectively. PcdHeapGuardPoolType and/or
PcdHeapGuardPageType are used to enable or disable guard for specific type
of memory. For example, we can turn on guard only for EfiRuntimeServicesCode
and EfiRuntimeServicesData by setting the PCD with value 0x60.

Pool memory is not ususally integer multiple of one page, and is more likely
less than a page. There's no way to monitor the overflow at both top and
bottom of pool memory. BIT7 of PcdHeapGuardPropertyMask is used to control
how to position the head of pool memory so that it's easier to catch memory
overflow in memory growing direction or in decreasing direction.

Cc: Star Zeng <star.z...@intel.com<mailto:star.z...@intel.com>>
Cc: Eric Dong <eric.d...@intel.com<mailto:eric.d...@intel.com>>
Cc: Jiewen Yao <jiewen@intel.com<mailto:jiewen@intel.com>>
Cc: Michael Kinney 
<

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 26, 2017 6:08 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> Hello Jian,
> 
> On 10/23/17 08:50, Jian J Wang wrote:
> > More than one entry of RT_CODE memory might cause boot problem for
> some
> > old OSs. This patch will fix this issue to keep OS compatibility as much
> > as possible.
> >
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> Thank you again for the explanation elsewhere in this thread. I filed
> the following TianoCore Bugzilla entry about this issue, and assigned it
> to you:
> 
>   https://bugzilla.tianocore.org/show_bug.cgi?id=753
> 
> Can you please read the BZ, and add corrections (in further comments) if
> you think any such are necessary?
> 
> I suggest that the BZ reference be included in the commit message. (If
> there is no v2 necessary for this patch, then Eric can do that as well,
> when he commits / pushes your patch.)
> 

You're welcome. Those information should have been provided at the very 
beginning. 
I think I have a lot to learn from you to do better for open source community. 
Like the
Bugzilla entry. I'd say this is the best description I've ever read.

> I think the patch is good, but I have one technical question below:
> 
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index d312eb66f8..0802464b9d 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -829,6 +829,15 @@ RefreshGcdMemoryAttributesFromPaging (
> >  // Sync real page attributes to GCD
> >  BaseAddress   = MemorySpaceMap[Index].BaseAddress;
> >  MemorySpaceLength = MemorySpaceMap[Index].Length;
> > +Capabilities  = MemorySpaceMap[Index].Capabilities |
> > +EFI_MEMORY_PAGETYPE_MASK;
> > +Status = gDS->SetMemorySpaceCapabilities (
> > +BaseAddress,
> > +MemorySpaceLength,
> > +Capabilities
> > +);
> > +ASSERT_EFI_ERROR (Status);
> > +
> 
> This logic -- i.e. the addition of the EFI_MEMORY_PAGETYPE_MASK
> capabilities -- will be applied to *all* GCD memory space map entries
> that have a type different from "EfiGcdMemoryTypeNonExistent".
> 
> I wonder if that's a good idea -- for example I don't think it makes
> much sense for "EfiGcdMemoryTypeMemoryMappedIo".
> 
> How about the following alternatives:
> 
> (1) *Either* restrict this capability addition to
> EfiGcdMemoryTypeSystemMemory (and maybe some other GCD types as well?),
> 
> (2) *or*, remove this change, and:
> 
> >  while (MemorySpaceLength > 0) {
> >if (PageLength == 0) {
> >  PageEntry = GetPageTableEntry (, BaseAddress,
> );
> > @@ -846,7 +855,6 @@ RefreshGcdMemoryAttributesFromPaging (
> >  if (Attributes != (MemorySpaceMap[Index].Attributes &
> EFI_MEMORY_PAGETYPE_MASK)) {
> >DoUpdate = TRUE;
> >Attributes |= (MemorySpaceMap[Index].Attributes &
> ~EFI_MEMORY_PAGETYPE_MASK);
> > -  Capabilities = Attributes | MemorySpaceMap[Index].Capabilities;
> >  } else {
> >DoUpdate = FALSE;
> >  }
> > @@ -854,8 +862,8 @@ RefreshGcdMemoryAttributesFromPaging (
> >
> >Length = MIN (PageLength, MemorySpaceLength);
> >if (DoUpdate) {
> > -gDS->SetMemorySpaceCapabilities (BaseAddress, Length, 
> > Capabilities);
> > -gDS->SetMemorySpaceAttributes (BaseAddress, Length, Attributes);
> > +Status = gDS->SetMemorySpaceAttributes (BaseAddress, Length,
> Attributes);
> > +ASSERT_EFI_ERROR (Status);
> >  DEBUG ((DEBUG_INFO, "Update memory space attribute: [%02d] %016lx
> - %016lx (%08lx -> %08lx)\r\n",
> >   Index, BaseAddress, BaseAddress + Length - 1,
> >   MemorySpaceMap[Index].Attributes, 
> > Attributes));
> >
> 
> ke

Re: [edk2] [PATCH v3 0/6] Implement heap guard feature

[Wang, Jian J]

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 26, 2017 9:27 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: Yao, Jiewen <jiewen@intel.com>; edk2-devel@lists.01.org; Kinney,
> Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> <ayellet.wol...@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng, Star
> <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH v3 0/6] Implement heap guard feature
> 
> Hi Jian,
> 
> On 10/26/17 09:38, Wang, Jian J wrote:
> > Thanks for the feedback.
> >
> >> -Original Message-
> >> From: Yao, Jiewen
> >> Sent: Thursday, October 26, 2017 2:49 PM
> >> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> >> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> >> <ayellet.wol...@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng, Star
> >> <star.z...@intel.com>; Yao, Jiewen <jiewen@intel.com>
> >> Subject: RE: [edk2] [PATCH v3 0/6] Implement heap guard feature
> >>
> >> That is great work. Jian.
> >>
> >> Some suggestion for your consideration:
> >>
> >> 0) I suggest add Laszlo to review SMM part, and add Ruiyu to review
> >> SMM_MEMORY_ATTRIBUTE_PROTOCOL.
> >>
> >
> > Ok, already pinged them.
> >
> >> 1) Would you please mention what test we have done for this feature?
> >> Such as OVMF/realPlatform? IA32/X64?
> >>
> >
> > I did following test:
> >
> > Boot to shell (OVMF/Intel platform) (both IA32 and X64)
> > Boot to Fedora 25 (64 only)
> 
> May I ask if you used KVM virtualization (i.e., a Linux host computer)
> for this?
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-
> QEMU,-KVM-and-libvirt
> 

No, I'm using Qemu on Windows. I think Qemu doesn't support VM on Windows
machine but I do enabled SMM mode for it. Please let me know if there's any 
differences between them I should be aware of.

> > Windows 10 boot loader has a limit of 512-memory-descriptor, which will
> > cause boot failure. This is due to a fact that enabling this feature will 
> > cause
> > more memory fragments (pool memory). Since this is a debug feature, I
> suppose
> > this is an acceptable result.
> 
> This feature is large; I can't even attempt to review it in the time
> that I could allocate to it.
> 
> However, I would like to regression test it (thank you Jiewen for the
> reference!) Preferably, given that a v4 is already planned, I should
> test v4.
> 
> If you can post v4 on Oct 27th (tomorrow), I'll make an effort to test
> it in the afternoon / evening, on the 27th. (Please CC me.) Next week I
> will be mostly inactive on edk2-devel -- I wouldn't like to block your
> work, but I also wouldn't like an OVMF regression.
> 

Thanks for trying. I'll try my best to send v4 today. I'd remind you in advance
I have already found heap overflow (just read) in UiApp and Openssl code.

> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard feature for SMM mode

[Wang, Jian J]

I forgot the dependency part. If so, it's ok to me to add a new protocol like 
gEdkiiSmmMemoryAttributeProtocol. I think this protocol will l be implemented 
in PiSmmCpuDxeSmm driver. If no other comments on this, I'll update the code 
and send the v3 patch soon.

From: Yao, Jiewen
Sent: Friday, October 20, 2017 9:37 AM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Kinney, 
Michael D <michael.d.kin...@intel.com>
Subject: RE: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard 
feature for SMM mode

I remember MdeModulePkg cannot depend on UefiCpuPkg. Is that correct, Mike?

Maybe we can define a new one in MdeModulePkg, such as 
gEdkiiSmmMemoryAttributeProtocol.

Thank you
Yao Jiewen


From: Wang, Jian J
Sent: Friday, October 20, 2017 8:55 AM
To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: RE: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard 
feature for SMM mode

I took a look at current available protocols and found that we have already 
gEfiSmmCpuProtocolGuid and gEfiSmmCpuServiceProtocolGuid. Just like 
gEfiCpuArchProtocolGuid which provides the API to update memory attributes 
(MTRR and paging), how about we add new interfaces to gEfiSmmCpuProtocolGuid or 
gEfiSmmCpuServiceProtocolGuid (I'm not sure which is more appropriate for this 
situation)?

gEfiSmmCpuProtocolGuid is defined in MdePkg. I would assume it's spec related. 
gEfiSmmCpuServiceProtocolGuid is defined in UefiCpuPkg, which looks like to be 
a better candidate.

From: Yao, Jiewen
Sent: Wednesday, October 18, 2017 1:55 PM
To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: RE: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard 
feature for SMM mode

I do not think there is interface *change*.
We can define a *new* interface in MdeModulePkg\Include\Protocol.

Thank you
Yao Jiewen

From: Wang, Jian J
Sent: Wednesday, October 18, 2017 1:52 PM
To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: RE: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard 
feature for SMM mode

Yes, we can. But that also means public interfaces changes, which might affect 
internal/external users. Any formal procedure required to make such kind of 
changes?

From: Yao, Jiewen
Sent: Wednesday, October 18, 2017 1:07 PM
To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: RE: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard 
feature for SMM mode

Hi
I am a little worried about adding page table management in PiSmmCore directly.

Can we define an interface between PiSmmCore and PiSmmCpu driver to set memory 
attribute? Like what we did in DxeCore and DxeCpu driver.

Thank you
Yao Jiewen

From: Wang, Jian J
Sent: Tuesday, October 17, 2017 9:29 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>; Yao, Jiewen 
<jiewen@intel.com<mailto:jiewen@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: [PATCH v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard feature 
for SMM mode

> According to Eric's feedback:
> a. Remove local variable initializer with memory copy from globals
> b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
>message
> c. Remove unnecessary debug code
> d. Change name of function InitializePageTableLib to
>Initiali

Re: [edk2] [patch 3/4] MdeModulePkg/DxeIplPeim: Refine coding style in function comments

[Wang, Jian J]

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>




> -Original Message-
> From: Bi, Dandan
> Sent: Friday, October 20, 2017 9:00 AM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J <jian.j.w...@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: [patch 3/4] MdeModulePkg/DxeIplPeim: Refine coding style in function
> comments
> 
> Make the comments align with the function.
> And add some missing function comments.
> 
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 14 +++---
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 15 +++
>  2 files changed, 18 insertions(+), 11 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> index ecf1866..f3aabdb 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> @@ -239,28 +239,28 @@ Decompress (
>OUT   VOID**OutputBuffer,
>OUT   UINTN   *OutputSize
>);
> 
>  /**
> -   Clear legacy memory located at the first 4K-page.
> +  Clear legacy memory located at the first 4K-page.
> 
> -   This function traverses the whole HOB list to check if memory from 0 to 
> 4095
> -   exists and has not been allocated, and then clear it if so.
> +  This function traverses the whole HOB list to check if memory from 0 to 
> 4095
> +  exists and has not been allocated, and then clear it if so.
> 
> -   @param HoStart The start of HobList passed to DxeCore.
> +  @param HobStart The start of HobList passed to DxeCore.
> 
>  **/
>  VOID
>  ClearFirst4KPage (
>IN  VOID *HobStart
>);
> 
>  /**
> -   Return configure status of NULL pointer detection feature
> +  Return configure status of NULL pointer detection feature.
> 
> -   @return TRUE   NULL pointer detection feature is enabled
> -   @return FALSE  NULL pointer detection feature is disabled
> +  @return TRUE   NULL pointer detection feature is enabled
> +  @return FALSE  NULL pointer detection feature is disabled
>  **/
>  BOOLEAN
>  IsNullDetectionEnabled (
>VOID
>);
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> index a10dea2..29b6205 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> @@ -30,16 +30,16 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> 
>  #include "DxeIpl.h"
>  #include "VirtualMemory.h"
> 
>  /**
> -   Clear legacy memory located at the first 4K-page, if available.
> +  Clear legacy memory located at the first 4K-page, if available.
> 
> -   This function traverses the whole HOB list to check if memory from 0 to 
> 4095
> -   exists and has not been allocated, and then clear it if so.
> +  This function traverses the whole HOB list to check if memory from 0 to 
> 4095
> +  exists and has not been allocated, and then clear it if so.
> 
> -   @param HoStart   The start of HobList passed to DxeCore.
> +  @param HobStart  The start of HobList passed to DxeCore.
> 
>  **/
>  VOID
>  ClearFirst4KPage (
>IN  VOID *HobStart
> @@ -84,10 +84,17 @@ ClearFirst4KPage (
>}
> 
>return;
>  }
> 
> +/**
> +  Return configure status of NULL pointer detection feature.
> +
> +  @return TRUE   NULL pointer detection feature is enabled
> +  @return FALSE  NULL pointer detection feature is disabled
> +
> +**/
>  BOOLEAN
>  IsNullDetectionEnabled (
>VOID
>)
>  {
> --
> 1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 2/4] IntelFrameworkModule/LegacyBios: Avoid explicit comparison for BOOLEAN

[Wang, Jian J]

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>




> -Original Message-
> From: Bi, Dandan
> Sent: Friday, October 20, 2017 9:00 AM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J <jian.j.w...@intel.com>; Gao, Liming <liming@intel.com>
> Subject: [patch 2/4] IntelFrameworkModule/LegacyBios: Avoid explicit
> comparison for BOOLEAN
> 
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> index e00..c6461f5 100644
> --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> @@ -804,11 +804,11 @@ EnableNullDetection (
>EFI_STATUSStatus;
>EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
> 
>if (((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0)
>||
> -  ((mEndOfDxe == TRUE)  &&
> +  ((mEndOfDxe)  &&
> ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT7|BIT0))
>  == (BIT7|BIT0)))
>   ) {
>  return;
>}
> @@ -854,11 +854,11 @@ DisableNullDetection (
>EFI_STATUSStatus;
>EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
> 
>if (((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0)
>||
> -  ((mEndOfDxe == TRUE)  &&
> +  ((mEndOfDxe)  &&
> ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT7|BIT0))
>  == (BIT7|BIT0)))
>   ) {
>  return;
>}
> --
> 1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 1/4] IntelFrameworkModulePkg/Csm: Refine coding style in comments

[Wang, Jian J]

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>


> -Original Message-
> From: Bi, Dandan
> Sent: Friday, October 20, 2017 9:00 AM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J <jian.j.w...@intel.com>; Gao, Liming <liming@intel.com>
> Subject: [patch 1/4] IntelFrameworkModulePkg/Csm: Refine coding style in
> comments
> 
> Make the comments follow Edk2 coding style:
> 1. Make the comments starts with /** and end with **/.
> 2. Make the comments descrition end with '.'
> 
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c | 8
> 
>  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c   | 8 
>  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosInterface.h  | 8
> 
>  3 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git
> a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
> b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
> index d2224a2..ebf03d3 100644
> --- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
> +++
> b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
> @@ -1731,12 +1731,12 @@ CheckKeyboardConnect (
>  return TRUE;
>}
>  }
> 
>  /**
> -   Disable NULL pointer detection
> -*/
> +  Disable NULL pointer detection.
> +**/
>  VOID
>  DisableNullDetection (
>VOID
>)
>  {
> @@ -1778,12 +1778,12 @@ DisableNullDetection (
>  DEBUG ((DEBUG_WARN, "!!! Page 0 is supposed to be disabled !!!\r\n"));
>}
>  }
> 
>  /**
> -   Enable NULL pointer detection
> -*/
> +   Enable NULL pointer detection.
> +**/
>  VOID
>  EnableNullDetection (
>VOID
>)
>  {
> diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> index 3176a98..e00 100644
> --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> @@ -792,12 +792,12 @@ ToggleEndOfDxeStatus (
>  // functions can be used to disable/enable NULL pointer detection 
> before/after
>  // accessing those memory.
>  //
> 
>  /**
> -   Enable NULL pointer detection
> -*/
> +   Enable NULL pointer detection.
> +**/
>  VOID
>  EnableNullDetection (
>VOID
>)
>  {
> @@ -842,12 +842,12 @@ EnableNullDetection (
>  ASSERT_EFI_ERROR (Status);
>}
>  }
> 
>  /**
> -   Disable NULL pointer detection
> -*/
> +   Disable NULL pointer detection.
> +**/
>  VOID
>  DisableNullDetection (
>VOID
>)
>  {
> diff --git
> a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosInterface.h
> b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosInterface.h
> index 20dfef3..86a3b09 100644
> --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosInterface.h
> +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosInterface.h
> @@ -1543,20 +1543,20 @@ EFI_STATUS
>  LegacyBiosInstallVgaRom (
>IN  LEGACY_BIOS_INSTANCE*Private
>);
> 
>  /**
> -   Enable NULL pointer detection
> -*/
> +   Enable NULL pointer detection.
> +**/
>  VOID
>  EnableNullDetection (
>VOID
>);
> 
>  /**
> -   Disable NULL pointer detection
> -*/
> +   Disable NULL pointer detection.
> +**/
>  VOID
>  DisableNullDetection (
>VOID
>);
> 
> --
> 1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg VarCheckHii: Make sure the bin at required alignment

[Wang, Jian J]

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>


> -Original Message-
> From: Zeng, Star
> Sent: Friday, December 29, 2017 6:14 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>;
> Yao, Jiewen <jiewen@intel.com>
> Subject: [PATCH] MdeModulePkg VarCheckHii: Make sure the bin at required
> alignment
> 
> According to UEFI/PI spec, the AllocateXXXPool() interfaces should
> return eight-byte aligned buffer that satisfies the required
> HEADER_ALIGNMENT which is 4.
> 
> This patch adds ASSERT to make sure the bin at required alignment,
> that can help catch the issue earlier about incorrect aligned buffer
> returned from AllocateXXXPool().
> 
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng <star.z...@intel.com>
> ---
>  MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c
> b/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c
> index c0efed450bfb..0db1383491f7 100644
> --- a/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c
> +++ b/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c
> @@ -1518,6 +1518,10 @@ BuildVarCheckHiiBin (
>//
>Data = AllocateRuntimeZeroPool (BinSize);
>ASSERT (Data != NULL);
> +  //
> +  // Make sure the allocated buffer for VarCheckHiiBin at required alignment.
> +  //
> +  ASSERT UINTN) Data) & (HEADER_ALIGNMENT - 1)) == 0);
>DEBUG ((DEBUG_INFO, "VarCheckHiiBin - built at 0x%x\n", Data));
> 
>//
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg VarCheckPcd: Make sure the bin at required alignment

[Wang, Jian J]

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>

> -Original Message-
> From: Zeng, Star
> Sent: Friday, December 29, 2017 6:19 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>;
> Yao, Jiewen <jiewen@intel.com>
> Subject: [PATCH] MdeModulePkg VarCheckPcd: Make sure the bin at required
> alignment
> 
> According to UEFI/PI spec, the AllocateXXXPool() interfaces should
> return eight-byte aligned buffer that satisfies the required
> HEADER_ALIGNMENT which is 4.
> 
> This patch adds ASSERT to make sure the bin at required alignment,
> that can help catch the issue earlier about incorrect aligned buffer
> returned from AllocateXXXPool().
> 
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng <star.z...@intel.com>
> ---
>  MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLibNullClass.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLibNullClass.c
> b/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLibNullClass.c
> index 72b0363b1979..d24ee966a44c 100644
> --- a/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLibNullClass.c
> +++ b/MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLibNullClass.c
> @@ -1,7 +1,7 @@
>  /** @file
>Var Check PCD handler.
> 
> -Copyright (c) 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -435,6 +435,10 @@ LocateVarCheckPcdBin (
>  //
>  mVarCheckPcdBin = AllocateRuntimeCopyPool (VarCheckPcdBinSize,
> VarCheckPcdBin);
>  ASSERT (mVarCheckPcdBin != NULL);
> +//
> +// Make sure the allocated buffer for VarCheckPcdBin at required 
> alignment.
> +//
> +ASSERT UINTN) mVarCheckPcdBin) & (HEADER_ALIGNMENT - 1)) == 0);
>  mVarCheckPcdBinSize = VarCheckPcdBinSize;
>  FreePool (VarCheckPcdBin);
> 
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] OvmfPkg/BaseMemEncryptSevLib: Enable protection for newly added page table

[Wang, Jian J]

Add Cc to Ruiyu, who has plan to consolidate page table manipulation method.
He may want to share more information.

Regards,
Jian


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, January 05, 2018 3:07 AM
> To: Brijesh Singh <brijesh.si...@amd.com>; edk2-devel@lists.01.org
> Cc: Tom Lendacky <thomas.lenda...@amd.com>; Wang, Jian J
> <jian.j.w...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Justen, Jordan
> L <jordan.l.jus...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>
> Subject: Re: [PATCH] OvmfPkg/BaseMemEncryptSevLib: Enable protection for
> newly added page table
> 
> Hi Brijesh,
> 
> meta comment: please also CC Ard on OvmfPkg patches; he too co-maintains
> OvmfPkg.
> 
> More below:
> 
> On 01/04/18 18:06, Brijesh Singh wrote:
> > Commit 2ac1730bf2a5 (MdeModulePkg/DxeIpl: Mark page table as read-only)
> > sets the memory pages used for page table as read-only after paging is
> > setup and sets CR0.WP to protect CPU modifying the read-only pages.
> > The commit causes #PF when MemEncryptSevClearPageEncMask() or
> > MemEncryptSevSetPageEncMask() tries to change the page-table attributes.
> >
> > This patch takes the similar approach as Commit 147fd35c3e38
> > (UefiCpuPkg/CpuDxe: Enable protection for newly added page table).
> > When page table protection is enabled, we disable it temporarily before
> > changing the page table attributes.
> >
> > This patch makes use of the same approach as Commit 2ac1730bf2a5
> > (MdeModulePkg/DxeIpl: Mark page table as read-only)) for allocating
> > page table memory from reserved memory pool, which helps to reduce a
> 
> "reserved memory pool" is a misleading term, it invokes thoughts about
> EfiReservedMemoryType, which is also allocatable.
> 
> > potential "split" operation.
> >
> > Cc: Jian J Wang <jian.j.w...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Jordan Justen <jordan.l.jus...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Signed-off-by: Brijesh Singh <brijesh.si...@amd.com>
> 
> The following line is missing, from above your S-o-b:
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> > ---
> >  OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h |  28 ++
> >  OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c | 378
> +++-
> >  2 files changed, 399 insertions(+), 7 deletions(-)
> 
> I find it awful that we have to duplicate all this code in OvmfPkg.
> 
> The page protection (+ other security) features have been constantly
> refined since Jian started to work on them. There's no guarantee that
> this is the last synchronization we have to do in OvmfPkg due to another
> feature (or bugfix) under UefiCpuPkg.
> 
> You can see in the messages of both commits 2ac1730bf2a5 and
> 147fd35c3e38 that I participated in the regression-testing of those commits.
> 
> You can also see on the commit messages that I simply ran out of steam
> while trying to keep up with rapid iterations of those patches -- I
> regression-tested versions that I thought would be final, but even after
> that, further updates were made, and I couldn't test the final versions.
> 
> Even in those regression tests that I managed to do, I didn't test the
> patches in a SEV guest. The reason is that the test matrix has now grown
> to an unmanageable size, such that sometimes it doesn't even occur to me
> that this or that virt environment could be affected by a UefiCpuPkg or
> Mde*Pkg patch. I realized the risk, which is why I asked for, and got,
> Reviewer role under UefiCpuPkg -- purely so I could *test* (not
> necessarily review!) UefiCpuPkg patches first-hand, *before* they are
> committed. But, I'm at (and beyond) capacity, even in recognizing what
> affects what.
> 
> There are only two fixes for this (they are independent, and both should
> be done):
> 
> (1) An automated regression test environment. We discussed this earlier
> with Jian (because his work had both introduced, and elsewhere exposed,
> a large number of bugs). After that, I also talked to virt-QE at Red
> Hat. Hopefully virt-QE @RH will find some resources in February 2018 to
> write OVMF test cases for the avocado-vt project. I'm not sure.
> Currently, *zero* OVMF test cases exist in any automated test
> environment that I'm aware of; and I have spent a frightening amount of
> time on manual regression testing.
> 
> (2) Code sharing / reuse between top-level Pkgs in edk2, as diligently
> as possible. I very much dislike that we have page table management
> scattered bet

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

I'm not familiar with BSP/AP switch code either. I just happen to see code 
comments
mentioned  switching BSP/AP. So I think it would be better to initialize cpu 0 
the same 
way as others. No matter what, as what the field name implies, ApTopOfStack 
should
never be used to store stack base address.

I'll try to find if any test cases for the BSP/AP switch were developed before. 
If non,
I think it's not easy for me to write one. If it's OK, I prefer to check in 
current fix and
test what you concern later. I think nobody uses this feature.

I'll send v3 as what you suggested. Thanks a lot for all your comments.

Regards,
Jian


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, January 04, 2018 8:22 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> as Stack Guard
> 
> On 01/04/18 02:45, Wang, Jian J wrote:
> > A correction: although BSP doesn't need it, we still need to initialize its
> ApTopOfStack
> > correctly because the MP service supports BSP/AP exchange. So I think the 
> > line
> 1501
> > should be changed to
> >
> >   InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer + CpuMpData-
> >CpuApStackSize);
> >
> > instead of
> >
> >   InitializeApData (CpuMpData, 0, 0, NULL);
> 
> Hmm... Although I don't immediately see all possible consequences of
> such a change, it looks like a correct fix.
> 
> Unfortunately, I don't know of any code that actually exercises the
> BSP/AP exchange service. I think Intel must have access to some client
> code like this, because I vaguely recall some patches over time that
> improved BSP/AP exchange.
> 
> If you modify the InitializeApData() call in question like suggested
> above, can you perhaps locate that client code, and test the change with it?
> 
> Thanks!
> Laszlo
> 
> 
> >> -Original Message-
> >> From: Wang, Jian J
> >> Sent: Thursday, January 04, 2018 9:09 AM
> >> To: Wang, Jian J <jian.j.w...@intel.com>; Laszlo Ersek
> <ler...@redhat.com>;
> >> edk2-devel@lists.01.org
> >> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> >> Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address
> set
> >> as Stack Guard
> >>
> >> Laszlo,
> >>
> >> More explanations:
> >>
> >> [UefiCpuPkg\Library\MpInitLib\MpLib.c]
> >> According to the code, the BSP's (CpuInfoInHob[0].ApTopOfStack) is
> initialized
> >> to
> >> the bottom of the stack (line 1501) but AP's ApTopOfStack is correctly
> initialized
> >> (line 598). Although my calculation is correct, I think it'd be better to 
> >> use AP's
> >> ApTopOfStack directly. From this perspective, you're right.
> >>
> >> Maybe it'd be better to pass a NULL pointer at line 1501 because BSP 
> >> doesn't
> >> need
> >> it anyway.
> >>
> >> Regards,
> >> Jian
> >>
> >>
> >>> -Original Message-
> >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >> Wang,
> >>> Jian J
> >>> Sent: Thursday, January 04, 2018 8:42 AM
> >>> To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org
> >>> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> >>> Subject: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address
> set
> >>> as Stack Guard
> >>>
> >>> Laszlo,
> >>>
> >>> I revisited code of MpInitLib. I found that CPU_INFO_IN_HOB.ApTopOfStack
> >>> was assigned to CpuMpData->Buffer in MpInitLibInitialize()
> >>>
> >>> (line1501)  InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer);
> >>>
> >>> but in
> >>>
> >>> (line598)  ApTopOfStack  = CpuMpData->Buffer + (ProcessorNumber + 1) *
> >>> CpuMpData->CpuApStackSize;
> >>> (line608)  InitializeApData (CpuMpData, ProcessorNumber, BistData,
> >>> ApTopOfStack);
> >>>
> >>> Since InitMpGlobalData() is called just after first situation, my patch is
> correct.
> >>>
> >>> I think the problem here is that ApTopOfStack initialized at line 1501 is 
> >>> not
> >>> correct.
> >>>
> >>>
> >>> Reg

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

Glad to know. That saves me time to write my own case:)

Regards,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Friday, January 05, 2018 11:05 AM
To: Yao, Jiewen <jiewen@intel.com>; Wang, Jian J <jian.j.w...@intel.com>; 
Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>
Subject: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Cool. PI SCT is better and easier.

Jeff

发件人: Yao, Jiewen<mailto:jiewen@intel.com>
发送时间: 2018年1月5日 10:58
收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; Fan 
Jeff<mailto:vanjeff_...@hotmail.com>; Laszlo Ersek<mailto:ler...@redhat.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Dong, Eric<mailto:eric.d...@intel.com>
主题: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Good. I also suggest we run PI-SCT to make sure it is well tested.

Thank you
Yao Jiewen

From: Wang, Jian J
Sent: Friday, January 5, 2018 10:56 AM
To: Fan Jeff <vanjeff_...@hotmail.com<mailto:vanjeff_...@hotmail.com>>; Laszlo 
Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>
Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Got it. Many thanks!

Regards,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Friday, January 05, 2018 10:50 AM
To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; Laszlo 
Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>
Subject: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Sorry, Dump the APICID, not CPUID.

Jeff

发件人: Fan Jeff<mailto:vanjeff_...@hotmail.com>
发送时间: 2018年1月5日 10:48
收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; Laszlo 
Ersek<mailto:ler...@redhat.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Yao, Jiewen<mailto:jiewen@intel.com>; Dong, 
Eric<mailto:eric.d...@intel.com>
主题: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

You may use MP->SwitchBSP() to do BSP switch and then dump BSP’s CPUID to know 
if the switch is successfully.

Jeff


From: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>
Sent: Friday, January 5, 2018 9:57:31 AM
To: Fan Jeff; Laszlo Ersek; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen; Dong, Eric
Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Hi Jeff,

Do you think the change is OK? Do you know how to test switching BSP?

Regards,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Friday, January 05, 2018 9:40 AM
To: Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>; Wang, Jian J 
<jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>
Subject: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Laszlo,

Firstly, SwitchBSP() is one service of MP defined in PI spec.

For real case, I think multiple socket system(with different processor 
stepping) may use this service for purpose.

Thanks!
Jeff

发件人: Laszlo Ersek<mailto:ler...@redhat.com>
发送时间: 2018年1月4日 20:21
收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Yao, Jiewen<mailto:jiewen@intel.com>; Dong, 
Eric<mailto:eric.d...@intel.com>
主题: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

On 01/04/18 02:45, Wang, Jian J wrote:
> A correction: although BSP doesn't need it, we still need to initialize its 
> ApTopOfStack
> correctly because the MP service supports BSP/AP exchange. So I think the 
> line 1501
> should be changed to
>
>   InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer + 
> CpuMpData->CpuApStackSize);
>
> instead of
>
>   InitializeApData (CpuMpData, 0, 0, NULL);

Hmm... Although I don't immediately see all possible consequences of
such a change, it looks like a correct fix.

Unfortunately, I don't know of any code that actually exercises the
BSP/AP exchange service. I think Intel must have access to some client
code

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

Hi Jeff,

Do you think the change is OK? Do you know how to test switching BSP?

Regards,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Friday, January 05, 2018 9:40 AM
To: Laszlo Ersek <ler...@redhat.com>; Wang, Jian J <jian.j.w...@intel.com>; 
edk2-devel@lists.01.org
Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
Subject: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Laszlo,

Firstly, SwitchBSP() is one service of MP defined in PI spec.

For real case, I think multiple socket system(with different processor 
stepping) may use this service for purpose.

Thanks!
Jeff

发件人: Laszlo Ersek<mailto:ler...@redhat.com>
发送时间: 2018年1月4日 20:21
收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Yao, Jiewen<mailto:jiewen@intel.com>; Dong, 
Eric<mailto:eric.d...@intel.com>
主题: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

On 01/04/18 02:45, Wang, Jian J wrote:
> A correction: although BSP doesn't need it, we still need to initialize its 
> ApTopOfStack
> correctly because the MP service supports BSP/AP exchange. So I think the 
> line 1501
> should be changed to
>
>   InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer + 
> CpuMpData->CpuApStackSize);
>
> instead of
>
>   InitializeApData (CpuMpData, 0, 0, NULL);

Hmm... Although I don't immediately see all possible consequences of
such a change, it looks like a correct fix.

Unfortunately, I don't know of any code that actually exercises the
BSP/AP exchange service. I think Intel must have access to some client
code like this, because I vaguely recall some patches over time that
improved BSP/AP exchange.

If you modify the InitializeApData() call in question like suggested
above, can you perhaps locate that client code, and test the change with it?

Thanks!
Laszlo


>> -----Original Message-
>> From: Wang, Jian J
>> Sent: Thursday, January 04, 2018 9:09 AM
>> To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; 
>> Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>;
>> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
>> Cc: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Dong, 
>> Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>
>> Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
>> as Stack Guard
>>
>> Laszlo,
>>
>> More explanations:
>>
>> [UefiCpuPkg\Library\MpInitLib\MpLib.c]
>> According to the code, the BSP's (CpuInfoInHob[0].ApTopOfStack) is 
>> initialized
>> to
>> the bottom of the stack (line 1501) but AP's ApTopOfStack is correctly 
>> initialized
>> (line 598). Although my calculation is correct, I think it'd be better to 
>> use AP's
>> ApTopOfStack directly. From this perspective, you're right.
>>
>> Maybe it'd be better to pass a NULL pointer at line 1501 because BSP doesn't
>> need
>> it anyway.
>>
>> Regards,
>> Jian
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Wang,
>>> Jian J
>>> Sent: Thursday, January 04, 2018 8:42 AM
>>> To: Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>; 
>>> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
>>> Cc: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Dong, 
>>> Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>
>>> Subject: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
>>> as Stack Guard
>>>
>>> Laszlo,
>>>
>>> I revisited code of MpInitLib. I found that CPU_INFO_IN_HOB.ApTopOfStack
>>> was assigned to CpuMpData->Buffer in MpInitLibInitialize()
>>>
>>> (line1501)  InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer);
>>>
>>> but in
>>>
>>> (line598)  ApTopOfStack  = CpuMpData->Buffer + (ProcessorNumber + 1) *
>>> CpuMpData->CpuApStackSize;
>>> (line608)  InitializeApData (CpuMpData, ProcessorNumber, BistData,
>>> ApTopOfStack);
>>>
>>> Since InitMpGlobalData() is called just after first situation, my patch is 
>>> correct.
>>>
>>> I think the problem here is that ApTopOfStack initialized at line 1501 is 
>>> not
>>> correct.
>>>
>>>
>>> Regards,
>>> Jian
>>>
>>>
>>>> -Original M

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

Got it. Many thanks!

Regards,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Friday, January 05, 2018 10:50 AM
To: Wang, Jian J <jian.j.w...@intel.com>; Laszlo Ersek <ler...@redhat.com>; 
edk2-devel@lists.01.org
Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
Subject: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Sorry, Dump the APICID, not CPUID.

Jeff

发件人: Fan Jeff<mailto:vanjeff_...@hotmail.com>
发送时间: 2018年1月5日 10:48
收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; Laszlo 
Ersek<mailto:ler...@redhat.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Yao, Jiewen<mailto:jiewen@intel.com>; Dong, 
Eric<mailto:eric.d...@intel.com>
主题: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

You may use MP->SwitchBSP() to do BSP switch and then dump BSP’s CPUID to know 
if the switch is successfully.

Jeff


From: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>
Sent: Friday, January 5, 2018 9:57:31 AM
To: Fan Jeff; Laszlo Ersek; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen; Dong, Eric
Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Hi Jeff,

Do you think the change is OK? Do you know how to test switching BSP?

Regards,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Friday, January 05, 2018 9:40 AM
To: Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>; Wang, Jian J 
<jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Dong, Eric 
<eric.d...@intel.com<mailto:eric.d...@intel.com>>
Subject: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

Laszlo,

Firstly, SwitchBSP() is one service of MP defined in PI spec.

For real case, I think multiple socket system(with different processor 
stepping) may use this service for purpose.

Thanks!
Jeff

发件人: Laszlo Ersek<mailto:ler...@redhat.com>
发送时间: 2018年1月4日 20:21
收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
抄送: Yao, Jiewen<mailto:jiewen@intel.com>; Dong, 
Eric<mailto:eric.d...@intel.com>
主题: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as 
Stack Guard

On 01/04/18 02:45, Wang, Jian J wrote:
> A correction: although BSP doesn't need it, we still need to initialize its 
> ApTopOfStack
> correctly because the MP service supports BSP/AP exchange. So I think the 
> line 1501
> should be changed to
>
>   InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer + 
> CpuMpData->CpuApStackSize);
>
> instead of
>
>   InitializeApData (CpuMpData, 0, 0, NULL);

Hmm... Although I don't immediately see all possible consequences of
such a change, it looks like a correct fix.

Unfortunately, I don't know of any code that actually exercises the
BSP/AP exchange service. I think Intel must have access to some client
code like this, because I vaguely recall some patches over time that
improved BSP/AP exchange.

If you modify the InitializeApData() call in question like suggested
above, can you perhaps locate that client code, and test the change with it?

Thanks!
Laszlo


>> -Original Message-
>> From: Wang, Jian J
>> Sent: Thursday, January 04, 2018 9:09 AM
>> To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; 
>> Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>;
>> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
>> Cc: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Dong, 
>> Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>
>> Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
>> as Stack Guard
>>
>> Laszlo,
>>
>> More explanations:
>>
>> [UefiCpuPkg\Library\MpInitLib\MpLib.c]
>> According to the code, the BSP's (CpuInfoInHob[0].ApTopOfStack) is 
>> initialized
>> to
>> the bottom of the stack (line 1501) but AP's ApTopOfStack is correctly 
>> initialized
>> (line 598). Although my calculation is correct, I think it'd be better to 
>> use AP's
>> ApTopOfStack directly. From this perspective, you're right.
>>
>> Maybe it'd be better to pass a NULL pointer at line 1501 because BSP doesn't
>> need
>> it anyway.
>>
>> Regards,
>> Jian
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: Fix incorrect Guard page setup for APs

[Wang, Jian J]

Hi,

Anyone has any comments on this?

Regards,
Jian


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Thursday, December 21, 2017 9:27 AM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Yao, Jiewen ;
> Dong, Eric 
> Subject: [edk2] [PATCH] UefiCpuPkg/MpInitLib: Fix incorrect Guard page setup
> for APs
> 
> AP has its own stack for code execution. If PcdCpuStackGuard is enabled,
> the page at the bottom of stack of AP will be disabled (NOT PRESENT) to
> monitor the stack overflow issue. This requires PcdCpuApStackSize to be
> set with value more than one page of memory.
> 
> Cc: Jiewen Yao 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |  1 +
>  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   | 34
> ---
>  2 files changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> index 805641b516..e7b9eb4462 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> @@ -73,4 +73,5 @@
>gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ##
> CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode   ## 
> CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate   ##
> SOMETIMES_CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard  ##
> CONSUMES
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> index 479f8189f6..40c1bf407a 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
> 
> @@ -288,9 +289,12 @@ InitMpGlobalData (
>IN CPU_MP_DATA   *CpuMpData
>)
>  {
> -  EFI_STATUS Status;
> -  EFI_PHYSICAL_ADDRESS   Address;
> -  UINTN  ApSafeBufferSize;
> +  EFI_STATUS  Status;
> +  EFI_PHYSICAL_ADDRESSAddress;
> +  UINTN   ApSafeBufferSize;
> +  UINTN   Index;
> +  EFI_GCD_MEMORY_SPACE_DESCRIPTOR MemDesc;
> +  UINTN   StackBase;
> 
>SaveCpuMpData (CpuMpData);
> 
> @@ -301,6 +305,30 @@ InitMpGlobalData (
>  return;
>}
> 
> +  if (PcdGetBool (PcdCpuStackGuard)) {
> +//
> +// One extra page at the bottom of the stack is needed for Guard page.
> +//
> +if (CpuMpData->CpuApStackSize <= EFI_PAGE_SIZE) {
> +  DEBUG ((DEBUG_ERROR, "PcdCpuApStackSize is not big enough for Stack
> Guard!\n"));
> +  ASSERT (FALSE);
> +}
> +
> +for (Index = 0; Index < CpuMpData->CpuCount; ++Index) {
> +  StackBase = CpuMpData->Buffer + Index * CpuMpData->CpuApStackSize;
> +
> +  Status = gDS->GetMemorySpaceDescriptor (StackBase, );
> +  ASSERT_EFI_ERROR (Status);
> +
> +  Status = gDS->SetMemorySpaceAttributes (
> +  StackBase,
> +  EFI_PAGES_TO_SIZE (1),
> +  MemDesc.Attributes | EFI_MEMORY_RP
> +  );
> +  ASSERT_EFI_ERROR (Status);
> +}
> +  }
> +
>//
>// Avoid APs access invalid buffer data which allocated by BootServices,
>// so we will allocate reserved data for AP loop code. We also need to
> --
> 2.15.1.windows.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: Fix incorrect Guard page setup for APs

[Wang, Jian J]

You're right. It will be updated to use more accurate wording. Thanks for 
catching it.

Regards,
Jian


> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, December 22, 2017 1:22 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Laszlo Ersek <ler...@redhat.com>; Dong, Eric <eric.d...@intel.com>
> Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: Fix incorrect Guard page
> setup for APs
> 
> I do not think we have AP guard page before, right?
> So I suggest we change commit message to be: Add missing Guard page setup
> for APs.
> 
> With commit message update, reviewed-by: jiewen@intel.com
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Friday, December 22, 2017 12:26 PM
> > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > Cc: Laszlo Ersek <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>;
> > Dong, Eric <eric.d...@intel.com>
> > Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: Fix incorrect Guard page
> > setup for APs
> >
> > Hi,
> >
> > Anyone has any comments on this?
> >
> > Regards,
> > Jian
> >
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jian
> > J
> > > Wang
> > > Sent: Thursday, December 21, 2017 9:27 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Laszlo Ersek <ler...@redhat.com>; Yao, Jiewen
> <jiewen@intel.com>;
> > > Dong, Eric <eric.d...@intel.com>
> > > Subject: [edk2] [PATCH] UefiCpuPkg/MpInitLib: Fix incorrect Guard page
> setup
> > > for APs
> > >
> > > AP has its own stack for code execution. If PcdCpuStackGuard is enabled,
> > > the page at the bottom of stack of AP will be disabled (NOT PRESENT) to
> > > monitor the stack overflow issue. This requires PcdCpuApStackSize to be
> > > set with value more than one page of memory.
> > >
> > > Cc: Jiewen Yao <jiewen@intel.com>
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Cc: Laszlo Ersek <ler...@redhat.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > > ---
> > >  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |  1 +
> > >  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c   | 34
> > > ---
> > >  2 files changed, 32 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> > > b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> > > index 805641b516..e7b9eb4462 100644
> > > --- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> > > +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> > > @@ -73,4 +73,5 @@
> > >gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize
> > ##
> > > CONSUMES
> > >gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode
> > ## CONSUMES
> > >gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate
> > ##
> > > SOMETIMES_CONSUMES
> > > +  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard
> > ##
> > > CONSUMES
> > >
> > > diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > index 479f8189f6..40c1bf407a 100644
> > > --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > @@ -17,6 +17,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include 
> > >
> > > @@ -288,9 +289,12 @@ InitMpGlobalData (
> > >IN CPU_MP_DATA   *CpuMpData
> > >)
> > >  {
> > > -  EFI_STATUS Status;
> > > -  EFI_PHYSICAL_ADDRESS   Address;
> > > -  UINTN  ApSafeBufferSize;
> > > +  EFI_STATUS  Status;
> > > +  EFI_PHYSICAL_ADDRESSAddress;
> > > +  UINTN   ApSafeBufferSize;
> > > +  UINTN   Index;
> > > +  EFI_GCD_MEMORY_SPACE_DESCRIPTOR MemDesc;
> > > +  UINTN   StackBase;
> > >
> > >SaveCpuMpData (CpuMpData);
> > >
> > > @@ -301,6 +305,30 @@ InitMpGlobalData (
> > >  return;
> > >}
> > >
>

Re: [edk2] [PATCH] MdeModulePkg/Core: Fix heap guard issues

[Wang, Jian J]

Sorry for the email title. This is not a series patch.

And I missed one more issue addressed by this patch:
c. NULL address handling due to allocation failure
When allocation failure, normally a NULL will be returned. But Heap Guard code
will still try to adjust the starting address of it, which will cause a 
non-NULL pointer
returned.

Regards,
Jian


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Monday, December 25, 2017 10:23 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Zeng, Star 
> Subject: [edk2] [PATCH 1/2] MdeModulePkg/Core: Fix heap guard issues
> 
> Two issues addressed here:
> 
> a. Make NX memory protection and heap guard to be compatible
> The solution is to check PcdDxeNxMemoryProtectionPolicy in Heap Guard to see
> if the free memory should be set to NX, and set the Guard page to NX before
> it's freed back to memory pool. This can solve the issue which NX setting
> would be overwritten by Heap Guard feature in certain configuration.
> 
> b. Returned pool address was not 8-byte aligned sometimes
> This happened only when BIT7 is not set in PcdHeapGuardPropertyMask. Since
> 8-byte alignment is UEFI spec required, letting allocated pool adjacent to
> tail guard page cannot be guaranteed.
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 31
> ++-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c |  3 ---
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.c   | 14 ++--
>  3 files changed, 38 insertions(+), 10 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index bee229f4c8..0f035043e1 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -583,8 +583,7 @@ SetGuardPage (
>mOnGuarding = TRUE;
>//
>// Note: This might overwrite other attributes needed by other features,
> -  // such as memory protection (NX). Please make sure they are not enabled
> -  // at the same time.
> +  // such as NX memory protection.
>//
>gCpu->SetMemoryAttributes (gCpu, BaseAddress, EFI_PAGE_SIZE,
> EFI_MEMORY_RP);
>mOnGuarding = FALSE;
> @@ -605,6 +604,18 @@ UnsetGuardPage (
>IN  EFI_PHYSICAL_ADDRESS  BaseAddress
>)
>  {
> +  UINT64  Attributes;
> +
> +  //
> +  // Once the Guard page is unset, it will be freed back to memory pool. NX
> +  // memory protection must be restored for this page if NX is enabled for 
> free
> +  // memory.
> +  //
> +  Attributes = 0;
> +  if ((PcdGet64 (PcdDxeNxMemoryProtectionPolicy) & (1 <<
> EfiConventionalMemory)) != 0) {
> +Attributes |= EFI_MEMORY_XP;
> +  }
> +
>//
>// Set flag to make sure allocating memory without GUARD for page table
>// operation; otherwise infinite loops could be caused.
> @@ -615,7 +626,7 @@ UnsetGuardPage (
>// such as memory protection (NX). Please make sure they are not enabled
>// at the same time.
>//
> -  gCpu->SetMemoryAttributes (gCpu, BaseAddress, EFI_PAGE_SIZE, 0);
> +  gCpu->SetMemoryAttributes (gCpu, BaseAddress, EFI_PAGE_SIZE, Attributes);
>mOnGuarding = FALSE;
>  }
> 
> @@ -869,6 +880,15 @@ AdjustMemoryS (
>  {
>UINT64  Target;
> 
> +  //
> +  // UEFI spec requires that allocated pool must be 8-byte aligned. If it's
> +  // indicated to put the pool near the Tail Guard, we need extra bytes to
> +  // make sure alignment of the returned pool address.
> +  //
> +  if ((PcdGet8 (PcdHeapGuardPropertyMask) & BIT7) == 0) {
> +SizeRequested = ALIGN_VALUE(SizeRequested, 8);
> +  }
> +
>Target = Start + Size - SizeRequested;
> 
>//
> @@ -1052,7 +1072,7 @@ AdjustPoolHeadA (
>IN UINTN   Size
>)
>  {
> -  if ((PcdGet8 (PcdHeapGuardPropertyMask) & BIT7) != 0) {
> +  if (Memory == 0 || (PcdGet8 (PcdHeapGuardPropertyMask) & BIT7) != 0) {
>  //
>  // Pool head is put near the head Guard
>  //
> @@ -1062,6 +1082,7 @@ AdjustPoolHeadA (
>//
>// Pool head is put near the tail Guard
>//
> +  Size = ALIGN_VALUE (Size, 8);
>return (VOID *)(UINTN)(Memory + EFI_PAGES_TO_SIZE (NoPages) - Size);
>  }
> 
> @@ -1077,7 +1098,7 @@ AdjustPoolHeadF (
>IN EFI_PHYSICAL_ADDRESSMemory
>)
>  {
> -  if ((PcdGet8 (PcdHeapGuardPropertyMask) & BIT7) != 0) {
> +  if (Memory == 0 || (PcdGet8 (PcdHeapGuardPropertyMask) & BIT7) != 0) {
>  //
>  // Pool head is put near the head Guard
>  //
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> index a74cfc137a..862593f562 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> +++ 

Re: [edk2] [PATCH 3/4] UefiCpuPkg/UefiCpuPkg.uni: Add missing string definition for new PCDs

[Wang, Jian J]

Sure. Thanks.

Regards,
Jian


> -Original Message-
> From: Bi, Dandan
> Sent: Monday, December 25, 2017 9:59 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Laszlo Ersek <ler...@redhat.com>
> Subject: RE: [PATCH 3/4] UefiCpuPkg/UefiCpuPkg.uni: Add missing string
> definition for new PCDs
> 
> Hi Jian,
> 
> Could you add the "string" keyword before the string token when you commit
> the patch. You can refer to other codes in the uni file.
> With this update, Reviewed-by: Dandan Bi <dandan...@intel.com>
> 
> Thanks,
> Dandan
> -Original Message-
> From: Wang, Jian J
> Sent: Monday, December 25, 2017 9:07 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Laszlo Ersek <ler...@redhat.com>
> Subject: [PATCH 3/4] UefiCpuPkg/UefiCpuPkg.uni: Add missing string definition
> for new PCDs
> 
> Cc: Dandan Bi <dandan...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> ---
>  UefiCpuPkg/UefiCpuPkg.uni | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni index
> a7073b10c8..6fcfc6e7f2 100644
> --- a/UefiCpuPkg/UefiCpuPkg.uni
> +++ b/UefiCpuPkg/UefiCpuPkg.uni
> @@ -230,5 +230,17 @@
>   
>"Processor trace is enabled
> through set BIT44(CPU_FEATURE_PROC_TRACE) in
> PcdCpuFeaturesSetting.\n"
>   
>"This PCD is ignored if CPU
> processor trace is disabled.\n"
>   
>"Default value is 0 which means
> single range output scheme will be used if CPU processor trace is
> enabled.\n"
> - 
>"0 - Single Range output
> scheme.\n"
> 
> - 
>"1 - ToPA(Table of physical
> address) scheme.\n"
> \ No newline at end of file
> + 
>"0 - Single Range output
> scheme.\n"
> + 
>"1 - ToPA(Table of physical
> address) scheme.\n"
> +
> +#STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuStackSwitchExceptionList_PROMP
> T  #language en-US "Specify exception vectors which need switching stack."
> +
> +#STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuStackSwitchExceptionList_HELP
> #language en-US "List of exception vectors which need switching stack.\n"
> + 
>"This PCD will only take into
> effect if PcdCpuStackGuard is enabled.n"
> + 
>"By default exception #DD(8),
> #PF(14) are supported.n"
> +
> +#STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuKnownGoodStackSize_PROMPT
> #language en-US "Specify size of good stack of exception which need switching
> stack."
> +
> +#STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuKnownGoodStackSize_HELP
> #language en-US "Size of good stack for an exception.\n"
> + 
>  "This PCD will only take into effect if
> PcdCpuStackGuard is enabled.\n"
> +
> --
> 2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/4] MdePkg/BaseLib.h: Coding style clean-up

[Wang, Jian J]

Ok. Thanks for catching it.

Regards,
Jian

> -Original Message-
> From: Bi, Dandan
> Sent: Monday, December 25, 2017 9:51 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: RE: [PATCH 1/4] MdePkg/BaseLib.h: Coding style clean-up
> 
> Hi Jian,
> 
> This patch is fine.
> Could you help to add a period(.) for  following function description when you
> commit the patch? Thanks!
> /**
>   Load given selector into TR register   // Add a period(.) here, or ECC tool 
> will
> report an error here.
> 
>   @param[in] Selector Task segment selector
> **/
> VOID
> EFIAPI
> AsmWriteTr (
>   IN UINT16 Selector
>   );
> 
> With this update, Reviewed-by: Dandan Bi <dandan...@intel.com>
> 
> Regards,
> Dandan
> -Original Message-
> From: Wang, Jian J
> Sent: Monday, December 25, 2017 9:07 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan <dandan...@intel.com>; Zeng, Star <star.z...@intel.com>;
> Dong, Eric <eric.d...@intel.com>
> Subject: [PATCH 1/4] MdePkg/BaseLib.h: Coding style clean-up
> 
> Cc: Dandan Bi <dandan...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> ---
>  MdePkg/Include/Library/BaseLib.h | 72 --
> --
>  1 file changed, 36 insertions(+), 36 deletions(-)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index 2b98af4cd1..f51079aeb1 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -6672,41 +6672,41 @@ typedef union {
>  typedef struct {
>UINT16PreviousTaskLink;
>UINT16Reserved_2;
> -  UINT32ESP0;
> -  UINT16SS0;
> +  UINT32Esp0;
> +  UINT16Ss0;
>UINT16Reserved_10;
> -  UINT32ESP1;
> -  UINT16SS1;
> +  UINT32Esp1;
> +  UINT16Ss1;
>UINT16Reserved_18;
> -  UINT32ESP2;
> -  UINT16SS2;
> +  UINT32Esp2;
> +  UINT16Ss2;
>UINT16Reserved_26;
> -  UINT32CR3;
> -  UINT32EIP;
> -  UINT32EFLAGS;
> -  UINT32EAX;
> -  UINT32ECX;
> -  UINT32EDX;
> -  UINT32EBX;
> -  UINT32ESP;
> -  UINT32EBP;
> -  UINT32ESI;
> -  UINT32EDI;
> -  UINT16ES;
> +  UINT32Cr3;
> +  UINT32Eip;
> +  UINT32Eflags;
> +  UINT32Eax;
> +  UINT32Ecx;
> +  UINT32Edx;
> +  UINT32Ebx;
> +  UINT32Esp;
> +  UINT32Ebp;
> +  UINT32Esi;
> +  UINT32Edi;
> +  UINT16Es;
>UINT16Reserved_74;
> -  UINT16CS;
> +  UINT16Cs;
>UINT16Reserved_78;
> -  UINT16SS;
> +  UINT16Ss;
>UINT16Reserved_82;
> -  UINT16DS;
> +  UINT16Ds;
>UINT16Reserved_86;
> -  UINT16FS;
> +  UINT16Fs;
>UINT16Reserved_90;
> -  UINT16GS;
> +  UINT16Gs;
>UINT16Reserved_94;
>UINT16LDTSegmentSelector;
>UINT16Reserved_98;
> -  UINT16T;
> +  UINT16Tflag;
>UINT16IOMapBaseAddress;
>  } IA32_TASK_STATE_SEGMENT;
> 
> @@ -6717,12 +6717,12 @@ typedef union {
>  UINT32  BaseMid:8;  ///< Base Address  23..16
>  UINT32  Type:4; ///< Type (1 0 B 1)
>  UINT32  Reserved_43:1;  ///< 0
> -UINT32  DPL:2;  ///< Descriptor Privilege Level
> -UINT32  P:1;///< Segment Present
> +UINT32  Dpl:2;  ///< Descriptor Privilege Level
> +UINT32  Present:1;  ///< Segment Present
>  UINT32  LimitHigh:4;///< Segment Limit 19..16
> -UINT32  AVL:1;  ///< Available for use by system software
> +UINT32  Avl:1;  ///< Available for use by system software
>  UINT32  Reserved_52:2;  ///< 0 0
> -UINT32  G:1;///< Granularity
> +UINT32  Granularity:1;  ///< Granularity
>  UINT32  BaseHigh:8; ///< Base Address 31..24
>} Bits;
>UINT64  Uint64;
> @@ -6757,11 +6757,11 @@ typedef union {
>  //
>  typedef struct {
>UINT32Reserved_0;
> -  UINT64RSP0;
> -  UINT64RSP1;
> -  UINT64RSP2;
> +  UINT64Rsp0;
> +  UINT64Rsp1;
> +  UINT64Rsp2;
>UINT64Reserved_28;
> -  UINT64IST[7];
> +  UINT64Ist[7];
>UINT64Reserved_92;
>UINT16Reserved_100;
>UINT16IOMapBaseAddress;
> @@ -6774,12 +6774,12 @@ typedef uni

Re: [edk2] 答复: [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

I see. Thanks a lot!

Regards,
Jian


> -Original Message-
> From: Chaganty, Rangasai V
> Sent: Friday, January 05, 2018 10:55 AM
> To: Fan Jeff <vanjeff_...@hotmail.com>; Wang, Jian J
> <jian.j.w...@intel.com>; Laszlo Ersek <ler...@redhat.com>; edk2-
> de...@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: RE: [edk2] 答复: [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address
> set as Stack Guard
> 
> APIC_BASE MSR 1BH (BIT8) should tell us if the executing thread is BSP or not.
> This MSR is defined in SDM.
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fan
> Jeff
> Sent: Thursday, January 04, 2018 6:50 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: [edk2] 答复: [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> as Stack Guard
> 
> Sorry, Dump the APICID, not CPUID.
> 
> Jeff
> 
> 发件人: Fan Jeff<mailto:vanjeff_...@hotmail.com>
> 发送时间: 2018年1月5日 10:48
> 收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; Laszlo
> Ersek<mailto:ler...@redhat.com>; edk2-devel@lists.01.org<mailto:edk2-
> de...@lists.01.org>
> 抄送: Yao, Jiewen<mailto:jiewen@intel.com>; Dong,
> Eric<mailto:eric.d...@intel.com>
> 主题: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> as Stack Guard
> 
> You may use MP->SwitchBSP() to do BSP switch and then dump BSP’s CPUID to
> know if the switch is successfully.
> 
> Jeff
> 
> 
> From: Wang, Jian J <jian.j.w...@intel.com>
> Sent: Friday, January 5, 2018 9:57:31 AM
> To: Fan Jeff; Laszlo Ersek; edk2-devel@lists.01.org
> Cc: Yao, Jiewen; Dong, Eric
> Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> as Stack Guard
> 
> Hi Jeff,
> 
> Do you think the change is OK? Do you know how to test switching BSP?
> 
> Regards,
> Jian
> 
> From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
> Sent: Friday, January 05, 2018 9:40 AM
> To: Laszlo Ersek <ler...@redhat.com>; Wang, Jian J <jian.j.w...@intel.com>;
> edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: 答复: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> as Stack Guard
> 
> Laszlo,
> 
> Firstly, SwitchBSP() is one service of MP defined in PI spec.
> 
> For real case, I think multiple socket system(with different processor 
> stepping)
> may use this service for purpose.
> 
> Thanks!
> Jeff
> 
> 发件人: Laszlo Ersek<mailto:ler...@redhat.com>
> 发送时间: 2018年1月4日 20:21
> 收件人: Wang, Jian J<mailto:jian.j.w...@intel.com>; edk2-
> de...@lists.01.org<mailto:edk2-devel@lists.01.org>
> 抄送: Yao, Jiewen<mailto:jiewen@intel.com>; Dong,
> Eric<mailto:eric.d...@intel.com>
> 主题: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as
> Stack Guard
> 
> On 01/04/18 02:45, Wang, Jian J wrote:
> > A correction: although BSP doesn't need it, we still need to
> > initialize its ApTopOfStack correctly because the MP service supports
> > BSP/AP exchange. So I think the line 1501 should be changed to
> >
> >   InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer +
> > CpuMpData->CpuApStackSize);
> >
> > instead of
> >
> >   InitializeApData (CpuMpData, 0, 0, NULL);
> 
> Hmm... Although I don't immediately see all possible consequences of such a
> change, it looks like a correct fix.
> 
> Unfortunately, I don't know of any code that actually exercises the BSP/AP
> exchange service. I think Intel must have access to some client code like 
> this,
> because I vaguely recall some patches over time that improved BSP/AP
> exchange.
> 
> If you modify the InitializeApData() call in question like suggested above, 
> can
> you perhaps locate that client code, and test the change with it?
> 
> Thanks!
> Laszlo
> 
> 
> >> -Original Message-
> >> From: Wang, Jian J
> >> Sent: Thursday, January 04, 2018 9:09 AM
> >> To: Wang, Jian J
> >> <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; Laszlo Ersek
> >> <ler...@redhat.com<mailto:ler...@redhat.com>>;
> >> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> >> Cc: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>;
> >> Dong, Eric <eric.d...@intel.com<mailto

Re: [edk2] [PATCH 2/2] UefiCpuPkg/CpuDxe: remove all code to flush TLB for APs

[Wang, Jian J]

Right. I'll update the comments.

Regards,
Jian


> -Original Message-
> From: Ni, Ruiyu
> Sent: Friday, January 26, 2018 5:14 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Laszlo Ersek <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>;
> Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH 2/2] UefiCpuPkg/CpuDxe: remove all code to flush
> TLB for APs
> 
> On 1/26/2018 5:03 PM, Jian J Wang wrote:
> > The reason doing this is that we found that calling StartupAllAps() to
> > flush TLB for all APs in CpuDxe driver after changing page attributes
> > will spend a lot of time to complete. If there are many page attributes
> > update requests, the whole system performance will be slowed down
> > explicitly, including any shell command and UI operation.
> >
> > The solution is removing the flush operation for AP in CpuDxe driver
> > and let AP flush TLB after woken up.
> >
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >   UefiCpuPkg/CpuDxe/CpuPageTable.c | 85 
> > +++-
> >   1 file changed, 5 insertions(+), 80 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index a33ac5519e..a5bf0dfe28 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -89,70 +89,6 @@ PAGE_ATTRIBUTE_TABLE mPageAttributeTable[] = {
> >
> >   PAGE_TABLE_POOL   *mPageTablePool = NULL;
> >
> > -/**
> > -  Enable write protection function for AP.
> > -
> > -  @param[in,out] Buffer  The pointer to private data buffer.
> > -**/
> > -VOID
> > -EFIAPI
> > -SyncCpuEnableWriteProtection (
> > -  IN OUT VOID *Buffer
> > -  )
> > -{
> > -  AsmWriteCr0 (AsmReadCr0 () | BIT16);
> > -}
> > -
> > -/**
> > -  CpuFlushTlb function for AP.
> > -
> > -  @param[in,out] Buffer  The pointer to private data buffer.
> > -**/
> > -VOID
> > -EFIAPI
> > -SyncCpuFlushTlb (
> > -  IN OUT VOID *Buffer
> > -  )
> > -{
> > -  CpuFlushTlb();
> > -}
> > -
> > -/**
> > -  Sync memory page attributes for AP.
> > -
> > -  @param[in] ProcedureA pointer to the function to be run on 
> > enabled
> APs of
> > -  the system.
> > -**/
> > -VOID
> > -SyncMemoryPageAttributesAp (
> > -  IN EFI_AP_PROCEDUREProcedure
> > -  )
> > -{
> > -  EFI_STATUSStatus;
> > -  EFI_MP_SERVICES_PROTOCOL  *MpService;
> > -
> > -  Status = gBS->LocateProtocol (
> > -  ,
> > -  NULL,
> > -  (VOID **)
> > -  );
> > -  //
> > -  // Synchronize the update with all APs
> > -  //
> > -  if (!EFI_ERROR (Status)) {
> > -Status = MpService->StartupAllAPs (
> > -  MpService,  // This
> > -  Procedure,  // Procedure
> > -  FALSE,  // SingleThread
> > -  NULL,   // WaitEvent
> > -  0,  // TimeoutInMicrosecsond
> > -  NULL,   // ProcedureArgument
> > -  NULL// FailedCpuList
> > -  );
> > -ASSERT (Status == EFI_SUCCESS || Status == EFI_NOT_STARTED || Status
> == EFI_NOT_READY);
> > -  }
> > -}
> > -
> >   /**
> > Return current paging context.
> >
> > @@ -574,20 +510,6 @@ IsReadOnlyPageWriteProtected (
> > return ((AsmReadCr0 () & BIT16) != 0);
> >   }
> >
> > -/**
> > -  Disable write protection function for AP.
> > -
> > -  @param[in,out] Buffer  The pointer to private data buffer.
> > -**/
> > -VOID
> > -EFIAPI
> > -SyncCpuDisableWriteProtection (
> > -  IN OUT VOID *Buffer
> > -  )
> > -{
> > -  AsmWriteCr0 (AsmReadCr0() & ~BIT16);
> > -}
> > -
> >   /**
> >Disable Write Protect on pages marked as read-only.
> >   **/
> > @@ -835,10 +757,13 @@ AssignMemoryPageAt

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix issue in wakeup buffer initialization

[Wang, Jian J]

Considering that there's a similar assignment in "else" block

ExchangeInfo->ModeTransitionMemory = (UINT32)
  (ExchangeInfo->BufferStart + CpuMpData->AddressMap.ModeTransitionOffset);

I would rather keep the assignment statement you mentioned inside "if" block.

Actually there's another issue in this part of code. To fix it, the assignment 
to
ModeHighMemory and ModeHighSegment will be moved outside the "if" block.
>From this fix perspective, it'd be also better to keep all assignments to
ModeTransitionMemory inside "if/else" block. You'll see it in a new patch later.

Anyway, thanks for the comments.

Regards,
Jian


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, January 24, 2018 11:30 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [PATCH] UefiCpuPkg/MpInitLib: fix issue in wakeup buffer
> initialization
> 
> On 01/24/18 03:08, Jian J Wang wrote:
> > To fix an issue in which enabling NX feature will mark the AP wakeup
> > buffer as non-executable and fail the AP init, the buffer was split
> > into two part: the lower part in memory within 1MB and the higher part
> > within allocated executable memory (EfiBootServicesCode). But the
> > address of higher part memory was stored in lower part memory, which
> > is actually shared with legacy components and will be overwritten by
> > LegacyBiosDxe driver if CSM is enabled.
> >
> > This patch fixes this issue by storing the address of higher part
> > memory in CpuMpData instead of ExchangeInfo.
> >
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/Library/MpInitLib/MpLib.c | 20 ++--
> >  UefiCpuPkg/Library/MpInitLib/MpLib.h |  1 +
> >  2 files changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > index 6231968c74..42011d6231 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> > @@ -823,19 +823,20 @@ FillExchangeInfoData (
> >// Copy all 32-bit code and 64-bit code into memory with type of
> >// EfiBootServicesCode to avoid page fault if NX memory protection is
> enabled.
> >//
> > -  if (ExchangeInfo->ModeTransitionMemory != 0) {
> > +  if (CpuMpData->WakeupBufferHigh != 0) {
> >  Size = CpuMpData->AddressMap.RendezvousFunnelSize -
> > CpuMpData->AddressMap.ModeTransitionOffset;
> >  CopyMem (
> > -  (VOID *)(UINTN)ExchangeInfo->ModeTransitionMemory,
> > +  (VOID *)CpuMpData->WakeupBufferHigh,
> >CpuMpData->AddressMap.RendezvousFunnelAddress +
> >CpuMpData->AddressMap.ModeTransitionOffset,
> >Size
> >);
> >
> > -ExchangeInfo->ModeHighMemory = ExchangeInfo-
> >ModeTransitionMemory;
> > -ExchangeInfo->ModeHighMemory += (UINT32)ExchangeInfo->ModeOffset
> -
> > -   (UINT32)CpuMpData->AddressMap.ModeTransitionOffset;
> > +ExchangeInfo->ModeTransitionMemory = (UINT32)CpuMpData-
> >WakeupBufferHigh;
> > +ExchangeInfo->ModeHighMemory = (UINT32)CpuMpData-
> >WakeupBufferHigh +
> > +   (UINT32)ExchangeInfo->ModeOffset -
> > +   
> > (UINT32)CpuMpData->AddressMap.ModeTransitionOffset;
> >  ExchangeInfo->ModeHighSegment = (UINT16)ExchangeInfo->CodeSegment;
> >} else {
> >  ExchangeInfo->ModeTransitionMemory = (UINT32)
> > @@ -916,11 +917,10 @@ AllocateResetVector (
> >  CpuMpData->WakeupBuffer  = GetWakeupBuffer (ApResetVectorSize);
> >  CpuMpData->MpCpuExchangeInfo = (MP_CPU_EXCHANGE_INFO *) (UINTN)
> >  (CpuMpData->WakeupBuffer + CpuMpData-
> >AddressMap.RendezvousFunnelSize);
> > -CpuMpData->MpCpuExchangeInfo->ModeTransitionMemory = (UINT32)
> > -GetModeTransitionBuffer (
> > -  CpuMpData->AddressMap.RendezvousFunnelSize -
> > -  CpuMpData->AddressMap.ModeTransitionOffset
> > -  );
> > +CpuMpData->WakeupBufferHigh  = GetModeTransitionBuffer (
> >

Re: [edk2] [PATCH] MdeModulePkg/Partition: Fix media probe

[Wang, Jian J]

Tested-by/Reviewed-by: Jian J Wang <jian.j.w...@intel.com>

> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, January 25, 2018 5:45 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J <jian.j.w...@intel.com>
> Subject: [PATCH] MdeModulePkg/Partition: Fix media probe
> 
> The call in ProbeMediaStatusEx() to the ReadDisk() function of the
> EFI_DISK_IO_PROTOCOL interface implemented in DiskIoDxe/DiskIo.c
> crashed in DiskIo2ReadWriteDisk() because of the NULL value of
> the destination buffer pointer.
> 
> Pass the address of a buffer in the stack instead of a NULL
> pointer.
> 
> The similar fix was applied to ProbeMediaStatus in commit
> df473cc1fc9acd1a623ec7e05276f2f0635c19d2
> * MdeModulePkg/PartitionDxe: Fix media probe
> 
> Somehow ProbeMediaStatusEx() wasn't changed together.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Jian J Wang <jian.j.w...@intel.com>
> ---
>  MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> index bb9d0b70ce..46c0877cee 100644
> --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c
> @@ -4,7 +4,7 @@
>of the raw block devices media. Currently "El Torito CD-ROM", UDF, Legacy
>MBR, and GPT partition schemes are supported.
> 
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  This program and the accompanying materials
>  are licensed and made available under the terms and conditions of the BSD
> License
>  which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -777,11 +777,15 @@ ProbeMediaStatusEx (
>)
>  {
>EFI_STATUS Status;
> +  UINT8  Buffer[1];
> 
>//
> -  // Read 1 byte from offset 0 but passing NULL as buffer pointer
> +  // Read 1 byte from offset 0 to check if the MediaId is still valid.
> +  // The reading operation is synchronious thus it is not worth it to
> +  // allocate a buffer from the pool. The destination buffer for the
> +  // data is in the stack.
>//
> -  Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, NULL);
> +  Status = DiskIo2->ReadDiskEx (DiskIo2, MediaId, 0, NULL, 1, (VOID*)Buffer);
>if ((Status == EFI_NO_MEDIA) || (Status == EFI_MEDIA_CHANGED)) {
>  return Status;
>}
> --
> 2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/6] UefiCpuPkg/MpInitLib: split wake up buffer into two parts

[Wang, Jian J]

Hi Laszlo,

We've found this issue. The patch for it has sent out at 

https://lists.01.org/pipermail/edk2-devel/2018-January/020467.html 

It will be checked in soon.

Regards,
Jian


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, January 29, 2018 5:44 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Dong,
> Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH 1/6] UefiCpuPkg/MpInitLib: split wake up buffer 
> into
> two parts
> 
> On 01/27/18 17:17, Laszlo Ersek wrote:
> > Hello Jian,
> >
> > On 01/15/18 09:54, Jian J Wang wrote:
> >> If PcdDxeNxMemoryProtectionPolicy is set to enable protection for memory
> >> of EfiBootServicesCode, EfiConventionalMemory, the BIOS will hang at a
> page
> >> fault exception during MP initialization.
> >>
> >> The root cause is that the AP wake up buffer, which is below 1MB and used
> >> to hold both AP init code and data, is type of EfiConventionalMemory (not
> >> really allocated because of potential conflict with legacy code), and is
> >> marked as non-executable. During the transition from real address mode
> >> to long mode, the AP init code has to enable paging which will then cause
> >> itself a page fault exception because it's just running in non-executable
> >> memory.
> >>
> >> The solution is splitting AP wake up buffer into two part: lower part is
> >> still below 1MB and shared with legacy system, higher part is really
> >> allocated memory of BootServicesCode type. The init code in the memory
> >> below 1MB will not enable paging but just switch to protected mode and
> >> jump to higher memory, in which the init code will enable paging and
> >> switch to long mode.
> >>
> >> Cc: Jiewen Yao <jiewen@intel.com>
> >> Cc: Ruiyu Ni <ruiyu...@intel.com>
> >> Cc: Eric Dong <eric.d...@intel.com>
> >> Cc: Laszlo Ersek <ler...@redhat.com>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> >> ---
> >>  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c| 34 ++
> >>  UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc|  5 ++
> >>  UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm | 32 +-
> >>  UefiCpuPkg/Library/MpInitLib/MpLib.c   | 45 +
> >>  UefiCpuPkg/Library/MpInitLib/MpLib.h   | 22 +++
> >>  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c| 23 +++
> >>  UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc |  5 +-
> >>  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm  | 87 -
> -
> >>  8 files changed, 204 insertions(+), 49 deletions(-)
> >
> > This patch breaks OVMF on KVM. The symptom is that the guest crashes
> > and reboots as follows (infinite reboot loop):
> >
> >> Loading PEIM at 0x0007FEB EntryPoint=0x0007FEB5C96 CpuMpPei.efi
> >> AP Loop Mode is 1
> >> WakeupBufferStart = 9F000, WakeupBufferSize = 1000
> >> -- crash & reboot here --
> >> SecCoreStartupWithStack(0xFFFCC000, 0x82)
> 
> The following build options were used for this build:
> 
> $ build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -D SECURE_BOOT_ENABLE \
> -t GCC48 -b NOOPT -D HTTP_BOOT_ENABLE
> 
> The tree was built at 06c1f423e17f ("BeagleBoardPkg: reroute Firmware
> Vendor Pcd to MdeModulePkg", 2018-01-26). (This commit is listed at the
> top of the bisection log in my previous email.)
> 
> Here's the KVM log up to the triple fault:
> 
> >  CPU-32283 [004] 13652.374591: kvm_entry:vcpu 2
> >  CPU-32283 [004] 13652.374594: kvm_exit: reason 
> > CR_ACCESS
> rip 0x3a info 0 0
> >  CPU-32283 [004] 13652.374595: kvm_cr:   cr_write 0 
> > =
> 0x6013
> >  CPU-32283 [004] 13652.374596: kvm_entry:vcpu 2
> >  CPU-32283 [004] 13652.374597: kvm_exit: reason 
> > CR_ACCESS
> rip 0x9f06a info 4 0
> >  CPU-32283 [004] 13652.374598: kvm_cr:   cr_write 4 
> > = 0x20
> >  CPU-32283 [004] 13652.374603: kvm_entry:vcpu 2
> >  CPU-32283 [004] 13652.374604: kvm_exit: reason 
> > CR_ACCESS
> rip 0x9f075 info 103 0
> >  CPU-32283 [004] 13652.374605: kvm_cr:   cr_write 3 
> > = 0x80
> > 

Re: [edk2] [PATCH 4/6] UefiCpuPkg/PiSmmCpuDxeSmm: Enable NXE if it's supported

[Wang, Jian J]

Hi Laszlo,

I don't know the history of these code but I guess they're converted from .asm 
file.
That may be why there's "DB 66h" prefix. I think you're right these tricks 
should be
replaced with more formal ways. Please submit a bz tracker for it.

As to the issue, I don't have clue right now. The code seems no problem. Since 
msr
write didn't happen, code flow is correct. And those code has executed on real
32-bit platform without problem. I need more time to investigate it.

Regards,
Jian


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, January 29, 2018 6:47 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Dong,
> Eric <eric.d...@intel.com>; Paolo Bonzini <pbonz...@redhat.com>; Radim
> Kr?má? <rkrc...@redhat.com>
> Subject: Re: [edk2] [PATCH 4/6] UefiCpuPkg/PiSmmCpuDxeSmm: Enable NXE if
> it's supported
> 
> Hello Jian,
> 
> On 01/15/18 09:54, Jian J Wang wrote:
> > If PcdDxeNxMemoryProtectionPolicy is set to enable protection for memory
> > of EfiBootServicesCode, EfiConventionalMemory, the BIOS will hang at a page
> > fault exception triggered by PiSmmCpuDxeSmm.
> >
> > The root cause is that PiSmmCpuDxeSmm will access default SMM RAM
> starting
> > at 0x3 which is marked as non-executable, but NX feature was not
> > enabled during SMM initialization. Accessing memory which has invalid
> > attributes set will cause page fault exception. This patch fixes it by
> > checking NX capability in cpuid and enable NXE in EFER MSR if it's
> > available.
> >
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmInit.nasm | 14 ++
> >  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmInit.nasm  | 12 +++-
> >  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> This patch also breaks OVMF on KVM. However, the circumstances and the
> symptom differ from those of the other regression that I reported under
> patch 1/6 in this series [1] [2].
> 
> Namely, this affects the IA32 build, with SMM:
> 
> $ build -a IA32 -p OvmfPkg/OvmfPkgIa32.dsc -D SECURE_BOOT_ENABLE \
> -D SMM_REQUIRE -t GCC48 -b NOOPT -D HTTP_BOOT_ENABLE
> 
> The value of PcdDxeNxMemoryProtectionPolicy is zero in this build too.
> 
> The virtual CPU model that this OVMF build runs on does *not* support
> NX. (Please refer to "OvmfPkg/README":
> 
> > === SMM support ===
> >
> > [...]
> >
> > * QEMU binary and options specific to 32-bit guests:
> >
> >   $ qemu-system-i386 -cpu coreduo,-nx \
> 
> )
> 
> The boot hangs at the following location:
> 
> > Loading SMM driver at 0x0007FFA2000 EntryPoint=0x0007FFA844D
> PiSmmCpuDxeSmm.efi
> > SMRR Base: 0x7F00, SMRR Size: 0x100
> > PcdCpuSmmCodeAccessCheckEnable = 1
> > mAddressEncMask = 0x0
> > SMRAM TileSize = 0x2000 (0x1000, 0x1000)
> > SMRAM SaveState Buffer (0x7FF94000, 0xE000)
> > CPU[000]  APIC ID=  SMBASE=7FF8C000  SaveState=7FF9BC00
> Size=0400
> > CPU[001]  APIC ID=0001  SMBASE=7FF8E000  SaveState=7FF9DC00
> Size=0400
> > CPU[002]  APIC ID=0002  SMBASE=7FF9  SaveState=7FF9FC00
> Size=0400
> > CPU[003]  APIC ID=0003  SMBASE=7FF92000  SaveState=7FFA1C00
> Size=0400
> > <--HANG-->
> 
> KVM trace (excerpt):
> 
> >  1 CPU-4989  [002] 16163.874223: kvm_enter_smm:vcpu 1: entering SMM,
> smbase 0x3
> >  2 CPU-4989  [002] 16163.874244: kvm_fpu:  load
> >  3 CPU-4989  [002] 16163.874245: kvm_entry:vcpu 1
> >  4 CPU-4989  [002] 16163.874247: kvm_exit: reason EPT_VIOLATION 
> > rip
> 0x8000 info 184 0
> >  5 CPU-4989  [002] 16163.874247: kvm_page_fault:   address 38000
> error_code 184
> >  6 CPU-4989  [002] 16163.874251: kvm_entry:vcpu 1
> >  7 CPU-4989  [002] 16163.874253: kvm_exit: reason EPT_VIOLATION 
> > rip
> 0x7ff864ba info 184 0
> >  8 CPU-4989  [002] 16163.874253: kvm_page_fault:   address 7ffb64ba
> error_code 184
> >  9 CPU-4989  [002] 16163.874256: kvm_entry:vcpu 1
> > 10 CPU-4989  [002] 16163.874257: kvm_exit: reason CPUID rip
> 0x7ff864c0 info 0 0
> > 11 CPU-4989  [002] 16163.874258: kvm_c

Re: [edk2] [PATCH] MdeModulePkg/Core: fix feature conflict between NX and NULL detection

[Wang, Jian J]

gCpu->SetMemoryAttributes() called by SetUefiImageMemoryAttributes() will return
without any problem if Length is 0.

Regards,
Jian


> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, January 30, 2018 10:09 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Ni,
> Ruiyu <ruiyu...@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/Core: fix feature conflict between NX and
> NULL detection
> 
> Hi Jian
> May I know how we handle MemoryMapEntry->NumberOfPages is 1?
> The lengh will be 0 in that case. Should we add additional check?
> 
> > +SetUefiImageMemoryAttributes (
> > +  MemoryMapEntry->PhysicalStart + EFI_PAGE_SIZE,
> > +  LShiftU64 (MemoryMapEntry->NumberOfPages - 1,
> > EFI_PAGE_SHIFT),
> > +  Attributes);
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Monday, January 29, 2018 7:10 PM
> > To: edk2-devel@lists.01.org
> > Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Yao,
> > Jiewen <jiewen@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> > Subject: [PATCH] MdeModulePkg/Core: fix feature conflict between NX and
> > NULL detection
> >
> > If enabled, NX memory protection feature will mark all free memory as
> > NX (non-executable), including page 0. This will overwrite the attributes
> > of page 0 if NULL pointer detection feature is also enabled and then
> > compromise the functionality of it. The solution is skipping the NX
> > attributes setting to page 0 if NULL pointer detection feature is enabled.
> >
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 20
> > 
> >  1 file changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > index 862593f562..150167bf66 100644
> > --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > @@ -845,10 +845,22 @@ InitializeDxeNxMemoryProtectionPolicy (
> >
> >  Attributes = GetPermissionAttributeForMemoryType
> > (MemoryMapEntry->Type);
> >  if (Attributes != 0) {
> > -  SetUefiImageMemoryAttributes (
> > -MemoryMapEntry->PhysicalStart,
> > -LShiftU64 (MemoryMapEntry->NumberOfPages, EFI_PAGE_SHIFT),
> > -Attributes);
> > +  if (MemoryMapEntry->PhysicalStart == 0 &&
> > +  PcdGet8 (PcdNullPointerDetectionPropertyMask) != 0) {
> > +//
> > +// Skip page 0 if NULL pointer detection is enabled to avoid 
> > attributes
> > +// overwritten.
> > +//
> > +SetUefiImageMemoryAttributes (
> > +  MemoryMapEntry->PhysicalStart + EFI_PAGE_SIZE,
> > +  LShiftU64 (MemoryMapEntry->NumberOfPages - 1,
> > EFI_PAGE_SHIFT),
> > +  Attributes);
> > +  } else {
> > +SetUefiImageMemoryAttributes (
> > +  MemoryMapEntry->PhysicalStart,
> > +  LShiftU64 (MemoryMapEntry->NumberOfPages, EFI_PAGE_SHIFT),
> > +  Attributes);
> > +  }
> >  }
> >  MemoryMapEntry = NEXT_MEMORY_DESCRIPTOR (MemoryMapEntry,
> > DescriptorSize);
> >}
> > --
> > 2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Core: fix feature conflict between NX and NULL detection

[Wang, Jian J]

Ok. Thanks for the comments.

Regards,
Jian

> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, February 01, 2018 1:54 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH] MdeModulePkg/Core: fix feature conflict between
> NX and NULL detection
> 
> On 2/1/2018 1:33 PM, Ni, Ruiyu wrote:
> > On 2/1/2018 9:17 AM, Wang, Jian J wrote:
> >> You're right. Using a mask or separating the API into two
> >> (SetMemoryAttributes/ClearMemoryAttributes)
> >> is much better and can avoid many potential issues.
> >>
> >> Regards,
> >> Jian
> >>
> >
> > For now the patch is good enough to leave NULL pointer detection
> > feature enabled.
> >
> > Reviewed-by: Ruiyu Ni <ruiyu...@intel.com>
> >
> >
> >>
> >>> -Original Message-
> >>> From: Ni, Ruiyu
> >>> Sent: Tuesday, January 30, 2018 12:38 PM
> >>> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> >>> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric
> >>> <eric.d...@intel.com>; Yao,
> >>> Jiewen <jiewen@intel.com>
> >>> Subject: Re: [PATCH] MdeModulePkg/Core: fix feature conflict between
> >>> NX and
> >>> NULL detection
> >>>
> >>> On 1/29/2018 7:09 PM, Jian J Wang wrote:
> >>>> If enabled, NX memory protection feature will mark all free memory as
> >>>> NX (non-executable), including page 0. This will overwrite the
> >>>> attributes
> >>>> of page 0 if NULL pointer detection feature is also enabled and then
> >>>> compromise the functionality of it. The solution is skipping the NX
> >>>> attributes setting to page 0 if NULL pointer detection feature is
> >>>> enabled.
> >>>>
> >>>> Cc: Star Zeng <star.z...@intel.com>
> >>>> Cc: Eric Dong <eric.d...@intel.com>
> >>>> Cc: Jiewen Yao <jiewen@intel.com>
> >>>> Cc: Ruiyu Ni <ruiyu...@intel.com>
> >>>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>>> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> >>>> ---
> >>>>    MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 20
> >>> 
> >>>>    1 file changed, 16 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> >>> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> >>>> index 862593f562..150167bf66 100644
> >>>> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> >>>> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> >>>> @@ -845,10 +845,22 @@ InitializeDxeNxMemoryProtectionPolicy (
> >>>>
> >>>>    Attributes = GetPermissionAttributeForMemoryType
> >>>> (MemoryMapEntry-
> >>>> Type);
> >>>>    if (Attributes != 0) {
> >>>> -  SetUefiImageMemoryAttributes (
> >>>> -    MemoryMapEntry->PhysicalStart,
> >>>> -    LShiftU64 (MemoryMapEntry->NumberOfPages, EFI_PAGE_SHIFT),
> >>>> -    Attributes);
> >>>> +  if (MemoryMapEntry->PhysicalStart == 0 &&
> >>>> +  PcdGet8 (PcdNullPointerDetectionPropertyMask) != 0) {
> >>>> +    //
> >>>> +    // Skip page 0 if NULL pointer detection is enabled to
> >>>> avoid attributes
> >>>> +    // overwritten.
> >>>> +    //
> 
> By the way, could you please add an assertion here?
> ASSERT (MemoryMapEntry->NumberOfPages != 0);
> >>>> +    SetUefiImageMemoryAttributes (
> >>>> +  MemoryMapEntry->PhysicalStart + EFI_PAGE_SIZE,
> >>>> +  LShiftU64 (MemoryMapEntry->NumberOfPages - 1,
> >>>> EFI_PAGE_SHIFT),
> >>>> +  Attributes);
> >>>> +  } else {
> >>>> +    SetUefiImageMemoryAttributes (
> >>>> +  MemoryMapEntry->PhysicalStart,
> >>>> +  LShiftU64 (MemoryMapEntry->NumberOfPages, EFI_PAGE_SHIFT),
> >>>> +  Attributes);
> >>>> +  }
> >>>>    }
> >>>>    MemoryMapEntry = NEXT_MEMORY_DESCRIPTOR (MemoryMapEntry,
> >>> DescriptorSize);
> >>>>  }
> >>>>
> >>> Does this bug expose an API-level issue?
> >>> SetUefiImageMemoryAttributes () should also accept a Mask value?
> >>>
> >>> --
> >>> Thanks,
> >>> Ray
> >
> >
> 
> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/SafeString: Directly return when length of source string is 0

[Wang, Jian J]

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>

> -Original Message-
> From: Ni, Ruiyu
> Sent: Friday, February 02, 2018 6:48 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Gao, Liming <liming....@intel.com>;
> Wang, Jian J <jian.j.w...@intel.com>
> Subject: [PATCH] MdePkg/SafeString: Directly return when length of source
> string is 0
> 
> Today's implementation of [Ascii]StrnCpyS/[Ascii]StrnCatS doesn't
> directly return the the length of source string is 0.
> 
> When length of source string is 0, it means the Source points to
> a memory that shouldn't be deferenced at all.
> So it's not proper to call StrnLenS() in such situation.
> In a pool guard enabled environment, when using shell to edit an
> existing file which contains empty line, the page fault is met.
> 
> The patch fixes the four library functions to align to the behavior
> of non-safe version: directly return when length of source string
> is 0.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Jian J Wang <jian.j.w...@intel.com>
> ---
>  MdePkg/Library/BaseLib/SafeString.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/BaseLib/SafeString.c
> b/MdePkg/Library/BaseLib/SafeString.c
> index 68c33e9b7b..fed818ef33 100644
> --- a/MdePkg/Library/BaseLib/SafeString.c
> +++ b/MdePkg/Library/BaseLib/SafeString.c
> @@ -1,7 +1,7 @@
>  /** @file
>Safe String functions.
> 
> -  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -317,6 +317,10 @@ StrnCpyS (
>  {
>UINTNSourceLen;
> 
> +  if (Length == 0) {
> +return RETURN_SUCCESS;
> +  }
> +
>ASSERT (((UINTN) Destination & BIT0) == 0);
>ASSERT (((UINTN) Source & BIT0) == 0);
> 
> @@ -515,6 +519,10 @@ StrnCatS (
>UINTN   CopyLen;
>UINTN   SourceLen;
> 
> +  if (Length == 0) {
> +return RETURN_SUCCESS;
> +  }
> +
>ASSERT (((UINTN) Destination & BIT0) == 0);
>ASSERT (((UINTN) Source & BIT0) == 0);
> 
> @@ -1894,6 +1902,10 @@ AsciiStrnCpyS (
>  {
>UINTNSourceLen;
> 
> +  if (Length == 0) {
> +return RETURN_SUCCESS;
> +  }
> +
>//
>// 1. Neither Destination nor Source shall be a null pointer.
>//
> @@ -2082,6 +2094,10 @@ AsciiStrnCatS (
>UINTN   CopyLen;
>UINTN   SourceLen;
> 
> +  if (Length == 0) {
> +return RETURN_SUCCESS;
> +  }
> +
>//
>// Let CopyLen denote the value DestMax - AsciiStrnLenS(Destination,
> DestMax) upon entry to AsciiStrnCatS.
>//
> --
> 2.16.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/2] Fix error in PrintLib

[Wang, Jian J]

Mike,

Thanks for catching it. The patch has sent out.

Regards,
Jian


> -Original Message-
> From: Kinney, Michael D
> Sent: Friday, December 29, 2017 9:08 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org; Kinney,
> Michael D <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [PATCH v2 0/2] Fix error in PrintLib
> 
> Jian,
> 
> This change breaks GCC5 builds.
> 
> /home/mdkinney/tianocore/edk2/MdeModulePkg/Library/DxePrintLibPrint2Pro
> tocol/PrintLib.c: In function 'InternalPrintLibSPrintMarker':
> /home/mdkinney/tianocore/edk2/MdeModulePkg/Library/DxePrintLibPrint2Pro
> tocol/PrintLib.c:2054:71: error: suggest parentheses around '&&' within '||' 
> [-
> Werror=parentheses]
>  ArgumentString[Count * BytesPerArgumentCharacter] != '\0' &&
> 
> ~~^~~
>  Count < Precision || ((Flags & PRECISION) == 0);
>  ~
> 
> Mike
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org] On Behalf Of Jian J Wang
> > Sent: Wednesday, December 27, 2017 6:38 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH v2 0/2] Fix error in PrintLib
> >
> > > v2:
> > >a. Correct incorrect description in commit log
> > >b. Fix another similar issue in the same function
> > >c. Fix similar issues in
> > MdeModulePkg/DxePrintLibPrint2Protocol
> >
> > Due to a potential hole in the stop condition of the
> > loop, the two continuous
> > access to ArgumentString (index, index+1) inside the
> > loop might cause the
> > string ending character ('\0') and the byte after it to
> > be read.
> >
> > Jian J Wang (2):
> >   MdePkg/BasePrintLib: Fix error in Precision position
> > calculation
> >   MdeModulePkg/DxePrintLibPrint2Protocol: Fix potential
> > string over read
> >
> >
> > MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib
> > .c | 7 +--
> >  MdePkg/Library/BasePrintLib/PrintLibInternal.c
> > | 7 +--
> >  2 files changed, 10 insertions(+), 4 deletions(-)
> >
> > --
> > 2.15.1.windows.2
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

Jiewen,

Please take a look at this patch.

Regards,
Jian


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Friday, December 29, 2017 4:37 PM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Yao, Jiewen ;
> Dong, Eric 
> Subject: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as
> Stack Guard
> 
> The reason is that DXE part initialization will reuse the stack allocated
> at PEI phase, if MP was initialized before. Some code added to check this
> situation and use stack base address saved in HOB passed from PEI.
> 
> Cc: Jiewen Yao 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> index 40c1bf407a..05484c9ff3 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> @@ -295,6 +295,7 @@ InitMpGlobalData (
>UINTN   Index;
>EFI_GCD_MEMORY_SPACE_DESCRIPTOR MemDesc;
>UINTN   StackBase;
> +  CPU_INFO_IN_HOB *CpuInfoInHob;
> 
>SaveCpuMpData (CpuMpData);
> 
> @@ -314,9 +315,18 @@ InitMpGlobalData (
>ASSERT (FALSE);
>  }
> 
> -for (Index = 0; Index < CpuMpData->CpuCount; ++Index) {
> -  StackBase = CpuMpData->Buffer + Index * CpuMpData->CpuApStackSize;
> +//
> +// DXE will reuse stack allocated for APs at PEI phase if it's available.
> +// Let's check it here.
> +//
> +CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData->CpuInfoInHob;
> +if (CpuInfoInHob != NULL && CpuInfoInHob->ApTopOfStack != 0) {
> +  StackBase = CpuInfoInHob->ApTopOfStack;
> +} else {
> +  StackBase = CpuMpData->Buffer;
> +}
> 
> +for (Index = 0; Index < CpuMpData->CpuCount; ++Index) {
>Status = gDS->GetMemorySpaceDescriptor (StackBase, );
>ASSERT_EFI_ERROR (Status);
> 
> @@ -326,6 +336,9 @@ InitMpGlobalData (
>MemDesc.Attributes | EFI_MEMORY_RP
>);
>ASSERT_EFI_ERROR (Status);
> +
> +  DEBUG ((DEBUG_VERBOSE, "Stack Guard set at %x [cpu%d]!\n", StackBase,
> Index));
> +  StackBase += CpuMpData->CpuApStackSize;
>  }
>}
> 
> --
> 2.15.1.windows.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Coding style clean-up

[Wang, Jian J]

Hi Mike,

Since this patch has been checked in trunk, do you think it should be reverted?
In addition, instead of using exception list for the ECC tool, I think it'd be 
better
to update ECC tool to use keyword match to check if a field name is public spec
defined one. Otherwise, if there's new structure type using those field names,
the tool will still report errors.

Regards,
Jian

> -Original Message-
> From: Kinney, Michael D
> Sent: Wednesday, December 27, 2017 12:48 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org; Kinney,
> Michael D <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [PATCH 0/4] Coding style clean-up
> 
> Jian,
> 
> I do not think this change should be made.
> 
> One of the exceptions for not following the
> EDK II code style is if the field names are
> defined in a public specification.  In this case
> these fields are all listed in a structure in
> the Intel 64 and IA-32 Architectures Software
> Development Manual, Section 7.2.1, Figure 7-2
> using upper case register names.
> 
> Thanks,
> 
> Mike
> 
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> > On Behalf Of Jian J Wang
> > Sent: Sunday, December 24, 2017 5:07 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH 0/4] Coding style clean-up
> >
> > This patch series are meant for cleaning up code
> > according to coding style
> > requirements.
> >
> > Jian J Wang (4):
> >   MdePkg/BaseLib.h: Coding style clean-up
> >   MdeModulePkg/Core: Coding style clean-up
> >   UefiCpuPkg/UefiCpuPkg.uni: Add missing string
> > definition for new PCDs
> >   UefiCpuPkg: Update code to use new structure field
> > names
> >
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  5
> > ++
> >  MdePkg/Include/Library/BaseLib.h   | 72
> > +++---
> >  .../Ia32/ArchExceptionHandler.c| 24
> > 
> >  .../X64/ArchExceptionHandler.c |  6
> > +-
> >  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  2
> > +-
> >  UefiCpuPkg/UefiCpuPkg.uni  | 16
> > -
> >  6 files changed, 71 insertions(+), 54 deletions(-)
> >
> > --
> > 2.15.1.windows.2
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BasePrintLib: Fix incorrect Precision position calculation

[Wang, Jian J]

I revisit the code again. You're right that the commit log is not correct.
The '\0' would be read and even the one pass it.

Regards,
Jian


> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 28, 2017 12:38 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org; Kinney,
> Michael D <michael.d.kin...@intel.com>
> Cc: Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>;
> Gao, Liming <liming@intel.com>
> Subject: RE: [edk2] [PATCH] MdePkg/BasePrintLib: Fix incorrect Precision
> position calculation
> 
> Is the commit log correct?
> 
> Is the issue that the character past the '\0' could be read?
> 
> Mike
> 
> > -Original Message-----
> > From: Wang, Jian J
> > Sent: Tuesday, December 26, 2017 6:14 PM
> > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-
> > de...@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Yao,
> > Jiewen <jiewen@intel.com>; Zeng, Star
> > <star.z...@intel.com>; Gao, Liming <liming@intel.com>
> > Subject: RE: [edk2] [PATCH] MdePkg/BasePrintLib: Fix
> > incorrect Precision position calculation
> >
> > Mike and Liming,
> >
> > Could you take a look at this patch?
> >
> > Regards,
> > Jian
> >
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org] On Behalf Of Jian J
> > > Wang
> > > Sent: Monday, December 25, 2017 10:09 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>;
> > Yao, Jiewen
> > > <jiewen@intel.com>; Zeng, Star
> > <star.z...@intel.com>; Gao, Liming
> > > <liming@intel.com>
> > > Subject: [edk2] [PATCH] MdePkg/BasePrintLib: Fix
> > incorrect Precision position
> > > calculation
> > >
> > > Due to the a potential hole in the stop condition of
> > for-loop, the two
> > > continuous access to ArgumentString (index, index+1)
> > inside the loop
> > > might cause the string ending character ('\0') to be
> > read.
> > >
> > > Cc: Michael D Kinney <michael.d.kin...@intel.com>
> > > Cc: Liming Gao <liming@intel.com>
> > > Cc: Jiewen Yao <jiewen@intel.com>
> > > Cc: Star Zeng <star.z...@intel.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > > ---
> > >  MdePkg/Library/BasePrintLib/PrintLibInternal.c | 5
> > -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > a/MdePkg/Library/BasePrintLib/PrintLibInternal.c
> > > b/MdePkg/Library/BasePrintLib/PrintLibInternal.c
> > > index 28d946472f..297d5a05b5 100644
> > > --- a/MdePkg/Library/BasePrintLib/PrintLibInternal.c
> > > +++ b/MdePkg/Library/BasePrintLib/PrintLibInternal.c
> > > @@ -1107,7 +1107,10 @@ BasePrintLibSPrintMarker (
> > >// Compute the number of characters in
> > ArgumentString and store it in
> > > Count
> > >// ArgumentString is either null-terminated, or
> > it contains Precision
> > > characters
> > >//
> > > -  for (Count = 0; Count < Precision || ((Flags &
> > PRECISION) == 0); Count++) {
> > > +  for (Count = 0;
> > > +ArgumentString[Count *
> > BytesPerArgumentCharacter] != '\0' &&
> > > +(Count < Precision || ((Flags & PRECISION)
> > == 0));
> > > +  Count++) {
> > >  ArgumentCharacter = ((ArgumentString[Count *
> > > BytesPerArgumentCharacter] & 0xff) |
> > ((ArgumentString[Count *
> > > BytesPerArgumentCharacter + 1]) << 8)) & ArgumentMask;
> > >  if (ArgumentCharacter == 0) {
> > >break;
> > > --
> > > 2.15.1.windows.2
> > >
> > > ___
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] Coding style clean-up

[Wang, Jian J]

Theoretically, yes. But I think it's a rare case in which someone
will use ESP in a structure but not to represent ESP register.

Regards,
Jian


> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 28, 2017 8:37 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org; Kinney,
> Michael D <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [PATCH 0/4] Coding style clean-up
> 
> Jian,
> 
> I think . is the correct way to list
> this type of exception.  Otherwise we can miss incorrect
> use of that field name.
> 
> Mike
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, December 27, 2017 4:28 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>;
> > edk2-devel@lists.01.org
> > Subject: RE: [edk2] [PATCH 0/4] Coding style clean-up
> >
> > Current ECC use . in exception
> > list to exclude those special
> > field name spec defined. Whenever there's a new
> > structure introduced with those field
> > names, which have been added to exception list, the ECC
> > will still report coding style
> > violation. Maybe we can just use  to do
> > field name match for any structure
> > type to exclude those special names. This can avoid the
> > false reports as many as possible.
> >
> > Regards,
> > Jian
> >
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Thursday, December 28, 2017 12:35 AM
> > > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-
> > de...@lists.01.org; Kinney,
> > > Michael D <michael.d.kin...@intel.com>
> > > Subject: RE: [edk2] [PATCH 0/4] Coding style clean-up
> > >
> > > Yes.  Please revert.
> > >
> > > I am not sure I understand the ECC tool update you
> > are suggesting.
> > > Can you provide more details?
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Wang, Jian J
> > > > Sent: Tuesday, December 26, 2017 4:40 PM
> > > > To: Kinney, Michael D <michael.d.kin...@intel.com>;
> > edk2-
> > > > de...@lists.01.org
> > > > Subject: RE: [edk2] [PATCH 0/4] Coding style clean-
> > up
> > > >
> > > > Hi Mike,
> > > >
> > > > Since this patch has been checked in trunk, do you
> > think
> > > > it should be reverted?
> > > > In addition, instead of using exception list for
> > the ECC
> > > > tool, I think it'd be better
> > > > to update ECC tool to use keyword match to check if
> > a
> > > > field name is public spec
> > > > defined one. Otherwise, if there's new structure
> > type
> > > > using those field names,
> > > > the tool will still report errors.
> > > >
> > > > Regards,
> > > > Jian
> > > >
> > > > > -Original Message-
> > > > > From: Kinney, Michael D
> > > > > Sent: Wednesday, December 27, 2017 12:48 AM
> > > > > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-
> > > > de...@lists.01.org; Kinney,
> > > > > Michael D <michael.d.kin...@intel.com>
> > > > > Subject: RE: [edk2] [PATCH 0/4] Coding style
> > clean-up
> > > > >
> > > > > Jian,
> > > > >
> > > > > I do not think this change should be made.
> > > > >
> > > > > One of the exceptions for not following the
> > > > > EDK II code style is if the field names are
> > > > > defined in a public specification.  In this case
> > > > > these fields are all listed in a structure in
> > > > > the Intel 64 and IA-32 Architectures Software
> > > > > Development Manual, Section 7.2.1, Figure 7-2
> > > > > using upper case register names.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: edk2-devel [mailto:edk2-devel-
> > > > boun...@lists.01.org]
> > > > > > On Behalf Of Jian J Wang
> > > > > > Sent: Sunday, December 24, 2017 5:07 PM
> > > > > > To: edk2-devel@lists.01.org
> > > > > > Subject: [edk2] [PATCH 0/4] Coding style clean-
> > up
> > > > > >
> 

Re: [edk2] [PATCH] MdePkg/BasePrintLib: Fix incorrect Precision position calculation

[Wang, Jian J]

Sure.

Regards,
Jian


> -Original Message-
> From: Gao, Liming
> Sent: Thursday, December 28, 2017 9:57 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH] MdePkg/BasePrintLib: Fix incorrect Precision
> position calculation
> 
> Jian:
>   MdePkg/Library/BasePrintLib/PrintLibInternal.c line 1171 has the similar 
> issue.
> Could you fix it also?
> 
>   And, MdeModulePkg\Library\DxePrintLibPrint2Protocol\PrintLib.c have the
> same issue. Could you sync this fix to it?
> 
> Thanks
> Liming
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, December 28, 2017 8:29 AM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>;
> Gao, Liming <liming@intel.com>
> > Subject: RE: [edk2] [PATCH] MdePkg/BasePrintLib: Fix incorrect Precision
> position calculation
> >
> > I revisit the code again. You're right that the commit log is not correct.
> > The '\0' would be read and even the one pass it.
> >
> > Regards,
> > Jian
> >
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Thursday, December 28, 2017 12:38 AM
> > > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org; Kinney,
> > > Michael D <michael.d.kin...@intel.com>
> > > Cc: Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>;
> > > Gao, Liming <liming@intel.com>
> > > Subject: RE: [edk2] [PATCH] MdePkg/BasePrintLib: Fix incorrect Precision
> > > position calculation
> > >
> > > Is the commit log correct?
> > >
> > > Is the issue that the character past the '\0' could be read?
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Wang, Jian J
> > > > Sent: Tuesday, December 26, 2017 6:14 PM
> > > > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-
> > > > de...@lists.01.org
> > > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Yao,
> > > > Jiewen <jiewen@intel.com>; Zeng, Star
> > > > <star.z...@intel.com>; Gao, Liming <liming@intel.com>
> > > > Subject: RE: [edk2] [PATCH] MdePkg/BasePrintLib: Fix
> > > > incorrect Precision position calculation
> > > >
> > > > Mike and Liming,
> > > >
> > > > Could you take a look at this patch?
> > > >
> > > > Regards,
> > > > Jian
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: edk2-devel [mailto:edk2-devel-
> > > > boun...@lists.01.org] On Behalf Of Jian J
> > > > > Wang
> > > > > Sent: Monday, December 25, 2017 10:09 AM
> > > > > To: edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>;
> > > > Yao, Jiewen
> > > > > <jiewen@intel.com>; Zeng, Star
> > > > <star.z...@intel.com>; Gao, Liming
> > > > > <liming@intel.com>
> > > > > Subject: [edk2] [PATCH] MdePkg/BasePrintLib: Fix
> > > > incorrect Precision position
> > > > > calculation
> > > > >
> > > > > Due to the a potential hole in the stop condition of
> > > > for-loop, the two
> > > > > continuous access to ArgumentString (index, index+1)
> > > > inside the loop
> > > > > might cause the string ending character ('\0') to be
> > > > read.
> > > > >
> > > > > Cc: Michael D Kinney <michael.d.kin...@intel.com>
> > > > > Cc: Liming Gao <liming@intel.com>
> > > > > Cc: Jiewen Yao <jiewen@intel.com>
> > > > > Cc: Star Zeng <star.z...@intel.com>
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > > > > ---
> > > > >  MdePkg/Library/BasePrintLib/PrintLibInternal.c | 5
> > > > -
> > > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git
> > > > a/MdeP

Re: [edk2] [PATCH 0/4] Coding style clean-up

[Wang, Jian J]

Current ECC use . in exception list to exclude those 
special
field name spec defined. Whenever there's a new structure introduced with those 
field
names, which have been added to exception list, the ECC will still report 
coding style
violation. Maybe we can just use  to do field name match for any 
structure
type to exclude those special names. This can avoid the false reports as many 
as possible.

Regards,
Jian


> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, December 28, 2017 12:35 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org; Kinney,
> Michael D <michael.d.kin...@intel.com>
> Subject: RE: [edk2] [PATCH 0/4] Coding style clean-up
> 
> Yes.  Please revert.
> 
> I am not sure I understand the ECC tool update you are suggesting.
> Can you provide more details?
> 
> Mike
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Tuesday, December 26, 2017 4:40 PM
> > To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-
> > de...@lists.01.org
> > Subject: RE: [edk2] [PATCH 0/4] Coding style clean-up
> >
> > Hi Mike,
> >
> > Since this patch has been checked in trunk, do you think
> > it should be reverted?
> > In addition, instead of using exception list for the ECC
> > tool, I think it'd be better
> > to update ECC tool to use keyword match to check if a
> > field name is public spec
> > defined one. Otherwise, if there's new structure type
> > using those field names,
> > the tool will still report errors.
> >
> > Regards,
> > Jian
> >
> > > -Original Message-
> > > From: Kinney, Michael D
> > > Sent: Wednesday, December 27, 2017 12:48 AM
> > > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-
> > de...@lists.01.org; Kinney,
> > > Michael D <michael.d.kin...@intel.com>
> > > Subject: RE: [edk2] [PATCH 0/4] Coding style clean-up
> > >
> > > Jian,
> > >
> > > I do not think this change should be made.
> > >
> > > One of the exceptions for not following the
> > > EDK II code style is if the field names are
> > > defined in a public specification.  In this case
> > > these fields are all listed in a structure in
> > > the Intel 64 and IA-32 Architectures Software
> > > Development Manual, Section 7.2.1, Figure 7-2
> > > using upper case register names.
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-
> > boun...@lists.01.org]
> > > > On Behalf Of Jian J Wang
> > > > Sent: Sunday, December 24, 2017 5:07 PM
> > > > To: edk2-devel@lists.01.org
> > > > Subject: [edk2] [PATCH 0/4] Coding style clean-up
> > > >
> > > > This patch series are meant for cleaning up code
> > > > according to coding style
> > > > requirements.
> > > >
> > > > Jian J Wang (4):
> > > >   MdePkg/BaseLib.h: Coding style clean-up
> > > >   MdeModulePkg/Core: Coding style clean-up
> > > >   UefiCpuPkg/UefiCpuPkg.uni: Add missing string
> > > > definition for new PCDs
> > > >   UefiCpuPkg: Update code to use new structure field
> > > > names
> > > >
> > > >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |
> > 5
> > > > ++
> > > >  MdePkg/Include/Library/BaseLib.h   |
> > 72
> > > > +++---
> > > >  .../Ia32/ArchExceptionHandler.c|
> > 24
> > > > 
> > > >  .../X64/ArchExceptionHandler.c |
> > 6
> > > > +-
> > > >  UefiCpuPkg/Library/MpInitLib/MpLib.c   |
> > 2
> > > > +-
> > > >  UefiCpuPkg/UefiCpuPkg.uni  |
> > 16
> > > > -
> > > >  6 files changed, 71 insertions(+), 54 deletions(-)
> > > >
> > > > --
> > > > 2.15.1.windows.2
> > > >
> > > > ___
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

Laszlo,

I revisited code of MpInitLib. I found that CPU_INFO_IN_HOB.ApTopOfStack
was assigned to CpuMpData->Buffer in MpInitLibInitialize()

(line1501)  InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer);

but in 

(line598)  ApTopOfStack  = CpuMpData->Buffer + (ProcessorNumber + 1) * 
CpuMpData->CpuApStackSize;
(line608)  InitializeApData (CpuMpData, ProcessorNumber, BistData, 
ApTopOfStack);

Since InitMpGlobalData() is called just after first situation, my patch is 
correct.

I think the problem here is that ApTopOfStack initialized at line 1501 is not 
correct.


Regards,
Jian


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, January 04, 2018 1:33 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Jeff Fan <vanjeff_...@hotmail.com>
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> as Stack Guard
> 
> (CC Jeff)
> 
> Sorry about the delay.
> 
> I have some light comments below; I expect at least a few of them to be
> incorrect :)
> 
> On 12/29/17 09:36, Jian J Wang wrote:
> > The reason is that DXE part initialization will reuse the stack allocated
> > at PEI phase, if MP was initialized before. Some code added to check this
> > situation and use stack base address saved in HOB passed from PEI.
> >
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 17 +++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > index 40c1bf407a..05484c9ff3 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > @@ -295,6 +295,7 @@ InitMpGlobalData (
> >UINTN   Index;
> >EFI_GCD_MEMORY_SPACE_DESCRIPTOR MemDesc;
> >UINTN   StackBase;
> > +  CPU_INFO_IN_HOB *CpuInfoInHob;
> >
> >SaveCpuMpData (CpuMpData);
> >
> > @@ -314,9 +315,18 @@ InitMpGlobalData (
> >ASSERT (FALSE);
> >  }
> >
> > -for (Index = 0; Index < CpuMpData->CpuCount; ++Index) {
> > -  StackBase = CpuMpData->Buffer + Index * CpuMpData->CpuApStackSize;
> > +//
> > +// DXE will reuse stack allocated for APs at PEI phase if it's 
> > available.
> > +// Let's check it here.
> > +//
> > +CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData-
> >CpuInfoInHob;
> > +if (CpuInfoInHob != NULL && CpuInfoInHob->ApTopOfStack != 0) {
> > +  StackBase = CpuInfoInHob->ApTopOfStack;
> > +} else {
> > +  StackBase = CpuMpData->Buffer;
> > +}
> 
> So, if the HOB is not found, then StackBase is set okay.
> 
> However, I'm unsure about the other case. The
> CPU_INFO_IN_HOB.ApTopOfStack field identifies the *top* of the stack
> (highest address, and the stack grows down); however the loop below
> *increments* StackBase. Given the incrementing nature of the loop,
> shouldn't we first calculate the actual base (= lowest address) from the
> CPU_INFO_IN_HOB.ApTopOfStack field?
> 
> Actually... I'm even more confused. The CpuMpData->CpuInfoInHob field
> points to an *array* of CPU_INFO_IN_HOB structures. Therefore, for any
> given processor #N, we should not calculate the stack base as
> 
>   CpuMpData->CpuInfoInHob->ApTopOfStack + N * CpuMpData-
> >CpuApStackSize
> 
> instead we should calculate the stack base as something like:
> 
>   CpuMpData->CpuInfoInHob[N].ApTopOfStack - CpuMpData->CpuApStackSize
> 
> See
> - the InitializeApData() function,
> - and its call site in the ApWakeupFunction() function.
> 
> (To my surprise, I personally modified InitializeApData() earlier, in
> commit dd3fa0cd72de ("UefiCpuPkg/MpInitLib: support 64-bit AP stack
> addresses", 2016-11-17) -- I've totally forgotten about that by now!)
> 
> What do you think?
> 
> >
> > +for (Index = 0; Index < CpuMpData->CpuCount; ++Index) {
> >Status = gDS->GetMemorySpaceDescriptor (StackBase, );
> >ASSERT_EFI_ERROR (Status);
> >
> > @@ -326,6 +336,9 @@ InitMpGlobalData (
> >Me

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

Laszlo,

More explanations:

[UefiCpuPkg\Library\MpInitLib\MpLib.c]
According to the code, the BSP's (CpuInfoInHob[0].ApTopOfStack) is initialized 
to
the bottom of the stack (line 1501) but AP's ApTopOfStack is correctly 
initialized
(line 598). Although my calculation is correct, I think it'd be better to use 
AP's 
ApTopOfStack directly. From this perspective, you're right.

Maybe it'd be better to pass a NULL pointer at line 1501 because BSP doesn't 
need
it anyway.

Regards,
Jian


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Thursday, January 04, 2018 8:42 AM
> To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> as Stack Guard
> 
> Laszlo,
> 
> I revisited code of MpInitLib. I found that CPU_INFO_IN_HOB.ApTopOfStack
> was assigned to CpuMpData->Buffer in MpInitLibInitialize()
> 
> (line1501)  InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer);
> 
> but in
> 
> (line598)  ApTopOfStack  = CpuMpData->Buffer + (ProcessorNumber + 1) *
> CpuMpData->CpuApStackSize;
> (line608)  InitializeApData (CpuMpData, ProcessorNumber, BistData,
> ApTopOfStack);
> 
> Since InitMpGlobalData() is called just after first situation, my patch is 
> correct.
> 
> I think the problem here is that ApTopOfStack initialized at line 1501 is not
> correct.
> 
> 
> Regards,
> Jian
> 
> 
> > -----Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Thursday, January 04, 2018 1:33 AM
> > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> > Jeff Fan <vanjeff_...@hotmail.com>
> > Subject: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> > as Stack Guard
> >
> > (CC Jeff)
> >
> > Sorry about the delay.
> >
> > I have some light comments below; I expect at least a few of them to be
> > incorrect :)
> >
> > On 12/29/17 09:36, Jian J Wang wrote:
> > > The reason is that DXE part initialization will reuse the stack allocated
> > > at PEI phase, if MP was initialized before. Some code added to check this
> > > situation and use stack base address saved in HOB passed from PEI.
> > >
> > > Cc: Jiewen Yao <jiewen@intel.com>
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Cc: Laszlo Ersek <ler...@redhat.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > > ---
> > >  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 17 +++--
> > >  1 file changed, 15 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > index 40c1bf407a..05484c9ff3 100644
> > > --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > @@ -295,6 +295,7 @@ InitMpGlobalData (
> > >UINTN   Index;
> > >EFI_GCD_MEMORY_SPACE_DESCRIPTOR MemDesc;
> > >UINTN   StackBase;
> > > +  CPU_INFO_IN_HOB *CpuInfoInHob;
> > >
> > >SaveCpuMpData (CpuMpData);
> > >
> > > @@ -314,9 +315,18 @@ InitMpGlobalData (
> > >ASSERT (FALSE);
> > >  }
> > >
> > > -for (Index = 0; Index < CpuMpData->CpuCount; ++Index) {
> > > -  StackBase = CpuMpData->Buffer + Index * CpuMpData->CpuApStackSize;
> > > +//
> > > +// DXE will reuse stack allocated for APs at PEI phase if it's 
> > > available.
> > > +// Let's check it here.
> > > +//
> > > +CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData-
> > >CpuInfoInHob;
> > > +if (CpuInfoInHob != NULL && CpuInfoInHob->ApTopOfStack != 0) {
> > > +  StackBase = CpuInfoInHob->ApTopOfStack;
> > > +} else {
> > > +  StackBase = CpuMpData->Buffer;
> > > +}
> >
> > So, if the HOB is not found, then StackBase is set okay.
> >
> > However, I'm unsure about the other case. The
> > CPU_INFO_IN_HOB.ApTopOfStack field identifies the *top* of the stack
> > (highest address, and the stack grows down

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set as Stack Guard

[Wang, Jian J]

A correction: although BSP doesn't need it, we still need to initialize its 
ApTopOfStack
correctly because the MP service supports BSP/AP exchange. So I think the line 
1501
should be changed to

  InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer + 
CpuMpData->CpuApStackSize);

instead of

  InitializeApData (CpuMpData, 0, 0, NULL);

Regards,
Jian


> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, January 04, 2018 9:09 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: RE: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> as Stack Guard
> 
> Laszlo,
> 
> More explanations:
> 
> [UefiCpuPkg\Library\MpInitLib\MpLib.c]
> According to the code, the BSP's (CpuInfoInHob[0].ApTopOfStack) is initialized
> to
> the bottom of the stack (line 1501) but AP's ApTopOfStack is correctly 
> initialized
> (line 598). Although my calculation is correct, I think it'd be better to use 
> AP's
> ApTopOfStack directly. From this perspective, you're right.
> 
> Maybe it'd be better to pass a NULL pointer at line 1501 because BSP doesn't
> need
> it anyway.
> 
> Regards,
> Jian
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wang,
> > Jian J
> > Sent: Thursday, January 04, 2018 8:42 AM
> > To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> > Subject: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address set
> > as Stack Guard
> >
> > Laszlo,
> >
> > I revisited code of MpInitLib. I found that CPU_INFO_IN_HOB.ApTopOfStack
> > was assigned to CpuMpData->Buffer in MpInitLibInitialize()
> >
> > (line1501)  InitializeApData (CpuMpData, 0, 0, CpuMpData->Buffer);
> >
> > but in
> >
> > (line598)  ApTopOfStack  = CpuMpData->Buffer + (ProcessorNumber + 1) *
> > CpuMpData->CpuApStackSize;
> > (line608)  InitializeApData (CpuMpData, ProcessorNumber, BistData,
> > ApTopOfStack);
> >
> > Since InitMpGlobalData() is called just after first situation, my patch is 
> > correct.
> >
> > I think the problem here is that ApTopOfStack initialized at line 1501 is 
> > not
> > correct.
> >
> >
> > Regards,
> > Jian
> >
> >
> > > -Original Message-
> > > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > > Sent: Thursday, January 04, 2018 1:33 AM
> > > To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> > > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> > > Jeff Fan <vanjeff_...@hotmail.com>
> > > Subject: Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix wrong base address
> set
> > > as Stack Guard
> > >
> > > (CC Jeff)
> > >
> > > Sorry about the delay.
> > >
> > > I have some light comments below; I expect at least a few of them to be
> > > incorrect :)
> > >
> > > On 12/29/17 09:36, Jian J Wang wrote:
> > > > The reason is that DXE part initialization will reuse the stack 
> > > > allocated
> > > > at PEI phase, if MP was initialized before. Some code added to check 
> > > > this
> > > > situation and use stack base address saved in HOB passed from PEI.
> > > >
> > > > Cc: Jiewen Yao <jiewen@intel.com>
> > > > Cc: Eric Dong <eric.d...@intel.com>
> > > > Cc: Laszlo Ersek <ler...@redhat.com>
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > > > ---
> > > >  UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 17 +++--
> > > >  1 file changed, 15 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > > index 40c1bf407a..05484c9ff3 100644
> > > > --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > > +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> > > > @@ -295,6 +295,7 @@ InitMpGlobalData (
> > > >UINTN   Index;
> > > >EFI_GCD_MEMORY_SPACE_DESCRIPTOR MemDesc;
> > > >UINTN  

Re: [edk2] [PATCH 17/26] MdeModulePkg PiSmmCore: Remove redundant functions

[Wang, Jian J]

For HeapGuard.c part,

Reviewed-by: Jian J Wang 
mailto:jian.j.w...@intel.com>>

Regards,
Jian

From: Ni, Ruiyu
Sent: Thursday, August 09, 2018 11:12 AM
To: Zhang, Shenglei ; edk2-devel@lists.01.org
Cc: Dong, Eric ; Zeng, Star ; Wang, 
Jian J 
Subject: RE: [edk2] [PATCH 17/26] MdeModulePkg PiSmmCore: Remove redundant 
functions

+ Wang Jian.

Thanks/Ray

> -Original Message-
> From: edk2-devel 
> mailto:edk2-devel-boun...@lists.01.org>> On 
> Behalf Of shenglei
> Sent: Wednesday, August 8, 2018 4:47 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Zeng, Star 
> mailto:star.z...@intel.com>>
> Subject: [edk2] [PATCH 17/26] MdeModulePkg PiSmmCore: Remove
> redundant functions
>
> The functions that are never called have been removed.
> They are IsImageInsideSmram,FindImageRecord,SmmRemoveImageRecord,
> SmmMemoryAttributesTableConsistencyCheck,DumpSmmMemoryMapEntr
> y,
> SmmMemoryMapConsistencyCheckRange,SmmMemoryMapConsistencyCh
> eck,
> DumpSmmMemoryMap,ClearGuardMapBit,SetGuardMapBit,AdjustMemory
> A,
> AdjustMemoryS,IsHeadGuard and IsTailGuard.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1062
>
> Cc: Star Zeng mailto:star.z...@intel.com>>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: shenglei 
> mailto:shenglei.zh...@intel.com>>
> ---
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.c   | 166 --
>  .../Core/PiSmmCore/MemoryAttributesTable.c| 131 --
>  MdeModulePkg/Core/PiSmmCore/Page.c| 121 -
>  3 files changed, 418 deletions(-)
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> index d9e54b96cb..f7ae9ae286 100644
> --- a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> +++ b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> @@ -455,51 +455,6 @@ GetGuardMapBit (
>return 0;
>  }
>
> -/**
> -  Set the bit in bitmap table for the given address.
> -
> -  @param[in]  Address The address to set for.
> -
> -  @return VOID.
> -**/
> -VOID
> -EFIAPI
> -SetGuardMapBit (
> -  IN EFI_PHYSICAL_ADDRESSAddress
> -  )
> -{
> -  UINT64*GuardMap;
> -  UINT64BitMask;
> -
> -  FindGuardedMemoryMap (Address, TRUE, );
> -  if (GuardMap != NULL) {
> -BitMask = LShiftU64 (1, GUARDED_HEAP_MAP_ENTRY_BIT_INDEX
> (Address));
> -*GuardMap |= BitMask;
> -  }
> -}
> -
> -/**
> -  Clear the bit in bitmap table for the given address.
> -
> -  @param[in]  Address The address to clear for.
> -
> -  @return VOID.
> -**/
> -VOID
> -EFIAPI
> -ClearGuardMapBit (
> -  IN EFI_PHYSICAL_ADDRESSAddress
> -  )
> -{
> -  UINT64*GuardMap;
> -  UINT64BitMask;
> -
> -  FindGuardedMemoryMap (Address, TRUE, );
> -  if (GuardMap != NULL) {
> -BitMask = LShiftU64 (1, GUARDED_HEAP_MAP_ENTRY_BIT_INDEX
> (Address));
> -*GuardMap &= ~BitMask;
> -  }
> -}
>
>  /**
>Check to see if the page at the given address is a Guard page or not.
> @@ -526,39 +481,7 @@ IsGuardPage (
>return ((BitMap == BIT0) || (BitMap == BIT2) || (BitMap == (BIT2 | 
> BIT0)));  }
>
> -/**
> -  Check to see if the page at the given address is a head Guard page or not.
>
> -  @param[in]  Address The address to check for.
> -
> -  @return TRUE  The page at Address is a head Guard page.
> -  @return FALSE The page at Address is not a head Guard page.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsHeadGuard (
> -  IN EFI_PHYSICAL_ADDRESSAddress
> -  )
> -{
> -  return (GetGuardedMemoryBits (Address, 2) == BIT1); -}
> -
> -/**
> -  Check to see if the page at the given address is a tail Guard page or not.
> -
> -  @param[in]  Address The address to check for.
> -
> -  @return TRUE  The page at Address is a tail Guard page.
> -  @return FALSE The page at Address is not a tail Guard page.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsTailGuard (
> -  IN EFI_PHYSICAL_ADDRESSAddress
> -  )
> -{
> -  return (GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 2) == BIT0); -}
>
>  /**
>Check to see if the page at the given address is guarded or not.
> @@ -864,66 +787,7 @@ UnsetGuardForMemory (
>ClearGuardedMemoryBits(Memory, NumberOfPages);  }
>
> -/**
> -  Adjust address of free memory according to existing and/or required
> Guard.
> -
> -  This function will check if there're existing Guard pages of adjacent
> -  memory blocks, and try to use it as the Guard page of the memory to be
> -  allocated.
>
> -  @par

Re: [edk2] [PATCH 16/26] MdeModulePkg Core/Dxe: Remove redundant functions

[Wang, Jian J]

For HeapGuard.c part,

Reviewed-by: Jian J Wang 
mailto:jian.j.w...@intel.com>>

Regards,
Jian

From: Ni, Ruiyu
Sent: Thursday, August 09, 2018 11:10 AM
To: Zhang, Shenglei ; edk2-devel@lists.01.org
Cc: Dong, Eric ; Zeng, Star ; Wang, 
Jian J 
Subject: RE: [edk2] [PATCH 16/26] MdeModulePkg Core/Dxe: Remove redundant 
functions

Copying Wang Jian.

Reviewed-by: Ruiyu Ni mailto:ruiyu...@intel.com>>

Thanks/Ray

> -Original Message-
> From: edk2-devel 
> mailto:edk2-devel-boun...@lists.01.org>> On 
> Behalf Of shenglei
> Sent: Wednesday, August 8, 2018 4:47 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Zeng, Star 
> mailto:star.z...@intel.com>>
> Subject: [edk2] [PATCH 16/26] MdeModulePkg Core/Dxe: Remove
> redundant functions
>
> The functions that are never called have been removed.
> They are ClearGuardMapBit,SetGuardMapBit,IsHeadGuard,
> IsTailGuard and CoreEfiNotAvailableYetArg0.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1062
>
> Cc: Star Zeng mailto:star.z...@intel.com>>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: shenglei 
> mailto:shenglei.zh...@intel.com>>
> ---
>  MdeModulePkg/Core/Dxe/DxeMain.h | 13 -
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c | 22 ---
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c   | 78 -
>  3 files changed, 113 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h
> b/MdeModulePkg/Core/Dxe/DxeMain.h index 7ec82388a3..8f0b28d095
> 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
> @@ -2178,19 +2178,6 @@ CoreDisplayDiscoveredNotDispatched (
>);
>
>
> -/**
> -  Place holder function until all the Boot Services and Runtime Services are
> -  available.
> -
> -  @return EFI_NOT_AVAILABLE_YET
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -CoreEfiNotAvailableYetArg0 (
> -  VOID
> -  );
> -
>
>  /**
>Place holder function until all the Boot Services and Runtime Services are
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> index fc46022c3c..bbb048a127 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> +++ b/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
> @@ -560,28 +560,6 @@ DxeMain (
>
>
>
> -/**
> -  Place holder function until all the Boot Services and Runtime Services are
> -  available.
> -
> -  @return EFI_NOT_AVAILABLE_YET
> -
> -**/
> -EFI_STATUS
> -EFIAPI
> -CoreEfiNotAvailableYetArg0 (
> -  VOID
> -  )
> -{
> -  //
> -  // This function should never be executed.  If it does, then the 
> architectural
> protocols
> -  // have not been designed correctly.  The CpuBreakpoint () is commented
> out for now until the
> -  // DXE Core and all the Architectural Protocols are complete.
> -  //
> -
> -  return EFI_NOT_AVAILABLE_YET;
> -}
> -
>
>  /**
>Place holder function until all the Boot Services and Runtime Services are
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 447c56bb11..663f969c0d 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -443,51 +443,6 @@ GetGuardMapBit (
>return 0;
>  }
>
> -/**
> -  Set the bit in bitmap table for the given address.
> -
> -  @param[in]  Address The address to set for.
> -
> -  @return VOID.
> -**/
> -VOID
> -EFIAPI
> -SetGuardMapBit (
> -  IN EFI_PHYSICAL_ADDRESSAddress
> -  )
> -{
> -  UINT64*GuardMap;
> -  UINT64BitMask;
> -
> -  FindGuardedMemoryMap (Address, TRUE, );
> -  if (GuardMap != NULL) {
> -BitMask = LShiftU64 (1, GUARDED_HEAP_MAP_ENTRY_BIT_INDEX
> (Address));
> -*GuardMap |= BitMask;
> -  }
> -}
> -
> -/**
> -  Clear the bit in bitmap table for the given address.
> -
> -  @param[in]  Address The address to clear for.
> -
> -  @return VOID.
> -**/
> -VOID
> -EFIAPI
> -ClearGuardMapBit (
> -  IN EFI_PHYSICAL_ADDRESSAddress
> -  )
> -{
> -  UINT64*GuardMap;
> -  UINT64BitMask;
> -
> -  FindGuardedMemoryMap (Address, TRUE, );
> -  if (GuardMap != NULL) {
> -BitMask = LShiftU64 (1, GUARDED_HEAP_MAP_ENTRY_BIT_INDEX
> (Address));
> -*GuardMap &= ~BitMask;
> -  }
> -}
>
>  /**
>Check to see if the page at the given address is a Guard page or not.
> @@ -514,39 +469,6 @@ IsGuardPage (
>return ((BitMap == BIT0) || (BitMap == BIT2) || (BitMap == (BIT2 | 
> BIT0)));  

Re: [edk2] [PATCH v3] IntelFrameworkModulePkg/Csm: Set CSM memory executable

[Wang, Jian J]

Hi Ruiyu,

In function description comments, the @retval doesn't match the changes in this 
patch.

With those changes,
Reviewed-by: Jian J Wang 

Regards,
Jian

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, August 08, 2018 1:28 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Laszlo Ersek ;
> Wang, Jian J 
> Subject: [PATCH v3] IntelFrameworkModulePkg/Csm: Set CSM memory
> executable
> 
> Commit b22a62be5cdc8fd19d87ec1ecfa5b28fb9be50ad
> * IntelFrameworkModule/LegacyBios:Use reserved memory for legacy data
> allocates reserved memory for holding legacy code/data.
> 
> But with PcdDxeNxMemoryProtectionPolicy set to certain value to
> forbid execution when code is in certain type of memory, it's
> possible that a platform forbids execution when code is in reserved
> memory. The patch calls GCD service to allow such case otherwise
> CPU exception may occur.
> 
> Code execution in BSCode area should be enabled by platform by
> default.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Star Zeng 
> Cc: Laszlo Ersek 
> Cc: Jian Wang 
> ---
>  .../Csm/LegacyBiosDxe/LegacyBios.c | 28 
> ++
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> index 8f14687b28..80efe40489 100644
> --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c
> @@ -64,8 +64,9 @@ AllocateLegacyMemory (
>OUT EFI_PHYSICAL_ADDRESS  *Result
>)
>  {
> -  EFI_STATUSStatus;
> -  EFI_PHYSICAL_ADDRESS  MemPage;
> +  EFI_STATUS  Status;
> +  EFI_PHYSICAL_ADDRESSMemPage;
> +  EFI_GCD_MEMORY_SPACE_DESCRIPTOR MemDesc;
> 
>//
>// Allocate Pages of memory less <= StartPageAddress
> @@ -81,12 +82,29 @@ AllocateLegacyMemory (
>// Do not ASSERT on Status error but let caller decide since some cases
>// memory is already taken but that is ok.
>//
> +  if (!EFI_ERROR (Status)) {
> +if (MemoryType != EfiBootServicesCode) {
> +  //
> +  // Make sure that the buffer can be used to store code.
> +  //
> +  Status = gDS->GetMemorySpaceDescriptor (MemPage, );
> +  if (!EFI_ERROR (Status) && (MemDesc.Attributes & EFI_MEMORY_XP) != 0) {
> +Status = gDS->SetMemorySpaceAttributes (
> +MemPage,
> +EFI_PAGES_TO_SIZE (Pages),
> +MemDesc.Attributes & (~EFI_MEMORY_XP)
> +);
> +  }
> +  if (EFI_ERROR (Status)) {
> +gBS->FreePages (MemPage, Pages);
> +  }
> +}
> +  }
> +
>if (!EFI_ERROR (Status)) {
>  *Result = (EFI_PHYSICAL_ADDRESS) (UINTN) MemPage;
>}
> -  //
> -  // If reach here the status = EFI_SUCCESS
> -  //
> +
>return Status;
>  }
> 
> --
> 2.16.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/edit: Fix heap access out-of-bounds

[Wang, Jian J]

Reviewed-by: Jian J Wang 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, August 16, 2018 2:33 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Wang, Jian J
> 
> Subject: [PATCH] ShellPkg/edit: Fix heap access out-of-bounds
> 
> The issue was found when heap guard is turned on.
> PrintLib somehow receives a non-null terminated string in var-arg.
> When the PrintLib implementation reads the string it keeps
> reading because no null-terminator is met, which triggers the page
> fault set by the heap guard.
> 
> The issue is caused by a bug in FileBufferPrintLine().
> When "edit" opens a binary file, in FileBufferPrintLine(),
> the Line->Buffer may start with \x00 \x00, but the Line->Size is
> larger than MainEditor.ScreenSize.Column, it causes the PrintLine is
> set to an empty string by below call:
> StrnCpyS (
>   PrintLine, BufLen/sizeof(CHAR16), Buffer,
>   MIN(Limit, MainEditor.ScreenSize.Column)
>   );
> But since Limit (equals to Line->Size) is larger than
> MainEditor.ScreenSize.Column, below for-loop doesn't successfully
> set the whole PrintLine to all-empty-space.
> for (; Limit < MainEditor.ScreenSize.Column; Limit++) {
>   PrintLine[Limit] = L' ';
> }
> So after the for-loop, PrintLine is still an empty string.
> Later in below call, the PrintLine2 is created based on PrintLine.
> ShellCopySearchAndReplace (
>   PrintLine, PrintLine2,
>   BufLen * 2, L"%", L"^%", FALSE, FALSE
>   );
> But due to the implementation of ShellCopySearchAndReplace(),
> PrintLine2 is untouched and INVALID_PARAMETER is returned.
> Finally an uninitialized string is passed to ShellPrintEx()
> which causes the #PF exception.
> 
> The fix is to reset Limit to StrLen(PrintLine) before for-loop.
> So that PrintLine can be converted from an empty string to a
> string containing all spaces.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> Cc: Jian Wang 
> ---
>  ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> index 56ccd399b0..39a5afb53f 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c
> @@ -500,7 +500,7 @@ FileBufferPrintLine (
>PrintLine = AllocatePool (BufLen);
>if (PrintLine != NULL) {
>  StrnCpyS (PrintLine, BufLen/sizeof(CHAR16), Buffer, MIN(Limit,
> MainEditor.ScreenSize.Column));
> -for (; Limit < MainEditor.ScreenSize.Column; Limit++) {
> +for (Limit = StrLen (PrintLine); Limit < MainEditor.ScreenSize.Column; 
> Limit++)
> {
>PrintLine[Limit] = L' ';
>  }
> 
> --
> 2.16.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 3/4] UefiCpuPkg/CpuDxe: implement non-stop mode for uefi

[Wang, Jian J]

Hi Laszlo,

Regards,
Jian

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, August 21, 2018 10:59 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Dong, Eric 
Subject: Re: [edk2] [PATCH v2 3/4] UefiCpuPkg/CpuDxe: implement non-stop mode 
for uefi

I only have some superficial comments here.

On 08/21/18 05:05, Jian J Wang wrote:
>> v2 changes:
>>n/a
>
> Same as SMM profile feature, a special #PF is used to set page attribute
> to 'present' and a special #DB handler to reset it back to 'not-present',
> right after the instruction causing #PF got executed.
>
> Since the new #PF handler won't enter into dead-loop, the instruction
> which caused the #PF will get chance to re-execute with accessible pages.
>
> The exception message will still be printed out on debug console so that
> the developer/QA can find that there's potential heap overflow or null
> pointer access occurred.
>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.h   |  39 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.inf |   3 +
>  UefiCpuPkg/CpuDxe/CpuMp.c|  34 -
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 271 
> +++
>  4 files changed, 341 insertions(+), 6 deletions(-)
>
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.h b/UefiCpuPkg/CpuDxe/CpuDxe.h
> index 540f5f2dbf..7d65e39e90 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.h
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.h
> @@ -57,6 +57,12 @@
> EFI_MEMORY_RO\
> )
>
> +#define HEAP_GUARD_NONSTOP_MODE   \
> +((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT6|BIT1|BIT0)) > BIT6)
> +
> +#define NULL_DETECTION_NONSTOP_MODE   \
> +((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT6|BIT0)) > 
> BIT6)
> +
>  /**
>Flush CPU data cache. If the instruction cache is fully coherent
>with all DMA operations then function can just return EFI_SUCCESS.
> @@ -273,7 +279,40 @@ RefreshGcdMemoryAttributesFromPaging (
>VOID
>);
>
> +/**
> +  Special handler for #DB exception, which will restore the page attributes
> +  (not-present). It should work with #PF handler which will set pages to
> +  'present'.
> +
> +  @param ExceptionType  Exception type.
> +  @param SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugExceptionHandler (
> +  IN EFI_EXCEPTION_TYPE   InterruptType,
> +  IN EFI_SYSTEM_CONTEXT   SystemContext
> +  );
> +
> +/**
> +  Special handler for #PF exception, which will set the pages which caused
> +  #PF to be 'present'. The attribute of those pages should be restored in
> +  the subsequent #DB handler.
> +
> +  @param ExceptionType  Exception type.
> +  @param SystemContext  Pointer to EFI_SYSTEM_CONTEXT.
> +
> +**/
> +VOID
> +EFIAPI
> +PageFaultExceptionHandler (
> +  IN EFI_EXCEPTION_TYPE   InterruptType,
> +  IN EFI_SYSTEM_CONTEXT   SystemContext
> +  );
> +
>  extern BOOLEAN mIsAllocatingPageTable;
> +extern UINTN   mNumberOfProcessors;
>
>  #endif
>
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> index 6a199b72f7..97a381b046 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> @@ -46,6 +46,7 @@
>ReportStatusCodeLib
>MpInitLib
>TimerLib
> +  PeCoffGetEntryPointLib
>
>  [Sources]
>CpuDxe.c
> @@ -79,6 +80,8 @@
>  [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask## 
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ## 
> CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
> CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
> CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList  ## 
> CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize## 
> CONSUMES
>
> diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
> index 82145e7624..f8489eb1c3 100644
> --- a/UefiCpuPkg/CpuDxe/CpuMp.c
> +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
> @@ -673,10 +673,6 @@ InitializeMpExceptionStackSwitchHandlers (
>UINT8   *GdtBuffer;
>UINT8   *StackTop;
>
> -  if (!PcdGetBool (PcdCpuStackGuard)) {
> -return;
> -  }
> -
>ExceptionNumber = Fixed

Re: [edk2] [PATCH v2 4/4] UefiCpuPkg/PiSmmCpuDxeSmm: implement non-stop mode for SMM

[Wang, Jian J]

Hi Laszlo,

Thanks.

Regards,
Jian

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, August 21, 2018 11:45 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Dong, Eric 
Subject: Re: [edk2] [PATCH v2 4/4] UefiCpuPkg/PiSmmCpuDxeSmm: implement 
non-stop mode for SMM

On 08/21/18 05:05, Jian J Wang wrote:
>> v2 changes:
>>fix GCC build error caused by an unused variable in GuardPagePFHandler()
>
> Since SMM profile feature has already implemented non-stop mode if #PF
> occurred, this patch just makes use of the existing implementation to
> accommodate heap guard and NULL pointer detection feature.
>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 43 --
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.nasm |  3 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c   | 58 
> +++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h   | 15 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h   |  6 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 43 --
>  6 files changed, 137 insertions(+), 31 deletions(-)

It seems like the changes are no-ops for platforms that set all these
PCDs to zero, so from my side

Acked-by: Laszlo Ersek mailto:ler...@redhat.com>>

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/4] Support non-stop mode in heap guard and null detection

[Wang, Jian J]

Hi Laszlo,

Regards,
Jian

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, August 21, 2018 10:28 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH v2 0/4] Support non-stop mode in heap guard and null 
detection

On 08/21/18 05:05, Jian J Wang wrote:
>> v2 changes:
>>fix GCC build error
>
> Background:
> Heap Guard and NULL Pointer Detection are very useful features to detect
> code flaw in EDK II. If an issue is detected, #PF exception will be
> triggered and the BIOS will enter into dead loop, which is the default
> behavior of exception handling. From QA perspective, this default behavior
> will block them to collect all tests result in reasonable time.
>
> Solution:
> This patch series update CpuDxe, PiSmmCpuDxeSmm and CpuExceptionHandlerLib
> to allow the code to continue execution after #PF. The mechanism behind it
> is the same as SMM Profile feature, in which a special #PF handler is
> registered to set the page causing #PF to be 'present' and setup single
> steop trap, then return the control back to the instruction accessing that
> page. Once the instruction is re-executed, a #DB is triggered and a special
> handler for it will be called to reset the page back to 'not-present'.
>
> Usage:
> The non-stop mode is enabled/disabled by BIT6 of following PCDs
>
>   gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
>   gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
>
> The default setting is 'disable'.
>
> BZ Tracker:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1095
>
> OS Boot Validation:
>   Platform: OVMF
>   OS (x64): Fedora 26, Ubuntu 18.04, Windows 10, Windows 7
>
> Jian J Wang (4):
>   MdeModulePkg/MdeModulePkg.dec: add new settings for PCDs
>   UefiCpuPkg/CpuExceptionHandlerLib: Setup single step in #PF handler
>   UefiCpuPkg/CpuDxe: implement non-stop mode for uefi
>   UefiCpuPkg/PiSmmCpuDxeSmm: implement non-stop mode for SMM
>
>  MdeModulePkg/MdeModulePkg.dec  |   4 +-
>  UefiCpuPkg/CpuDxe/CpuDxe.h |  39 +++
>  UefiCpuPkg/CpuDxe/CpuDxe.inf   |   3 +
>  UefiCpuPkg/CpuDxe/CpuMp.c  |  34 ++-
>  UefiCpuPkg/CpuDxe/CpuPageTable.c   | 271 
> +
>  .../Ia32/ExceptionHandlerAsm.nasm  |   7 +
>  .../Ia32/ExceptionTssEntryAsm.nasm |   4 +-
>  .../X64/ExceptionHandlerAsm.nasm   |   4 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |  43 ++--
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiException.nasm   |   3 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c |  58 -
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h |  15 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |   6 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|  43 ++--
>  14 files changed, 493 insertions(+), 41 deletions(-)
>


(1) This looks like a feature addition, so please include the BZ
reference (1095) on the following wiki page:

https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning

(under "Proposed Features")

[Jian] Sure. I’ll add it.

(2) The general description should be moved (or copied) from this email
(v2 0/4) to patch #1 (v2 1/4). The cover letter is not captured in the
commit log, and I think there isn't going to be any other documentation
for the feature than the DEC file.

(Note that I'm not suggesting that you add the documentation to the DEC
file in patch #1 -- instead, the commit message on patch #1 should
contain it. Then people can find the commit from the DEC file with "git
blame", and read the description.)

[Jian] You’re right. I forgot this point. I’ll copy it. Thanks.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/4] UefiCpuPkg/CpuExceptionHandlerLib: Setup single step in #PF handler

[Wang, Jian J]

Thanks. Since there're just some minor changes, I'll not provide v3 patches
and push the changes to master soon.

Regards,
Jian

From: Dong, Eric
Sent: Tuesday, August 28, 2018 9:15 AM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Laszlo Ersek ; Ni, Ruiyu 
Subject: RE: [PATCH v2 2/4] UefiCpuPkg/CpuExceptionHandlerLib: Setup single 
step in #PF handler

Reviewed-by: Eric Dong mailto:eric.d...@intel.com>>

> -Original Message-
> From: Wang, Jian J
> Sent: Tuesday, August 21, 2018 11:05 AM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Laszlo 
> Ersek mailto:ler...@redhat.com>>; Ni,
> Ruiyu mailto:ruiyu...@intel.com>>
> Subject: [PATCH v2 2/4] UefiCpuPkg/CpuExceptionHandlerLib: Setup single
> step in #PF handler
>
> > v2 changes:
> >n/a
>
> Once the #PF handler has set the page to be 'present', there should be a way
> to reset it to 'not-present'. 'TF' bit in EFLAGS can be used for this 
> purpose. 'TF'
> bit will be set in interrupted function context so that it can be triggered 
> once
> the cpu control returns back to the instruction causing #PF and re-execute it.
>
> This is an necessary step to implement non-stop mode for Heap Guard and
> NULL Pointer Detection feature.
>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  .../Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.nasm   | 7
> +++
>  .../Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm  | 4 +--
> -
>  .../Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm| 4
> 
>  3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.na
> sm
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.na
> sm
> index 45d6474091..6fcf5fb23f 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.na
> sm
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm
> +++ .nasm
> @@ -383,6 +383,13 @@ ErrorCodeAndVectorOnStack:
>  pop dword [ebp - 4]
>  mov esp, ebp
>  pop ebp
> +
> +; Enable TF bit after page fault handler runs
> +cmp dword [esp], 14   ; #PF?
> +jne .5
> +bts dword [esp + 16], 8   ; EFLAGS
> +
> +.5:
>  add esp, 8
>  cmp dword [esp - 16], 0   ; check
> EXCEPTION_HANDLER_CONTEXT.OldIdtHandler
>  jz  DoReturn
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.n
> asm
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.n
> asm
> index 62bcedea1a..7aac29c7e7 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.n
> asm
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAs
> +++ m.nasm
> @@ -355,10 +355,8 @@ o16 mov [ecx + IA32_TSS._SS], ax
>  movzx  ebx, word [ecx + IA32_TSS._CS]
>  mov[eax - 0x8], ebx  ; create CS in old stack
>  movebx, dword [ecx + IA32_TSS.EFLAGS]
> -btsebx, 8
> +btsebx, 8; Set TF
>  mov[eax - 0x4], ebx  ; create eflags in old stack
> -movdword [ecx + IA32_TSS.EFLAGS], ebx; update eflags in old TSS
> -moveax, dword [ecx + IA32_TSS._ESP]  ; Get old stack pointer
>  subeax, 0xc  ; minus 12 byte
>  movdword [ecx + IA32_TSS._ESP], eax  ; Set new stack pointer
>
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.na
> sm
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.na
> sm
> index 7b97810d10..f842af2336 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.na
> sm
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.
> +++ nasm
> @@ -336,6 +336,10 @@ HasErrorCode:
>  pop r15
>
>  mov rsp, rbp
> +cmp qword [rbp + 8], 14 ; #PF?
> +jne .1
> +bts qword [rsp + 40], 8 ; RFLAGS.TF
> +.1:
>  pop rbp
>  add rsp, 16
>  cmp qword [rsp - 32], 0  ; check
> EXCEPTION_HANDLER_CONTEXT.OldIdtHandler
> --
> 2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Maintainers.txt: Update maintainer of MdeModulePkg

[Wang, Jian J]

Reviewed-by: Jian J Wang 

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, August 28, 2018 1:36 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Dong, Eric ; Kinney, Michael D
> ; Laszlo Ersek ; Andrew Fish
> ; Leif Lindholm 
> Subject: [PATCH] Maintainers.txt: Update maintainer of MdeModulePkg
> 
> Add Jian J Wang  and
> remove Eric Dong .
> Eric is focusing on UefiCpuPkg.
> 
> Cc: Jian J Wang 
> Cc: Eric Dong 
> Cc: Michael D Kinney 
> Cc: Laszlo Ersek 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index df7dc48f75b5..61df6e198b79 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -172,7 +172,7 @@ M: Rangasai V Chaganty
> 
>  MdeModulePkg
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
>  M: Star Zeng 
> -M: Eric Dong 
> +M: Jian J Wang 
>  M: NetworkPkg maintainers
>(Universal/Network and related libraries, header files)
>  R: Ruiyu Ni 
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix incorrect check of SMM mode

[Wang, Jian J]

Hi Lazlo,

Thank you very much for the effort. We do have an emergency situation.

(1) Agree. Filed a bug (https://bugzilla.tianocore.org/show_bug.cgi?id=1039)
 for it.
(2) I went through the code you mentioned. I think it won't cause problem
 but it might miss protecting certain images (very rare case like calling
 gBS->LoadImage() from SMM driver entry point). I'll consult more relevant
experts before filing a bug.
(3) I'll update the commit message to reflect this for sure.

Regards,
Jian


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, July 19, 2018 10:46 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Zeng, Star 
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix incorrect check of SMM
> mode
> 
> On 07/18/18 04:35, Wang, Jian J wrote:
> > Hi Laszlo,
> >
> >
> > Regards,
> > Jian
> >
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Tuesday, July 17, 2018 10:37 PM
> >> To: Wang, Jian J ; edk2-devel@lists.01.org
> >> Cc: Dong, Eric ; Yao, Jiewen ;
> >> Zeng, Star 
> >> Subject: Re: [PATCH] UefiCpuPkg/CpuDxe: fix incorrect check of SMM mode
> >>
> >> On 07/13/18 07:53, Jian J Wang wrote:
> >>> Current IsInSmm() method makes use of
> gEfiSmmBase2ProtocolGuid.InSmm()
> >> to
> >>> check if current processor is in SMM mode or not. But this is not correct
> >>> because gEfiSmmBase2ProtocolGuid.InSmm() can only detect if the caller is
> >>> running in SMRAM or from SMM driver. It cannot guarantee if the caller is
> >>> running in SMM mode.
> >>
> >> Wow. This is the exact difference which I asked about, in my question
> >> (9b), and I was assured that InSmm() actually determined whether we were
> >> executing in Management Mode (meaning the processor operating mode).
> >>
> >> http://mid.mail-
> >>
> archive.com/0c09afa07dd0434d9e2a0c6aeb0483103bb55...@shsmsx102.cc
> >> r.corp.intel.com
> >>
> >> (Scroll down in that message to see my original question (9b).)
> >>
> >> So why doesn't Star's explanation, from the original thread, apply
> >> ultimately?
> >>
> >
> > We did many tests for this and didn't found any issue. So I took a risk. (I
> thought
> > a very precise check of SMM mode is hard and time consuming.)
> >
> >>> Because SMM mode will load its own page table, adding
> >>> an extra check of saved DXE page table base address against current CR3
> >>> register value can help to get the correct answer for sure (in SMM mode or
> >>> not in SMM mode).
> >>
> >> So, apparently, the PI spec offers no standard way for a platform module
> >> to determine whether it runs in Management Mode, despite protocol
> member
> >> being called "InSmm". Do we need a PI spec ECR for introducing the
> >> needed facility?
> >>
> >> Alternatively, the PI spec might already intend to specify that, but the
> >> edk2 implementation doesn't do what the PI spec requires.
> >>
> >> Which one is the case?
> >>
> >
> > The implementation conforms to the spec. It's my misunderstanding. But it's
> true
> > that there's no specific protocol API to determine if it's in SMM mode or 
> > not.
> >
> >>>
> >>> This is an issue caused by check-in at
> >>>
> >>>   d106cf71eabaacff63c14626a4a87346b93074dd
> >>
> >> I disagree; I think the issue was introduced in commit 2a1408d1d739
> >> ("UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode",
> >> 2018-06-19).
> >>
> >
> > You're right. Thanks for pointing this out.
> >
> >>
> >> How did you encounter / find this issue?
> >>
> >
> > I didn't find it. The issue came to me. In other words, I think it's random 
> > and
> hard
> > to reproduce it. Maybe a subtle change in boot sequence will hide it away.
> >
> >>>
> >>> Cc: Eric Dong 
> >>> Cc: Laszlo Ersek 
> >>> Cc: Jiewen Yao 
> >>> Cc: Star Zeng 
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Jian J Wang 
> >>> ---
> >>>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 9 -
> >>>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/UefiCpuPkg/CpuDxe

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix incorrect check of SMM mode

[Wang, Jian J]

Hi Laszlo,


Regards,
Jian


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, July 17, 2018 10:37 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Yao, Jiewen ;
> Zeng, Star 
> Subject: Re: [PATCH] UefiCpuPkg/CpuDxe: fix incorrect check of SMM mode
> 
> On 07/13/18 07:53, Jian J Wang wrote:
> > Current IsInSmm() method makes use of gEfiSmmBase2ProtocolGuid.InSmm()
> to
> > check if current processor is in SMM mode or not. But this is not correct
> > because gEfiSmmBase2ProtocolGuid.InSmm() can only detect if the caller is
> > running in SMRAM or from SMM driver. It cannot guarantee if the caller is
> > running in SMM mode.
> 
> Wow. This is the exact difference which I asked about, in my question
> (9b), and I was assured that InSmm() actually determined whether we were
> executing in Management Mode (meaning the processor operating mode).
> 
> http://mid.mail-
> archive.com/0c09afa07dd0434d9e2a0c6aeb0483103bb55...@shsmsx102.cc
> r.corp.intel.com
> 
> (Scroll down in that message to see my original question (9b).)
> 
> So why doesn't Star's explanation, from the original thread, apply
> ultimately?
> 

We did many tests for this and didn't found any issue. So I took a risk. (I 
thought
a very precise check of SMM mode is hard and time consuming.) 

> > Because SMM mode will load its own page table, adding
> > an extra check of saved DXE page table base address against current CR3
> > register value can help to get the correct answer for sure (in SMM mode or
> > not in SMM mode).
> 
> So, apparently, the PI spec offers no standard way for a platform module
> to determine whether it runs in Management Mode, despite protocol member
> being called "InSmm". Do we need a PI spec ECR for introducing the
> needed facility?
> 
> Alternatively, the PI spec might already intend to specify that, but the
> edk2 implementation doesn't do what the PI spec requires.
> 
> Which one is the case?
> 

The implementation conforms to the spec. It's my misunderstanding. But it's true
that there's no specific protocol API to determine if it's in SMM mode or not.

> >
> > This is an issue caused by check-in at
> >
> >   d106cf71eabaacff63c14626a4a87346b93074dd
> 
> I disagree; I think the issue was introduced in commit 2a1408d1d739
> ("UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode",
> 2018-06-19).
> 

You're right. Thanks for pointing this out.

> 
> How did you encounter / find this issue?
> 

I didn't find it. The issue came to me. In other words, I think it's random and 
hard
to reproduce it. Maybe a subtle change in boot sequence will hide it away.

> >
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Jiewen Yao 
> > Cc: Star Zeng 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang 
> > ---
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index 850eed60e7..df021798c0 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -136,7 +136,14 @@ IsInSmm (
> >  mSmmBase2->InSmm (mSmmBase2, );
> >}
> >
> > -  return InSmm;
> > +  //
> > +  // mSmmBase2->InSmm() can only detect if the caller is running in SMRAM
> > +  // or from SMM driver. It cannot tell if the caller is running in SMM 
> > mode.
> > +  // Check page table base address to guarantee that because SMM mode
> willl
> > +  // load its own page table.
> > +  //
> > +  return (InSmm &&
> > +  mPagingContext.ContextData.X64.PageTableBase !=
> (UINT64)AsmReadCr3());
> >  }
> >
> >  /**
> >
> 
> Shouldn't we consider Ia32.PageTableBase when that's appropriate? From
> "UefiCpuPkg/CpuDxe/CpuPageTable.h":
> 
> typedef struct {
>   UINT32  PageTableBase;
>   UINT32  Reserved;
>   UINT32  Attributes;
> } PAGE_TABLE_LIB_PAGING_CONTEXT_IA32;
> 
> typedef struct {
>   UINT64  PageTableBase;
>   UINT32  Attributes;
> } PAGE_TABLE_LIB_PAGING_CONTEXT_X64;
> 
> typedef union {
>   PAGE_TABLE_LIB_PAGING_CONTEXT_IA32  Ia32;
>   PAGE_TABLE_LIB_PAGING_CONTEXT_X64   X64;
> } PAGE_TABLE_LIB_PAGING_CONTEXT_DATA;
> 
> The Ia32/X64 structure types are not packed, and even if they were, I
> wouldn't think we should rely on "Reserved" being zero.
> 

mPagingContext is zero-ed at each update in GetCurrentPagingContext

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix incorrect check of SMM mode

[Wang, Jian J]

Hi Laszlo,

Do you have more comments? Or can you give a r-b?

Regards,
Jian

> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, July 18, 2018 10:36 AM
> To: Laszlo Ersek ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Yao, Jiewen ;
> Zeng, Star 
> Subject: RE: [PATCH] UefiCpuPkg/CpuDxe: fix incorrect check of SMM mode
> 
> Hi Laszlo,
> 
> 
> Regards,
> Jian
> 
> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Tuesday, July 17, 2018 10:37 PM
> > To: Wang, Jian J ; edk2-devel@lists.01.org
> > Cc: Dong, Eric ; Yao, Jiewen ;
> > Zeng, Star 
> > Subject: Re: [PATCH] UefiCpuPkg/CpuDxe: fix incorrect check of SMM mode
> >
> > On 07/13/18 07:53, Jian J Wang wrote:
> > > Current IsInSmm() method makes use of gEfiSmmBase2ProtocolGuid.InSmm()
> > to
> > > check if current processor is in SMM mode or not. But this is not correct
> > > because gEfiSmmBase2ProtocolGuid.InSmm() can only detect if the caller is
> > > running in SMRAM or from SMM driver. It cannot guarantee if the caller is
> > > running in SMM mode.
> >
> > Wow. This is the exact difference which I asked about, in my question
> > (9b), and I was assured that InSmm() actually determined whether we were
> > executing in Management Mode (meaning the processor operating mode).
> >
> > http://mid.mail-
> >
> archive.com/0c09afa07dd0434d9e2a0c6aeb0483103bb55...@shsmsx102.cc
> > r.corp.intel.com
> >
> > (Scroll down in that message to see my original question (9b).)
> >
> > So why doesn't Star's explanation, from the original thread, apply
> > ultimately?
> >
> 
> We did many tests for this and didn't found any issue. So I took a risk. (I 
> thought
> a very precise check of SMM mode is hard and time consuming.)
> 
> > > Because SMM mode will load its own page table, adding
> > > an extra check of saved DXE page table base address against current CR3
> > > register value can help to get the correct answer for sure (in SMM mode or
> > > not in SMM mode).
> >
> > So, apparently, the PI spec offers no standard way for a platform module
> > to determine whether it runs in Management Mode, despite protocol member
> > being called "InSmm". Do we need a PI spec ECR for introducing the
> > needed facility?
> >
> > Alternatively, the PI spec might already intend to specify that, but the
> > edk2 implementation doesn't do what the PI spec requires.
> >
> > Which one is the case?
> >
> 
> The implementation conforms to the spec. It's my misunderstanding. But it's
> true
> that there's no specific protocol API to determine if it's in SMM mode or not.
> 
> > >
> > > This is an issue caused by check-in at
> > >
> > >   d106cf71eabaacff63c14626a4a87346b93074dd
> >
> > I disagree; I think the issue was introduced in commit 2a1408d1d739
> > ("UefiCpuPkg/CpuDxe: allow accessing (DXE) page table in SMM mode",
> > 2018-06-19).
> >
> 
> You're right. Thanks for pointing this out.
> 
> >
> > How did you encounter / find this issue?
> >
> 
> I didn't find it. The issue came to me. In other words, I think it's random 
> and hard
> to reproduce it. Maybe a subtle change in boot sequence will hide it away.
> 
> > >
> > > Cc: Eric Dong 
> > > Cc: Laszlo Ersek 
> > > Cc: Jiewen Yao 
> > > Cc: Star Zeng 
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang 
> > > ---
> > >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 9 -
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > index 850eed60e7..df021798c0 100644
> > > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > > @@ -136,7 +136,14 @@ IsInSmm (
> > >  mSmmBase2->InSmm (mSmmBase2, );
> > >}
> > >
> > > -  return InSmm;
> > > +  //
> > > +  // mSmmBase2->InSmm() can only detect if the caller is running in SMRAM
> > > +  // or from SMM driver. It cannot tell if the caller is running in SMM 
> > > mode.
> > > +  // Check page table base address to guarantee that because SMM mode
> > willl
> > > +  // load its own page table.
> > > +  //
> > > +  return (InSmm &&
> > > +  mPagingContext.ContextData.X64.PageTableBa

Re: [edk2] [PATCH 4/4] UefiCpuPkg/CpuMpPei: support stack guard feature

[Wang, Jian J]

Thanks for the comments. It will be fixed.

Regards,
Jian

From: Dong, Eric
Sent: Thursday, September 06, 2018 9:46 AM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Laszlo Ersek ; Ni, Ruiyu ; Yao, 
Jiewen ; Zeng, Star ; Ware, Ryan R 

Subject: RE: [PATCH 4/4] UefiCpuPkg/CpuMpPei: support stack guard feature

Hi Jian,

Below code has ECC issue, please check with ECC tool to fix all ECC issues.

  /**
Initializes MP and exceptions handlers.

@retval EFI_SUCCESS MP was successfully initialized.
@retval others  Error occurred in MP initialization.

  **/
  EFI_STATUS
  InitializeCpuMpWorker (
IN CONST EFI_PEI_SERVICES **PeiServices
)

With ECC issues fixed, Reviewed-by: Eric Dong 
mailto:eric.d...@intel.com>>

Thanks,
Eric

> -Original Message-
> From: Wang, Jian J
> Sent: Monday, September 3, 2018 11:16 AM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Laszlo 
> Ersek mailto:ler...@redhat.com>>; Ni,
> Ruiyu mailto:ruiyu...@intel.com>>; Yao, Jiewen 
> mailto:jiewen@intel.com>>; Zeng,
> Star mailto:star.z...@intel.com>>; Ware, Ryan R 
> mailto:ryan.r.w...@intel.com>>
> Subject: [PATCH 4/4] UefiCpuPkg/CpuMpPei: support stack guard feature
>
> This feature is the same as Stack Guard enabled in driver CpuDxe but applies
> to PEI phase. Due to the specialty in PEI module dispatching, this driver is
> changed to do the actual initialization in notify callback of event
> gEfiPeiMemoryDiscoveredPpiGuid. This can let the stack guard apply to as
> most PEI drivers as possible.
>
> To let Stack Guard work, some simple page table management code are
> introduced to setup Guard page at base of stack for each processor.
>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>
> Cc: Jiewen Yao mailto:jiewen@intel.com>>
> Cc: Star Zeng mailto:star.z...@intel.com>>
> Cc: "Ware, Ryan R" mailto:ryan.r.w...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  UefiCpuPkg/CpuMpPei/CpuMpPei.c   | 269 -
>  UefiCpuPkg/CpuMpPei/CpuMpPei.h   |  14 +
>  UefiCpuPkg/CpuMpPei/CpuMpPei.inf |  11 +-
> UefiCpuPkg/CpuMpPei/CpuPaging.c  | 637
> +++
>  4 files changed, 916 insertions(+), 15 deletions(-)  create mode 100644
> UefiCpuPkg/CpuMpPei/CpuPaging.c
>
> diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> b/UefiCpuPkg/CpuMpPei/CpuMpPei.c index 7c94d5a6d7..e3762daf39 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
> @@ -409,25 +409,225 @@ PeiWhoAmI (
>  }
>
>  /**
> -  The Entry point of the MP CPU PEIM.
> +  Get GDT register value.
>
> -  This function will wakeup APs and collect CPU AP count and install the
> -  Mp Service Ppi.
> +  This function is mainly for AP purpose because AP may have different
> + GDT  table than BSP.
>
> -  @param  FileHandleHandle of the file being invoked.
> -  @param  PeiServices   Describes the list of possible PEI Services.
> +  @param[in,out] Buffer  The pointer to private data buffer.
>
> -  @retval EFI_SUCCESS   MpServicePpi is installed successfully.
> +**/
> +VOID
> +EFIAPI
> +GetGdtr (
> +  IN OUT VOID *Buffer
> +  )
> +{
> +  AsmReadGdtr ((IA32_DESCRIPTOR *)Buffer); }
> +
> +/**
> +  Initializes CPU exceptions handlers for the sake of stack switch
> requirement.
> +
> +  This function is a wrapper of InitializeCpuExceptionHandlersEx. It's
> + mainly  for the sake of AP's init because of EFI_AP_PROCEDURE API
> requirement.
> +
> +  @param[in,out] Buffer  The pointer to private data buffer.
>
>  **/
> -EFI_STATUS
> +VOID
>  EFIAPI
> -CpuMpPeimInit (
> -  IN   EFI_PEI_FILE_HANDLE  FileHandle,
> +InitializeExceptionStackSwitchHandlers (
> +  IN OUT VOID *Buffer
> +  )
> +{
> +  CPU_EXCEPTION_INIT_DATA   *EssData;
> +  IA32_DESCRIPTOR   Idtr;
> +  EFI_STATUSStatus;
> +
> +  EssData = Buffer;
> +  //
> +  // We don't plan to replace IDT table with a new one, but we should
> +not assume
> +  // the AP's IDT is the same as BSP's IDT either.
> +  //
> +  AsmReadIdtr ();
> +  EssData->Ia32.IdtTable = (VOID *)Idtr.Base;
> +  EssData->Ia32.IdtTableSize = Idtr.Limit + 1;
> +  Status = InitializeCpuExceptionHandlersEx (NULL, EssData);
> +  ASSERT_EFI_ERROR (Status);
> +}
> +
> +/**
> +  Initializes MP exceptions handlers for the 

Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: add message for S3 config error

[Wang, Jian J]

Make sense to me.

Regards,
Jian


> -Original Message-
> From: Zeng, Star
> Sent: Monday, September 10, 2018 1:08 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: You, Benjamin ; Dong, Eric
> ; Laszlo Ersek ; Zeng, Star
> 
> Subject: RE: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: add message for S3
> config error
> 
> I agree to add the ASSERT, but even with the ASSERT, I still suggest moving
> //
> // Patch SmmS3ResumeState->SmmS3Cr3
> //
> InitSmmS3Cr3 ();
> 
> into
>   GuidHob = GetFirstGuidHob ();
>   if (GuidHob != NULL) {
> ...
>   }
> 
> With that, Reviewed-by: Star Zeng 
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Monday, September 10, 2018 11:22 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; You, Benjamin
> ; Dong, Eric ; Laszlo Ersek
> 
> Subject: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: add message for S3 config
> error
> 
> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=1165
> 
> HOB gEfiAcpiVariableGuid is a must have data for S3 resume if PcdAcpiS3Enable
> is set to TRUE. Current code in CpuS3.c doesn't embody this strong binding
> between them. An error message and ASSERT is added by this patch to warn
> platform developer about it.
> 
> Cc: Star Zeng 
> Cc: Benjamin You 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> index abd8a5a07b..f371667c44 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> @@ -744,6 +744,9 @@ InitSmmS3ResumeState (
>  if (sizeof (UINTN) == sizeof (UINT32)) {
>SmmS3ResumeState->Signature = SMM_S3_RESUME_SMM_32;
>  }
> +  } else {
> +DEBUG ((DEBUG_ERROR, "ERROR: HOB(gEfiAcpiVariableGuid) needed by S3
> resume doesn't exist!\n"));
> +ASSERT (FALSE);
>}
> 
>//
> --
> 2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/MdeModulePkg.uni: update PCD string per dec file change

[Wang, Jian J]

Sure. Make sense.

Regards,
Jian

> -Original Message-
> From: Zeng, Star
> Sent: Friday, August 31, 2018 9:43 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Zeng, Star 
> Subject: RE: [PATCH] MdeModulePkg/MdeModulePkg.uni: update PCD string per
> dec file change
> 
> Please mention 8f2613628acf601a2a17bb64bb49ef73f85cfe2c (which updated
> the PCDs in dec) in commit log.
> 
> Reviewed that, Reviewed-by: Star Zeng 
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Friday, August 31, 2018 9:22 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Dong, Eric 
> Subject: [PATCH] MdeModulePkg/MdeModulePkg.uni: update PCD string per dec
> file change
> 
> PcdNullPointerDetectionPropertyMask and PcdHeapGuardPropertyMask have
> been updated in dec file to reflect a new feature (non-stop mode). This patch
> updates corresponding unicode strings in uni file to match those changes.
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/MdeModulePkg.uni | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.uni
> b/MdeModulePkg/MdeModulePkg.uni index 080b8a62c0..8807af801e 100644
> --- a/MdeModulePkg/MdeModulePkg.uni
> +++ b/MdeModulePkg/MdeModulePkg.uni
> @@ -1146,7 +1146,8 @@
>   
>   " If enabled, accessing
> NULL address in UEFI or SMM code can be caught.\n\n"
>   
>   "   BIT0- Enable NULL
> pointer detection for UEFI.\n"
>   
>   "   BIT1- Enable NULL
> pointer detection for SMM.\n"
> - 
>   "   BIT2..6 - Reserved
> for future uses.\n"
> + 
>   "   BIT2..5 - Reserved
> for future uses.\n"
> + 
>   "   BIT6- Enable non-
> stop mode.\n"
>   
>   "   BIT7- Disable
> NULL pointer detection just after EndOfDxe."
>   
>   " This is a workaround
> for those unsolvable NULL access issues in"
>   
>   " OptionROM, boot
> loader, etc. It can also help to avoid unnecessary"
> @@ -1225,6 +1226,7 @@
>   
>"   BIT1 - Enable UEFI pool
> guard.\n"
>   
>"   BIT2 - Enable SMM page
> guard.\n"
>   
>"   BIT3 - Enable SMM pool
> guard.\n"
> + 
>"   BIT6 - Enable non-stop
> mode.\n"
>   
>"   BIT7 - The direction of
> Guard Page for Pool Guard.\n"
>   
>"  0 - The returned pool is
> near the tail guard page.\n"
>   
>"  1 - The returned pool is
> near the head guard page."
> --
> 2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: change level of DEBUG message

[Wang, Jian J]

Laszlo,

Thanks for the comment. I’ll add the info.

Regards,
Jian

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, August 29, 2018 9:54 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Dong, Eric 
Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: change level of DEBUG message

On 08/29/18 05:21, Jian J Wang wrote:
> It's reported the debug message in CpuDxe driver is quite annoying in
> boot and shell, and slow down the boot process. To solve this issue,
> this patch changes the DEBUG_INFO to DEBUG_VERBOSE. On a typical Intel
> real platform, at least 16s boot time can be saved.
>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.c   | 2 +-
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
> index cfd4c415ae..76661cbcd9 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> @@ -404,7 +404,7 @@ CpuSetMemoryAttributes (
>// to avoid unnecessary computing.
>//
>if (mIsFlushingGCD) {
> -DEBUG((DEBUG_INFO, "  Flushing GCD\n"));
> +DEBUG((DEBUG_VERBOSE, "  Flushing GCD\n"));
>  return EFI_SUCCESS;
>}
>
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c 
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index df021798c0..609df58e3a 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -528,7 +528,7 @@ SplitPage (
>  ASSERT (SplitAttribute == Page4K);
>  if (SplitAttribute == Page4K) {
>NewPageEntry = AllocatePagesFunc (1);
> -  DEBUG ((DEBUG_INFO, "Split - 0x%x\n", NewPageEntry));
> +  DEBUG ((DEBUG_VERBOSE, "Split - 0x%x\n", NewPageEntry));
>if (NewPageEntry == NULL) {
>  return RETURN_OUT_OF_RESOURCES;
>}
> @@ -549,7 +549,7 @@ SplitPage (
>  ASSERT (SplitAttribute == Page2M || SplitAttribute == Page4K);
>  if ((SplitAttribute == Page2M || SplitAttribute == Page4K)) {
>NewPageEntry = AllocatePagesFunc (1);
> -  DEBUG ((DEBUG_INFO, "Split - 0x%x\n", NewPageEntry));
> +  DEBUG ((DEBUG_VERBOSE, "Split - 0x%x\n", NewPageEntry));
>if (NewPageEntry == NULL) {
>  return RETURN_OUT_OF_RESOURCES;
>}
>

Before you push this patch, please add a reference to

  https://bugzilla.tianocore.org/show_bug.cgi?id=1127

in the commit message.

With that:

Reviewed-by: Laszlo Ersek mailto:ler...@redhat.com>>

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix ECC reported issues

[Wang, Jian J]

Forgot to mention the BZ info:

https://bugzilla.tianocore.org/show_bug.cgi?id=1160

Regards,
Jian

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> Sent: Saturday, September 08, 2018 10:22 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan 
> Subject: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix ECC reported issues
> 
> There're two parameters which have different name in comment and prototype.
> 
> Cc: Dandan Bi 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.h b/UefiCpuPkg/CpuDxe/CpuDxe.h
> index 7d65e39e90..064ea05bba 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.h
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.h
> @@ -291,7 +291,7 @@ RefreshGcdMemoryAttributesFromPaging (
>  VOID
>  EFIAPI
>  DebugExceptionHandler (
> -  IN EFI_EXCEPTION_TYPE   InterruptType,
> +  IN EFI_EXCEPTION_TYPE   ExceptionType,
>IN EFI_SYSTEM_CONTEXT   SystemContext
>);
> 
> @@ -307,7 +307,7 @@ DebugExceptionHandler (
>  VOID
>  EFIAPI
>  PageFaultExceptionHandler (
> -  IN EFI_EXCEPTION_TYPE   InterruptType,
> +  IN EFI_EXCEPTION_TYPE   ExceptionType,
>IN EFI_SYSTEM_CONTEXT   SystemContext
>);
> 
> --
> 2.16.2.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix an incorrect bit-wise operation

[Wang, Jian J]

Forgot to mention BZ info:
https://bugzilla.tianocore.org/show_bug.cgi?id=1095

Regards,
Jian


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> Sent: Saturday, September 08, 2018 10:48 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A 
> Subject: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix an incorrect bit-wise operation
> 
> The left operand is 64-bit but right operand could be 32-bit.
> A typecast is a must because of '~' op before it.
> 
> Cc: Hao A Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index ef6e080a07..0a980b9753 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -1181,7 +1181,7 @@ DebugExceptionHandler (
> 
>for (PFEntry = 0; PFEntry < mPFEntryCount[CpuIndex]; PFEntry++) {
>  if (mLastPFEntryPointer[CpuIndex][PFEntry] != NULL) {
> -  *mLastPFEntryPointer[CpuIndex][PFEntry] &= ~IA32_PG_P;
> +  *mLastPFEntryPointer[CpuIndex][PFEntry] &= ~(UINT64)IA32_PG_P;
>  }
>}
> 
> --
> 2.16.2.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix an incorrect bit-wise operation

[Wang, Jian J]

And BZ#1164: https://bugzilla.tianocore.org/show_bug.cgi?id=1164

Regards,
Jian

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
Sent: Saturday, September 08, 2018 11:25 AM
To: edk2-devel ; edk2-devel@lists.01.org
Cc: Wu, Hao A 
Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix an incorrect bit-wise 
operation

Forgot to mention BZ info:
https://bugzilla.tianocore.org/show_bug.cgi?id=1095

Regards,
Jian


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> Sent: Saturday, September 08, 2018 10:48 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A mailto:hao.a...@intel.com>>
> Subject: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix an incorrect bit-wise operation
>
> The left operand is 64-bit but right operand could be 32-bit.
> A typecast is a must because of '~' op before it.
>
> Cc: Hao A Wu mailto:hao.a...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index ef6e080a07..0a980b9753 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -1181,7 +1181,7 @@ DebugExceptionHandler (
>
>for (PFEntry = 0; PFEntry < mPFEntryCount[CpuIndex]; PFEntry++) {
>  if (mLastPFEntryPointer[CpuIndex][PFEntry] != NULL) {
> -  *mLastPFEntryPointer[CpuIndex][PFEntry] &= ~IA32_PG_P;
> +  *mLastPFEntryPointer[CpuIndex][PFEntry] &= ~(UINT64)IA32_PG_P;
>  }
>}
>
> --
> 2.16.2.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] expire the use of PcdSetNxForStack

[Wang, Jian J]

Hi Ard,

Sorry for the title which misleads you (I used a wrong word too. Shame!).
The real problem this patch series try to address is the confusion in these
two PCDs, PcdSetNxForStack and PcdDxeNxMemoryProtectionPolicy.
One of them will enable NX feature in cpu but another won’t. And there’s
also functionality overlap between them because stack memory is actually
type of EfiBootServiceData, which is also controlled by BIT4 of
PcdDxeNxMemoryProtectionPolicy.

Regards,
Jian

From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Tuesday, September 11, 2018 4:58 PM
To: Wang, Jian J ; Laszlo Ersek ; 
Charles Garcia-Tobin ; Leif Lindholm 

Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/5] expire the use of PcdSetNxForStack

On 11 September 2018 at 07:16, Jian J Wang 
mailto:jian.j.w...@intel.com>> wrote:
> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=1116
>
> Since the stack memory is allocated as EfiBootServicesData, its NX protection
> can be covered by BIT4 of PcdDxeNxMemoryProtectionPolicy. To avoid confusing
> in setting related PCDs, PcdSetNxForStack will be expired. Instead, If BIT4
> of PcdDxeNxMemoryProtectionPolicy is set, the DxeIpl will set NX bit in page
> table entries mapping the stack memory.
>

I disagree. This removes the possibility to map EfiBootServicesData as
executable while still mapping the stack NX. As we all know, an
executable stack is in a class of its own when it comes to
exploitability, and should *never* be mapped executable unless in
highly exceptional cases. Mapping all EfiBootServicesData as
non-executable may cause backward compatibility problems.

In particular, this makes it impossible for AArch64 to populate the
1:1 mapping using 64k pages (which is necessary for 52-bit address
support) and still have a non-executable stack, since
PcdDxeNxMemoryProtectionPolicy is disabled in that scenario.

So please disregard these patches.


> Jian J Wang (5):
>   MdeModulePkg/DxeIplPeim: expire the use of PcdSetNxForStack
>   OvmfPkg/PlatformPei: expire the use of PcdSetNxForStack
>   OvmfPkg: expire the use of PcdSetNxForStack
>   ArmVirtPkg/ArmVirt.dsc.inc: expire the use of PcdSetNxForStack
>   MdeModulePkg: expire PcdSetNxForStack
>
>  ArmVirtPkg/ArmVirt.dsc.inc   |  5 -
>  MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c   |  6 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  2 +-
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  3 ++-
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  2 +-
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 14 +++---
>  MdeModulePkg/MdeModulePkg.dec| 10 +-
>  MdeModulePkg/MdeModulePkg.uni| 10 +-
>  OvmfPkg/OvmfPkgIa32.dsc  |  1 -
>  OvmfPkg/OvmfPkgIa32X64.dsc   |  1 -
>  OvmfPkg/OvmfPkgX64.dsc   |  1 -
>  OvmfPkg/PlatformPei/Platform.c   |  1 -
>  OvmfPkg/PlatformPei/PlatformPei.inf  |  1 -
>  13 files changed, 22 insertions(+), 35 deletions(-)
>
> --
> 2.16.2.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/UefiShellLevel3CommandsLib: fix string over-read

[Wang, Jian J]

Fair enough. It'll be updated in v2.

Regards,
Jian


> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, January 24, 2018 11:36 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [PATCH] ShellPkg/UefiShellLevel3CommandsLib: fix string over-read
> 
> On 1/23/2018 10:14 AM, Jian J Wang wrote:
> > In the for-loop condition of original code, the expression
> >
> >*CurrentCommand != CHAR_NULL
> >
> > is put before expression
> >
> >CurrentCommand < SortedCommandList +
> SortedCommandListSize/sizeof(CHAR16)
> >
> > When CurrentCommand walks to the end of string buffer, one more character
> > over the end of string buffer will be read and then stop.
> >
> > To fix this issue, just move the last expression to the first one. Because
> > of short-circuit evaludation of and-expression, the following one
> >
> >*CurrentCommand != CHAR_NULL
> >
> > will not be evaluated if the expression before it is evaludated as FALSE.
> >
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >   ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c
> b/ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c
> > index a71ade3a20..75e3d74200 100644
> > --- a/ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c
> > +++ b/ShellPkg/Library/UefiShellLevel3CommandsLib/Help.c
> > @@ -397,7 +397,7 @@ ShellCommandRunHelp (
> >   CopyListOfCommandNamesWithDynamic(,
> );
> >
> >   for (CurrentCommand = SortedCommandList
> > -  ; CurrentCommand != NULL && *CurrentCommand != CHAR_NULL &&
> CurrentCommand < SortedCommandList +
> SortedCommandListSize/sizeof(CHAR16)
> > +  ; CurrentCommand < SortedCommandList +
> SortedCommandListSize/sizeof(CHAR16) && CurrentCommand != NULL &&
> *CurrentCommand != CHAR_NULL
> > ; CurrentCommand += StrLen(CurrentCommand) + 1
> > ) {
> > //
> >
> How about keep "CurrentCommand != NULL" in the beginning? I agree to
> swap the other two checks.
> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/5] OvmfPkg/PlatformPei: expire the use of PcdSetNxForStack

[Wang, Jian J]

Hi Laszlo and Ard,

Retiring the PcdSetNxForStack is not the intention of this patch series. It's 
just
a side effect of solving problem stated in BZ#1116. Sorry again for the 
misleading
title. I'm not insisting that we have to remove this PCD anyway (My personal
opinion. Others might have different ones). 

I think I understand the importance of PcdSetNxForStack to arm/aarch64 now. And 
I
agree that it'd be better to enable NX for stack independent of enabling NX for
EfiBootServcesData memory. But since the stack is type of EfiBootServicesData,
I think we should avoid any confusion in enabling/disabling NX for them. That's 
what
BZ#1116 tries to complain about. But I'm still not clear any concrete 
suggestion on
how to solve the BZ#1116 from all comment so far, if my patch series cannot 
satisfy
all kinds of platforms. Simply keep PcdSetNxForStack doesn't help, I think. (It 
doesn't
imply we must remove it.)

As I commented in the BZ#1116, maybe we can just simply assert if there's one
trying to disable NX for stack but enable NX for EfiBootServicesData at the 
same time,
because it doesn't make sense. I think all other setting combinations won't have
such confusion and don't need to take care specifically.

And for x86 CPU, we'll always enable CPU NX feature if any NX related PCDs have 
bits
set. Current DxeIpl will just enable NX for PcdSetNxForStack only.

Regards,
Jian

From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, September 11, 2018 11:53 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Justen, Jordan L 
; Yao, Jiewen ; Zeng, Star 
; Ard Biesheuvel 
Subject: Re: [edk2] [PATCH 2/5] OvmfPkg/PlatformPei: expire the use of 
PcdSetNxForStack

On 09/11/18 07:16, Jian J Wang wrote:
> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=1116
>
> Since PcdSetNxForStack is expired, remove related config code.
> PcdDxeNxMemoryProtectionPolicy cannot be used as dynamic PCD.
> There's no need to add it in code to replace PcdSetNxForStack.
>
> Cc: Laszlo Ersek 
> Cc: Star Zeng 
> Cc: Jordan Justen 
> Cc: Ard Biesheuvel 
> Cc: Ruiyu Ni 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  OvmfPkg/PlatformPei/Platform.c  | 1 -
>  OvmfPkg/PlatformPei/PlatformPei.inf | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
> index 5a78668126..6627d236e0 100644
> --- a/OvmfPkg/PlatformPei/Platform.c
> +++ b/OvmfPkg/PlatformPei/Platform.c
> @@ -340,7 +340,6 @@ NoexecDxeInitialization (
>)
>  {
>UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdPropertiesTableEnable);
> -  UPDATE_BOOLEAN_PCD_FROM_FW_CFG (PcdSetNxForStack);
>  }
>
>  VOID
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
>b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 9c5ad9961c..ef5dcb7693 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -96,7 +96,6 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
>gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
>gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
>gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
>

I disagree with this change. I explained my reasons in
<https://bugzilla.tianocore.org/show_bug.cgi?id=1116#c6>, but for the
sake of discussion, I'll state the same here:

> Ard's got a point here. Just because one PCD implies another, the
> reverse is not necessarily true.
>
> For example, in OVMF, we set PcdSetNxForStack to TRUE originally, but
> then we had to make it conditional, due to old GRUB variants breaking
> with a non-executable stack. (Please refer to commit d20b06a3afdf,
> "OvmfPkg: disable no-exec DXE stack by default", 2015-09-15).
> Therefore we now default to FALSE, and let the user set it to TRUE on
> the QEMU command line.
>
> In addition, we intentionally inherit a zero
> PcdDxeNxMemoryProtectionPolicy from "MdeModulePkg.dec".
>
> Both of the above configurations satisfy the requirement
>
>   ((PcdGet64 (PcdDxeNxMemoryProtectionPolicy) &
> (1 << EfiBootServicesData)) == 0 ||
>PcdGetBool (PcdSetNxForStack))
>
> i.e. the requirement that "NX for BS data" imply "NX for stack".
>
> If you remove the standalone knob for PcdSetNxForStack, then the
> default behavior of OVMF will continue to work, however the command
> line option, for setting PcdSetNxForStack *only*, will break.

I'd like to add another comment just here (not mentioned in the BZ):

To my understanding, the Heap Guard is a debug feature [1

Re: [edk2] [PATCH] UefiCpuPkg/CpuMpPei: suppress compiler complaining

[Wang, Jian J]

Laszlo,

Thanks for the comments.


(1)Sure. My fault. I thought it’s just very small change for compiler 
warning.

(2)From language point view, it’s a valid warning. But from code logic, 
it’s invalid.

(3)Agree. It’ll be dropped.

(4)Agree. I’ll change it.


Regards,
Jian

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, September 11, 2018 10:56 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Wu, Hao A ; Bi, Dandan ; Dong, 
Eric 
Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuMpPei: suppress compiler complaining

Jian,

On 09/11/18 06:47, Jian J Wang wrote:
> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=1166
>
> Cc: Dandan Bi mailto:dandan...@intel.com>>
> Cc: Hao A Wu mailto:hao.a...@intel.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  UefiCpuPkg/CpuMpPei/CpuPaging.c | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)

(1) Please remember to CC the package maintainers / reviewers on
patches. "Maintainers.txt" lists Eric (M) and myself (R) for UefiCpuPkg.
It's OK to CC other people as well, of course.

(2) Bug 1166 mentions "warning C4701: potentially uninitialized local
variable 'StackBase' used".

If that warning is invalid (= the variable can never be read
unassigned), then we have some suggested language for that; please see
<https://bugzilla.tianocore.org/show_bug.cgi?id=607>.

Furthermore:

>
> diff --git a/UefiCpuPkg/CpuMpPei/CpuPaging.c b/UefiCpuPkg/CpuMpPei/CpuPaging.c
> index bcb942a8e5..a63421a1af 100644
> --- a/UefiCpuPkg/CpuMpPei/CpuPaging.c
> +++ b/UefiCpuPkg/CpuMpPei/CpuPaging.c
> @@ -517,7 +517,7 @@ GetStackBase (
>IN OUT VOID *Buffer
>)
>  {
> -  EFI_PHYSICAL_ADDRESSStackBase;
> +  volatile EFI_PHYSICAL_ADDRESS   StackBase;

(3) "volatile" seems unrelated; I suggest dropping it.

(Especially without the comment mentioned in TianoCore#607, "volatile"
is totally unjustified and confusing.)

>
>StackBase = (EFI_PHYSICAL_ADDRESS)(UINTN)
>StackBase += BASE_4KB;
> @@ -554,6 +554,8 @@ SetupStackGuardPage (
>MpInitLibGetNumberOfProcessors(, NULL);
>MpInitLibWhoAmI ();
>for (Index = 0; Index < NumberOfProcessors; ++Index) {
> +StackBase = 0;
> +
>  if (Index == Bsp) {
>Hob.Raw = GetHobList ();
>while ((Hob.Raw = GetNextHob (EFI_HOB_TYPE_MEMORY_ALLOCATION, 
> Hob.Raw)) != NULL) {
> @@ -570,12 +572,19 @@ SetupStackGuardPage (
>//
>MpInitLibStartupThisAP(GetStackBase, Index, NULL, 0, (VOID 
> *), NULL);
>  }
> -//
> -// Set Guard page at stack base address.
> -//
> -ConvertMemoryPageAttributes(StackBase, EFI_PAGE_SIZE, 0);
> -DEBUG ((DEBUG_INFO, "Stack Guard set at %lx [cpu%lu]!\n",
> -(UINT64)StackBase, (UINT64)Index));
> +
> +if (StackBase == 0) {
> +  DEBUG ((DEBUG_ERROR, "Stack base address was not found for 
> [cpu%lu]!\n",
> +  (UINT64)Index));
> +  ASSERT(StackBase != 0);

(4) On the other hand, if it *can* happen in practice that the stack
base is not found (and in that case, we should halt), then:

* the subject line is wrong, because the compiler warning is *valid*,
and we don't suppress it, but fix the issue caught by the compiler;

* we must not proceed in a RELEASE build either, therefore an ASSERT is
insufficient. A CpuDeadLoop() is necessary.

(Again, this only applies if StackBase may be zero here by design.)

Thanks
Laszlo


> +} else {
> +  //
> +  // Set Guard page at stack base address.
> +  //
> +  ConvertMemoryPageAttributes(StackBase, EFI_PAGE_SIZE, 0);
> +  DEBUG ((DEBUG_INFO, "Stack Guard set at %lx [cpu%lu]!\n",
> +  (UINT64)StackBase, (UINT64)Index));
> +}
>}
>
>//
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: add message for S3 config error

[Wang, Jian J]

Laszlo,

Thanks for the comment. I think it’ll ok to add it in a separate patch.

Just a little confuse about “a separate patch”. Does it mean a separate patch 
file
in the same patch series or a separate patch which needs a separate BZ tracker?

Regards,
Jian

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, September 11, 2018 9:52 PM
To: Zeng, Star ; Wang, Jian J ; 
edk2-devel@lists.01.org
Cc: You, Benjamin ; Dong, Eric 
Subject: Re: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: add message for S3 config error

On 09/10/18 07:07, Zeng, Star wrote:
> I agree to add the ASSERT, but even with the ASSERT, I still suggest moving
> //
> // Patch SmmS3ResumeState->SmmS3Cr3
> //
> InitSmmS3Cr3 ();
>
> into
>   GuidHob = GetFirstGuidHob ();
>   if (GuidHob != NULL) {
> ...
>   }
>
> With that, Reviewed-by: Star Zeng 
> mailto:star.z...@intel.com>>

I think that's a valid idea, but shouldn't it be done in a separate
patch? One patch for the assert, and another moving InitSmmS3Cr3() under
the right condition. Does that sound OK?

Thanks
Laszlo


>
>
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Monday, September 10, 2018 11:22 AM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Zeng, Star mailto:star.z...@intel.com>>; You, 
> Benjamin mailto:benjamin@intel.com>>; Dong, Eric 
> mailto:eric.d...@intel.com>>; Laszlo Ersek 
> mailto:ler...@redhat.com>>
> Subject: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: add message for S3 config error
>
> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=1165
>
> HOB gEfiAcpiVariableGuid is a must have data for S3 resume if PcdAcpiS3Enable 
> is set to TRUE. Current code in CpuS3.c doesn't embody this strong binding 
> between them. An error message and ASSERT is added by this patch to warn 
> platform developer about it.
>
> Cc: Star Zeng mailto:star.z...@intel.com>>
> Cc: Benjamin You mailto:benjamin@intel.com>>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> index abd8a5a07b..f371667c44 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> @@ -744,6 +744,9 @@ InitSmmS3ResumeState (
>  if (sizeof (UINTN) == sizeof (UINT32)) {
>SmmS3ResumeState->Signature = SMM_S3_RESUME_SMM_32;
>  }
> +  } else {
> +DEBUG ((DEBUG_ERROR, "ERROR: HOB(gEfiAcpiVariableGuid) needed by S3 
> resume doesn't exist!\n"));
> +ASSERT (FALSE);
>}
>
>//
> --
> 2.16.2.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: add message for S3 config error

[Wang, Jian J]

Laszlo,

Thanks for the comments.


(1)Agree. It’ll be updated in v2.

(2)DEBUG_ERROR level won’t print word “ERROR” on console. I think an “ERROR”

word in log should get the attention more easily.

(3)How about log both of them? GUID value may be more friendly to log 
parser but
a GUID name is more friendly to person.

(4)Good idea. I’ll add it in v2.

Regards,
Jian

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, September 11, 2018 10:01 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Zeng, Star ; You, Benjamin ; 
Dong, Eric 
Subject: Re: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: add message for S3 config error

On 09/10/18 05:22, Jian J Wang wrote:
> BZ#: https://bugzilla.tianocore.org/show_bug.cgi?id=1165
>
> HOB gEfiAcpiVariableGuid is a must have data for S3 resume if
> PcdAcpiS3Enable is set to TRUE. Current code in CpuS3.c doesn't
> embody this strong binding between them. An error message and
> ASSERT is added by this patch to warn platform developer about
> it.
>
> Cc: Star Zeng mailto:star.z...@intel.com>>
> Cc: Benjamin You mailto:benjamin@intel.com>>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> mailto:jian.j.w...@intel.com>>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> index abd8a5a07b..f371667c44 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
> @@ -744,6 +744,9 @@ InitSmmS3ResumeState (
>  if (sizeof (UINTN) == sizeof (UINT32)) {
>SmmS3ResumeState->Signature = SMM_S3_RESUME_SMM_32;
>  }
> +  } else {
> +DEBUG ((DEBUG_ERROR, "ERROR: HOB(gEfiAcpiVariableGuid) needed by S3 
> resume doesn't exist!\n"));
> +ASSERT (FALSE);
>}
>
>//
>

I have some superficial comments for this patch.

(1) in case the "if" has an "else" branch, I think it's better style to
use "==" in the condition than "!=". To me,

  if (GuidHob != NULL) {
//
// do a bunch of stuff
//
  } else {
//
// error
//
  }

is more difficult to read than:

  if (GuidHob == NULL) {
//
// error
//
  } else {
//
// do a bunch of stuff
//
  }

in particular if the "bunch of stuff" includes nested "if" statements.


(2) I think the error message could be improved. I'd suggest removing
the word "ERROR", since DEBUG_ERROR already sets the error level / mask.

(3) Furthermore, I suggest not logging the name "gEfiAcpiVariableGuid"
textually, as a string -- in edk2 we generally log GUIDs by value, and
log parsers / translators usually look for GUID values. Thus I suggest
using %g with 

(4) Please consider logging the module name and/or the function name
too, with "%a", and gEfiCallerBaseName and/or __FUNCTION__.
"gEfiCallerBaseName" is usually only helpful with libraries (because
they can be linked into multiple drivers), but __FUNCTION__ is more
frequently helpful.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/2] Resolve feature conflict between NX and Stack guard

[Wang, Jian J]

Thanks for fixing the issue.

For this patch series:

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>

> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, March 06, 2018 9:33 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A <hao.a...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>;
> Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Yao,
> Jiewen <jiewen@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [PATCH v2 0/2] Resolve feature conflict between NX and Stack guard
> 
> V2 changes:
> 
> A. Use Hoblib APIs to get the base of stack from Hob.
> B. Remove unnecessary local variable used in function
>InitializeDxeNxMemoryProtectionPolicy().
> 
> V1 history:
> 
> If enabled, NX memory protection feature will mark some types of active
> memory as NX (non-executable), which includes the first page of the stack.
> This will overwrite the attributes of the first page of the stack if the
> stack guard feature is also enabled.
> 
> The series will override the attributes setting to the first page of the
> stack by adding back the 'EFI_MEMORY_RP' attribute when the stack guard
> feature is enabled.
> 
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> 
> Hao Wu (2):
>   MdeModulePkg/Core: Refine handling NULL detection in NX setting
>   MdeModulePkg/Core: Fix feature conflict between NX and Stack guard
> 
>  MdeModulePkg/Core/Dxe/DxeMain.inf |  4 +-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 74
> +++
>  2 files changed, 67 insertions(+), 11 deletions(-)
> 
> --
> 2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/2] Resolve feature conflict between NX and Stack guard

[Wang, Jian J]

Regards,
Jian


> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, March 07, 2018 11:17 AM
> To: Wu, Hao A <hao.a...@intel.com>; edk2-devel@lists.01.org
> Cc: Wang, Jian J <jian.j.w...@intel.com>; Zeng, Star <star.z...@intel.com>;
> Dong, Eric <eric.d...@intel.com>; Yao, Jiewen <jiewen@intel.com>
> Subject: Re: [PATCH v2 0/2] Resolve feature conflict between NX and Stack
> guard
> 
> On 3/6/2018 9:33 PM, Hao Wu wrote:
> > V2 changes:
> >
> > A. Use Hoblib APIs to get the base of stack from Hob.
> > B. Remove unnecessary local variable used in function
> > InitializeDxeNxMemoryProtectionPolicy().
> >
> > V1 history:
> >
> > If enabled, NX memory protection feature will mark some types of active
> > memory as NX (non-executable), which includes the first page of the stack.
> > This will overwrite the attributes of the first page of the stack if the
> > stack guard feature is also enabled.
> >
> > The series will override the attributes setting to the first page of the
> > stack by adding back the 'EFI_MEMORY_RP' attribute when the stack guard
> > feature is enabled.
> >
> > Cc: Jian J Wang <jian.j.w...@intel.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> >
> > Hao Wu (2):
> >MdeModulePkg/Core: Refine handling NULL detection in NX setting
> >MdeModulePkg/Core: Fix feature conflict between NX and Stack guard
> >
> >   MdeModulePkg/Core/Dxe/DxeMain.inf |  4 +-
> >   MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 74
> +++
> >   2 files changed, 67 insertions(+), 11 deletions(-)
> >
> 
>if (MemoryMapEntry->PhysicalStart == 0 &&
>PcdGet8 (PcdNullPointerDetectionPropertyMask) != 0) {
> 
>  ASSERT (MemoryMapEntry->NumberOfPages > 0);
>  //
>  // Add EFI_MEMORY_RP attribute for page 0 if NULL pointer
> detection is
>  // enabled.
>  //
> [Ray] 1. I prefer to move the above comments before the "if (...)".
> 
>  SetUefiImageMemoryAttributes (
>0,
>EFI_PAGES_TO_SIZE (1),
>EFI_MEMORY_RP | Attributes);
>}
> 
>if (StackBase != 0 &&
>(StackBase >= MemoryMapEntry->PhysicalStart &&
> StackBase <  MemoryMapEntry->PhysicalStart +
>  LShiftU64 (MemoryMapEntry->NumberOfPages,
> EFI_PAGE_SHIFT)) &&
>PcdGetBool (PcdCpuStackGuard)) {
> 
>  //
>  // Add EFI_MEMORY_RP attribute for the first page of the stack
> if stack
>  // guard is enabled.
>  //
>  SetUefiImageMemoryAttributes (
>StackBase,
>EFI_PAGES_TO_SIZE (1),
>EFI_MEMORY_RP | Attributes);
> [Ray] 2. The StackBase is directly used here. So do we need to check
> whether it's page aligned? Do we need to check whether the range
> [StackBase, StackBase + 4KB) is inside the MemoryMapEntry?
>}

If PcdCpuStackGuard is TRUE, I think the owner who allocates memory for 
StackBase
should make sure all the conditions you mentioned, but not here.

> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg CpuExceptionHandlerLib: use FixedPcdGetSize() as the macro value

[Wang, Jian J]

Reviewed-by: Jian J Wang <jian.j.w...@intel.com>

> -Original Message-
> From: Gao, Liming
> Sent: Friday, March 16, 2018 9:47 AM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J <jian.j.w...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>;
> Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: [Patch] UefiCpuPkg CpuExceptionHandlerLib: use FixedPcdGetSize() as
> the macro value
> 
> FixedPcdGetSize() is used as the macro value, PcdGetSize() is used as global
> variable or function. Here usage is to access macro value.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao <liming@intel.com>
> Cc: Wang Jian J <jian.j.w...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> ---
>  UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchInterruptDefs.h | 6 +++-
> --
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchInterruptDefs.h
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchInterruptDefs.h
> index d9ded5977f..ac3650a2a3 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchInterruptDefs.h
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchInterruptDefs.h
> @@ -1,7 +1,7 @@
>  /** @file
>Ia32 arch definition for CPU Exception Handler Library.
> 
> -  Copyright (c) 2013, Intel Corporation. All rights reserved.
> +  Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be 
> found
> at
> @@ -43,10 +43,10 @@ typedef struct {
> 
>  #define CPU_TSS_DESC_SIZE \
>(sizeof (IA32_TSS_DESCRIPTOR) * \
> -   (PcdGetSize (PcdCpuStackSwitchExceptionList) + 1))
> +   (FixedPcdGetSize (PcdCpuStackSwitchExceptionList) + 1))
> 
>  #define CPU_TSS_SIZE \
>(sizeof (IA32_TASK_STATE_SEGMENT) * \
> -   (PcdGetSize (PcdCpuStackSwitchExceptionList) + 1))
> +   (FixedPcdGetSize (PcdCpuStackSwitchExceptionList) + 1))
> 
>  #endif
> --
> 2.11.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Core: allow HeapGuard even before CpuArchProtocol installed

[Wang, Jian J]

There's a bit operation error found in 32-bit platform. I'll send a v2 patch 
later.

Regards,
Jian


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Wednesday, March 14, 2018 4:31 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Zeng, Star 
> Subject: [edk2] [PATCH] MdeModulePkg/Core: allow HeapGuard even before
> CpuArchProtocol installed
> 
> Due to the fact that HeapGuard needs CpuArchProtocol to update page
> attributes, the feature is normally enabled after CpuArchProtocol is
> installed. Since there're some drivers are loaded before CpuArchProtocl,
> they cannot make use HeapGuard feature to detect potential issues.
> 
> This patch fixes above situation by updating the DXE core to skip the
> NULL check against global gCpu in the IsMemoryTypeToGuard(), and adding
> NULL check against gCpu in SetGuardPage() and UnsetGuardPage() to make
> sure that they can be called but do nothing. This will allow HeapGuard to
> record all guarded memory without setting the related Guard pages to not-
> present.
> 
> Once the CpuArchProtocol is installed, a protocol notify will be called
> to complete the work of setting Guard pages to not-present.
> 
> Please note that above changes will cause a #PF in GCD code during cleanup
> of map entries, which is initiated by CpuDxe driver to update real mtrr
> and paging attributes back to GCD. During that time, CpuDxe doesn't allow
> GCD to update memory attributes and then any Guard page cannot be unset.
> As a result, this will prevent Guarded memory from freeing during memory
> map cleanup.
> 
> The solution is to avoid allocating guarded memory as memory map entries
> in GCD code. It's done by setting global mOnGuarding to TRUE before memory
> allocation and setting it back to FALSE afterwards in GCD function
> CoreAllocateGcdMapEntry().
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c   |  10 ++
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 132
> +-
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.h |   8 ++
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c |   5 +
>  4 files changed, 154 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> index 8fbc3d282c..77f4adb4bc 100644
> --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> @@ -16,6 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> 
>  #include "DxeMain.h"
>  #include "Gcd.h"
> +#include "Mem/HeapGuard.h"
> 
>  #define MINIMUM_INITIAL_MEMORY_SIZE 0x1
> 
> @@ -391,12 +392,21 @@ CoreAllocateGcdMapEntry (
>IN OUT EFI_GCD_MAP_ENTRY  **BottomEntry
>)
>  {
> +  //
> +  // Set to mOnGuarding to TRUE before memory allocation. This will make sure
> +  // that the entry memory is not "guarded" by HeapGuard. Otherwise it might
> +  // cause problem when it's freed (if HeapGuard is enabled).
> +  //
> +  mOnGuarding = TRUE;
>*TopEntry = AllocateZeroPool (sizeof (EFI_GCD_MAP_ENTRY));
> +  mOnGuarding = FALSE;
>if (*TopEntry == NULL) {
>  return EFI_OUT_OF_RESOURCES;
>}
> 
> +  mOnGuarding = TRUE;
>*BottomEntry = AllocateZeroPool (sizeof (EFI_GCD_MAP_ENTRY));
> +  mOnGuarding = FALSE;
>if (*BottomEntry == NULL) {
>  CoreFreePool (*TopEntry);
>  return EFI_OUT_OF_RESOURCES;
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 19245049c2..de2c468b83 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -576,6 +576,10 @@ SetGuardPage (
>IN  EFI_PHYSICAL_ADDRESS  BaseAddress
>)
>  {
> +  if (gCpu == NULL) {
> +return;
> +  }
> +
>//
>// Set flag to make sure allocating memory without GUARD for page table
>// operation; otherwise infinite loops could be caused.
> @@ -606,6 +610,10 @@ UnsetGuardPage (
>  {
>UINT64  Attributes;
> 
> +  if (gCpu == NULL) {
> +return;
> +  }
> +
>//
>// Once the Guard page is unset, it will be freed back to memory pool. NX
>// memory protection must be restored for this page if NX is enabled for 
> free
> @@ -652,7 +660,7 @@ IsMemoryTypeToGuard (
>UINT64 ConfigBit;
>BOOLEAN InSmm;
> 
> -  if (gCpu == NULL || AllocateType == AllocateAddress) {
> +  if (AllocateType == AllocateAddress) {
>  return FALSE;
>}
> 
> @@ -1160,6 +1168,128 @@ CoreConvertPagesWithGuard (
>return CoreConvertPages (Start, NumberOfPages, NewType);
>  }
> 
> +/**
> +  Set all Guard pages which cannot be set before CPU Arch Protocol installed.
> +**/
> +VOID
> 

Re: [edk2] [PATCH] MdeModulePkg/Core: allow HeapGuard even before CpuArchProtocol installed

[Wang, Jian J]

Thanks catching this. New patch has sent out.

Regards,
Jian


> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, March 15, 2018 11:47 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH] MdeModulePkg/Core: allow HeapGuard even
> before CpuArchProtocol installed
> 
> On 3/15/2018 10:27 AM, Jian J Wang wrote:
> >> v2 changes:
> >> Fix a logic hole in bits operation on address on 64K boundary with
> >> just 64-bit length (SetBits(), ClearBits(), GetBits()).
> >
> > Due to the fact that HeapGuard needs CpuArchProtocol to update page
> > attributes, the feature is normally enabled after CpuArchProtocol is
> > installed. Since there're some drivers are loaded before CpuArchProtocl,
> > they cannot make use HeapGuard feature to detect potential issues.
> >
> > This patch fixes above situation by updating the DXE core to skip the
> > NULL check against global gCpu in the IsMemoryTypeToGuard(), and adding
> > NULL check against gCpu in SetGuardPage() and UnsetGuardPage() to make
> > sure that they can be called but do nothing. This will allow HeapGuard to
> > record all guarded memory without setting the related Guard pages to not-
> > present.
> >
> > Once the CpuArchProtocol is installed, a protocol notify will be called
> > to complete the work of setting Guard pages to not-present.
> >
> > Please note that above changes will cause a #PF in GCD code during cleanup
> > of map entries, which is initiated by CpuDxe driver to update real mtrr
> > and paging attributes back to GCD. During that time, CpuDxe doesn't allow
> > GCD to update memory attributes and then any Guard page cannot be unset.
> > As a result, this will prevent Guarded memory from freeing during memory
> > map cleanup.
> >
> > The solution is to avoid allocating guarded memory as memory map entries
> > in GCD code. It's done by setting global mOnGuarding to TRUE before memory
> > allocation and setting it back to FALSE afterwards in GCD function
> > CoreAllocateGcdMapEntry().
> >
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >   MdeModulePkg/Core/Dxe/Gcd/Gcd.c   |  10 ++
> >   MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 148
> --
> >   MdeModulePkg/Core/Dxe/Mem/HeapGuard.h |   8 ++
> >   MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c |   5 +
> >   MdeModulePkg/Core/PiSmmCore/HeapGuard.c   |  16 +--
> >   5 files changed, 174 insertions(+), 13 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > index 8fbc3d282c..77f4adb4bc 100644
> > --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > @@ -16,6 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> >
> >   #include "DxeMain.h"
> >   #include "Gcd.h"
> > +#include "Mem/HeapGuard.h"
> >
> >   #define MINIMUM_INITIAL_MEMORY_SIZE 0x1
> >
> > @@ -391,12 +392,21 @@ CoreAllocateGcdMapEntry (
> > IN OUT EFI_GCD_MAP_ENTRY  **BottomEntry
> > )
> >   {
> > +  //
> > +  // Set to mOnGuarding to TRUE before memory allocation. This will make
> sure
> > +  // that the entry memory is not "guarded" by HeapGuard. Otherwise it 
> > might
> > +  // cause problem when it's freed (if HeapGuard is enabled).
> > +  //
> > +  mOnGuarding = TRUE;
> > *TopEntry = AllocateZeroPool (sizeof (EFI_GCD_MAP_ENTRY));
> > +  mOnGuarding = FALSE;
> > if (*TopEntry == NULL) {
> >   return EFI_OUT_OF_RESOURCES;
> > }
> >
> > +  mOnGuarding = TRUE;
> > *BottomEntry = AllocateZeroPool (sizeof (EFI_GCD_MAP_ENTRY));
> > +  mOnGuarding = FALSE;
> > if (*BottomEntry == NULL) {
> >   CoreFreePool (*TopEntry);
> >   return EFI_OUT_OF_RESOURCES;
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > index ac043b5d9b..fd6aeee8da 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > @@ -70,7 +70,7 @@ SetBits (
&

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: fix #PF caused by freeing read-only memory

[Wang, Jian J]

DxeCore will only apply EFI_MEMORY_RO to image CODE memory (controlled by
PcdImageProtectionPolicy). Normally allocated rt_code/bs_code memory won't be
marked as read-only. So my answer is NO.

Regards,
Jian


> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, March 15, 2018 2:56 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: fix #PF caused by
> freeing read-only memory
> 
> On 3/15/2018 2:22 PM, Jian J Wang wrote:
> > SMM core will add a HEADER before each allocated pool memory and clean
> > up this header once it's freed. If a block of allocated pool is marked
> > as read-only after allocation (EfiRuntimeServicesCode type of pool in
> > SMM will always be marked as read-only), #PF exception will be triggered
> > during memory pool freeing.
> >
> > Normally EfiRuntimeServicesCode type of pool should not be freed in the
> > real world. But some test suites will actually do memory free for all
> > types of memory for the purpose of functionality and conformance test.
> > So this issue should be fixed anyway.
> 
> Does DxeCore have such problem?
> 
> >
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Ruiyu Ni <ruiyu...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >   MdeModulePkg/Core/PiSmmCore/HeapGuard.c | 22
> ++
> >   1 file changed, 22 insertions(+)
> >
> > diff --git a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> > index f9657f9baa..d5556eb79c 100644
> > --- a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> > +++ b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> > @@ -941,6 +941,7 @@ AdjustMemoryF (
> > EFI_PHYSICAL_ADDRESS  MemoryToTest;
> > UINTN PagesToFree;
> > UINT64GuardBitmap;
> > +  UINT64Attributes;
> >
> > if (Memory == NULL || NumberOfPages == NULL || *NumberOfPages == 0)
> {
> >   return;
> > @@ -949,6 +950,27 @@ AdjustMemoryF (
> > Start = *Memory;
> > PagesToFree = *NumberOfPages;
> >
> > +  //
> > +  // In case the memory to free is marked as read-only (e.g.
> EfiRuntimeServicesCode).
> > +  //
> > +  if (mSmmMemoryAttribute != NULL) {
> > +Attributes = 0;
> > +mSmmMemoryAttribute->GetMemoryAttributes (
> > +   mSmmMemoryAttribute,
> > +   Start,
> > +   EFI_PAGES_TO_SIZE (PagesToFree),
> > +   
> > +   );
> > +if ((Attributes & EFI_MEMORY_RO) != 0) {
> > +  mSmmMemoryAttribute->ClearMemoryAttributes (
> > + mSmmMemoryAttribute,
> > + Start,
> > + EFI_PAGES_TO_SIZE (PagesToFree),
> > + EFI_MEMORY_RO
> > + );
> > +}
> > +  }
> > +
> > //
> > // Head Guard must be one page before, if any.
> > //
> >
> 
> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel