Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe driver to bypass NULL pointer detection if enabled.

[Wang, Jian J]

It’s an implementation limitation. All page attributes will be filtered out 
before calling CPU arch protocol to update the attributes (Gcd.c).

From: Yao, Jiewen
Sent: Thursday, September 14, 2017 4:38 PM
To: Laszlo Ersek <ler...@redhat.com>; Wang, Jian J <jian.j.w...@intel.com>
Cc: Dong, Eric <eric.d...@intel.com>; Justen, Jordan L 
<jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Wolman, Ayellet 
<ayellet.wol...@intel.com>; Kinney, Michael D <michael.d.kin...@intel.com>; 
Zeng, Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

HI
I wonder if it is spec limitation or implementation limitation.

If it is implementation limitation, we can enhance the DxeCore to allow it.

Thank you
Yao Jiewen

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Thursday, September 14, 2017 4:30 PM
To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>
Cc: Dong, Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>; Justen, 
Jordan L <jordan.l.jus...@intel.com<mailto:jordan.l.jus...@intel.com>>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Yao, Jiewen 
<jiewen@intel.com<mailto:jiewen@intel.com>>; Wolman, Ayellet 
<ayellet.wol...@intel.com<mailto:ayellet.wol...@intel.com>>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Zeng, Star 
<star.z...@intel.com<mailto:star.z...@intel.com>>
Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

On 09/14/17 05:17, Wang, Jian J wrote:
> For the use of arch protocol, there's one thing I mentioned is not
> accurate. I actually tried gDS->SetMemorySpaceAttributes() but it
> cannot change page attributes. That's why I have to turn to cpu arch
> protocol.
Thank you for the explanation.

In that case, we cannot avoid violating the PI spec. I agree we can
break the spec if it happens for security purposes, but in that case, I
believe that hiding the implementation behind a library class is
mandatory. Viewed from the spec side, accessing the CPU Arch protocol is
a hack, and so it should not be spread to the source code of several
driver modules.

Thank you,
Laszlo


>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang, 
> Jian J
> Sent: Thursday, September 14, 2017 9:17 AM
> To: Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>
> Cc: Dong, Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>; Justen, 
> Jordan L <jordan.l.jus...@intel.com<mailto:jordan.l.jus...@intel.com>>; 
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Yao, Jiewen 
> <jiewen@intel.com<mailto:jiewen@intel.com>>; Wolman, Ayellet 
> <ayellet.wol...@intel.com<mailto:ayellet.wol...@intel.com>>; Kinney, Michael 
> D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Zeng, Star 
> <star.z...@intel.com<mailto:star.z...@intel.com>>
> Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
> driver to bypass NULL pointer detection if enabled.
>
> Thanks for the comments and good advices. Sorry the format issues.
> This is my first patch for this project. Too many details for me to get
> familiar with.
>
> (1) Sure.
> (2) I'll change that.
> (3) I'll use the tool to ensure the patch format.
> (4) I'll remove the ',' in name
> (5) I'll add more description about it.
> (6) You're right. I should use SetMemorySpaceAttributes() of DXE service
>  instead. The only reason I didn't do it is that I found
>   GetMemorySpaceDescriptor() doesn't return the same information
>  which SetMemorySpaceAttributes() just changed. So I feel using CPU
> arch protocol is a bit safer. Anyway, I'll change it.
> (7) I did put those macros in the install function before. To reduce the
>  number of changed files, I made current changes. You're right it's
>  not worthy.
> (8) Using macro can help the readability, which is more important to me.
> I know function can do the same. But it looks a bit heavy in this 
> situation.
> I have to admit replacing  the macros with a library is a very good idea,
> which brings the same readability. I didn't think of that before. Although
> Library is still a little bit heavy to me but it's in a different way, I 
> think it
>     worth a trying.
> (9) Putting a space before open parenthesis is forced style? If so, I'll add 
> it.
> (10) You're right. Using library can reduce the disturbs to affected drivers
>by this feature to the minimum.
>

Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe driver to bypass NULL pointer detection if enabled.

[Wang, Jian J]

For record, we'll make following changes to address the page attributes issue:

(1) Update gDS->SetMemorySpaceAddress() to remove the filter set on page 
attributes
(2) Update CPU driver to sync all memory attributes including page related. No 
platform code changes needed.

Above changes will be submitted in a separate patch. As a result (after it's 
done), the related changes for this patch will be 
(3) Replace macros with functions, in which gDS->SetMemorySpaceAttributes() 
will be used instead of CPU arch method.


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang, 
Jian J
Sent: Friday, September 15, 2017 8:15 AM
To: Zeng, Star <star.z...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Yao, 
Jiewen <jiewen@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Justen, Jordan L 
<jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Dong, Eric 
<eric.d...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

gDS-> SetMemorySpaceCapabilities() can change the Capability at any time. But 
I'm not sure about any side-effect of it.

-Original Message-
From: Zeng, Star 
Sent: Thursday, September 14, 2017 6:17 PM
To: Laszlo Ersek <ler...@redhat.com>; Wang, Jian J <jian.j.w...@intel.com>; 
Yao, Jiewen <jiewen@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Justen, Jordan L 
<jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Dong, Eric 
<eric.d...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; Zeng, Star 
<star.z...@intel.com>
Subject: RE: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

No, I want to say even the GCD is updated to not filter page attributes, it 
will still not work as all the memory controller code for now are not reporting 
the Capability.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, September 14, 2017 5:55 PM
To: Zeng, Star <star.z...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>; 
Yao, Jiewen <jiewen@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Justen, Jordan L 
<jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Dong, Eric 
<eric.d...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

On 09/14/17 11:39, Zeng, Star wrote:
> There is a realistic problem I just found and want to share.
> 
> GCD database is built based on resource hob reported from PEI, and GCD 
> checks the input Attributes against Capabilities when setting 
> Attributes, but we (I just searched the whole codebase) can see there 
> is no code reporting resource hob with 
> EFI_RESOURCE_ATTRIBUTE_READ_PROTECTABLE,
> EFI_RESOURCE_ATTRIBUTE_EXECUTION_PROTECTABLE or 
> EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE set.
... Are you saying that, if we modify AddMemoryBaseSizeHob() in 
OvmfPkg/PlatformPei, to report EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE 
(*), then
gDS->SetMemorySpaceAttributes() will start to work?

((*) "MdePkg/Include/Pi/PiHob.h": "NOTE: Since PI spec 1.4, please use 
EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE as Memory capability
attribute: The memory supports being protected from processor writes")

If that's the case, then I hope Jian can include such an OvmfPkg patch in his 
series. :)

Thanks!
Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, September 14, 2017 4:54 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; Yao, Jiewen 
> <jiewen@intel.com>
> Cc: Dong, Eric <eric.d...@intel.com>; Justen, Jordan L 
> <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Wolman, Ayellet 
> <ayellet.wol...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
> driver to bypass NULL pointer detection if enabled.
> 
> On 09/14/17 10:46, Wang, Jian J wrote:
>> It’s an implementation limitation. All page attributes will be filtered out 
>> before calling CPU arch protocol to update the attributes (Gcd.c).
> 
> That cannot be a random occurrence; I'm sure there was some specific intent 
> behind filtering out the page attributes.
> 
> Does "git blame" provide a reason, from the message of the commit that added 
> the filtering?
> 
> Thanks,
> Laszlo
> 
>> From: Yao, Jiewe

Re: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver

[Wang, Jian J]

I found there's a logic hole in code. A new patch will be sent out.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J 
Wang
Sent: Monday, September 18, 2017 11:09 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 
; Yao, Jiewen ; Zeng, Star 

Subject: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver

There're two issues here actually.

>From GCD perspective, its SetMemorySpaceAttributes() method doesn't accept
page related attributes. That means users cannot use it to change page
attributes, and have to turn to CPU arch protocol to do it, which is not
be allowed by PI spec.

>From CpuDxe driver perspective, it doesn't update GCD memory attributes 
from current page table setup during its initialization. So the memory
attributes in GCD might not reflect all memory attributes in real world.

Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Michael Kinney 
Suggested-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 

Jian J Wang (2):
  MdeModulePkg/Core: Fix out-of-sync issue in GCD
  UefiCpuPkg/CpuDxe: Fix out-of-sync issue in page attributes

 MdeModulePkg/Core/Dxe/Gcd/Gcd.c  | 45 
 UefiCpuPkg/CpuDxe/CpuDxe.c   |  5 +++
 UefiCpuPkg/CpuDxe/CpuDxe.h   |  9 
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 92 
 4 files changed, 133 insertions(+), 18 deletions(-)

-- 
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 0/2] Fixe out-of-sync issue between GCD and CPU driver

[Wang, Jian J]

Jiewen,

Any comments on this patch?


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J 
Wang
Sent: Tuesday, September 19, 2017 2:10 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Laszlo Ersek 
; Yao, Jiewen ; Dong, Eric 
; Zeng, Star 
Subject: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver

There're two issues here actually.

>From GCD perspective, its SetMemorySpaceAttributes() method doesn't
accept page related attributes. That means users cannot use it to
change page attributes, and have to turn to CPU arch protocol to do it,
which is not be allowed by PI spec.

>From CpuDxe driver perspective, it doesn't update GCD memory attributes
from current page table setup during its initialization. So the memory
attributes in GCD might not reflect all memory attributes in real world.

Cc: Jiewen Yao 
Cc: Eric Dong 
Cc: Star Zeng 
Cc: Laszlo Ersek 
Cc: Michael Kinney 
Suggested-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 

Jian J Wang (2):
  UefiCpuPkg/CpuDxe: Fix out-of-sync issue in CpuDxe
  MdeModulePkg/Core: Fix out-of-sync issue in GCD

 MdeModulePkg/Core/Dxe/Gcd/Gcd.c  | 45 ++
 UefiCpuPkg/CpuDxe/CpuDxe.c   |  5 ++
 UefiCpuPkg/CpuDxe/CpuDxe.h   |  9 
 UefiCpuPkg/CpuDxe/CpuPageTable.c | 99 
 4 files changed, 140 insertions(+), 18 deletions(-)

-- 
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 0/2] Fixe out-of-sync issue between GCD and CPU driver

[Wang, Jian J]

Jiewen,

Yes. The patch has passed the validation of the UEFI booting Windows 10, 
Windows 7 and Fedora 25.

If no comments from you and others, I'll push the patch to upstream soon.

Thanks,
Jian Wang

-Original Message-
From: Yao, Jiewen 
Sent: Wednesday, September 20, 2017 2:08 PM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek 
<ler...@redhat.com>; Dong, Eric <eric.d...@intel.com>; Zeng, Star 
<star.z...@intel.com>
Subject: RE: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU 
driver

Hi
I take a look at the driver. I think the update is good.

Would you please share what test you have done with the updated UEFI memory map?
Such as UEFI Windows boot, UEFI Linux boot?

Thank you
Yao Jiewen


> -----Original Message-
> From: Wang, Jian J
> Sent: Wednesday, September 20, 2017 1:12 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek
> <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU
> driver
> 
> Jiewen,
> 
> Any comments on this patch?
> 
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Tuesday, September 19, 2017 2:10 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek
> <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver
> 
> There're two issues here actually.
> 
> From GCD perspective, its SetMemorySpaceAttributes() method doesn't
> accept page related attributes. That means users cannot use it to
> change page attributes, and have to turn to CPU arch protocol to do it,
> which is not be allowed by PI spec.
> 
> From CpuDxe driver perspective, it doesn't update GCD memory attributes
> from current page table setup during its initialization. So the memory
> attributes in GCD might not reflect all memory attributes in real world.
> 
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Suggested-by: Jiewen Yao <jiewen@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> 
> Jian J Wang (2):
>   UefiCpuPkg/CpuDxe: Fix out-of-sync issue in CpuDxe
>   MdeModulePkg/Core: Fix out-of-sync issue in GCD
> 
>  MdeModulePkg/Core/Dxe/Gcd/Gcd.c  | 45 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.c   |  5 ++
>  UefiCpuPkg/CpuDxe/CpuDxe.h   |  9 
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 99
> 
>  4 files changed, 140 insertions(+), 18 deletions(-)
> 
> --
> 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 GCC build error on commit c1cab54ce57c2608b8b3ea051c7041f036f21153

[Wang, Jian J]

Ok, thanks for the review.

-Original Message-
From: Wu, Hao A 
Sent: Friday, September 22, 2017 11:21 AM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Cc: Anthony PERARD <anthony.per...@citrix.com>
Subject: RE: [PATCH] UefiCpuPkg/CpuDxe: Fix GCC build error on commit 
c1cab54ce57c2608b8b3ea051c7041f036f21153

One minor comment, please shorten the subject of the patch.

Maybe like:
UefiCpuPkg/CpuDxe: Fix GCC build error on commit c1cab54

With that change,
Reviewed-by: Hao Wu <hao.a...@intel.com>


Best Regards,
Hao Wu

> -Original Message-----
> From: Wang, Jian J
> Sent: Friday, September 22, 2017 10:15 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Anthony PERARD
> Subject: [PATCH] UefiCpuPkg/CpuDxe: Fix GCC build error on commit
> c1cab54ce57c2608b8b3ea051c7041f036f21153
> 
> Cc: Hao Wu <hao.a...@intel.com>
> Cc: Anthony PERARD <anthony.per...@citrix.com>
> Suggested-by: 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 | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index ae93f3f553..d312eb66f8 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -802,8 +802,12 @@ RefreshGcdMemoryAttributesFromPaging (
> 
>GetCurrentPagingContext ();
> 
> -  BaseAddress = 0;
> -  PageLength  = 0;
> +  DoUpdate  = FALSE;
> +  Capabilities  = 0;
> +  Attributes= 0;
> +  BaseAddress   = 0;
> +  PageLength= 0;
> +
>for (Index = 0; Index < NumberOfDescriptors; Index++) {
>  if (MemorySpaceMap[Index].GcdMemoryType ==
> EfiGcdMemoryTypeNonExistent) {
>continue;
> --
> 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 2/2] MdeModulePkg/Core: Fix out-of-sync issue in GCD

[Wang, Jian J]

Sure. I'll submit a new patch after enough validation. Thanks for the review.

-Original Message-
From: Zeng, Star 
Sent: Wednesday, September 20, 2017 5:30 PM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek 
<ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>; Dong, Eric 
<eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH 2/2] MdeModulePkg/Core: Fix out-of-sync issue in GCD

Reviewed-by: Star Zeng <star.z...@intel.com> for this patch.

Please notice that the MemoryProtection.c is using gCpu->SetMemoryAttributes 
but not GCD SetMemorySpaceAttributes.
You should need update it to use GCD SetMemorySpaceAttributes, you can have 
separated patch to cover it.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J 
Wang
Sent: Tuesday, September 19, 2017 2:10 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek 
<ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>; Dong, Eric 
<eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: [edk2] [PATCH 2/2] MdeModulePkg/Core: Fix out-of-sync issue in GCD

>From GCD perspective, its SetMemorySpaceAttributes() method doesn't accept 
>page related attributes. That means users cannot use it to change page 
>attributes, and have to turn to CPU arch protocol to do it, which is not be 
>allowed by PI spec.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
Suggested-by: 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 | 45 -
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c 
index a06f8bb77c..e9d1d5b612 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -40,6 +40,13 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #define PRESENT_MEMORY_ATTRIBUTES (EFI_RESOURCE_ATTRIBUTE_PRESENT)
 
+#define EXCLUSIVE_MEMORY_ATTRIBUTES   (EFI_MEMORY_UC | EFI_MEMORY_WC | \
+   EFI_MEMORY_WT | EFI_MEMORY_WB | \
+   EFI_MEMORY_WP | EFI_MEMORY_UCE)
+
+#define NONEXCLUSIVE_MEMORY_ATTRIBUTES (EFI_MEMORY_XP | EFI_MEMORY_RP | \
+EFI_MEMORY_RO)
+
 #define INVALID_CPU_ARCH_ATTRIBUTES   0x
 
 //
@@ -654,28 +661,30 @@ ConverToCpuArchAttributes (
   UINT64 Attributes
   )
 {
-  if ( (Attributes & EFI_MEMORY_UC) == EFI_MEMORY_UC) {
-return EFI_MEMORY_UC;
-  }
+  UINT64  CpuArchAttributes;
 
-  if ( (Attributes & EFI_MEMORY_WC ) == EFI_MEMORY_WC) {
-return EFI_MEMORY_WC;
+  if ((Attributes & ~(EXCLUSIVE_MEMORY_ATTRIBUTES |
+  NONEXCLUSIVE_MEMORY_ATTRIBUTES)) != 0) {
+return INVALID_CPU_ARCH_ATTRIBUTES;
   }
 
-  if ( (Attributes & EFI_MEMORY_WT ) == EFI_MEMORY_WT) {
-return EFI_MEMORY_WT;
-  }
-
-  if ( (Attributes & EFI_MEMORY_WB) == EFI_MEMORY_WB) {
-return EFI_MEMORY_WB;
-  }
-
-  if ( (Attributes & EFI_MEMORY_WP) == EFI_MEMORY_WP) {
-return EFI_MEMORY_WP;
-  }
-
-  return INVALID_CPU_ARCH_ATTRIBUTES;
+  CpuArchAttributes = Attributes & NONEXCLUSIVE_MEMORY_ATTRIBUTES;
 
+  if ( (Attributes & EFI_MEMORY_UC) == EFI_MEMORY_UC) {
+CpuArchAttributes |= EFI_MEMORY_UC;  } else if ( (Attributes & 
+ EFI_MEMORY_WC ) == EFI_MEMORY_WC) {
+CpuArchAttributes |= EFI_MEMORY_WC;  } else if ( (Attributes & 
+ EFI_MEMORY_WT ) == EFI_MEMORY_WT) {
+CpuArchAttributes |= EFI_MEMORY_WT;  } else if ( (Attributes & 
+ EFI_MEMORY_WB) == EFI_MEMORY_WB) {
+CpuArchAttributes |= EFI_MEMORY_WB;  } else if ( (Attributes & 
+ EFI_MEMORY_UCE) == EFI_MEMORY_UCE) {
+CpuArchAttributes |= EFI_MEMORY_UCE;  } else if ( (Attributes & 
+ EFI_MEMORY_WP) == EFI_MEMORY_WP) {
+CpuArchAttributes |= EFI_MEMORY_WP;  }
+
+  return CpuArchAttributes;
 }
 
 
--
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 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe driver to bypass NULL pointer detection if enabled.

[Wang, Jian J]

For the use of arch protocol, there's one thing I mentioned is not accurate. I 
actually tried gDS->SetMemorySpaceAttributes() but it cannot change page 
attributes. That's why I have to turn to cpu arch protocol.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang, 
Jian J
Sent: Thursday, September 14, 2017 9:17 AM
To: Laszlo Ersek <ler...@redhat.com>
Cc: Dong, Eric <eric.d...@intel.com>; Justen, Jordan L 
<jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Yao, Jiewen 
<jiewen@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; Kinney, 
Michael D <michael.d.kin...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

Thanks for the comments and good advices. Sorry the format issues.
This is my first patch for this project. Too many details for me to get 
familiar with. 

(1) Sure.
(2) I'll change that.
(3) I'll use the tool to ensure the patch format.
(4) I'll remove the ',' in name
(5) I'll add more description about it.
(6) You're right. I should use SetMemorySpaceAttributes() of DXE service
 instead. The only reason I didn't do it is that I found 
  GetMemorySpaceDescriptor() doesn't return the same information
 which SetMemorySpaceAttributes() just changed. So I feel using CPU
arch protocol is a bit safer. Anyway, I'll change it.
(7) I did put those macros in the install function before. To reduce the
 number of changed files, I made current changes. You're right it's
 not worthy.
(8) Using macro can help the readability, which is more important to me.
I know function can do the same. But it looks a bit heavy in this situation.
I have to admit replacing  the macros with a library is a very good idea,  
which brings the same readability. I didn't think of that before. Although 
Library is still a little bit heavy to me but it's in a different way, I 
think it 
worth a trying.
(9) Putting a space before open parenthesis is forced style? If so, I'll add it.
(10) You're right. Using library can reduce the disturbs to affected drivers
   by this feature to the minimum.

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, September 14, 2017 7:35 AM
To: Wang, Jian J <jian.j.w...@intel.com>
Cc: edk2-devel@lists.01.org; Justen, Jordan L <jordan.l.jus...@intel.com>; 
Dong, Eric <eric.d...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; Yao, 
Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

Hi,

some of the points I'm going to make have already been pointed out by
Jordan:

(1) When posting a patch series, please collect the Cc: tags from all of
the patches, and add them *all* to the cover letter. This way everyone
will get a personal copy of the general description.


(2) The subject line is too long. One possible simplification:

OvmfPkg/QemuVideoDxe: bypass NULL pointer detection


On 09/13/17 11:25, Wang, Jian J wrote:
> QemuVideoDxe driver will install VBE SHIM into page 0. If NULL pointer
> detection is enabled, page 0 must be enabled temporarily before
> installing and disabled again afterwards. For Windows 7 boot, BIT7 of
> PcdNullPointerDetectionPropertyMask must still be set to avoid hang.

(3) Subject line and commit message both should not exceed 74 characters
line length. (Not sure how many chars PatchCheck.py actually enforces, I
always stick with 74, following the Linux kernel tradition.)

I rewrapped the commit message here for readability.


>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
> Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>

(4) I think this is also something that Jordan had pointed out a long
time ago (apologies if I mis-remember):

The strings after the tags should form correct email addresses, and if
there are various email meta-characters in them, like "." (dot) and ","
(comma), then they should be quoted, like this:

Cc: "Justen, Jordan L" <jordan.l.jus...@intel.com>
Cc: "Kinney, Michael D" <michael.d.kin...@intel.com>
Cc: "Wolman, Ayellet" <ayellet.wol...@intel.com>
Suggested-by: &q

Re: [edk2] [PATCH 1/4] MdeModulePkg/Core: Implement NULL pointer detection in EDK-II Core.

[Wang, Jian J]

See my comments start with [Jian] below.

-Original Message-
From: Justen, Jordan L 
Sent: Thursday, September 14, 2017 1:28 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>; Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
Subject: Re: [PATCH 1/4] MdeModulePkg/Core: Implement NULL pointer detection in 
EDK-II Core.

On 2017-09-13 02:25:04, Wang, Jian J wrote:
> The mechanism behind is to trigger a page fault exception at address 0. This 
> can be made by disabling page 0 (0-4095) during page table setup. So this 
> feature can only be available on platform with paging enabled. Once this 
> feature is enabled, any code, like CSM, which has to access memory in page 0 
> needs to enable this page temporarily in advance and disable it afterwards. 
> PcdNullPointerDetectionPropertyMask is used to control and elaborate the use 
> cases.
>

Your commit message line is > 450 columns.

https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

I think BaseTools/Scripts/PatchCheck.py can help detect this issue.

(more below...)

[Jian] Sure.

> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
> Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
> ---
>  MdeModulePkg/Core/Dxe/DxeMain.inf|  3 +-
>  MdeModulePkg/Core/Dxe/Mem/Page.c | 21 ++
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c| 47 +
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 15 +++
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  3 +-
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c   | 53 
> 
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  8 +++-
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  2 +
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 23 ++
>  MdeModulePkg/MdeModulePkg.dec| 12 ++
>  10 files changed, 167 insertions(+), 20 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
> b/MdeModulePkg/Core/Dxe/DxeMain.inf
> index 30d5984f7c..273b8b7c0e 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain.inf
> +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
> @@ -179,7 +179,7 @@
>gEfiWatchdogTimerArchProtocolGuid ## CONSUMES
>  
>  [FeaturePcd]
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport ## 
> CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport  
> ## CONSUMES

Why is this line changed?
[Jian] Just align the comment followed because the new one added

>  
>  [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressBootTimeCodePageNumber
> ## SOMETIMES_CONSUMES
> @@ -192,6 +192,7 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable   
> ## CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   
> ## CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy 
> ## CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
> ## CONSUMES
>  
>  # [Hob]
>  # RESOURCE_DESCRIPTOR   ## CONSUMES
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c 
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index a142c79ee2..2e0b72f864 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -170,6 +170,7 @@ CoreAddRange (
>  {
>LIST_ENTRY*Link;
>MEMORY_MAP*Entry;
> +  EFI_STATUSStatus;
>  
>ASSERT ((Start & EFI_PAGE_MASK) == 0);
>ASSERT (End > Start) ;
> @@ -188,7 +189,17 @@ CoreAddRange (
>// used for other purposes.
>//  
>if (Type == EfiConventionalMemory && Start == 0 && (End >= EFI_PAGE_SIZE - 
> 1)) {
> -SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
> +if ((PcdGet8(PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
> +  SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
> +} else if (gCpu != NULL) {
> +  Status = gCpu->SetMemoryAttributes(gCpu, 0, EFI_PAGE_SIZE, 0);
> +  ASSERT_EFI_ERROR(Status);
> +
> +  SetMem ((VOID *

Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe driver to bypass NULL pointer detection if enabled.

[Wang, Jian J]

Thanks for the comments and good advices. Sorry the format issues.
This is my first patch for this project. Too many details for me to get 
familiar with. 

(1) Sure.
(2) I'll change that.
(3) I'll use the tool to ensure the patch format.
(4) I'll remove the ',' in name
(5) I'll add more description about it.
(6) You're right. I should use SetMemorySpaceAttributes() of DXE service
 instead. The only reason I didn't do it is that I found 
  GetMemorySpaceDescriptor() doesn't return the same information
 which SetMemorySpaceAttributes() just changed. So I feel using CPU
arch protocol is a bit safer. Anyway, I'll change it.
(7) I did put those macros in the install function before. To reduce the
 number of changed files, I made current changes. You're right it's
 not worthy.
(8) Using macro can help the readability, which is more important to me.
I know function can do the same. But it looks a bit heavy in this situation.
I have to admit replacing  the macros with a library is a very good idea,  
which brings the same readability. I didn't think of that before. Although 
Library is still a little bit heavy to me but it's in a different way, I 
think it 
worth a trying.
(9) Putting a space before open parenthesis is forced style? If so, I'll add it.
(10) You're right. Using library can reduce the disturbs to affected drivers
   by this feature to the minimum.

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, September 14, 2017 7:35 AM
To: Wang, Jian J <jian.j.w...@intel.com>
Cc: edk2-devel@lists.01.org; Justen, Jordan L <jordan.l.jus...@intel.com>; 
Dong, Eric <eric.d...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; Yao, 
Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

Hi,

some of the points I'm going to make have already been pointed out by
Jordan:

(1) When posting a patch series, please collect the Cc: tags from all of
the patches, and add them *all* to the cover letter. This way everyone
will get a personal copy of the general description.


(2) The subject line is too long. One possible simplification:

OvmfPkg/QemuVideoDxe: bypass NULL pointer detection


On 09/13/17 11:25, Wang, Jian J wrote:
> QemuVideoDxe driver will install VBE SHIM into page 0. If NULL pointer
> detection is enabled, page 0 must be enabled temporarily before
> installing and disabled again afterwards. For Windows 7 boot, BIT7 of
> PcdNullPointerDetectionPropertyMask must still be set to avoid hang.

(3) Subject line and commit message both should not exceed 74 characters
line length. (Not sure how many chars PatchCheck.py actually enforces, I
always stick with 74, following the Linux kernel tradition.)

I rewrapped the commit message here for readability.


>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
> Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>

(4) I think this is also something that Jordan had pointed out a long
time ago (apologies if I mis-remember):

The strings after the tags should form correct email addresses, and if
there are various email meta-characters in them, like "." (dot) and ","
(comma), then they should be quoted, like this:

Cc: "Justen, Jordan L" <jordan.l.jus...@intel.com>
Cc: "Kinney, Michael D" <michael.d.kin...@intel.com>
Cc: "Wolman, Ayellet" <ayellet.wol...@intel.com>
Suggested-by: "Wolman, Ayellet" <ayellet.wol...@intel.com>
Signed-off-by: "Wang, Jian J" <jian.j.w...@intel.com>

If you look at the actual addresses on the emails that have been sent
out, you can see they are all malformed. For example, I have:

"Jordan L <jordan.l.jus...@intel.com>" for Jordan -- the part before the
comma was taken to be a separate email address (a malformed one).

At least for my reply, I have fixed up the email addresses.


(5) The commit message mentions BIT7 of the new PCD.

First, thanks for checking Windows 7 boot (and I'm happy that I got
suspicious of the feature with regard to Windows 7). I think BIT7 is a
good feature.

However, please include the short description of that feature in the
commit message -- it is one sentence; "Disable NULL pointer detection
just af

Re: [edk2] [PATCH 2/4] UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM mode code.

[Wang, Jian J]

I'll use the tool to check the format. For the macro, it's for readability 
purpose. How's the library replacement suggestion from Laszlo? 

-Original Message-
From: Justen, Jordan L 
Sent: Thursday, September 14, 2017 1:32 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>; Laszlo Ersek <ler...@redhat.com>; Justen; Kinney; 
Kinney, Michael D <michael.d.kin...@intel.com>; Wolman; Wolman, Ayellet 
<ayellet.wol...@intel.com>
Subject: Re: [PATCH 2/4] UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer 
detection for SMM mode code.

On 2017-09-13 02:25:05, Wang, Jian J wrote:
> The mechanism behind is the same as NULL pointer detection enabled in EDK-II 
> core. SMM has its own page table and we have to disable page 0 again in SMM 
> mode.
> 
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
> Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 11 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 25 -
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |  2 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 17 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 11 +++
>  5 files changed, 57 insertions(+), 9 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index f295c2ebf2..d423958783 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -155,6 +155,17 @@ SmiPFHandler (
>  }
>}
>  
> +  //
> +  // If NULL pointer was just accessed
> +  //
> +  if (NULL_DETECTION_ENABLED && (PFAddress >= 0 && PFAddress < 
> EFI_PAGE_SIZE)) {
> +DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
> +DEBUG_CODE (
> +  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Rip);
> +);
> +CpuDeadLoop ();
> +  }
> +
>if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
>  SmmProfilePFHandler (
>SystemContext.SystemContextIa32->Eip,
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index f086b97c30..81c5ac9d11 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -855,10 +855,10 @@ Gen4GPageTable (
>  Pte[Index] = (Index << 21) | mAddressEncMask | IA32_PG_PS | 
> PAGE_ATTRIBUTE_BITS;
>}
>  
> +  Pdpte = (UINT64*)PageTable;
>if (FeaturePcdGet (PcdCpuSmmStackGuard)) {
>  Pages = (UINTN)PageTable + EFI_PAGES_TO_SIZE (5);
>  GuardPage = mSmmStackArrayBase + EFI_PAGE_SIZE;
> -Pdpte = (UINT64*)PageTable;
>  for (PageIndex = Low2MBoundary; PageIndex <= High2MBoundary; PageIndex 
> += SIZE_2MB) {
>Pte = (UINT64*)(UINTN)(Pdpte[BitFieldRead32 ((UINT32)PageIndex, 30, 
> 31)] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
>Pte[BitFieldRead32 ((UINT32)PageIndex, 21, 29)] = (UINT64)Pages | 
> mAddressEncMask | PAGE_ATTRIBUTE_BITS;
> @@ -886,6 +886,29 @@ Gen4GPageTable (
>  }
>}
>  
> +  if (NULL_DETECTION_ENABLED) {
> +Pte = (UINT64*)(UINT64)(Pdpte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 
> 1));
> +if ((Pte[0] & IA32_PG_PS) == 0) {
> +  // 4K-page entries are already mapped. Just hide the first one anyway.
> +  Pte = (UINT64*)(UINT64)(Pte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 
> 1));
> +  Pte[0] &= ~1; // Hide page 0
> +} else {
> +  // Create 4K-page entries
> +  Pages = (UINTN)AllocatePageTableMemory (1);
> +  ASSERT (Pages != 0);
> +
> +  Pte[0] = (UINT64)(Pages | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
> +
> +  Pte = (UINT64*)Pages;
> +  PageAddress = 0;
> +  Pte[0] = PageAddress | mAddressEncMask; // Hide page 0 but present left
> +  for (Index = 1; Index < EFI_PAGE_SIZE / sizeof (*Pte); Index++) {
> +PageAddress += EFI_PAGE_SIZE;
> +Pte[Index] = PageAddress | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
> +  }
> +}
> +  }
> +
>return (UINT32)(UINTN)PageTable;

Re: [edk2] [PATCH 2/4] UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM mode code.

[Wang, Jian J]

Thanks for the comments. See my comment start with [Jian] below.

-Original Message-
From: Johnson, Brian (EXL - Eagan) [mailto:brian.john...@hpe.com] 
Sent: Thursday, September 14, 2017 12:34 AM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Cc: jus...@ml01.01.org; Dong, Eric <eric.d...@intel.com>; kin...@ml01.01.org; 
Justen, Jordan L <jordan.l.jus...@intel.com>; wol...@ml01.01.org; Yao, Jiewen 
<jiewen@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; Kinney, 
Michael D <michael.d.kin...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Zeng, 
Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH 2/4] UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL 
pointer detection for SMM mode code.

Comments below.

Brian

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang, 
Jian J
Sent: Wednesday, September 13, 2017 4:25 AM
To: edk2-devel@lists.01.org
Cc: jus...@ml01.01.org; Eric Dong <eric.d...@intel.com>; kin...@ml01.01.org; 
Jordan L <jordan.l.jus...@intel.com>; wol...@ml01.01.org; Jiewen Yao 
<jiewen@intel.com>; Ayellet <ayellet.wol...@intel.com>; Michael D 
<michael.d.kin...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Star Zeng 
<star.z...@intel.com>
Subject: [edk2] [PATCH 2/4] UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer 
detection for SMM mode code.

The mechanism behind is the same as NULL pointer detection enabled in EDK-II 
core. SMM has its own page table and we have to disable page 0 again in SMM 
mode.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 11 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 25 -
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |  2 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 17 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 11 +++
 5 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index f295c2ebf2..d423958783 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -155,6 +155,17 @@ SmiPFHandler (
 }
   }
 
+  //
+  // If NULL pointer was just accessed
+  //
+  if (NULL_DETECTION_ENABLED && (PFAddress >= 0 && PFAddress < EFI_PAGE_SIZE)) 
{

[Brian] PFAddress is unsigned, so it will always be >= 0.  Some compilers 
complain about this  Should probably remove that part of the test.
[Jian] You're right. The first test is not necessary.

+DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
+DEBUG_CODE (
+  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Rip);
+);
+CpuDeadLoop ();
+  }
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 SmmProfilePFHandler (
   SystemContext.SystemContextIa32->Eip,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index f086b97c30..81c5ac9d11 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -855,10 +855,10 @@ Gen4GPageTable (
 Pte[Index] = (Index << 21) | mAddressEncMask | IA32_PG_PS | 
PAGE_ATTRIBUTE_BITS;
   }
 
+  Pdpte = (UINT64*)PageTable;
   if (FeaturePcdGet (PcdCpuSmmStackGuard)) {
 Pages = (UINTN)PageTable + EFI_PAGES_TO_SIZE (5);
 GuardPage = mSmmStackArrayBase + EFI_PAGE_SIZE;
-Pdpte = (UINT64*)PageTable;
 for (PageIndex = Low2MBoundary; PageIndex <= High2MBoundary; PageIndex += 
SIZE_2MB) {
   Pte = (UINT64*)(UINTN)(Pdpte[BitFieldRead32 ((UINT32)PageIndex, 30, 31)] 
& ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
   Pte[BitFieldRead32 ((UINT32)PageIndex, 21, 29)] = (UINT64)Pages | 
mAddressEncMask | PAGE_ATTRIBUTE_BITS;
@@ -886,6 +886,29 @@ Gen4GPageTable (
 }
   }
 
+  if (NULL_DETECTION_ENABLED) {
+Pte = (UINT64*)(UINT64)(Pdpte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 
1));

[Brian] Shouldn't the inner cast be (UINTN), not (UINT64)?  That would match 
the PcdCpuSmmStackGuard section above.
[Jian] You're right. Inner cast should be UINTN.

+if ((Pte[0] & IA32_PG_PS) == 0) {
+  // 4K-page entries are already mapped. Just hide the first one anyway.
+  Pte = (UINT64*)(UINT64)(Pte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 
1));

[Brian] Same comment re. the inner cast.

+  Pte[0

Re: [edk2] [PATCH 1/4] MdeModulePkg/Core: Implement NULL pointer detection in EDK-II Core.

[Wang, Jian J]

Thanks for the comment. I think there's no problem here because I'm using two 
separate HOB pointers (RscDescHob and MemAllocHob) to do the traversal. One 
won't interfere with another. 

-Original Message-
From: Johnson, Brian (EXL - Eagan) [mailto:brian.john...@hpe.com] 
Sent: Thursday, September 14, 2017 12:33 AM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Cc: jus...@ml01.01.org; Dong, Eric <eric.d...@intel.com>; kin...@ml01.01.org; 
Justen, Jordan L <jordan.l.jus...@intel.com>; wol...@ml01.01.org; Yao, Jiewen 
<jiewen@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; Kinney, 
Michael D <michael.d.kin...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Zeng, 
Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH 1/4] MdeModulePkg/Core: Implement NULL pointer 
detection in EDK-II Core.

ClearLegacyMemory() assumes that the memory allocation HOB comes after the 
resource descriptor HOB in the HOB list.  Is that guaranteed?  I'd think that 
the memory allocation HOB traversal should be a separate loop, after the 
resource descriptor HOB traversal loop.

Other than that:
Reviewed-by: Brian J. Johnson <brian.john...@hpe.com>

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang, 
Jian J
Sent: Wednesday, September 13, 2017 4:25 AM
To: edk2-devel@lists.01.org
Cc: jus...@ml01.01.org; Eric Dong <eric.d...@intel.com>; kin...@ml01.01.org; 
Jordan L <jordan.l.jus...@intel.com>; wol...@ml01.01.org; Jiewen Yao 
<jiewen@intel.com>; Ayellet <ayellet.wol...@intel.com>; Michael D 
<michael.d.kin...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Star Zeng 
<star.z...@intel.com>
Subject: [edk2] [PATCH 1/4] MdeModulePkg/Core: Implement NULL pointer detection 
in EDK-II Core.

The mechanism behind is to trigger a page fault exception at address 0. This 
can be made by disabling page 0 (0-4095) during page table setup. So this 
feature can only be available on platform with paging enabled. Once this 
feature is enabled, any code, like CSM, which has to access memory in page 0 
needs to enable this page temporarily in advance and disable it afterwards. 
PcdNullPointerDetectionPropertyMask is used to control and elaborate the use 
cases.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
---
 MdeModulePkg/Core/Dxe/DxeMain.inf|  3 +-
 MdeModulePkg/Core/Dxe/Mem/Page.c | 21 ++
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c| 47 +
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 15 +++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  3 +-
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c   | 53 
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  8 +++-
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  2 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 23 ++
 MdeModulePkg/MdeModulePkg.dec| 12 ++
 10 files changed, 167 insertions(+), 20 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index 30d5984f7c..273b8b7c0e 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -179,7 +179,7 @@
   gEfiWatchdogTimerArchProtocolGuid ## CONSUMES
 
 [FeaturePcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport   ## CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport  ## 
CONSUMES
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressBootTimeCodePageNumber## 
SOMETIMES_CONSUMES
@@ -192,6 +192,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
 
 # [Hob]
 # RESOURCE_DESCRIPTOR   ## CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index a142c79ee2..2e0b72f864 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -170,6 +170,7 @@ CoreAddRange (
 {
   LIST_ENTRY*Link;
   MEMORY_MAP*Entry;
+  EFI_STATUSStatus;
 
   ASSERT ((Start & EFI_PAGE_MASK) == 0);
   ASSERT (End > Start) ;
@@ -188,7 +189,17 @@ CoreAddRange (

Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe driver to bypass NULL pointer detection if enabled.

[Wang, Jian J]

gDS-> SetMemorySpaceCapabilities() can change the Capability at any time. But 
I'm not sure about any side-effect of it.

-Original Message-
From: Zeng, Star 
Sent: Thursday, September 14, 2017 6:17 PM
To: Laszlo Ersek <ler...@redhat.com>; Wang, Jian J <jian.j.w...@intel.com>; 
Yao, Jiewen <jiewen@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Justen, Jordan L 
<jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Dong, Eric 
<eric.d...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; Zeng, Star 
<star.z...@intel.com>
Subject: RE: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

No, I want to say even the GCD is updated to not filter page attributes, it 
will still not work as all the memory controller code for now are not reporting 
the Capability.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, September 14, 2017 5:55 PM
To: Zeng, Star <star.z...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>; 
Yao, Jiewen <jiewen@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Justen, Jordan L 
<jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Dong, Eric 
<eric.d...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

On 09/14/17 11:39, Zeng, Star wrote:
> There is a realistic problem I just found and want to share.
> 
> GCD database is built based on resource hob reported from PEI, and GCD 
> checks the input Attributes against Capabilities when setting 
> Attributes, but we (I just searched the whole codebase) can see there 
> is no code reporting resource hob with 
> EFI_RESOURCE_ATTRIBUTE_READ_PROTECTABLE,
> EFI_RESOURCE_ATTRIBUTE_EXECUTION_PROTECTABLE or 
> EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE set.
... Are you saying that, if we modify AddMemoryBaseSizeHob() in 
OvmfPkg/PlatformPei, to report EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE 
(*), then
gDS->SetMemorySpaceAttributes() will start to work?

((*) "MdePkg/Include/Pi/PiHob.h": "NOTE: Since PI spec 1.4, please use 
EFI_RESOURCE_ATTRIBUTE_READ_ONLY_PROTECTABLE as Memory capability
attribute: The memory supports being protected from processor writes")

If that's the case, then I hope Jian can include such an OvmfPkg patch in his 
series. :)

Thanks!
Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, September 14, 2017 4:54 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; Yao, Jiewen 
> <jiewen@intel.com>
> Cc: Dong, Eric <eric.d...@intel.com>; Justen, Jordan L 
> <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Wolman, Ayellet 
> <ayellet.wol...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
> driver to bypass NULL pointer detection if enabled.
> 
> On 09/14/17 10:46, Wang, Jian J wrote:
>> It’s an implementation limitation. All page attributes will be filtered out 
>> before calling CPU arch protocol to update the attributes (Gcd.c).
> 
> That cannot be a random occurrence; I'm sure there was some specific intent 
> behind filtering out the page attributes.
> 
> Does "git blame" provide a reason, from the message of the commit that added 
> the filtering?
> 
> Thanks,
> Laszlo
> 
>> From: Yao, Jiewen
>> Sent: Thursday, September 14, 2017 4:38 PM
>> To: Laszlo Ersek <ler...@redhat.com>; Wang, Jian J 
>> <jian.j.w...@intel.com>
>> Cc: Dong, Eric <eric.d...@intel.com>; Justen, Jordan L 
>> <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; Wolman, Ayellet 
>> <ayellet.wol...@intel.com>; Kinney, Michael D 
>> <michael.d.kin...@intel.com>; Zeng, Star <star.z...@intel.com>
>> Subject: RE: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
>> driver to bypass NULL pointer detection if enabled.
>>
>> HI
>> I wonder if it is spec limitation or implementation limitation.
>>
>> If it is implementation limitation, we can enhance the DxeCore to allow it.
>>
>> Thank you
>> Yao Jiewen
>>
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, September 14, 2017 4:30 PM
>> To: Wang, Jian J 
>> <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>
>> Cc: Dong, Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>;
>> Justen, Jord

Re: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU driver

[Wang, Jian J]

Thanks for catching it. Patch is on the way.

-Original Message-
From: Anthony PERARD [mailto:anthony.per...@citrix.com] 
Sent: Thursday, September 21, 2017 11:05 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>; Laszlo Ersek <ler...@redhat.com>; Dong, 
Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: Re: [edk2] [PATCH 0/2] Fixe out-of-sync issue between GCD and CPU 
driver

On Wed, Sep 20, 2017 at 07:53:36AM +, Wang, Jian J wrote:
> Jiewen,
> 
> Yes. The patch has passed the validation of the UEFI booting Windows 10, 
> Windows 7 and Fedora 25.
> 
> If no comments from you and others, I'll push the patch to upstream soon.
> 

Hi,

I think this patch series does not build, while building OVMF we have
those errors:

GNUmakefile:527: recipe for target 
'/home/osstest/build.113661.build-amd64/xen/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC49/X64/UefiCpuPkg/CpuDxe/CpuDxe/OUTPUT/Cp
uPageTable.obj' failed
make[8]: Leaving directory 
'/home/osstest/build.113661.build-amd64/xen/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC49/X64/UefiCpuPkg/CpuDxe/CpuDxe'
/home/osstest/build.113661.build-amd64/xen/tools/firmware/ovmf-dir-remote/UefiCpuPkg/CpuDxe/CpuPageTable.c:
 In function 'RefreshGcdMemoryAttributesFromPaging':
/home/osstest/build.113661.build-amd64/xen/tools/firmware/ovmf-dir-remote/UefiCpuPkg/CpuDxe/CpuPageTable.c:852:10:
 error: 'DoUpdate' may be used uninitialized in this functio
n [-Werror=maybe-uninitialized]
   if (DoUpdate) {
  ^
/home/osstest/build.113661.build-amd64/xen/tools/firmware/ovmf-dir-remote/UefiCpuPkg/CpuDxe/CpuPageTable.c:853:9:
 error: 'Capabilities' may be used uninitialized in this func
tion [-Werror=maybe-uninitialized]
 gDS->SetMemorySpaceCapabilities (BaseAddress, Length, Capabilities);
 ^
/home/osstest/build.113661.build-amd64/xen/tools/firmware/ovmf-dir-remote/UefiCpuPkg/CpuDxe/CpuPageTable.c:855:90:
 error: 'Attributes' may be used uninitialized in this funct
ion [-Werror=maybe-uninitialized]
 DEBUG ((DEBUG_INFO, "Update memory space attribute: [%02d] %016lx - 
%016lx (%08lx -> %08lx)\r\n",

  ^
cc1: all warnings being treated as errors



Full log can be found at:
http://logs.test-lab.xenproject.org/osstest/logs/113661/build-amd64/6.ts-xen-build.log

Regards,

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

Re: [edk2] [PATCH 1/4] MdeModulePkg/Core: Implement NULL pointer detection in EDK-II Core.

[Wang, Jian J]

It's a tab character in old version. It may look like the same if your tab 
width is to a certain number. In my editor, it looks unaligned. Sometimes I 
just can't resist the temptation to fix the tab:)   I'll restore it to avoid 
irrelevant changes in next patch update.

-Original Message-
From: Justen, Jordan L 
Sent: Thursday, September 14, 2017 2:34 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>; Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
Subject: RE: [PATCH 1/4] MdeModulePkg/Core: Implement NULL pointer detection in 
EDK-II Core.

On 2017-09-13 18:25:22, Wang, Jian J wrote:
> See my comments start with [Jian] below.
> 
> -Original Message-
> From: Justen, Jordan L 
> Sent: Thursday, September 14, 2017 1:28 AM
> 
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
> > b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > index 30d5984f7c..273b8b7c0e 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain.inf
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > @@ -179,7 +179,7 @@
> >gEfiWatchdogTimerArchProtocolGuid ## CONSUMES
> >  
> >  [FeaturePcd]
> > -  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport 
> > ## CONSUMES
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport  
> > ## CONSUMES
> 
> Why is this line changed?
> [Jian] Just align the comment followed because the new one added

I was looking in the patch, and it didn't look like it was now aligned
with the comments above or below. (It is 1 column less than the
section below, right?)

My opinion is to not change the line since it is in a separate section
of the inf file.

-Jordan

> 
> >  
> >  [Pcd]
> >gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressBootTimeCodePageNumber   
> >  ## SOMETIMES_CONSUMES
> > @@ -192,6 +192,7 @@
> >gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable  
> >  ## CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy  
> >  ## CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy
> >  ## CONSUMES
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask   
> >  ## CONSUMES
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe driver to bypass NULL pointer detection if enabled.

[Wang, Jian J]

Sure. I'll change them to functions.

-Original Message-
From: Justen, Jordan L 
Sent: Thursday, September 14, 2017 1:50 PM
To: Wang, Jian J <jian.j.w...@intel.com>; Laszlo Ersek <ler...@redhat.com>
Cc: edk2-devel@lists.01.org; Dong, Eric <eric.d...@intel.com>; Kinney, Michael 
D <michael.d.kin...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; 
Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
driver to bypass NULL pointer detection if enabled.

On 2017-09-13 18:17:26, Wang, Jian J wrote:
> Thanks for the comments and good advices. Sorry the format issues.
> This is my first patch for this project. Too many details for me to get 
> familiar with. 
> 
> (1) Sure.
> (2) I'll change that.
> (3) I'll use the tool to ensure the patch format.
> (4) I'll remove the ',' in name
> (5) I'll add more description about it.
> (6) You're right. I should use SetMemorySpaceAttributes() of DXE service
>  instead. The only reason I didn't do it is that I found 
>   GetMemorySpaceDescriptor() doesn't return the same information
>  which SetMemorySpaceAttributes() just changed. So I feel using CPU
> arch protocol is a bit safer. Anyway, I'll change it.
> (7) I did put those macros in the install function before. To reduce the
>  number of changed files, I made current changes. You're right it's
>  not worthy.
> (8) Using macro can help the readability, which is more important to me.
> I know function can do the same. But it looks a bit heavy in this 
> situation.

A macro can sometimes help readibility if it is doing a very common
task. I see the macros are only being used in 2 places. (Once each.)

In this case I would prefer you to just write the code all out rather
than using macros. I don't think it will make the code that much
bigger in this case, and it'll be easier to know what the code is
actually doing.

-Jordan

> I have to admit replacing  the macros with a library is a very good idea, 
>  
> which brings the same readability. I didn't think of that before. 
> Although 
> Library is still a little bit heavy to me but it's in a different way, I 
> think it 
> worth a trying.
> (9) Putting a space before open parenthesis is forced style? If so, I'll add 
> it.
> (10) You're right. Using library can reduce the disturbs to affected drivers
>by this feature to the minimum.
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Thursday, September 14, 2017 7:35 AM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org; Justen, Jordan L <jordan.l.jus...@intel.com>; 
> Dong, Eric <eric.d...@intel.com>; Kinney, Michael D 
> <michael.d.kin...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>; 
> Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe 
> driver to bypass NULL pointer detection if enabled.
> 
> Hi,
> 
> some of the points I'm going to make have already been pointed out by
> Jordan:
> 
> (1) When posting a patch series, please collect the Cc: tags from all of
> the patches, and add them *all* to the cover letter. This way everyone
> will get a personal copy of the general description.
> 
> 
> (2) The subject line is too long. One possible simplification:
> 
> OvmfPkg/QemuVideoDxe: bypass NULL pointer detection
> 
> 
> On 09/13/17 11:25, Wang, Jian J wrote:
> > QemuVideoDxe driver will install VBE SHIM into page 0. If NULL pointer
> > detection is enabled, page 0 must be enabled temporarily before
> > installing and disabled again afterwards. For Windows 7 boot, BIT7 of
> > PcdNullPointerDetectionPropertyMask must still be set to avoid hang.
> 
> (3) Subject line and commit message both should not exceed 74 characters
> line length. (Not sure how many chars PatchCheck.py actually enforces, I
> always stick with 74, following the Linux kernel tradition.)
> 
> I rewrapped the commit message here for readability.
> 
> 
> >
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
> > Cc: Kinney, Michael D <michael.d.kin...@intel.com>
> > Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
> > Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wang, Jian 

Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Wang, Jian J]

Got it. Thank you very much for the advice and information.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, October 10, 2017 4:13 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>; Yao, Jiewen <jiewen@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL
> pointer detection during VBE SHIM installing
> 
> On 10/10/17 03:50, Wang, Jian J wrote:
> > I have summary in each patch email.
> 
> Sure, you have a commit message, but you didn't point out any v3->v4
> changes. (If there are no v3->v4 changes, then please pick up the R-b's
> received for v3.)
> 
> > I removed the CC of some patches because
> > there's no update from v3 to v4. I thought this could remind you of this
> situation.
> > What's the recommended way? Keep the CC as-was and just add summaries in
> > cover letter?
> 
> Maintainers should always be CC'd, even if there are no changes relative
> to the previous version.
> 
> Personally I prefer summarizing the changes in the cover letter, and
> also explaining the changes in more detail -- or pointing out the lack
> of any changes -- on each individual patch.
> 
> If you have a bit of time for reading, I recommend the following wiki
> article:
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers
> 
> In it, I had written down most everything that I have in mind about the
> edk2 development process. The following steps pertain to the current
> discussion (i.e., picking up feedback tags, adding Maintainer CC's, and
> pointing out changes per patch):
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers#contrib-18
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers#contrib-28
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers#contrib-30
> 
> Thanks,
> Laszlo
> 
> 
> >
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Monday, October 09, 2017 11:56 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>; Yao, Jiewen <jiewen@intel.com>; Dong,
> Eric
> >> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> >> Subject: Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL
> >> pointer detection during VBE SHIM installing
> >>
> >> On 10/09/17 17:54, Laszlo Ersek wrote:
> >>> On 10/09/17 16:17, Jian J Wang wrote:
> >>>> QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
> >>>> detection is enabled, this driver will fail to load. NULL pointer 
> >>>> detection
> >>>> bypassing code is added to prevent such problem during boot.
> >>>>
> >>>> Please note that Windows 7 will try to access VBE SHIM during boot if 
> >>>> it's
> >>>> installed, and then cause boot failure. This can be fixed by setting BIT7
> >>>> of PcdNullPointerDetectionPropertyMask to disable NULL pointer
> detection
> >>>> after EndOfDxe. As far as we know, there's no other OSs has such issue.
> >>>>
> >>>> 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>
> >>>> Cc: Ayellet Wolman <ayellet.wol...@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>
> >>>> ---
> >>>>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  1 +
> >>>>  OvmfPkg/QemuVideoDxe/VbeShim.c| 14 ++
> >>>>  2 files changed, 15 insertions(+)
> >>>>
> >>>> diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >> b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> 

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

[Wang, Jian J]

Ok. I'll change it to follow required coding style. Thanks for catching it.

> -Original Message-
> From: Dong, Eric
> Sent: Friday, October 13, 2017 9:27 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Yao, Jiewen <jiewen@intel.com>;
> Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> <ayellet.wol...@intel.com>
> Subject: RE: [PATCH 2/5] MdeModulePkg/PiSmmCore: Implement heap guard
> feature for SMM mode
> 
> Hi Jian,
> 
> I think below code not follow EDKII coding style, EDKII requires definition 
> and
> assignment in different code.
> 
> +  UINTN   LevelShift[GUARDED_HEAP_MAP_TABLE_DEPTH]
> += GUARDED_HEAP_MAP_TABLE_DEPTH_SHIFTS;
> +  UINTN   LevelMask[GUARDED_HEAP_MAP_TABLE_DEPTH]
> += GUARDED_HEAP_MAP_TABLE_DEPTH_MASKS;
> 
> Thanks,
> Eric
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, October 11, 2017 11:18 AM
> > 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>; Wolman, Ayellet
> > <ayellet.wol...@intel.com>
> > Subject: [PATCH 2/5] MdeModulePkg/PiSmmCore: Implement heap guard
> > feature for SMM mode
> >
> > 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 EfiBootServicesData
> > and EfiRuntimeServicesData by setting the PCD with value 0x50.
> >
> > 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>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Michael Kinney <michael.d.kin...@intel.com>
> > Cc: Ayellet Wolman <ayellet.wol...@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/Core/PiSmmCore/Misc/HeapGuard.c | 1438
> > ++
> >  MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.h |  395 +++
> >  MdeModulePkg/Core/PiSmmCore/Misc/PageTable.c |  704
> > +
> >  MdeModulePkg/Core/PiSmmCore/Misc/PageTable.h |  174 
> >  MdeModulePkg/Core/PiSmmCore/Page.c   |   51 +-
> >  MdeModulePkg/Core/PiSmmCore/PiSmmCore.c  |   12 +-
> >  MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  |   80 +-
> >  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf|8 +
> >  MdeModulePkg/Core/PiSmmCore/Pool.c   |   77 +-
> >  9 files changed, 2911 insertions(+), 28 deletions(-)
> >  create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
> >  create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.h
> >  create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.c
> >  create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.h
> >
> > diff --git a/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
> > b/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
> > new file mode 100644
> > index 00..c64eaea5d1
> > --- /dev/null
> > +++ b/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
> > @@ -0,0 +1,1438 @@
> > +/** @file
> > +  UEFI Heap Guard functions.
> > +
> > +Copyright (c) 2017, Intel Corporation. All

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

[Wang, Jian J]

You're right. "BIT3 | BIT2" should be enclosed by parentheses. Thanks for 
catching this issue.

> -Original Message-
> From: Dong, Eric
> Sent: Friday, October 13, 2017 9:24 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
> Subject: RE: [PATCH 5/5] UefiCpuPkg/PiSmmCpuDxeSmm: Disable page table
> protection
> 
> Hi Jian,
> 
> > +  if (!mCpuSmmStaticPageTable || (PcdGet8 (PcdHeapGuardPropertyMask)
> > &
> > + BIT3 | BIT2) != 0) {
> 
> I think above code logic is not correct, the "&" will be handled before the 
> "|"
> which is not an expected order, right?
> 
> Thanks,
> Eric
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, October 11, 2017 11:18 AM
> > To: edk2-devel@lists.01.org
> > Cc: Dong, Eric <eric.d...@intel.com>; Yao, Jiewen <jiewen@intel.com>;
> > Kinney, Michael D <michael.d.kin...@intel.com>; Wolman, Ayellet
> > <ayellet.wol...@intel.com>
> > Subject: [PATCH 5/5] UefiCpuPkg/PiSmmCpuDxeSmm: Disable page table
> > protection
> >
> > 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>
> > Cc: Michael Kinney <michael.d.kin...@intel.com>
> > Cc: Ayellet Wolman <ayellet.wol...@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/PiSmmCpuDxeSmm.inf | 1 +
> >  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 2 +-
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> > index 099792e6ce..644709650c 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> > @@ -159,6 +159,7 @@
> >gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStaticPageTable   ##
> > CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable   ##
> > CONSUMES
> >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrM
> > ask## CONSUMES
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
> > ## CONSUMES
> >
> >  [Depex]
> >gEfiMpServiceProtocolGuid
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> > index 3dde80f9ba..4debce3a0f 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> > @@ -902,7 +902,7 @@ SetPageTableAttributes (
> >BOOLEAN   IsSplitted;
> >BOOLEAN   PageTableSplitted;
> >
> > -  if (!mCpuSmmStaticPageTable) {
> > +  if (!mCpuSmmStaticPageTable || (PcdGet8 (PcdHeapGuardPropertyMask)
> > &
> > + BIT3 | BIT2) != 0) {
> >  return ;
> >}
> >
> > --
> > 2.14.1.windows.1

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

[edk2] ASSERT in QemuVideoDxe driver during reset

[Wang, Jian J]

Hi guys,

I found an ASSERT issue in function InstallVbeShim() in QemuVideoDxe driver 
during reset. The assert statement is like below.

ASSERT (Int0x10->Segment == 0x);
ASSERT (Int0x10->Offset  == 0x);

This happened after I have enabled NULL pointer access detection feature, in 
which page 0 (4K)  is disabled. And because of page 0 disabled, I have to skip 
the memory clearing for page 0 in DXE core. Otherwise it will cause page fault 
exception there. It seems that QEMU may clear all its memory at startup. 
Skipping the action of clearing page 0 in core won't cause ASSERT issue in 
QemuVideoDxe, for the first time boot. But QemuVideoDxe will write int10 vector 
at memory 0x10 and QEMU will not clear all its memory during warm boot. ASSERT 
will be triggered after reset.

It's easy to fix this issue but there're some subtle situations which I'm not 
quite certain. I'd like your opinions for them.

Here're my thoughts on several solutions:
a) Remove the ASSERT statement in InstallVbeShim(). But I'm sure if it is safe 
to do so because I don't quite understand the purpose of the ASSERT. 
b) Instead of skipping clearing page 0, enable it, do clearing and then disable 
it. The problem here is that CPU arch protocol is not ready at that time. I 
have to "manually" do page operation, which might be non-portable and a little 
bit odd in DXE core.
c) Move code clearing page 0 from DXE core to another place wherever 
appropriate, like DxeIpl or cpu driver. But I think there's a good reason to 
put code there before.

Thanks,
Wang, Jian J
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] ASSERT in QemuVideoDxe driver during reset

[Wang, Jian J]

Hi Jiewen and Laszlo,

According to both of your comments:


1.  VBE SHIM must be installed to avoid boot failure of Windows 7.

2.  Enabling NULL detection should not break existing platforms.

Let me clarify a few things in advance. I think there’s a little 
misunderstanding on this issue (Sorry for my poor description originally).

1.  NULL detection is implemented by disable first 4K page (0-4095). Let me 
call it page 0.

2.  The ASSERT was not caused by accessing page 0. I do enabling page 0 
before access int10 vector in QemuVideoDxe driver while NULL detection is 
enabled.

3.  The ASSERT will only be triggered by reset because QemuVideoDxe will write 
int10 vector and memory at that place keeps intact during reset.

4.  The root cause of ASSERT is the fact that page 0 is always cleared in DXE 
core except to NULL detection enabled. I changed CoreAddRange() in page.c in 
DXC core like below to avoid page fault in core.
//
  // If memory of type EfiConventionalMemory is being added that includes the 
page
  // starting at address 0, then zero the page starting at address 0.  This has
  // two benifits.  It helps find NULL pointer bugs and it also maximizes
  // compatibility with operating systems that may evaluate memory in this page
  // for legacy data structures.  If memory of any other type is added starting
  // at address 0, then do not zero the page at address 0 because the page is 
being
  // used for other purposes.
  //
  if (Type == EfiConventionalMemory && Start == 0 && (End >= EFI_PAGE_SIZE - 
1)) {
if ((PcdGet8(PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
  SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
}
  }

I think the best solution at present is to update above code to make sure page 
0 is always cleared no matter NULL detection is enable or not. To make it 
possible, I have to enable page 0 before memory clearing and disable it again 
after then. My concern is that I cannot use CPU arch protocol to do so in 
CoreAddRange() function because it’s not ready at that time. There’re two 
options here. One is “manually” disabling page 0 (read cr3, then pm4l, then 
pde…) in above code; another is moving above code to another place where paging 
operation is at hand, like DxeIpl or CPU driver. My personal opinion is second 
one would be better. What’s your opinions? Or any better ideas?

Thanks,
Wang, Jian J

From: Yao, Jiewen
Sent: Wednesday, September 06, 2017 7:17 PM
To: Laszlo Ersek <ler...@redhat.com>; Wang, Jian J <jian.j.w...@intel.com>; 
Justen, Jordan L <jordan.l.jus...@intel.com>
Cc: edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: RE: ASSERT in QemuVideoDxe driver during reset

HI
I think the NULL detection feature should *never* break any existing platform.
No real function should be skipped for PcdNullDetection.

If InstallVbeShim () is needed for CSM, we should always call InstallVbeShim() 
for CSM.

I suggest below options:

1)  In OVMF, if CSM is enabled, disable PcdNullDetection.

2)  In OVMF, if any driver need access first 4K page, the code should 
explicit call SetAttribute(0, 4K, READ|WRITE), if PcdNullDetection is enabled.

Either #1 or #2 is OK.
#1 is simple, and #2 can help detect more potential issue.

Thank you
Yao Jiewen

From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, September 6, 2017 6:21 PM
To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>; Justen, 
Jordan L <jordan.l.jus...@intel.com<mailto:jordan.l.jus...@intel.com>>; Yao, 
Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D 
<michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
Subject: Re: ASSERT in QemuVideoDxe driver during reset

On 09/06/17 10:15, Wang, Jian J wrote:
> Hi guys,
>
> I found an ASSERT issue in function InstallVbeShim() in QemuVideoDxe
> driver during reset. The assert statement is like below.
>
> ASSERT (Int0x10->Segment == 0x);
> ASSERT (Int0x10->Offset  == 0x);
>
> This happened after I have enabled NULL pointer access detection
> feature, in which page 0 (4K)  is disabled.

The NULL pointer access detection conflicts with the VBE shim. For
installing the VBE shim, OVMF has to write to page 0, on purpose.

Please see commit 90803342b1b6 ("OvmfPkg: QemuVideoDxe: Int10h stub for
Windows 7 & 2008 (stdvga, QXL)", 2014-05-20).

> And because of page 0 disabled, I have to skip the memory clearing for
> page 0 in DXE core.

By doing that, you invalidate the following comment in said OVMF commit:

+//
+// We managed to allocate the page at zero. SVN r14218 guarantees that it
+// is NUL-filled.
+//
+ASSERT (Int0x10->Segment == 0x);
+ASSERT (Int0x10->Offset  == 0x);

B

[edk2] [PATCH 1/4] MdeModulePkg/Core: Implement NULL pointer detection in EDK-II Core.

[Wang, Jian J]

The mechanism behind is to trigger a page fault exception at address 0. This 
can be made by disabling page 0 (0-4095) during page table setup. So this 
feature can only be available on platform with paging enabled. Once this 
feature is enabled, any code, like CSM, which has to access memory in page 0 
needs to enable this page temporarily in advance and disable it afterwards. 
PcdNullPointerDetectionPropertyMask is used to control and elaborate the use 
cases.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
---
 MdeModulePkg/Core/Dxe/DxeMain.inf|  3 +-
 MdeModulePkg/Core/Dxe/Mem/Page.c | 21 ++
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c| 47 +
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 15 +++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  3 +-
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c   | 53 
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  8 +++-
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  2 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 23 ++
 MdeModulePkg/MdeModulePkg.dec| 12 ++
 10 files changed, 167 insertions(+), 20 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index 30d5984f7c..273b8b7c0e 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -179,7 +179,7 @@
   gEfiWatchdogTimerArchProtocolGuid ## CONSUMES
 
 [FeaturePcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport  ## 
CONSUMES
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressBootTimeCodePageNumber## 
SOMETIMES_CONSUMES
@@ -192,6 +192,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
 
 # [Hob]
 # RESOURCE_DESCRIPTOR   ## CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index a142c79ee2..2e0b72f864 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -170,6 +170,7 @@ CoreAddRange (
 {
   LIST_ENTRY*Link;
   MEMORY_MAP*Entry;
+  EFI_STATUSStatus;
 
   ASSERT ((Start & EFI_PAGE_MASK) == 0);
   ASSERT (End > Start) ;
@@ -188,7 +189,17 @@ CoreAddRange (
   // used for other purposes.
   //  
   if (Type == EfiConventionalMemory && Start == 0 && (End >= EFI_PAGE_SIZE - 
1)) {
-SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
+if ((PcdGet8(PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
+  SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
+} else if (gCpu != NULL) {
+  Status = gCpu->SetMemoryAttributes(gCpu, 0, EFI_PAGE_SIZE, 0);
+  ASSERT_EFI_ERROR(Status);
+
+  SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
+
+  Status = gCpu->SetMemoryAttributes(gCpu, 0, EFI_PAGE_SIZE, 
EFI_MEMORY_RP);
+  ASSERT_EFI_ERROR(Status);
+}
   }
   
   //
@@ -1972,11 +1983,3 @@ Done:
   return Status;
 }
 
-
-
-
-
-
-
-
-
diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index a73c4ccd64..2367d674e1 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -995,6 +995,36 @@ MemoryProtectionExitBootServicesCallback (
   }
 }
 
+/**
+  Disable NULL pointer detection after EndOfDxe. This is a workaround resort 
in 
+  order to skip unfixable NULL pointer access issues detected in OptionROM or 
+  boot loaders.
+
+  @param[in]  Event The Event this notify function registered to.
+  @param[in]  Context   Pointer to the context data registered to the Event.
+**/
+VOID
+EFIAPI
+DisableNullDetectionAtTheEndOfDxe (
+  EFI_EVENT   Event,
+  VOID*Context
+  )
+{
+  EFI_STATUSStatus;
+
+  DEBUG((DEBUG_INFO, "DisableNullDetectionAtTheEndOfDxe(): start\r\n"));
+  //
+  // Disable NULL pointer detection by enabling first 4K page
+  //
+  Status = gCpu->SetMemoryAttributes(gCpu, 0, EFI_PAGE_SIZE, 0);
+  ASSERT_EFI_ERROR(St

[edk2] [PATCH 2/4] UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM mode code.

[Wang, Jian J]

The mechanism behind is the same as NULL pointer detection enabled in EDK-II 
core. SMM has its own page table and we have to disable page 0 again in SMM 
mode.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 11 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 25 -
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h   |  2 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 17 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 11 +++
 5 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index f295c2ebf2..d423958783 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -155,6 +155,17 @@ SmiPFHandler (
 }
   }
 
+  //
+  // If NULL pointer was just accessed
+  //
+  if (NULL_DETECTION_ENABLED && (PFAddress >= 0 && PFAddress < EFI_PAGE_SIZE)) 
{
+DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
+DEBUG_CODE (
+  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Rip);
+);
+CpuDeadLoop ();
+  }
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 SmmProfilePFHandler (
   SystemContext.SystemContextIa32->Eip,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index f086b97c30..81c5ac9d11 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -855,10 +855,10 @@ Gen4GPageTable (
 Pte[Index] = (Index << 21) | mAddressEncMask | IA32_PG_PS | 
PAGE_ATTRIBUTE_BITS;
   }
 
+  Pdpte = (UINT64*)PageTable;
   if (FeaturePcdGet (PcdCpuSmmStackGuard)) {
 Pages = (UINTN)PageTable + EFI_PAGES_TO_SIZE (5);
 GuardPage = mSmmStackArrayBase + EFI_PAGE_SIZE;
-Pdpte = (UINT64*)PageTable;
 for (PageIndex = Low2MBoundary; PageIndex <= High2MBoundary; PageIndex += 
SIZE_2MB) {
   Pte = (UINT64*)(UINTN)(Pdpte[BitFieldRead32 ((UINT32)PageIndex, 30, 31)] 
& ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
   Pte[BitFieldRead32 ((UINT32)PageIndex, 21, 29)] = (UINT64)Pages | 
mAddressEncMask | PAGE_ATTRIBUTE_BITS;
@@ -886,6 +886,29 @@ Gen4GPageTable (
 }
   }
 
+  if (NULL_DETECTION_ENABLED) {
+Pte = (UINT64*)(UINT64)(Pdpte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 
1));
+if ((Pte[0] & IA32_PG_PS) == 0) {
+  // 4K-page entries are already mapped. Just hide the first one anyway.
+  Pte = (UINT64*)(UINT64)(Pte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 
1));
+  Pte[0] &= ~1; // Hide page 0
+} else {
+  // Create 4K-page entries
+  Pages = (UINTN)AllocatePageTableMemory (1);
+  ASSERT (Pages != 0);
+
+  Pte[0] = (UINT64)(Pages | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
+
+  Pte = (UINT64*)Pages;
+  PageAddress = 0;
+  Pte[0] = PageAddress | mAddressEncMask; // Hide page 0 but present left
+  for (Index = 1; Index < EFI_PAGE_SIZE / sizeof (*Pte); Index++) {
+PageAddress += EFI_PAGE_SIZE;
+Pte[Index] = PageAddress | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
+  }
+}
+  }
+
   return (UINT32)(UINTN)PageTable;
 }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
index 1cf85c1481..bcb3032db8 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
@@ -153,6 +153,8 @@ typedef UINT32  
SMM_CPU_ARRIVAL_EXCEPTIONS;
 #define ARRIVAL_EXCEPTION_DELAYED   0x2
 #define ARRIVAL_EXCEPTION_SMI_DISABLED  0x4
 
+#define NULL_DETECTION_ENABLED
((PcdGet8(PcdNullPointerDetectionPropertyMask) & BIT1) != 0)
+
 //
 // Private structure for the SMM CPU module that is stored in DXE Runtime 
memory
 // Contains the SMM Configuration Protocols that is produced.
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
index 099792e6ce..57a14d9f24 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
@@ -138,14 +138,14 @@
   gEdkiiPiSmmMemoryAttributesTableGuid ## CONSUMES ## SystemTable
 
 [FeaturePcd]
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmDebug ## CONSUMES
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmBlockStartupThisAp## CONSUMES
-  gUefiCpuPkgToken

[edk2] [PATCH 3/4] IntelFrameworkModulePkg/Csm: Update CSM code to temporarily bypass NULL pointer detection if enabled.

[Wang, Jian J]

CSM code has to access memory below 4096 (BDA, int vector, etc.). If NULL 
pointer detection is enabled, the page 0 must be enabled temporarily before 
accessing it and disabled again afterwards. Otherwise page fault will be 
triggered.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
---
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 10 +++-
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   | 18 +++
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |  2 +
 .../Csm/LegacyBiosDxe/LegacyBda.c  |  4 ++
 .../Csm/LegacyBiosDxe/LegacyBios.c | 55 ++
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|  2 +
 .../Csm/LegacyBiosDxe/LegacyBiosInterface.h| 23 +
 .../Csm/LegacyBiosDxe/LegacyBootSupport.c  | 33 ++---
 .../Csm/LegacyBiosDxe/LegacyPci.c  | 17 ++-
 IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  | 41 ++--
 10 files changed, 173 insertions(+), 32 deletions(-)

diff --git a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c 
b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
index 7308523ad8..96148ae367 100644
--- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
+++ b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
@@ -248,7 +248,7 @@ BiosKeyboardDriverBindingStart (
   //
   // Allocate the private device structure
   //
-BiosKeyboardPrivate = (BIOS_KEYBOARD_DEV *) AllocateZeroPool (sizeof 
(BIOS_KEYBOARD_DEV));
+  BiosKeyboardPrivate = (BIOS_KEYBOARD_DEV *) AllocateZeroPool (sizeof 
(BIOS_KEYBOARD_DEV));
   if (NULL == BiosKeyboardPrivate) {
 Status = EFI_OUT_OF_RESOURCES;
 goto Done;
@@ -281,6 +281,9 @@ BiosKeyboardDriverBindingStart (
   BiosKeyboardPrivate->SimpleTextInputEx.UnregisterKeyNotify = 
BiosKeyboardUnregisterKeyNotify;
   InitializeListHead (>NotifyList);
 
+  Status = gBS->LocateProtocol (, NULL, (VOID **) 
>Cpu);
+  ASSERT_EFI_ERROR(Status);
+
   //
   // Report that the keyboard is being enabled
   //
@@ -1842,7 +1845,9 @@ BiosKeyboardTimerHandler (
   //
   // Clear the CTRL and ALT BDA flag
   //
-  KbFlag1 = *((UINT8 *) (UINTN) 0x417);  // read the STATUS FLAGS 1
+  DISABLE_NULL_DETECTION(BiosKeyboardPrivate);
+
+  KbFlag1 = *((UINT8 *) (UINTN) 0x417); // read the STATUS FLAGS 1
   KbFlag2 = *((UINT8 *) (UINTN) 0x418); // read STATUS FLAGS 2
 
   DEBUG_CODE (
@@ -1916,6 +1921,7 @@ BiosKeyboardTimerHandler (
   KbFlag1 &= ~0x0C;  
   *((UINT8 *) (UINTN) 0x417) = KbFlag1; 
 
+  ENABLE_NULL_DETECTION(BiosKeyboardPrivate);
   
   //
   // Output EFI input key and shift/toggle state
diff --git a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h 
b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
index 0bf28ea140..b717ef676b 100644
--- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
+++ b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
@@ -26,6 +26,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -212,6 +213,7 @@ typedef struct {
   EFI_HANDLE  Handle;
   EFI_LEGACY_BIOS_PROTOCOL*LegacyBios;
   EFI_ISA_IO_PROTOCOL *IsaIo;
+  EFI_CPU_ARCH_PROTOCOL   *Cpu;
   EFI_SIMPLE_TEXT_INPUT_PROTOCOL  SimpleTextIn;
   EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL   SimpleTextInputEx;
   UINT16  DataRegisterAddress;
@@ -242,6 +244,22 @@ typedef struct {
   BIOS_KEYBOARD_DEV_SIGNATURE \
   )
 
+//
+// CSM needs to access memory between 0-4095, which will cause page fault 
exception 
+// if NULL pointer detection mechanism is enabled. Following macros can be used
+// to disable/enable NULL pointer detection before/after accessing those 
memory.
+//
+#define NULL_POINTER_DETECTION_ENABLED  
((PcdGet8(PcdNullPointerDetectionPropertyMask) & BIT0) != 0)
+#define DISABLE_NULL_DETECTION(Instance)   
 \
+  if (NULL_POINTER_DETECTION_ENABLED && (Instance)->Cpu != NULL) { 
 \
+(Instance)->Cpu->SetMemoryAttributes((Instance)->Cpu, 0, EFI_PAGE_SIZE, 
0); \
+  }
+  
+#define ENABLE_NULL_DETECTION(Instance)
 \
+  if (NULL_POINTER_DETECTION_ENABLED && (Instance)-&g

[edk2] [PATCH 4/4] OvmfPkg/QemuVideoDxe: Update QemuVideoDxe driver to bypass NULL pointer detection if enabled.

[Wang, Jian J]

QemuVideoDxe driver will install VBE SHIM into page 0. If NULL pointer 
detection is enabled, page 0 must be enabled temporarily before installing and 
disabled again afterwards. For Windows 7 boot, BIT7 of 
PcdNullPointerDetectionPropertyMask must still be set to avoid hang.

Cc: Jiewen Yao <jiewen@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Justen, Jordan L <jordan.l.jus...@intel.com>
Cc: Kinney, Michael D <michael.d.kin...@intel.com>
Cc: Wolman, Ayellet <ayellet.wol...@intel.com>
Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
---
 OvmfPkg/QemuVideoDxe/Driver.c | 15 ++-
 OvmfPkg/QemuVideoDxe/Qemu.h   | 16 
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  2 ++
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index 0dce80e59b..ee0eed7214 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -194,6 +194,7 @@ QemuVideoControllerDriverStart (
   PCI_TYPE00Pci;
   QEMU_VIDEO_CARD   *Card;
   EFI_PCI_IO_PROTOCOL   *ChildPciIo;
+  EFI_CPU_ARCH_PROTOCOL *Cpu;
 
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
 
@@ -479,7 +480,19 @@ QemuVideoControllerDriverStart (
 #if defined MDE_CPU_IA32 || defined MDE_CPU_X64
   if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO ||
   Private->Variant == QEMU_VIDEO_BOCHS) {
-InstallVbeShim (Card->Name, Private->GraphicsOutput.Mode->FrameBufferBase);
+//
+// Prepare CPU arch protocol for NULL pointer detection
+//
+Status = gBS->LocateProtocol (
+,
+NULL, 
+(VOID **) 
+);
+ASSERT_EFI_ERROR (Status);
+
+DISABLE_NULL_DETECTION(Cpu);
+  InstallVbeShim (Card->Name, 
Private->GraphicsOutput.Mode->FrameBufferBase);
+ENABLE_NULL_DETECTION(Cpu);
   }
 #endif
 
diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index 7fbb25b3ef..bb3bc6eb0f 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -82,6 +83,21 @@ typedef struct {
 
 #define GRAPHICS_OUTPUT_INVALIDE_MODE_NUMBER  0x
 
+//
+// VBE code will access memory between 0-4095 which will cause page fault 
exception 
+// if NULL pointer detection mechanism is enabled. Following macros can be 
used to 
+// disable/enable NULL pointer detection before/after accessing those memory.
+//
+#define NULL_DETECTION_ENABLED  ((PcdGet8(PcdNullPointerDetectionPropertyMask) 
& (BIT0|BIT7)) == BIT0)
+#define DISABLE_NULL_DETECTION(Cpu)
 \
+  if (NULL_DETECTION_ENABLED) {
 \
+(Cpu)->SetMemoryAttributes((Cpu), 0, EFI_PAGE_SIZE, 0);
 \
+  }
+#define ENABLE_NULL_DETECTION(Cpu) 
 \
+  if (NULL_DETECTION_ENABLED) {
 \
+(Cpu)->SetMemoryAttributes((Cpu), 0, EFI_PAGE_SIZE, EFI_MEMORY_RP);
 \
+  }
+
 //
 // QEMU Video Private Data Structure
 //
diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf 
b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
index 7c7d429bca..5d166eb99c 100644
--- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
+++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
@@ -72,7 +72,9 @@
   gEfiGraphicsOutputProtocolGuid# PROTOCOL BY_START
   gEfiDevicePathProtocolGuid# PROTOCOL BY_START
   gEfiPciIoProtocolGuid # PROTOCOL TO_START
+  gEfiCpuArchProtocolGuid
 
 [Pcd]
   gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
 
-- 
2.14.1.windows.1

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

[edk2] [PATCH 0/4] Implement NULL pointer detection feature for special pool

[Wang, Jian J]

The mechanism behind is to trigger a page fault exception at address 0. This 
can be made by disabling page 0 (0-4095) during page table setup. So this 
feature can only be available on platform with paging enabled. Once this 
feature is enabled, any code, like CSM, which has to access memory in page 0 
needs to enable this page temporarily in advance and disable it afterwards. 
PcdNullPointerDetectionPropertyMask is used to control and elaborate the use 
cases. For example, BIT7 of this PCD must be set for Windows 7 boot on Qemu if 
BIT0 set; or boot will fail.

Wang, Jian J (4):
  Implement NULL pointer detection in EDK-II Core.
  Implement NULL pointer detection for SMM mode code.
  Update CSM code to temporarily bypass NULL pointer detection if
enabled.
  Update QemuVideoDxe driver to bypass NULL pointer detection if
enabled.

 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 10 +++-
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   | 18 +++
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |  2 +
 .../Csm/LegacyBiosDxe/LegacyBda.c  |  4 ++
 .../Csm/LegacyBiosDxe/LegacyBios.c | 55 ++
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|  2 +
 .../Csm/LegacyBiosDxe/LegacyBiosInterface.h| 23 +
 .../Csm/LegacyBiosDxe/LegacyBootSupport.c  | 33 ++---
 .../Csm/LegacyBiosDxe/LegacyPci.c  | 17 ++-
 IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  | 41 ++--
 MdeModulePkg/Core/Dxe/DxeMain.inf  |  3 +-
 MdeModulePkg/Core/Dxe/Mem/Page.c   | 21 +
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c  | 47 ++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  | 15 ++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|  3 +-
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c | 53 +
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  8 +++-
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |  2 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   | 23 ++---
 MdeModulePkg/MdeModulePkg.dec  | 12 +
 OvmfPkg/QemuVideoDxe/Driver.c  | 15 +-
 OvmfPkg/QemuVideoDxe/Qemu.h| 16 +++
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |  2 +
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 11 +
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 25 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  2 +
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   | 17 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 11 +
 28 files changed, 429 insertions(+), 62 deletions(-)

-- 
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 0/4] Implement NULL pointer detection feature for special pool

[Wang, Jian J]

My git has problem in email send. Please ignore these serial patches. I'll send 
new ones later.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
w...@ml01.01.org
Sent: Wednesday, September 13, 2017 4:45 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 0/4] Implement NULL pointer detection feature for 
special pool

The mechanism behind is to trigger a page fault exception at address 0. This 
can be made by disabling page 0 (0-4095) during page table setup. So this 
feature can only be available on platform with paging enabled. Once this 
feature is enabled, any code, like CSM, which has to access memory in page 0 
needs to enable this page temporarily in advance and disable it afterwards. 
PcdNullPointerDetectionPropertyMask is used to control and elaborate the use 
cases. For example, BIT7 of this PCD must be set for Windows 7 boot on Qemu if 
BIT0 set; or boot will fail.

Wang, Jian J (4):
  Implement NULL pointer detection in EDK-II Core.
  Implement NULL pointer detection for SMM mode code.
  Update CSM code to temporarily bypass NULL pointer detection if
enabled.
  Update QemuVideoDxe driver to bypass NULL pointer detection if
enabled.

 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 10 +++-
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   | 18 +++
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |  2 +
 .../Csm/LegacyBiosDxe/LegacyBda.c  |  4 ++
 .../Csm/LegacyBiosDxe/LegacyBios.c | 55 ++
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|  2 +
 .../Csm/LegacyBiosDxe/LegacyBiosInterface.h| 23 +
 .../Csm/LegacyBiosDxe/LegacyBootSupport.c  | 33 ++---
 .../Csm/LegacyBiosDxe/LegacyPci.c  | 17 ++-
 IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  | 41 ++--
 MdeModulePkg/Core/Dxe/DxeMain.inf  |  3 +-
 MdeModulePkg/Core/Dxe/Mem/Page.c   | 21 +
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c  | 47 ++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  | 15 ++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|  3 +-
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c | 53 +
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  8 +++-
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |  2 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   | 23 ++---
 MdeModulePkg/MdeModulePkg.dec  | 12 +
 OvmfPkg/QemuVideoDxe/Driver.c  | 15 +-
 OvmfPkg/QemuVideoDxe/Qemu.h| 16 +++
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |  2 +
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   | 11 +
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  | 25 +-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  2 +
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   | 17 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 11 +
 28 files changed, 429 insertions(+), 62 deletions(-)

-- 
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 v2 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Wang, Jian J]

You're right that there's no such need. I just saw that this driver is loaded
before EndOfDxe but missed the fact that it's actually started after that.
So BIT7 of PcdNullPointerDetectionPropertyMask is enough.

And thanks a lot for other feedbacks in another emails, especially for the 
catching of potential attributes overridden issue, which also exists in other 
part of code. 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, September 22, 2017 11:29 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>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>
> Subject: Re: [PATCH v2 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer
> detection during VBE SHIM installing
> 
> On 09/22/17 13:50, Laszlo Ersek wrote:
> > This patch looks great to me, I would like to request a few small
> > updates:
> >
> > On 09/21/17 07:20, Jian J Wang wrote:
> >> QemuVideoDxe driver will install VBE SHIM into page 0. If NULL pointer
> >
> > (1) please replace the word "install" with "link".
> >
> > The VBE Shim is technically installed into the "real-mode" C segment,
> > only the int 0x10 vector lives in page 0.
> >
> >> detection is enabled, this driver will fail to load. NULL pointer detection
> >> bypassing code is added to prevent such problem during boot.
> >>
> >> Please note that Windows 7 will try to access VBE SHIM during boot if it's
> >> installed, and then cause boot failure. This can be fixed by setting BIT7
> >> of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
> >> after EndOfDxe. As far as we know, there's no other OSs has such issue.
> >
> > This is not a request, just a comment: I verified the default value in
> > the .dec, and I see it is 0. So there's no need to post an additional
> > patch for the OVMF DSC files, in order to set BIT7.
> 
> Actually, let me take a step back, and re-think the necessity of all
> this work for QemuVideoDxe!
> 
> The facts are:
> 
> (1) The *only* purpose of the VBE Shim is to allow Windows 7 to boot in
> pure UEFI mode (i.e. without a CSM).
> 
> (2) If I understand correctly, you guys have verified that Windows 7
> cannot boot with the page0 protection enabled, *regardless* of what we
> do in QemuVideoDxe. Can you confirm this please?
> 
> With the above in mind, let's consider the effects of the
> "PcdNullPointerDetectionPropertyMask" bits:
> 
> * BIT0 clear:
>   - The page0 protection is completely disabled.
>   - This patch does nothing, in effect.
>   - The VBE Shim works.
>   - Windows 7 boots.
> 
> * BIT0 set, BIT7 also set:
>   - The page0 protection is disabled in the DXE core at the end of DXE.
>   - This patch does nothing, in effect.
>   - The VBE Shim works, because it is a UEFI driver, and it connects its
> devices (and installs the shim) after End-of-Dxe, at which point
> page0 protection is no longer in effect.
>   - Windows 7 boots fine, again because it is loaded after End-of-Dxe.
> 
> * BIT0 set, BIT7 clear:
>   - The page0 protection is never disabled until the OS (loader)
> installs its own page tables.
>   - This patch enables the VBE Shim to work, by temporarily disabling
> page0 protection.
>   - However, Windows 7 will fail to boot nonetheless, because it cannot
> cope with page0 protection. (This is fact (2).)
> 
> Now, if you consider fact (1) as well: given that Windows 7 cannot boot
> with page0 protection enabled *anyway*, why mess with the VBE Shim at
> all?
> 
> How about the following patch instead:
> 
> > diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c
> b/OvmfPkg/QemuVideoDxe/VbeShim.c
> > index e45a08e8873f..8ba5522cde3c 100644
> > --- a/OvmfPkg/QemuVideoDxe/VbeShim.c
> > +++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
> > @@ -75,6 +75,20 @@ InstallVbeShim (
> >UINTNPrinted;
> >VBE_MODE_INFO*VbeModeInfo;
> >
> > +  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == 
> > BIT0)
> {
> > +DEBUG ((
> > +  DEBUG_WARN,
> > +  "%a: page 0 protected, not installing VBE shim\n",
> > +  __FUNCTION__
> > +  ));
> > +DEBUG ((
> > +  DEBUG_WARN,
> > +  "%a: page 0 protection prevents Windows 7 from booting anyway\n",
> > +  __FUNCTION__
> > +  ));
> > +return;
> > +  }
> > +
> >Segment0 = 0x0;
> >SegmentC = 0xC;
> >SegmentF = 0xF;
> 
> 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/DxeIpl: Implement NULL pointer detection

[Wang, Jian J]

Good catch. Thanks for the feedback.

> -Original Message-
> From: Yao, Jiewen
> Sent: Monday, September 25, 2017 4:51 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>; Laszlo
> Ersek <ler...@redhat.com>; Kinney, Michael D <michael.d.kin...@intel.com>;
> Justen, Jordan L <jordan.l.jus...@intel.com>; Wolman, Ayellet
> <ayellet.wol...@intel.com>
> Subject: RE: [PATCH v2 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> detection
> 
> Hi
> I do not think NULL pointer is related to NX.
> As long as NullPointer PCD is true and IA32PAE is supported, we can build page
> table.
> 
> +BuildPageTablesIa32Pae = (BOOLEAN) (IsIa32PaeSupport ()
> +&& IsExecuteDisableBitAvailable ()
> +&& (PcdGetBool (PcdSetNxForStack)
> +        || IsNullDetectionEnabled ()));
> 
> 
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, September 21, 2017 1:20 PM
> > To: edk2-devel@lists.01.org
> > Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Laszlo
> > Ersek <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>; Kinney,
> > Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
> > <jordan.l.jus...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
> > Subject: [PATCH v2 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> > detection
> >
> > NULL pointer detection is done by making use of paging mechanism of CPU.
> > During page table setup, if enabled, the first 4-K page (0-4095) will be
> > marked as NOT PRESENT. Any code which unintentionally access memory
> > between
> > 0-4095 will trigger a Page Fault exception which warns users that there's
> > potential illegal code in BIOS.
> >
> > This also means that legacy code which has to access memory between 0-
> 4095
> > should be cautious to temporarily disable this feature before the access
> > and re-enable it afterwards; or disalbe this feature at all.
> >
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Michael Kinney <michael.d.kin...@intel.com>
> > Cc: Jordan Justen <jordan.l.jus...@intel.com>
> > Cc: Ayellet Wolman <ayellet.wol...@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/Core/DxeIplPeim/DxeIpl.h| 25 +
> >  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  1 +
> >  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c   | 65
> > 
> >  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 11 +++-
> >  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  2 +
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 31 ---
> >  6 files changed, 126 insertions(+), 9 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> > b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> > index 72d2532f50..1654bcd2dc 100644
> > --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> > +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> > @@ -240,4 +240,29 @@ 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 HoStart The start of HobList passed to DxeCore.
> > +
> > +**/
> > +VOID
> > +ClearLegacyMemory (
> > +  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/DxeIpl.inf
> > b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> > index c54afe4aa6..9d0e76a293 100644
> > --- a/MdeModulePkg

Re: [edk2] [PATCH v2 1/6] MdeModulePkg/MdeModulePkg.dec: Add NULL pointer detection PCD

[Wang, Jian J]

Sure. Thanks for the feedback.

> -Original Message-
> From: Zeng, Star
> Sent: Monday, September 25, 2017 4:01 PM
> 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>; Yao,
> Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>; Zeng, Star
> <star.z...@intel.com>; Gao, Liming <liming@intel.com>
> Subject: RE: [PATCH v2 1/6] MdeModulePkg/MdeModulePkg.dec: Add NULL
> pointer detection PCD
> 
> You may need also add PcdNullPointerDetectionPropertyMask prompt and help
> into the MdeModulePkg.uni.
> 
> 
> Thanks,
> Star
> -Original Message-----
> From: Wang, Jian J
> Sent: Thursday, September 21, 2017 1:20 PM
> To: 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>; Laszlo Ersek <ler...@redhat.com>; Yao,
> Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>
> Subject: [PATCH v2 1/6] MdeModulePkg/MdeModulePkg.dec: Add NULL pointer
> detection PCD
> 
> From: "Wang, Jian J" <jian.j.w...@intel.com>
> 
> PCD PcdNullPointerDetectionPropertyMask is a bitmask used to control the
> NULL address detection functionality in code for different phases.
> 
> If enabled, accessing NULL address in UEFI or SMM code can be caught as a
> page fault exception.
> 
> BIT0- Enable NULL pointer detection for UEFI.
> BIT1- Enable NULL pointer detection for SMM.
> BIT2..6 - Reserved for future uses.
> 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 exception caused by legacy memory (0-4095) access
>   after EndOfDxe, such as Windows 7 boot on Qemu.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Ayellet Wolman <ayellet.wol...@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/MdeModulePkg.dec | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec index 403a66a5ad..3f90b8d7e6 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -863,6 +863,19 @@
># @ValidList  0x8006 | 0x03058002
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdErrorCodeSetVariable|0x03058002|UIN
> T32|0x30001040
> 
> +  ## Mask to control the NULL address detection in code for different phases.
> +  #  If enabled, accessing NULL address in UEFI or SMM code can be
> caught.
> +  #BIT0- Enable NULL pointer detection for UEFI.
> +  #BIT1- Enable NULL pointer detection for SMM.
> +  #BIT2..6 - Reserved for future uses.
> +  #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
> +  #  exception caused by legacy memory (0-4095) access after 
> EndOfDxe,
> +  #  such as Windows 7 boot on Qemu.
> +  # @Prompt Enable NULL address detection.
> +
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask|0x0
> + |UINT8|0x30001050
> +
>  [PcdsFixedAtBuild, PcdsPatchableInModule]
>## Dynamic type PCD can be registered callback function for Pcd setting 
> action.
>#  PcdMaxPeiPcdCallBackNumberPerPcdEntry indicates the maximum number
> of callback function
> --
> 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] UefiCpuPkg/CpuDxe: Fix assert issue on IA32 platform

[Wang, Jian J]

Mike,

Thanks for the feedback. I'll update the patch as what you suggested. And if no 
more other comments, I'll check in the updated one today (or tonight).

Jian

> -Original Message-
> From: Kinney, Michael D
> Sent: Saturday, September 30, 2017 12:27 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>
> Subject: RE: [PATCH] UefiCpuPkg/CpuDxe: Fix assert issue on IA32 platform
> 
> Jian,
> 
> The names of the functions do not look right to me.
> 
> I think the checks being made check to see if paging
> is enabled.  Also, the check being made is to see if both
> paging is enabled and page address extensions is enabled.
> 
> If you use the IA32_CR0 and IA32_CR4 structures from
> BaseLib.h, the updates will also be easier to understand
> than using BITxx macros.
> 
> Maybe use the following:
> 
> 
> BOOLEAN
> IsPagingAndPageAddressExtensionsEnabled (
>   VOID
>   )
> {
>   IA32_CR0  Cr0;
>   IA32_CR4  Cr4;
> 
>   Cr0.UintN = AsmReadCr0 ();
>   Cr4.UintN = AsmReadCr4 ();
>   return ((Cr0.Bits.PG != 0) && (Cr4.Bits.PAE != 0));
> }
> 
> Best regards,
> 
> Mike
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, September 28, 2017 10:40 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > Subject: [PATCH] UefiCpuPkg/CpuDxe: Fix assert issue on IA32
> > platform
> >
> > This patch is to fix an assert issue during booting IA32
> > platforms
> > such as OvmfIa32 or Quark. This issue is caused by trying to
> > access
> > page table on a platform without page table. A check is added
> > to
> > avoid the assert.
> >
> > Bug tracker: https://bugzilla.tianocore.org/show_bug.cgi?id=724
> >
> > c: Star Zeng <star.z...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Michael Kinney <michael.d.kin...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/CpuDxe/CpuDxe.c | 48
> > --
> >  1 file changed, 38 insertions(+), 10 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c
> > b/UefiCpuPkg/CpuDxe/CpuDxe.c
> > index 4e8fa100e0..85a520079f 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuDxe.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
> > @@ -683,7 +683,7 @@ SetGcdMemorySpaceAttributes (
> >
> >  **/
> >  VOID
> > -RefreshGcdMemoryAttributes (
> > +RefreshMemoryAttributesFromMtrr (
> >VOID
> >)
> >  {
> > @@ -704,14 +704,9 @@ RefreshGcdMemoryAttributes (
> >UINT32
> > FirmwareVariableMtrrCount;
> >UINT8   DefaultMemoryType;
> >
> > -  if (!IsMtrrSupported ()) {
> > -return;
> > -  }
> > -
> >FirmwareVariableMtrrCount = GetFirmwareVariableMtrrCount ();
> >ASSERT (FirmwareVariableMtrrCount <=
> > MTRR_NUMBER_OF_VARIABLE_MTRR);
> >
> > -  mIsFlushingGCD = TRUE;
> >MemorySpaceMap = NULL;
> >
> >//
> > @@ -862,11 +857,44 @@ RefreshGcdMemoryAttributes (
> >if (MemorySpaceMap != NULL) {
> >  FreePool (MemorySpaceMap);
> >}
> > +}
> >
> > -  //
> > -  // Update page attributes
> > -  //
> > -  RefreshGcdMemoryAttributesFromPaging();
> > +/**
> > + Check if paging is enabled or not.
> > +**/
> > +BOOLEAN
> > +IsPagingSupported (
> > +  VOID
> > +  )
> > +{
> > +  return (
> > +  (AsmReadCr0 () & BIT31) != 0
> > +  &&
> > +  (AsmReadCr4 () & BIT5) != 0
> > + );
> > +}
> > +
> > +/**
> > +  Refreshes the GCD Memory Space attributes according to MTRRs
> > and Paging.
> > +
> > +  This function refreshes the GCD Memory Space attributes
> > according to MTRRs
> > +  and page tables.
> > +
> > +**/
> > +VOID
> > +RefreshGcdMemoryAttributes (
> > +  VOID
> > +  )
> > +{
> > +  mIsFlushingGCD = TRUE;
> > +
> > +  if (IsMtrrSupported ()) {
> > +RefreshMemoryAttributesFromMtrr ();
> > +  }
> > +
> > +  if (IsPagingSupported ()) {
> > +RefreshGcdMemoryAttributesFromPaging ();
> > +  }
> >
> >mIsFlushingGCD = FALSE;
> >  }
> > --
> > 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] UefiCpuPkg/CpuDxe: Add missing function description comments

[Wang, Jian J]

Thanks for adding the comment. It look good to me.

> -Original Message-
> From: Bi, Dandan
> Sent: Monday, September 25, 2017 2:01 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>
> Subject: [patch] UefiCpuPkg/CpuDxe: Add missing function description
> comments
> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.h b/UefiCpuPkg/CpuDxe/CpuDxe.h
> index a25b35c..9c0d223 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.h
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.h
> @@ -263,10 +263,13 @@ VOID
>  EFIAPI
>  SetDataSelectors (
>UINT16 Selector
>);
> 
> +/**
> +  Update GCD memory space attributes according to current page table setup.
> +**/
>  VOID
>  RefreshGcdMemoryAttributesFromPaging (
>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 v3 3/6] MdeModulePkg/Core/Dxe: Add EndOfDxe workaround

[Wang, Jian J]

Thanks for the feedback. Please see my comments below.

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, September 28, 2017 11:35 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>; Yao,
> Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH v3 3/6] MdeModulePkg/Core/Dxe: Add EndOfDxe
> workaround
> 
> Some comments to this patch.
> 
> 1. How about using lower TPL TPL_CALLBACK instead of TPL_NOTIFY for the
> notification?

I think it's safe to use TPL_CALLBACK.

> 2. Should GCD SetMemorySpaceCapabilities + SetMemorySpaceAttributes be
> used instead of gCpu->SetMemoryAttributes()?

Yes. Since the GCG out-of-sync issue has been fixed, GCD service
should be used instead.

> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, September 28, 2017 9:04 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Laszlo
> Ersek <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>; Kinney,
> Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
> Subject: [PATCH v3 3/6] MdeModulePkg/Core/Dxe: Add EndOfDxe workaround
> 
> One of issue caused by enabling NULL pointer detection is that some PCI device
> OptionROM, binary drivers and binary OS boot loaders may have NULL pointer
> access bugs, which will prevent BIOS from booting and is almost impossible to
> fix. BIT7 of PCD PcdNullPointerDetectionPropertyMask is used as a workaround
> to indicate BIOS to disable NULL pointer detection right after event
> gEfiEndOfDxeEventGroupGuid, and then let boot continue.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Ayellet Wolman <ayellet.wol...@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/Core/Dxe/DxeMain.inf |  1 +
>  MdeModulePkg/Core/Dxe/Mem/Page.c  |  4 ++-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 48
> +++
>  3 files changed, 52 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf
> b/MdeModulePkg/Core/Dxe/DxeMain.inf
> index 30d5984f7c..0a161ffd71 100644
> --- a/MdeModulePkg/Core/Dxe/DxeMain.inf
> +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
> @@ -192,6 +192,7 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable   
> ##
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   
> ##
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy
> ## CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
> ## CONSUMES
> 
>  # [Hob]
>  # RESOURCE_DESCRIPTOR   ## CONSUMES
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index a142c79ee2..0468df3171 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -188,7 +188,9 @@ CoreAddRange (
>// used for other purposes.
>//
>if (Type == EfiConventionalMemory && Start == 0 && (End >= EFI_PAGE_SIZE -
> 1)) {
> -SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
> +if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
> +  SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
> +}
>}
> 
>//
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> index a73c4ccd64..73e3b269f3 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> @@ -995,6 +995,36 @@ MemoryProtectionExitBootServicesCallback (
>}
>  }
> 
> +/**
> +  Disable NULL pointer detection after EndOfDxe. This is a workaround
> +resort in
> +  order to skip unfixable NULL pointer access issues detected in
> +OptionROM or
> +  boot loaders.
> +
> +  @param[in]  Event The Event this notify function registered to.
> +  @param[in

Re: [edk2] [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer detection

[Wang, Jian J]

>From this perspective, you're right.

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, September 28, 2017 1:10 PM
> 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>; Yao,
> Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> detection
> 
> If NULL pointer detection is disabled, the code should be behave same with
> before, and ClearLegacyMemory() is not needed to be called because DxeCore
> will behave same with before to handle the first 4K page clear , right?
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, September 28, 2017 11:55 AM
> To: Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Yao,
> Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>
> Subject: RE: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> detection
> 
> Clearing this block of memory has nothing to do with NULL pointer detection.
> I'm not sure the extra check is necessary.
> 
> > -Original Message-
> > From: Zeng, Star
> > Sent: Thursday, September 28, 2017 11:31 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>; Yao, Jiewen <jiewen@intel.com>; Kinney,
> > Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
> > <jordan.l.jus...@intel.com>; Wolman, Ayellet
> > <ayellet.wol...@intel.com>; Zeng, Star <star.z...@intel.com>
> > Subject: RE: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL
> > pointer detection
> >
> > Another comment.
> > Should IsNullDetectionEnabled() be checked before calling
> > ClearLegacyMemory()?
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Zeng, Star
> > Sent: Thursday, September 28, 2017 11:24 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>; Yao, Jiewen <jiewen@intel.com>; Kinney,
> > Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
> > <jordan.l.jus...@intel.com>; Wolman, Ayellet
> > <ayellet.wol...@intel.com>; Zeng, Star <star.z...@intel.com>
> > Subject: RE: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL
> > pointer detection
> >
> > Minor comments to this patch.
> >
> > 1. IsNullDetectionEnabled() function is put in DxeLoad.c that is
> > shared by all ARCHs, and the function is consuming
> > PcdNullPointerDetectionPropertyMask,
> > but PcdNullPointerDetectionPropertyMask is only declared in
> > "[Pcd.IA32,Pcd.X64]" in inf.
> > I am not sure whether it will cause build failure or not for non-IA32/X64 
> > ARCHs.
> >
> > 2. How about using name "ClearFirst4KPage" instead of "ClearLegacyMemory"
> > to be more clear?
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, September 28, 2017 9:04 AM
> > To: edk2-devel@lists.01.org
> > Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric
> > <eric.d...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Yao, Jiewen
> > <jiewen@intel.com>; Kinney, Michael D
> > <michael.d.kin...@intel.com>; Justen, Jordan L
> > <jordan.l.jus...@intel.com>; Wolman, Ayellet
> > <ayellet.wol...@intel.com>
> > Subject: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> > detection
> >
> > > According to Jiewen's feedback, change the page split condition for
> > > NULL pointer detection to exclude IsExecuteDisableBitAvailable()
> > > (Ia32/DxeLoadFunc.c)
> >
> > NULL pointer detection is done by making use of paging mechanism of CPU.
> > During page table setup, if enabled, the first 4-K page (0-4095) will
> > be marked as NOT PRESENT. Any code which unintentionally access memory
> > between
> > 0-4095 will trigger a Pag

Re: [edk2] [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer detection

[Wang, Jian J]

Please see my comments inline below.

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, September 28, 2017 11:24 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>; Yao,
> Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> detection
> 
> Minor comments to this patch.
> 
> 1. IsNullDetectionEnabled() function is put in DxeLoad.c that is shared by all
> ARCHs, and the function is consuming PcdNullPointerDetectionPropertyMask,
> but PcdNullPointerDetectionPropertyMask is only declared in
> "[Pcd.IA32,Pcd.X64]" in inf.
> I am not sure whether it will cause build failure or not for non-IA32/X64 
> ARCHs.
> 

You're right. The PCD should not be under this section.

> 2. How about using name "ClearFirst4KPage" instead of "ClearLegacyMemory"
> to be more clear?
> 

I prefer a bit more general name in case of potential future change.

> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, September 28, 2017 9:04 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Laszlo
> Ersek <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>; Kinney,
> Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
> Subject: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> detection
> 
> > According to Jiewen's feedback, change the page split condition for
> > NULL pointer detection to exclude IsExecuteDisableBitAvailable()
> > (Ia32/DxeLoadFunc.c)
> 
> NULL pointer detection is done by making use of paging mechanism of CPU.
> During page table setup, if enabled, the first 4-K page (0-4095) will be 
> marked as
> NOT PRESENT. Any code which unintentionally access memory between
> 0-4095 will trigger a Page Fault exception which warns users that there's
> potential illegal code in BIOS.
> 
> This also means that legacy code which has to access memory between 0-4095
> should be cautious to temporarily disable this feature before the access and 
> re-
> enable it afterwards; or disalbe this feature at all.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Ayellet Wolman <ayellet.wol...@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/Core/DxeIplPeim/DxeIpl.h| 25 +
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  1 +
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c   | 65
> 
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 11 +++-
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  2 +
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 31 ---
>  6 files changed, 126 insertions(+), 9 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> index 72d2532f50..1654bcd2dc 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> @@ -240,4 +240,29 @@ 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 HoStart The start of HobList passed to DxeCore.
> +
> +**/
> +VOID
> +ClearLegacyMemory (
> +  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/DxeIpl.inf
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> index c54afe4aa6..9d0e76a293 10

Re: [edk2] [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer detection

[Wang, Jian J]

Clearing this block of memory has nothing to do with NULL pointer detection.
I'm not sure the extra check is necessary.

> -Original Message-
> From: Zeng, Star
> Sent: Thursday, September 28, 2017 11:31 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>; Yao,
> Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> detection
> 
> Another comment.
> Should IsNullDetectionEnabled() be checked before calling
> ClearLegacyMemory()?
> 
> 
> Thanks,
> Star
> -----Original Message-
> From: Zeng, Star
> Sent: Thursday, September 28, 2017 11:24 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>; Yao,
> Jiewen <jiewen@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>;
> Wolman, Ayellet <ayellet.wol...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> detection
> 
> Minor comments to this patch.
> 
> 1. IsNullDetectionEnabled() function is put in DxeLoad.c that is shared by all
> ARCHs, and the function is consuming PcdNullPointerDetectionPropertyMask,
> but PcdNullPointerDetectionPropertyMask is only declared in
> "[Pcd.IA32,Pcd.X64]" in inf.
> I am not sure whether it will cause build failure or not for non-IA32/X64 
> ARCHs.
> 
> 2. How about using name "ClearFirst4KPage" instead of "ClearLegacyMemory"
> to be more clear?
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Thursday, September 28, 2017 9:04 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Laszlo
> Ersek <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com>; Kinney,
> Michael D <michael.d.kin...@intel.com>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Wolman, Ayellet <ayellet.wol...@intel.com>
> Subject: [PATCH v3 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer
> detection
> 
> > According to Jiewen's feedback, change the page split condition for
> > NULL pointer detection to exclude IsExecuteDisableBitAvailable()
> > (Ia32/DxeLoadFunc.c)
> 
> NULL pointer detection is done by making use of paging mechanism of CPU.
> During page table setup, if enabled, the first 4-K page (0-4095) will be 
> marked as
> NOT PRESENT. Any code which unintentionally access memory between
> 0-4095 will trigger a Page Fault exception which warns users that there's
> potential illegal code in BIOS.
> 
> This also means that legacy code which has to access memory between 0-4095
> should be cautious to temporarily disable this feature before the access and 
> re-
> enable it afterwards; or disalbe this feature at all.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Jiewen Yao <jiewen@intel.com>
> Cc: Michael Kinney <michael.d.kin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Ayellet Wolman <ayellet.wol...@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/Core/DxeIplPeim/DxeIpl.h| 25 +
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  1 +
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c   | 65
> 
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 11 +++-
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  2 +
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 31 ---
>  6 files changed, 126 insertions(+), 9 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> index 72d2532f50..1654bcd2dc 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> @@ -240,4 +240,29 @@ 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

Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

[Wang, Jian J]

1)  I think this feature should be 'FALSE' by default. I forgot to reset 
its default value. This feature makes use of page mechanism to detect NULL 
pointer. So any ARCH doesn't support paging in EDK-II can't use it. Currently 
validated platform includes VLV2 and Denlow. Let me know if all platform must 
be validated or not.

2)  It's hard to make it a dynamic feature because we need to setup page 
table for physical address 0-4095 in advance. If there's no memory alloc/free 
action after enabling this feature, there's no chance to make those change in 
page table. Then the usage of feature will be limited in such case.

From: Yao, Jiewen
Sent: Monday, August 28, 2017 11:10 AM
To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

Thank you  to enable this feature.

I have 2 comments, after a very quick review.


1)  I notice it is enabled by default 
"gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetection|TRUE".

Would you please provide the information on how many open source platforms are 
validated?
Such as, IA platform (VLV2, Quark), emu platform (OVMF, NT32)?
Or do we need validate any ARM platform?



2)  I am thinking about CSM platform. Do you think we can make it dynamic, 
as such, a platform may set the validate based upon CSM enable/disable?


Or if we need update the CSM module to patch the page table automatically? Once 
this is feature is ON.


Thank you
Yao Jiewen


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Monday, August 28, 2017 10:51 AM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Subject: [edk2] [PATCH 0/2] Implement NULL pointer detection feature
>
> This patch is the implementation of NULL pointer detection feature,
> which is one of the small features of Special Pool.
>
> Wang, Jian J (2):
>   Implement NULL pointer detection for EDK-II Core
>   Implement NULL pointer detection for EDK-II SMM Core and driver
>
>  MdeModulePkg/Core/Dxe/DxeMain.inf|  3 ++-
>  MdeModulePkg/Core/Dxe/Mem/Page.c |  5 +++--
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  1 +
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  6 --
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 26
> 
>  MdeModulePkg/MdeModulePkg.dec|  7 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 12 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 25
> ++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |  1 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 12 +++
>  10 files changed, 84 insertions(+), 14 deletions(-)
>
> --
> 2.11.0.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

[edk2] [PATCH 1/2] Implement NULL pointer detection for EDK-II Core

[Wang, Jian J]

This feature is for debug purpose which helps to detect potential
NULL pointer access in code at run-time.

Cc: Star Zeng <star.z...@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
---
 MdeModulePkg/Core/Dxe/DxeMain.inf|  3 ++-
 MdeModulePkg/Core/Dxe/Mem/Page.c |  5 +++--
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  1 +
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  6 --
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 26 
 MdeModulePkg/MdeModulePkg.dec|  7 +++
 6 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index 30d5984f7c..3d75a0014d 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -179,7 +179,8 @@
   gEfiWatchdogTimerArchProtocolGuid ## CONSUMES
 
 [FeaturePcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFrameworkCompatibilitySupport  ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetection   ## 
CONSUMES
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdLoadFixAddressBootTimeCodePageNumber## 
SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index a142c79ee2..3fe77391b7 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -185,9 +185,10 @@ CoreAddRange (
   // compatibility with operating systems that may evaluate memory in this 
page 
   // for legacy data structures.  If memory of any other type is added 
starting 
   // at address 0, then do not zero the page at address 0 because the page is 
being 
-  // used for other purposes.
+  // used for other purposes. But don't do this if NULL pointer detection 
mechanism 
+  // is used.
   //  
-  if (Type == EfiConventionalMemory && Start == 0 && (End >= EFI_PAGE_SIZE - 
1)) {
+  if (!PcdGetBool(PcdNullPointerDetection) && Type == EfiConventionalMemory && 
Start == 0 && (End >= EFI_PAGE_SIZE - 1)) {
 SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
   }
   
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index c54afe4aa6..6b4d68cfa1 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -111,6 +111,7 @@
 
 [FeaturePcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportUefiDecompress ## CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetection## CONSUMES
 
 [Pcd.IA32,Pcd.X64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable  ## 
SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index 1957326caf..d4e1b7c858 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -123,7 +123,8 @@ Create4GPageTablesIa32Pae (
 PageDirectoryPointerEntry->Bits.Present = 1;
 
 for (IndexOfPageDirectoryEntries = 0; IndexOfPageDirectoryEntries < 512; 
IndexOfPageDirectoryEntries++, PageDirectoryEntry++, PhysicalAddress += 
SIZE_2MB) {
-  if ((PhysicalAddress < StackBase + StackSize) && ((PhysicalAddress + 
SIZE_2MB) > StackBase)) {
+  if ((PcdGetBool(PcdNullPointerDetection) && PhysicalAddress == 0)
+  || ((PhysicalAddress < StackBase + StackSize) && ((PhysicalAddress + 
SIZE_2MB) > StackBase))) {
 //
 // Need to split this 2M page that covers stack range.
 //
@@ -379,7 +380,8 @@ HandOffToDxeCore (
 TopOfStack = (EFI_PHYSICAL_ADDRESS) (UINTN) ALIGN_POINTER (TopOfStack, 
CPU_STACK_ALIGNMENT);
 
 PageTables = 0;
-BuildPageTablesIa32Pae = (BOOLEAN) (PcdGetBool (PcdSetNxForStack) && 
IsIa32PaeSupport () && IsExecuteDisableBitAvailable ());
+BuildPageTablesIa32Pae = (BOOLEAN) (IsIa32PaeSupport () && 
IsExecuteDisableBitAvailable ()
+&& (PcdGetBool (PcdSetNxForStack) || 
PcdGetBool (PcdNullPointerDetection)));
 if (BuildPageTablesIa32Pae) {
   PageTables = Create4GPageTablesIa32Pae (BaseOfStack, STACK_SIZE);
   EnableExecuteDisableBit ();
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 48150be4e1..c69f889d9e 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -89,9 +89,16 @@ Split2MPageTo4K (
 // Fill in the Page Table entries
 //
 PageTableEntry->Uint64 =

[edk2] [PATCH 2/2] Implement NULL pointer detection for EDK-II SMM Core and driver

[Wang, Jian J]

This feature is for debug purpose which helps to detect potential
NULL pointer access in code at run-time in SMM mode.

Cc: Eric Dong <eric.d...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Suggested-by: Wolman, Ayellet <ayellet.wol...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang, Jian J <jian.j.w...@intel.com>
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 12 
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 25 -
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |  1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 12 
 4 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index 32ce5958c5..3ad7e9a10f 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -153,6 +153,18 @@ SmiPFHandler (
 }
   }
 
+  //
+  // If NULL pointer was just accessed
+  //
+  if (FeaturePcdGet(PcdNullPointerDetection)
+  && (PFAddress >= 0 && PFAddress < EFI_PAGE_SIZE)) {
+DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
+DEBUG_CODE (
+  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Rip);
+);
+CpuDeadLoop ();
+  }
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 SmmProfilePFHandler (
   SystemContext.SystemContextIa32->Eip,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index f086b97c30..bba716c66f 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -855,10 +855,10 @@ Gen4GPageTable (
 Pte[Index] = (Index << 21) | mAddressEncMask | IA32_PG_PS | 
PAGE_ATTRIBUTE_BITS;
   }
 
+  Pdpte = (UINT64*)PageTable;
   if (FeaturePcdGet (PcdCpuSmmStackGuard)) {
 Pages = (UINTN)PageTable + EFI_PAGES_TO_SIZE (5);
 GuardPage = mSmmStackArrayBase + EFI_PAGE_SIZE;
-Pdpte = (UINT64*)PageTable;
 for (PageIndex = Low2MBoundary; PageIndex <= High2MBoundary; PageIndex += 
SIZE_2MB) {
   Pte = (UINT64*)(UINTN)(Pdpte[BitFieldRead32 ((UINT32)PageIndex, 30, 31)] 
& ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
   Pte[BitFieldRead32 ((UINT32)PageIndex, 21, 29)] = (UINT64)Pages | 
mAddressEncMask | PAGE_ATTRIBUTE_BITS;
@@ -886,6 +886,29 @@ Gen4GPageTable (
 }
   }
 
+  if (FeaturePcdGet(PcdNullPointerDetection)) {
+Pte = (UINT64*)(UINT64)(Pdpte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 
1));
+if ((Pte[0] & IA32_PG_PS) == 0) {
+  // 4K-page entries are already mapped. Just hide the first one anyway.
+  Pte = (UINT64*)(UINT64)(Pte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 
1));
+  Pte[0] &= ~1; // Hide page 0
+} else {
+  // Create 4K-page entries
+  Pages = (UINTN)AllocatePageTableMemory (1);
+  ASSERT (Pages != 0);
+
+  Pte[0] = (UINT64)(Pages | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
+
+  Pte = (UINT64*)Pages;
+  PageAddress = 0;
+  Pte[0] = PageAddress | mAddressEncMask; // Hide page 0 but present left
+  for (Index = 1; Index < EFI_PAGE_SIZE / sizeof (*Pte); Index++) {
+PageAddress += EFI_PAGE_SIZE;
+Pte[Index] = PageAddress | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
+  }
+}
+  }
+
   return (UINT32)(UINTN)PageTable;
 }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
index 099792e6ce..e28b89bce1 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
@@ -146,6 +146,7 @@
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmProfileEnable ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmProfileRingBuffer ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmFeatureControlMsrLock ## CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetection   ## CONSUMES
 
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber## 
SOMETIMES_CONSUMES
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 32385faae4..82427e176c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -873,6 +873,18 @@ SmiPFHandler (
 }
   }
 
+  //
+  // If NULL pointer was just accessed
+  //
+  if (FeaturePcdGet(PcdNullPointerDetection)
+  && (PFAddress >= 0 && PFAddress < EFI_PAGE_SIZE)) {
+DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
+DEBUG_CODE (
+  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextX64->Rip);
+);
+CpuDeadLoop ();
+  }
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 SmmProfilePFHandler (
   SystemContext.SystemContextX64->Rip,
-- 
2.11.0.windows.1

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

[edk2] [PATCH 0/2] Implement NULL pointer detection feature

[Wang, Jian J]

This patch is the implementation of NULL pointer detection feature,
which is one of the small features of Special Pool.

Wang, Jian J (2):
  Implement NULL pointer detection for EDK-II Core
  Implement NULL pointer detection for EDK-II SMM Core and driver

 MdeModulePkg/Core/Dxe/DxeMain.inf|  3 ++-
 MdeModulePkg/Core/Dxe/Mem/Page.c |  5 +++--
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  1 +
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |  6 --
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 26 
 MdeModulePkg/MdeModulePkg.dec|  7 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 12 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 25 ++-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |  1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 12 +++
 10 files changed, 84 insertions(+), 14 deletions(-)

-- 
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 0/2] Implement NULL pointer detection feature

[Wang, Jian J]

Let me summarize the changes to this feature. If no new comments, I'll start to 
make changes to current implementation.

a) Use one PCD with bit set/clear to enable/disable this feature for different 
boot phases. To make it easier to use, I'd suggest to use the bit sequence to 
follow the boot phase sequence (bit0->bit1->bit2..bit7 ===> 
PEI->DXE->PostDxe..SMM), just like below. SMM is a little bit special so it 
consumes the MSB.

 gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
 #  BIT0 - Enable NULL pointer detection for PEI.
 #  BIT1 - Enable NULL pointer detection for DXE.
 #  BIT2 - Enable NULL pointer detection after EndOfDxe.
 #  BIT7 - Disable NULL pointer detection for SMM.

This PCD is a "fixed" PCD and all bits are cleared by default. Since this 
is a feature for debug purpose, I see no reason to make it dynamic. 

b) Add PEI and post DXE phase support. Since PEI phase requirement has been 
covered by following new bug tracker, it won't be included by current patch 
update but a separate one. Changes for Post DXE phase will be included.

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

Thanks,
Wang, Jian J

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Thursday, August 31, 2017 9:16 AM
To: Johnson, Brian (EXL - Eagan) <brian.john...@hpe.com>; af...@apple.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

Thanks.
I have filed https://bugzilla.tianocore.org/show_bug.cgi?id=687 for PEI phase, 
with suggestion from Brian Johnson and Andrew Fish.

If you share some of your PEI code to elimination the duplicated effort, that 
would be great.

Yes, we can calculate the perf data in CSM to see what is the best way to 
enable this feature. Good suggestion.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Johnson, 
Brian (EXL - Eagan)
Sent: Thursday, August 31, 2017 5:36 AM
To: af...@apple.com; Yao, Jiewen <jiewen@intel.com>
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

Jiewen,

Certainly PEI could be done later.  There's no need to get all the code in at 
once, and you have the DXE/SMM part pretty much ready to go.

I'm willing to go with a single PCD with a bitmap, or multiple PCDs.  Whatever 
seems best.

IIRC protecting page 0 in PEI involves modifying the main GCD descriptor to be 
a grows-downward variety, with a limit above page 0.  That way you get an 
exception if page 0 is accessed.  I'd have to check on the steps needed to 
release the actual code, which may take quite a while.  You may be better off 
just doing it yourself.  I'll take another look at the code to make sure I'm 
explaining this properly, though.

CSM is one of the few pieces of BIOS which has a legitimate need to access page 
0.  We get the best protection by having it enable, access, and then disable 
page 0.  But if that affects performance too badly, we may need to have it 
leave page 0 enabled.  I don't enable CSM on the platforms I work on, so it's 
not something I have much to say about.  Those who use CSM would want to weigh 
in.

Brian Johnson

-Original Message-
From: af...@apple.com<mailto:af...@apple.com> [mailto:af...@apple.com]
Sent: Wednesday, August 30, 2017 11:27 AM
To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>
Cc: Johnson, Brian (EXL - Eagan) 
<brian.john...@hpe.com<mailto:brian.john...@hpe.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>
Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature


> On Aug 30, 2017, at 7:55 AM, Yao, Jiewen 
> <jiewen@intel.com<mailto:jiewen@intel.com>> wrote:
>
> Hi Brian
> Good feedback.
> Comment in line.
>
> From: Johnson, Brian (EXL - Eagan) [mailto:brian.john...@hpe.com]
> Sent: Tuesday, August 29, 2017 11:17 PM
> 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>
> Subject: RE: [edk2] [PATCH 0/2] Implement NULL pointer detection feature
>
> Thank you for implementing this feature!  It is very  helpful for catching 
> pointer-related problems.  We have used a similar scheme on our systems for 
> years, and caught several important bugs.  Some comments:
>
> * It's possible to implement similar protections in PEI (IA32) by modifying 
> the GDT descriptors.
> [Jiewen] Enabling PEI is interesting.
> Since we are working on DXE and SMM as our first priority, can we treat the 
> PEI enabling as a separate task?
> If 

Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

[Wang, Jian J]

Updated version according to some internal discussions:

a) Use one PCD with bitmask to enable/disable this feature for different boot 
phases. This PCD is a "fixed" PCD with type of UINT8, and all bits are cleared 
by default. Please note that setting BIT7 with BIT0 set is used to "DISABLE" 
NULL pointer detection for code after EndOfDxe as a workaround for non-fixable 
NULL access in OpROM or boot loaders.

 gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
 #  BIT0 - Enable NULL pointer detection for UEFI.
 #  BIT1 - Enable NULL pointer detection for SMM.
 #  BIT2-6 - Reserved for PEI and other possible uses.
 #  BIT7 - Disable NULL pointer detection after EndOfDxe.

b) Add PEI support. Since PEI requirement has been covered by following new bug 
tracker, it won't be included by current patch update but a separate one.

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

c) CSM code lines which access page 0 will be enclosed by  and 
then  code. This is subject to change if critical performance 
issue is found.


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang, 
Jian J
Sent: Friday, September 01, 2017 10:27 AM
To: Yao, Jiewen <jiewen@intel.com>; Johnson, Brian (EXL - Eagan) 
<brian.john...@hpe.com>; af...@apple.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

Let me summarize the changes to this feature. If no new comments, I'll start to 
make changes to current implementation.

a) Use one PCD with bit set/clear to enable/disable this feature for different 
boot phases. To make it easier to use, I'd suggest to use the bit sequence to 
follow the boot phase sequence (bit0->bit1->bit2..bit7 ===> 
PEI->DXE->PostDxe..SMM), just like below. SMM is a little bit special so it 
consumes the MSB.

 gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
 #  BIT0 - Enable NULL pointer detection for PEI.
 #  BIT1 - Enable NULL pointer detection for DXE.
 #  BIT2 - Enable NULL pointer detection after EndOfDxe.
 #  BIT7 - Disable NULL pointer detection for SMM.

This PCD is a "fixed" PCD and all bits are cleared by default. Since this 
is a feature for debug purpose, I see no reason to make it dynamic. 

b) Add PEI and post DXE phase support. Since PEI phase requirement has been 
covered by following new bug tracker, it won't be included by current patch 
update but a separate one. Changes for Post DXE phase will be included.

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

Thanks,
Wang, Jian J

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, 
Jiewen
Sent: Thursday, August 31, 2017 9:16 AM
To: Johnson, Brian (EXL - Eagan) <brian.john...@hpe.com>; af...@apple.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

Thanks.
I have filed https://bugzilla.tianocore.org/show_bug.cgi?id=687 for PEI phase, 
with suggestion from Brian Johnson and Andrew Fish.

If you share some of your PEI code to elimination the duplicated effort, that 
would be great.

Yes, we can calculate the perf data in CSM to see what is the best way to 
enable this feature. Good suggestion.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Johnson, 
Brian (EXL - Eagan)
Sent: Thursday, August 31, 2017 5:36 AM
To: af...@apple.com; Yao, Jiewen <jiewen@intel.com>
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [PATCH 0/2] Implement NULL pointer detection feature

Jiewen,

Certainly PEI could be done later.  There's no need to get all the code in at 
once, and you have the DXE/SMM part pretty much ready to go.

I'm willing to go with a single PCD with a bitmap, or multiple PCDs.  Whatever 
seems best.

IIRC protecting page 0 in PEI involves modifying the main GCD descriptor to be 
a grows-downward variety, with a limit above page 0.  That way you get an 
exception if page 0 is accessed.  I'd have to check on the steps needed to 
release the actual code, which may take quite a while.  You may be better off 
just doing it yourself.  I'll take another look at the code to make sure I'm 
explaining this properly, though.

CSM is one of the few pieces of BIOS which has a legitimate need to access page 
0.  We get the best protection by having it enable, access, and then disable 
page 0.  But if that affects performance too badly, we may need to have it 
leave page 0 enabled.  I don't enable CSM on the platforms I work on, so it's 
not something I have much to say about.  Those who use CSM would want to weigh 
in.

Brian Johnson

-Original Message-
From: af...@apple.com<mailto:af...@apple.com> [mailto:af...@apple.com]
Sent: Wednesday, August 30, 2017 11:27 AM
To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel

Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Wang, Jian J]

I have summary in each patch email. I removed the CC of some patches because 
there's no update from v3 to v4. I thought this could remind you of this 
situation.
What's the recommended way? Keep the CC as-was and just add summaries in 
cover letter?

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, October 09, 2017 11:56 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>; Yao, Jiewen <jiewen@intel.com>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL
> pointer detection during VBE SHIM installing
> 
> On 10/09/17 17:54, Laszlo Ersek wrote:
> > On 10/09/17 16:17, Jian J Wang wrote:
> >> QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
> >> detection is enabled, this driver will fail to load. NULL pointer detection
> >> bypassing code is added to prevent such problem during boot.
> >>
> >> Please note that Windows 7 will try to access VBE SHIM during boot if it's
> >> installed, and then cause boot failure. This can be fixed by setting BIT7
> >> of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
> >> after EndOfDxe. As far as we know, there's no other OSs has such issue.
> >>
> >> 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>
> >> Cc: Ayellet Wolman <ayellet.wol...@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>
> >> ---
> >>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  1 +
> >>  OvmfPkg/QemuVideoDxe/VbeShim.c| 14 ++
> >>  2 files changed, 15 insertions(+)
> >>
> >> diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >> index 577e07b0a8..ff68c99e96 100644
> >> --- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >> +++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >> @@ -77,3 +77,4 @@
> >>  [Pcd]
> >>gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
> >>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
> >> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
> >> diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c
> b/OvmfPkg/QemuVideoDxe/VbeShim.c
> >> index e45a08e887..8ba5522cde 100644
> >> --- a/OvmfPkg/QemuVideoDxe/VbeShim.c
> >> +++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
> >> @@ -75,6 +75,20 @@ InstallVbeShim (
> >>UINTNPrinted;
> >>VBE_MODE_INFO*VbeModeInfo;
> >>
> >> +  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == 
> >> BIT0)
> {
> >> +DEBUG ((
> >> +  DEBUG_WARN,
> >> +  "%a: page 0 protected, not installing VBE shim\n",
> >> +  __FUNCTION__
> >> +  ));
> >> +DEBUG ((
> >> +  DEBUG_WARN,
> >> +  "%a: page 0 protection prevents Windows 7 from booting anyway\n",
> >> +  __FUNCTION__
> >> +  ));
> >> +return;
> >> +  }
> >> +
> >>Segment0 = 0x0;
> >>SegmentC = 0xC;
> >>SegmentF = 0xF;
> >>
> >
> > If this patch is entirely identical to the previous version (v3), then
> > you should have please picked up the review tags from Jordan and myself,
> > the ones that you got for v3:
> >
> > http://mid.mail-
> archive.com/150696711831.2454.16712170525103415248@jljusten-skl
> >
> > http://mid.mail-archive.com/d1a20be5-8dbf-8ce6-1738-
> d03b33004...@redhat.com
> >
> > This way we can quickly filter out already reviewed patches, and avoid
> > re-reviewing when there are no changes.
> >
> >
> > Your cover letter v4 0/6 also does not summarize the changes relative to
> > v3; in the future please don't forget about that.
> 
> ... personal CC's for OvmfPkg maintainers and reviewers are also missing
> from this patch. Please check "Maintainers.txt" every time.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 5/6] IntelFrameworkModulePkg/Csm: Add code to bypass NULL pointer detection

[Wang, Jian J]

Thanks for catching this issue. Patch has been sent out. 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 12, 2017 5:30 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 v4 5/6] IntelFrameworkModulePkg/Csm: Add code
> to bypass NULL pointer detection
> 
> This patch breaks the GCC5 build:
> 
> On 10/09/17 16:17, Jian J Wang wrote:
> 
> > diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c
> b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c
> > index 3d9a8b9649..f42c13cd89 100644
> > --- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c
> > +++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c
> > @@ -57,7 +57,11 @@ LegacyBiosInt86 (
> >IN  EFI_IA32_REGISTER_SET *Regs
> >)
> >  {
> > -  UINT32  *VectorBase;
> > +  UINT16Segment;
> > +  UINT16Offset;
> > +  LEGACY_BIOS_INSTANCE  *Private;
> > +
> > +  Private = LEGACY_BIOS_INSTANCE_FROM_THIS (This);
> >
> >Regs->X.Flags.Reserved1 = 1;
> >Regs->X.Flags.Reserved2 = 0;
> > @@ -72,12 +76,15 @@ LegacyBiosInt86 (
> >// The base address of legacy interrupt vector table is 0.
> >// We use this base address to get the legacy interrupt handler.
> >//
> > -  VectorBase  = 0;
> > +  DisableNullDetection ();
> > +  Segment   = (UINT16)(((UINT32 *)0)[BiosInt] >> 16);
> > +  Offset= (UINT16)((UINT32 *)0)[BiosInt];
> > +  EnableNullDetection ();
> >
> >return InternalLegacyBiosFarCall (
> > This,
> > -   (UINT16) ((VectorBase)[BiosInt] >> 16),
> > -   (UINT16) (VectorBase)[BiosInt],
> > +   Segment,
> > +   Offset,
> > Regs,
> > >X.Flags,
> > sizeof (Regs->X.Flags)
> 
> IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c: In function
> 'LegacyBiosInt86':
> IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c:62:26: error: variable
> 'Private' set but not used [-Werror=unused-but-set-variable]
>LEGACY_BIOS_INSTANCE  *Private;
>   ^~~
> cc1: all warnings being treated as errors
> 
> Can you please send a patch?
> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 0/6] Add NULL pointer detection feature

[Wang, Jian J]

Hi,

Any more comments for this version of patch? If no, I'll check in it today. 
Thanks.

Jian

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Monday, October 09, 2017 10:17 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v4 0/6] Add NULL pointer detection feature
> 
> The mechanism behind is to trigger a page fault exception at address 0.
> This can be made by disabling page 0 (0-4095) during page table setup.
> So this feature can only be available on platform with paging enabled.
> 
> Once this feature is enabled, any code, like CSM, which has to access
> memory in page 0 needs to enable this page temporarily in advance and
> disable it afterwards.
> 
> PcdNullPointerDetectionPropertyMask is used to control and elaborate
> the use cases. For example, BIT7 of this PCD must be set for Windows 7
> boot on Qemu if BIT0 set; or boot will fail.
> 
> 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>
> 
> Jian J Wang (5):
>   MdeModulePkg/DxeIpl: Implement NULL pointer detection
>   MdeModulePkg/Core/Dxe: Add EndOfDxe workaround for NULL pointer
> detection
>   UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM
> code
>   IntelFrameworkModulePkg/Csm: Add code to bypass NULL pointer detection
>   OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM
> installing
> 
> Wang, Jian J (1):
>   MdeModulePkg/MdeModulePkg.dec,.uni: Add NULL pointer detection PCD
> 
>  .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 101 ++
>  .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   |   2 +
>  .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |   2 +
>  .../Csm/LegacyBiosDxe/LegacyBda.c  |   4 +
>  .../Csm/LegacyBiosDxe/LegacyBios.c | 152 
> +
>  .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|   2 +
>  .../Csm/LegacyBiosDxe/LegacyBiosInterface.h|  18 +++
>  .../Csm/LegacyBiosDxe/LegacyBootSupport.c  |  23 +++-
>  .../Csm/LegacyBiosDxe/LegacyPci.c  |  17 ++-
>  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  |  27 +++-
>  MdeModulePkg/Core/Dxe/DxeMain.inf  |   1 +
>  MdeModulePkg/Core/Dxe/Mem/Page.c   |   4 +-
>  MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c  |  65 +
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  |  25 
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   1 +
>  MdeModulePkg/Core/DxeIplPeim/DxeLoad.c |   1 +
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  17 ++-
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   4 +
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  93 -
>  MdeModulePkg/MdeModulePkg.dec  |  13 ++
>  MdeModulePkg/MdeModulePkg.uni  |  13 ++
>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |   1 +
>  OvmfPkg/QemuVideoDxe/VbeShim.c |  14 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |  12 ++
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  25 +++-
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |   1 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|  12 ++
>  27 files changed, 628 insertions(+), 22 deletions(-)
> 
> --
> 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 v2 2/6] MdeModulePkg/PiSmmCore: Implement heap guard feature for SMM mode

[Wang, Jian J]

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

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 
<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>>
---
 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c | 1446 ++
 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.h |  400 +++
 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.c |  704 +
 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.h |  174 
 MdeModulePkg/Core/PiSmmCore/Page.c   |   51 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.c  |   12 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.h  |   80 +-
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf|8 +
 MdeModulePkg/Core/PiSmmCore/Pool.c   |   75 +-
 9 files changed, 2922 insertions(+), 28 deletions(-)
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.h
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.c
 create mode 100644 MdeModulePkg/Core/PiSmmCore/Misc/PageTable.h

diff --git a/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c 
b/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
new file mode 100644
index 00..5c97422bb6
--- /dev/null
+++ b/MdeModulePkg/Core/PiSmmCore/Misc/HeapGuard.c
@@ -0,0 +1,1446 @@
+/** @file
+  UEFI Heap Guard functions.
+
+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 D

Re: [edk2] [PATCH v5 5/7] MdeModulePkg/DxeCore: Implement heap guard feature for UEFI

[Wang, Jian J]

Hi Ard,

I think the XP related feature is controlled by PCD 
PcdDxeNxMemoryProtectionPolicy.
So in addition to adding more comment, I think we can also add ASSERT statements
to tell user not to enable the same memory type like below

ASSERT (PcdGet64(PcdDxeNxMemoryProtectionPolicy) &
PcdGet64(PcdHeapGuardPoolType) == 0);
ASSERT (PcdGet64(PcdDxeNxMemoryProtectionPolicy) &
PcdGet64(PcdHeapGuardPageType) == 0);

Thanks,
Jian

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Monday, November 13, 2017 11:09 AM
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org;
> Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng,
> Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH v5 5/7] MdeModulePkg/DxeCore: Implement heap
> guard feature for UEFI
> 
> Thanks for the feedback. I'll add comment to explain more.
> 
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Sunday, November 12, 2017 5:51 AM
> > To: Wang, Jian J <jian.j.w...@intel.com>
> > Cc: edk2-devel@lists.01.org; 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: Re: [edk2] [PATCH v5 5/7] MdeModulePkg/DxeCore: Implement heap
> > guard feature for UEFI
> >
> > On 10 November 2017 at 05:19, Jian J Wang <jian.j.w...@intel.com> wrote:
> > >> v4
> > >> Coding style cleanup
> > >
> > >> v3
> > >> Fix build error with GCC toolchain
> > >
> > >> v2
> > >> According to Eric's feedback:
> > >> a. Remove local variable initializer with memory copy from globals
> > >> b. Add comment for the use of mOnGuarding
> > >> c. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
> > >>message
> > >>
> > >> Other changes:
> > >> d. Fix issues in 32-bit boot mode
> > >> e. Remove prototype of empty functions
> > >>
> > >
> > > 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
> > >
> > > BIT0 and BIT1 of PcdHeapGuardPropertyMask can be used to enable or
> disable
> > > memory guard for 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 EfiBootServicesData
> > > and EfiRuntimeServicesData by setting the PCD with value 0x50.
> > >
> > > 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.
> > >
> > > Note1: Turning on heap guard, especially pool guard, will introduce too
> many
> > > memory fragments. Windows 10 has a limitation in its boot loader, which
> > > accepts at most 512 memory descriptors passed from BIOS. This will prevent
> > > Windows 10 from booting if heap guard is enabled. The latest Linux
> > > distribution with grub boot loader has no such issue. Normally it's not
> > > recommended to enable this feature in production build of BIOS.
> > >
> > > Note2: Don't enable this feature for NT32 emulation platform which doesn't
> > > support paging.
> > >
> > > 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

Re: [edk2] [PATCH v5 5/7] MdeModulePkg/DxeCore: Implement heap guard feature for UEFI

[Wang, Jian J]

Thanks for the feedback. I'll add comment to explain more.

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Sunday, November 12, 2017 5:51 AM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org; 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: Re: [edk2] [PATCH v5 5/7] MdeModulePkg/DxeCore: Implement heap
> guard feature for UEFI
> 
> On 10 November 2017 at 05:19, Jian J Wang <jian.j.w...@intel.com> wrote:
> >> v4
> >> Coding style cleanup
> >
> >> v3
> >> Fix build error with GCC toolchain
> >
> >> v2
> >> According to Eric's feedback:
> >> a. Remove local variable initializer with memory copy from globals
> >> b. Add comment for the use of mOnGuarding
> >> c. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
> >>message
> >>
> >> Other changes:
> >> d. Fix issues in 32-bit boot mode
> >> e. Remove prototype of empty functions
> >>
> >
> > 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
> >
> > BIT0 and BIT1 of PcdHeapGuardPropertyMask can be used to enable or disable
> > memory guard for 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 EfiBootServicesData
> > and EfiRuntimeServicesData by setting the PCD with value 0x50.
> >
> > 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.
> >
> > Note1: Turning on heap guard, especially pool guard, will introduce too many
> > memory fragments. Windows 10 has a limitation in its boot loader, which
> > accepts at most 512 memory descriptors passed from BIOS. This will prevent
> > Windows 10 from booting if heap guard is enabled. The latest Linux
> > distribution with grub boot loader has no such issue. Normally it's not
> > recommended to enable this feature in production build of BIOS.
> >
> > Note2: Don't enable this feature for NT32 emulation platform which doesn't
> > support paging.
> >
> > 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>
> > Reviewed-by: Jiewen Yao <jiewen@intel.com>
> > Regression-tested-by: Laszlo Ersek <ler...@redhat.com>
> > ---
> >  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 -
> >  6 files changed, 1838 insertions(+), 64 deletions(-)
> >  create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> >  create mode 100644 MdeModulePkg/Core/Dxe/Mem/HeapGuard.h
> >
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf
> b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > index 15f4b03d3c..f2155fcab1 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain.inf
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > @@ -56,6 +56,7 @@
> >Mem/MemData.c
> >Mem/Imem.h
> >Mem/MemoryProfileRecord.c
> > +  Mem/HeapGuard.c
> >FwVolBlock/FwVolBlock.c
> >FwVolBlock/FwVolBlock.h
> >FwVol/FwVolWrite.c
>

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

[Wang, Jian J]

This is really a surprise. Anyway, thanks for validating so many OSs. I guess 
we 
have to turn to your suggestion before, which is adding capability to affected 
memory block only, not all memory space.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, November 10, 2017 8:24 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org; Dong, Eric <eric.d...@intel.com>; Yao, Jiewen
> <jiewen@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>; Matt
> Fleming <m...@codeblueprint.co.uk>
> Subject: Re: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
> memory map
> 
> Hi Jian,
> 
> I'm CC'ing Ard and Matt, and commenting at the bottom.
> 
> On 11/10/17 02:02, Jian J Wang wrote:
> >> 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 <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 | 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 capa

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

[Wang, Jian J]

I tried this workaround and there're no failure in booting Fedora 26 and Windows
server 2016 now. If no objection, I'll merge it into new version of this patch.

> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, November 15, 2017 3:37 PM
> To: Zeng, Star <star.z...@intel.com>; Laszlo Ersek <ler...@redhat.com>
> Cc: Matt Fleming <m...@codeblueprint.co.uk>; edk2-devel@lists.01.org; Yao,
> Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>; Ard
> Biesheuvel <ard.biesheu...@linaro.org>
> Subject: RE: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
> memory map
> 
> Since OS never had chance to use the those capabilities before, I think it's
> feasible.
> But it's just a workaround not solution because there's real gap between UEFI
> and
> OS on how to interpret the memory capabilities.
> 
> > -Original Message-----
> > From: Zeng, Star
> > Sent: Wednesday, November 15, 2017 2:53 PM
> > To: Wang, Jian J <jian.j.w...@intel.com>; Laszlo Ersek <ler...@redhat.com>
> > Cc: Matt Fleming <m...@codeblueprint.co.uk>; edk2-devel@lists.01.org; Yao,
> > Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>; Ard
> > Biesheuvel <ard.biesheu...@linaro.org>; Zeng, Star <star.z...@intel.com>
> > Subject: RE: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE
> in
> > memory map
> >
> > How about the code to filter out paging capabilities from UEFI memory map in
> > Page.c CoreGetMemoryMap(), then with maximum compatibility, the UEFI
> > memory map could be same with before
> > 14dde9e903bb9a719ebb8f3381da72b19509bc36 [MdeModulePkg/Core: Fix
> out-
> > of-sync issue in GCD].
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wang,
> > Jian J
> > Sent: Tuesday, November 14, 2017 10:36 PM
> > To: Laszlo Ersek <ler...@redhat.com>
> > Cc: Matt Fleming <m...@codeblueprint.co.uk>; edk2-devel@lists.01.org; Yao,
> > Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>; Ard
> > Biesheuvel <ard.biesheu...@linaro.org>
> > Subject: Re: [edk2] [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of
> > RT_CODE in memory map
> >
> > Hi Laszlo,
> >
> > I did some investigation works on this issue. I think I found the root 
> > cause and
> > tend to believe this is a Fedora kernel issue. Here're proves:
> >
> > memmap output patterns in which Fedora 26 failed to boot:
> > 1) BS_DataAE20-AE20EFFF 000F
> > 0002600F
> > RT_DataAE20F000-AE38EFFF 0180
> > 8002600F
> > RT_CodeAE38F000-AE48EFFF 0100
> > 8002600F
> > Reserved   AE48F000-AE58EFFF 0100
> > 0002600F
> >
> > 2) BS_DataAE20-AE20EFFF 000F
> > 000F
> > RT_DataAE20F000-AE38EFFF 0180
> > 800F
> > RT_CodeAE38F000-AE467FFF 00D9
> > 800F
> > RT_CodeAE468000-AE469FFF 0002
> > 8002600F
> > RT_CodeAE46A000-AE46EFFF 0005
> > 800F
> > RT_CodeAE46F000-AE470FFF 0002
> > 8002600F
> > RT_CodeAE471000-AE475FFF 0005
> > 800F
> > RT_CodeAE476000-AE479FFF 0004
> > 8002600F
> > RT_CodeAE47A000-AE47 0006
> > 800F
> > RT_CodeAE48-AE481FFF 0002
> > 8002600F
> > RT_CodeAE482000-AE487FFF 0006
> > 800F
> > RT_CodeAE488000-AE489FFF 0002
> > 8002600F
> > RT_CodeAE48A000-AE48EFFF 0005
> > 800F
> > Reserved   AE48F000-AE58EFFF 0100
> > 000F
> >
> > 3) RT_DataAE20F000-AE38EFFF 0180
> > 800F
> > RT_CodeAE38F000-AE418FFF 008A
> > 800F
> > RT_CodeAE419000-AE48EFFF 0076
> > 8000

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

Good catch. I’ll add them. Thanks.

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Saturday, November 25, 2017 9:28 PM
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 v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch 
support


Hi,



About 1.1), I agree with Jiewen’s suggestion. Besides it, we also need to 
provide dummy function of InitializeCpuExceptionStackSwitchHandlers() in NULL 
instance in MdeModulePkg/Library/CpuExceptionHandlerLibNull.

But we need to think about the return status carefully. For example, if return 
EFI_UNSUPPORTED in Pei/SMM instrance, we need to update public header file to 
add this return type.



Jeff




From: edk2-devel 
<edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>> on 
behalf of Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>
Sent: Thursday, November 23, 2017 2:43:44 PM
To: Yao, Jiewen; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Kinney, Michael D; Dong, Eric; Zeng, Star
Subject: Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack 
switch support

1.1) Got your point. I'll add dummy function in this patch.
1.2) Yep, we're on the same page.
1.3) Here's my opinion:

Actually almost all MP code has such assumption: any AP configuration will copy
 from BSP. If we allow AP to call InitializeCpuExceptionHandlers(), we have to 
do a lot
of other changes than just updating InitializeCpuExceptionHandlers(). If so, it 
may
be premature to figure out a solution at this patch.

In addition, CpuDxe actually calls InitializeCpuInterruptHandlers() which 
covers the
functionalities of InitializeCpuExceptionHandlers() (its settings will be 
overwritten).
If we want AP to initialize interrupt and exception individually, maybe we 
should
let AP call InitializeCpuInterruptHandlers() instead.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 2:16 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 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
>
> Here is my thought for 1)
>
> 1.1) We must provide the InitializeCpuExceptionStackSwitchHandlers()
> implementation in Pei instance and Smm instance.
>
> The basic requirement is a library instance must provide symbol for functions
> declared in header file.
> It is ok to return unsupported. But we MUST provide the symbol.
>
> 1.2) For SMM, I think our ultimate goal is to remove SMM specific stack guard,
> and use the common one. Duplicating code is completely unnecessary, and it is
> easy to introduce bug. And unfortunately, we already have bug in existing SMM
> exception handler. -- That is a good reason to remove duplication.
>
> Again, it is not necessary to do it in this patch. I am totally OK to do it 
> in another
> patch.
>
> 1.3) For PEI, I do not think we can use current way to allocate stack in data
> section, because it might be readonly in pre-mem phase. We must use some
> other way.
>
> 1.4) I believe this patch has a hidden assumption is that:
> InitializeCpuExceptionHandlers() won't be called by multiple APs.
> If 2 or more APs call the it at same time, it might be broken because you use
> mNewStack for all the callers
> Is that right?
>
>
> Thank you
> Yao Jiewen
>
>
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 23, 2017 2:06 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 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> >
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Thursday, November 23, 2017 1:50 PM
> > > To: Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com&

Re: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API

[Wang, Jian J]

If we use union data, other arch of processors can add their own definitions in 
it without interfering ours. Is the MdeModulePkg for IA32 only?

This data is used to reserve resources in different boot phases. Unless we can 
limit its uses in just UefiCpuPkg, maybe MdeModulePkg is the only choice. But 
at least in my current implementation, we can just put it in UefiCpuPkg. I’m 
just not sure of any future impact.

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Saturday, November 25, 2017 9:18 PM
To: Wang, Jian J <jian.j.w...@intel.com>; Yao, Jiewen <jiewen@intel.com>; 
edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: 答复: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a 
new API


Hi,



I am not sure if this is good idea to define such arch specific definitions in 
MdeModulePkg. Moreover, we don’t know how ARM or other processors define this 
definition, either.



Jeff




From: edk2-devel 
<edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>> on 
behalf of Wang, Jian J <jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>>
Sent: Thursday, November 23, 2017 1:06:53 PM
To: Yao, Jiewen; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Dong, Eric; Zeng, Star
Subject: Re: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a 
new API

Good idea. I think it should be defined in also in following file besides the 
new API

MdeModulePkg\Include\Library\CpuExceptionHandlerLib.h

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 12:08 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: Dong, Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>; Zeng, Star 
> <star.z...@intel.com<mailto:star.z...@intel.com>>
> Subject: RE: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h:
> Add a new API
>
> Hi
> I am a little worried about the way to use VOID * to pass arch dependent data.
>
> Can we define it clearly in each ARCH in the header file, and use a UNION to
> include all arch?
>
> I think both the caller and the callee need parse it. As such, VOID * is not 
> a good
> way.
>
> Thank you
> Yao Jiewen
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian
> J
> > Wang
> > Sent: Wednesday, November 22, 2017 4:46 PM
> > To: 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>>;
> > Zeng, Star <star.z...@intel.com<mailto:star.z...@intel.com>>
> > Subject: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h:
> Add
> > a new API
> >
> > > v2:
> > >Add prototype definition of InitializeCpuExceptionStackSwitchHandlers()
> >
> > A new API InitializeCpuExceptionStackSwitchHandlers() is introduced to
> support
> > initializing exception handlers being able to switch stack. StackSwitchData 
> > is
> > arch dependent and required by IA32 processor to convey resources reserved
> in
> > advance. This is necessary because the CpuExceptionHandlerLib will be linked
> > in different phases, in which there's no common way to reserve resources.
> >
> > EFI_STATUS
> > EFIAPI
> > InitializeCpuExceptionStackSwitchHandlers (
> >   IN VOID   *StackSwitchData  OPTIONAL
> >   );
> >
> > 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>>
> > 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>>
> > ---
> >  MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h | 18
> > ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > index 6cd8230127..68de4850e1 100644
> > --- a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > +++ b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > @@ -41,6 +41,24 @@ InitializeCp

Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Sorry just see this email. I just replied another one. Great to know it works 
for both of us.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, November 22, 2017 5:05 PM
> To: Zeng, Star <star.z...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org; Yao, Jiewen <jiewen@intel.com>
> Subject: Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory
> map
> 
> On 11/22/17 08:56, Zeng, Star wrote:
> > How about we have the v6 patch series in first with the feedback from Jiewen
> (about comments) and you (about MemoryMapStart) addressed?
> >
> > Then we can have a separated patch for the merging.
> 
> Good idea!
> 
> Thanks!
> Laszlo
> 
> 
> >
> >
> > Thanks,
> > Star
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> > Sent: Tuesday, November 21, 2017 9:38 PM
> > To: Wang, Jian J <jian.j.w...@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory
> map
> >
> > Jian,
> >
> > On 11/21/17 07:17, Jian J Wang wrote:
> >>> v7:
> >>>   Merge memory map after filtering paging attributes
> >>
> >> 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.
> >>
> >> Jian J Wang (2):
> >>   MdeModulePkg/DxeCore: Filter out all paging capabilities
> >>   UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
> >>
> >>  MdeModulePkg/Core/Dxe/DxeMain.h  | 18 ++
> >>  MdeModulePkg/Core/Dxe/Mem/Page.c | 21 +++
> >>  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  1 -
> >>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +--
> -
> >>  4 files changed, 112 insertions(+), 22 deletions(-)
> >>
> >
> > I don't have capacity to retest and re-review the series.
> >
> > Considering the following two options, I like none of them:
> >
> > (1) Version 7 is merged with my feedback tags from v6. I don't like this 
> > because
> I didn't review or test version 7.
> >
> > (2) Version 7 is merged without my feedback tags. I don't like this because 
> > I've
> put a lot of BZ writeup, and patch review and testing effort for this series, 
> and
> I'd like the commit log to reflect that.
> >
> >
> > Instead, I would like to request the following, for v8:
> >
> > Please submit a series that consists of three patches:
> >
> > - patch v8 1/3: identical to v6 1/2, except for the code comment update,
> > - patch v8 2/3: identical to v6 2/2,
> > - patch v8 3/3: please implement the merging of the memory map as a
> separate patch.
> >
> > Patches v8 1/3 and 2/3 should include *both* my Tested-by *and* my
> Reviewed-by tags, from v6.
> >
> > Patch v8 3/3 should be reviewed / tested separately by others. I don't 
> > think I
> can find the capacity for that at the moment.
> >
> > This approach will correctly reflect all the work done thus far, and it will
> provide the desired result for the code as well.
> >
> > Thanks
> > Laszlo
> > ___
> > 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 v7 0/2] Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

Laszlo,

Thanks for the comments. Sorry for the commit log which doesn't meet the 
requirement.
I appreciate everything you did to this patch series. It's not intended to 
ignore them in log.
I think I just need more time to get used to the commit conventions.

I've explained the reason why v7 doesn't need a re-test in another email. But I 
understand
it if you insist re-test is necessary. Star and Jiewen have given a proposal, 
similar to yours
but putting the "merge" into a new patch instead of in this series. I think 
it's feasible. Let me
know your opinion.

Again, thanks for all your valuable comments and test efforts on this series 
and all others.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 21, 2017 9:38 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v7 0/2] Fix multiple entries of RT_CODE in memory
> map
> 
> Jian,
> 
> On 11/21/17 07:17, Jian J Wang wrote:
> >> v7:
> >>   Merge memory map after filtering paging attributes
> >
> > 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.
> >
> > Jian J Wang (2):
> >   MdeModulePkg/DxeCore: Filter out all paging capabilities
> >   UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map
> >
> >  MdeModulePkg/Core/Dxe/DxeMain.h  | 18 ++
> >  MdeModulePkg/Core/Dxe/Mem/Page.c | 21 +++
> >  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  1 -
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94 +
> ---
> >  4 files changed, 112 insertions(+), 22 deletions(-)
> >
> 
> I don't have capacity to retest and re-review the series.
> 
> Considering the following two options, I like none of them:
> 
> (1) Version 7 is merged with my feedback tags from v6. I don't like this
> because I didn't review or test version 7.
> 
> (2) Version 7 is merged without my feedback tags. I don't like this
> because I've put a lot of BZ writeup, and patch review and testing
> effort for this series, and I'd like the commit log to reflect that.
> 
> 
> Instead, I would like to request the following, for v8:
> 
> Please submit a series that consists of three patches:
> 
> - patch v8 1/3: identical to v6 1/2, except for the code comment update,
> - patch v8 2/3: identical to v6 2/2,
> - patch v8 3/3: please implement the merging of the memory map as a
> separate patch.
> 
> Patches v8 1/3 and 2/3 should include *both* my Tested-by *and* my
> Reviewed-by tags, from v6.
> 
> Patch v8 3/3 should be reviewed / tested separately by others. I don't
> think I can find the capacity for that at the moment.
> 
> This approach will correctly reflect all the work done thus far, and it
> will provide the desired result for the code as well.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API

[Wang, Jian J]

Good idea. I think it should be defined in also in following file besides the 
new API

MdeModulePkg\Include\Library\CpuExceptionHandlerLib.h

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 12:08 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: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h:
> Add a new API
> 
> Hi
> I am a little worried about the way to use VOID * to pass arch dependent data.
> 
> Can we define it clearly in each ARCH in the header file, and use a UNION to
> include all arch?
> 
> I think both the caller and the callee need parse it. As such, VOID * is not 
> a good
> way.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian
> J
> > Wang
> > Sent: Wednesday, November 22, 2017 4:46 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>;
> > Zeng, Star <star.z...@intel.com>
> > Subject: [edk2] [PATCH v2 2/8] MdeModulePkg/CpuExceptionHandlerLib.h:
> Add
> > a new API
> >
> > > v2:
> > >Add prototype definition of InitializeCpuExceptionStackSwitchHandlers()
> >
> > A new API InitializeCpuExceptionStackSwitchHandlers() is introduced to
> support
> > initializing exception handlers being able to switch stack. StackSwitchData 
> > is
> > arch dependent and required by IA32 processor to convey resources reserved
> in
> > advance. This is necessary because the CpuExceptionHandlerLib will be linked
> > in different phases, in which there's no common way to reserve resources.
> >
> > EFI_STATUS
> > EFIAPI
> > InitializeCpuExceptionStackSwitchHandlers (
> >   IN VOID   *StackSwitchData  OPTIONAL
> >   );
> >
> > Cc: Star Zeng <star.z...@intel.com>
> > 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>
> > ---
> >  MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h | 18
> > ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > index 6cd8230127..68de4850e1 100644
> > --- a/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > +++ b/MdeModulePkg/Include/Library/CpuExceptionHandlerLib.h
> > @@ -41,6 +41,24 @@ InitializeCpuExceptionHandlers (
> >IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
> >);
> >
> > +/**
> > +  Setup separate stack for given exceptions. StackSwitchData is optional 
> > and
> its
> > +  content depends one the specific arch of CPU.
> > +
> > +  @param[in] StackSwitchData  Pointer to data required for setuping up
> > +  stack switch.
> > +
> > +  @retval EFI_SUCCESS The exceptions have been successfully
> > +  initialized.
> > +  @retval EFI_INVALID_PARAMETER   StackSwitchData contains invalid
> > content.
> > +
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +InitializeCpuExceptionStackSwitchHandlers (
> > +  IN VOID   *StackSwitchData  OPTIONAL
> > +  );
> > +
> >  /**
> >Initializes all CPU interrupt/exceptions entries and provides the default
> > interrupt/exception handlers.
> >
> > --
> > 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 v2 0/8] Implement stack guard feature

[Wang, Jian J]

I did test it with disabled. I'll try it enabled. Do you think this feature 
should be enabled
by default or not, just like the PcdCpuSmmStackGuard?

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 11:48 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH v2 0/8] Implement stack guard feature
> 
> For test, can we test boot OS (windows/Linux) with PcdCpuStackGuard enabled?
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian
> J
> > Wang
> > Sent: Wednesday, November 22, 2017 4:46 PM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH v2 0/8] Implement stack guard feature
> >
> > 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).
> >
> > Validation works include:
> >   a. OVMF emulated platform: boot to shell (IA32/X64)
> >   b. Intel real platform: boot to shell (IA32/X64)
> >
> > Jian J Wang (8):
> >   MdeModulePkg/metafile: Add PCD PcdCpuStackGuard
> >   MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API
> >   MdePkg/BaseLib: Add stack switch related definitions for IA32
> >   MdeModulePkg/DxeIpl: Enable paging for Stack Guard
> >   UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch
> >   UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data
> >   UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support
> >   UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> >
> >  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   5 +-
> >  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|   4 +
> >  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   1 +
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  51 ++-
> >  .../Include/Library/CpuExceptionHandlerLib.h   |  18 +
> >  MdeModulePkg/MdeModulePkg.dec  |   7 +
> >  MdeModulePkg/MdeModulePkg.uni  |   7 +
> >  MdePkg/Include/Library/BaseLib.h   | 115 ++
> >  MdePkg/Library/BaseLib/BaseLib.inf |   3 +
> >  MdePkg/Library/BaseLib/Ia32/WriteTr.nasm   |  36 ++
> >  MdePkg/Library/BaseLib/X64/WriteTr.nasm|  37 ++
> >  UefiCpuPkg/CpuDxe/CpuDxe.inf   |   3 +
> >  UefiCpuPkg/CpuDxe/CpuMp.c  | 168 +
> >  UefiCpuPkg/CpuDxe/CpuMp.h  |  12 +
> >  .../CpuExceptionHandlerLib/CpuExceptionCommon.h|  50 +++
> >  .../DxeCpuExceptionHandlerLib.inf  |   6 +
> >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
> >  .../Ia32/ArchExceptionHandler.c| 167 +
> >  .../Ia32/ArchInterruptDefs.h   |   8 +
> >  .../Ia32/ExceptionTssEntryAsm.nasm | 398
> > +
> >  .../PeiCpuExceptionHandlerLib.inf  |   1 +
> >  .../SecPeiCpuExceptionHandlerLib.inf   |   1 +
> >  .../SmmCpuExceptionHandlerLib.inf  |   1 +
> >  .../X64/ArchExceptionHandler.c | 133 +++
> >  .../CpuExceptionHandlerLib/X64/ArchInterruptDefs.h |   3 +
> >  UefiCpuPkg/Library/MpInitLib/MpLib.c   |  17 +
> >  UefiCpuPkg/Library/MpInitLib/MpLib.h   |   3 +
> >  UefiCpuPkg/UefiCpuPkg.dec  |  12 +
> >  28 files changed, 1304 insertions(+), 16 deletions(-)
> >  create mode 100644 MdePkg/Library/BaseLib/Ia32/WriteTr.nasm
> >  create mode 100644 MdePkg/Library/BaseLib/X64/WriteTr.nasm
> >  create mode 100644
> >
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionTssEntryAsm.nasm
> >
> > --
> > 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 v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 1:50 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 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> Some thought:
> 
> 1) I found InitializeCpuExceptionStackSwitchHandlers() is only implemented in
> DxeException.c.
> What about Pei/Smm instance?
> 
> I think it is OK to not implement it at this moment. But we need make sure no
> architecture issue if we want to enable it some time later.
> 
Like what we discussed before, this series of patch is for Stack Guard feature 
which
is only available for DXE (because Stack Guard needs paging to work). Stack 
switch
is enabled for the sake of Stack Guard feature. So I think it's enough to 
implement
it in DxeException.c. In addition, SMM has its own implementation of stack guard
and stack switch. It's not necessary to do it again.

I agree with you that we should merge those common code but I think we should do
it in a separate patch series since it's not Stack Guard relevant. And I've 
removed
all architecture issues I can think of. Current stack switch initialization 
should work
for both PEI and SMM as well.

> 2) #define IA32_GDT_TYPE_TSS   0x9
> This is generic, can we move to BaseLib.h?
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, November 22, 2017 4:46 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 v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch
> > support
> >
> > > v2:
> > >a. Move common TSS structure and API definitions to BaseLib.h
> > >b. Add EXCEPTION_STACK_SWITCH_DATA to convery data used to setup
> > stack
> > >   switch. This can avoid allocating memory for it in this library.
> > >c. Add globals to reserve memory for stack switch initialized in early
> > >   phase of DXE core.
> > >d. Remove the filter code used to exclude boot modes which doesn't
> > support
> > >   memory allocation because those memory can passed in by parameter
> > now.
> > >e. Remove the nasm macro to define exception handler one by one and
> > add a
> > >   function to return the start address of each handler.
> >
> > 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).
> >
> > 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|  50 +++
> >  .../DxeCpuExceptionHandlerLib.inf  |   6 +
> >  .../Library/CpuExceptionHandlerLib/DxeException.c  |  53 ++-
> >  .../Ia32/ArchExceptionHandler.c| 167 +
> >  .../Ia32/ArchInterruptDefs.h  

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

1.1) Got your point. I'll add dummy function in this patch.
1.2) Yep, we're on the same page.
1.3) Here's my opinion:

Actually almost all MP code has such assumption: any AP configuration will copy
 from BSP. If we allow AP to call InitializeCpuExceptionHandlers(), we have to 
do a lot
of other changes than just updating InitializeCpuExceptionHandlers(). If so, it 
may
be premature to figure out a solution at this patch.

In addition, CpuDxe actually calls InitializeCpuInterruptHandlers() which 
covers the
functionalities of InitializeCpuExceptionHandlers() (its settings will be 
overwritten).
If we want AP to initialize interrupt and exception individually, maybe we 
should
let AP call InitializeCpuInterruptHandlers() instead.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 2:16 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 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> Here is my thought for 1)
> 
> 1.1) We must provide the InitializeCpuExceptionStackSwitchHandlers()
> implementation in Pei instance and Smm instance.
> 
> The basic requirement is a library instance must provide symbol for functions
> declared in header file.
> It is ok to return unsupported. But we MUST provide the symbol.
> 
> 1.2) For SMM, I think our ultimate goal is to remove SMM specific stack guard,
> and use the common one. Duplicating code is completely unnecessary, and it is
> easy to introduce bug. And unfortunately, we already have bug in existing SMM
> exception handler. -- That is a good reason to remove duplication.
> 
> Again, it is not necessary to do it in this patch. I am totally OK to do it 
> in another
> patch.
> 
> 1.3) For PEI, I do not think we can use current way to allocate stack in data
> section, because it might be readonly in pre-mem phase. We must use some
> other way.
> 
> 1.4) I believe this patch has a hidden assumption is that:
> InitializeCpuExceptionHandlers() won't be called by multiple APs.
> If 2 or more APs call the it at same time, it might be broken because you use
> mNewStack for all the callers
> Is that right?
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 23, 2017 2:06 PM
> > To: Yao, Jiewen <jiewen@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 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> >
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Thursday, November 23, 2017 1:50 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 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > > switch support
> > >
> > > Some thought:
> > >
> > > 1) I found InitializeCpuExceptionStackSwitchHandlers() is only implemented
> in
> > > DxeException.c.
> > > What about Pei/Smm instance?
> > >
> > > I think it is OK to not implement it at this moment. But we need make 
> > > sure no
> > > architecture issue if we want to enable it some time later.
> > >
> > Like what we discussed before, this series of patch is for Stack Guard 
> > feature
> > which
> > is only available for DXE (because Stack Guard needs paging to work). Stack
> > switch
> > is enabled for the sake of Stack Guard feature. So I think it's enough to
> > implement
> > it in DxeException.c. In addition, SMM has its own implementation of stack
> guard
> > and stack switch. It's not necessary to do it again.
> >
> > I agree with you that we should merge those common code but I think we
> should
> > do
> > it in a separate patch series since it's not Stack Guard relevant. And I've
> removed
> > all architecture issues I can think of. Current stack switch initialization 
> > should
> work
> > for both PEI and SMM as well.
> >
> > > 2) #define IA32_GDT_TYPE_TSS   0x9
> > > This is generic, can we move to BaseLib.h?
> > >
> > >
> > > Thank you
> > > Yao Jiewen
>

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

1) No impact at all.

2)
Page at stack base will be disabled.
If Arch == IA32,
The stack switch for handler of #PF/#DD will be setup for BSP and AP
Else
The handler of #PF/#DD keeps the same
EndIf

If StackOverFlow,
If Arch == IA32,
#PF is triggered and its handler is called with KnownGoodStack.
CPU context is dumped successfully.
Else
#PF handler is triggered but its handler is called with corrupted 
stack.
CPU context cannot be dumped.
EndIf
EndIf

3) 
If Cpu == BSP,
Only Exceptions will be handled. Interrupts will not.
Else,
No exceptions and interrupts will be handled.
EndIf

4) 
Page at stack base will be disabled.
If Cpu == BSP,
Only Exceptions will be handled. Interrupts will not.

If Arch == IA32,
The stack switch for handler of #PF/#DD will be setup for BSP
Else
The handler of #PF/#DD keeps the same
EndIf

If StackOverFlow,
If Arch == IA32,
#PF is triggered and its handler is called with KnownGoodStack.
CPU context is dumped successfully.
Else
#PF handler is triggered but its handler is called with 
corrupted stack.
CPU context cannot be dumped.
EndIf
EndIf
Else,
No exceptions and interrupts will be handled.
EndIf

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 2:25 PM
> To: 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: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> I am ok to keep FALSE by default. But I still suggest we test existing UEFI OS
> behavior.
> 
> Please help me understand below condition, if we do not change a platform
> specific CPU driver:
> 1) If PcdCpuStackGuard is FALSE, and CPU driver is still consuming existing 
> API in
> ExceptionLib. Is there any impact?
> 2) If PcdCpuStackGuard is TRUE, and CPU driver is still consuming existing 
> API in
> ExceptionLib. Is there any impact?
> 3) If PcdCpuStackGuard is FALSE, and CPU driver is not consuming existing API 
> in
> ExceptionLib. Is there any impact?
> 4) If PcdCpuStackGuard is TRUE, and CPU driver is not consuming existing API 
> in
> ExceptionLib. Is there any impact?
> 
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 23, 2017 2:09 PM
> > To: 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: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> > If PcdCpuStackGuard is not enabled, there's no impact. If it's enabled, the 
> > only
> > issue is that the exception dump cannot be done but no other impact. From
> this
> > point of view, maybe PcdCpuStackGuard should be FALSE by default.
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Thursday, November 23, 2017 1:59 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>; Dong, Eric
> > > <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > > Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > > switch support
> > >
> > > One more question:
> > > I notice not all platforms are using the CpuDxe in UefiCpuPkg.
> > > If so, is there any impact to the platform whose CPU driver does not have
> such
> > > InitializeCpuExceptionStackSwitchHandlers() call?
> > > Have you tested that condition?
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Yao,
> > > > Jiewen
> > > > Sent: Thursday, November 23, 2017 1:50 PM
> > > > To: 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: Re: [edk2

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

If PcdCpuStackGuard is not enabled, there's no impact. If it's enabled, the only
issue is that the exception dump cannot be done but no other impact. From this
point of view, maybe PcdCpuStackGuard should be FALSE by default.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 1:59 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>; Dong, Eric
> <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch support
> 
> One more question:
> I notice not all platforms are using the CpuDxe in UefiCpuPkg.
> If so, is there any impact to the platform whose CPU driver does not have such
> InitializeCpuExceptionStackSwitchHandlers() call?
> Have you tested that condition?
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao,
> > Jiewen
> > Sent: Thursday, November 23, 2017 1:50 PM
> > To: 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: Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add
> > stack switch support
> >
> > Some thought:
> >
> > 1) I found InitializeCpuExceptionStackSwitchHandlers() is only implemented 
> > in
> > DxeException.c.
> > What about Pei/Smm instance?
> >
> > I think it is OK to not implement it at this moment. But we need make sure 
> > no
> > architecture issue if we want to enable it some time later.
> >
> > 2) #define IA32_GDT_TYPE_TSS   0x9
> > This is generic, can we move to BaseLib.h?
> >
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > > -Original Message-
> > > From: Wang, Jian J
> > > Sent: Wednesday, November 22, 2017 4:46 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 v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch
> > > support
> > >
> > > > v2:
> > > >a. Move common TSS structure and API definitions to BaseLib.h
> > > >b. Add EXCEPTION_STACK_SWITCH_DATA to convery data used to setup
> > > stack
> > > >   switch. This can avoid allocating memory for it in this library.
> > > >c. Add globals to reserve memory for stack switch initialized in 
> > > > early
> > > >   phase of DXE core.
> > > >d. Remove the filter code used to exclude boot modes which doesn't
> > > support
> > > >   memory allocation because those memory can passed in by
> > parameter
> > > now.
> > > >e. Remove the nasm macro to define exception handler one by one and
> > > add a
> > > >   function to return the start address of each handler.
> > >
> > > 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 

Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP

[Wang, Jian J]

Hi,

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 23, 2017 12:14 PM
> 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>;
> Kinney, Michael D <michael.d.kin...@intel.com>
> Subject: RE: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> 
> Hi
> 1) Can we enable this feature in early DxeCore?
> 
Yes. Intead of calling InitializeExceptionStackSwitchHandlers () directly in 
DxeCore,
InitializeCpuExceptionHandlers() calls InitializeExceptionStackSwitchHandlers().

I think it's reasonable to do this because 
InitializeExceptionStackSwitchHandlers()
is arch dependent. It'd be better not to call it in DxeCore. Another benefit is 
that 
this can avoid backward compatibility issue introduced by new API, which hasn't 
been implemented by cpu driver or lib of other archs.

> Current DxeCore still calling InitializeCpuExceptionHandlers().
> But I hope InitializeExceptionStackSwitchHandlers() can be used here.
> 
> In order to handle buffer from different arch, the DxeIpl can help provide 
> some
> data in hob and pass to DxeCore.
> 
> 2) In addition, InitializeCpuExceptionHandlers () has VectorInfoList as 
> parameter.
> Do we also need that for InitializeExceptionStackSwitchHandlers()?
> 
I don't see the need. Do you have any use cases in mind?

> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Wednesday, November 22, 2017 4:46 PM
> > To: edk2-devel@lists.01.org
> > Cc: Dong, Eric <eric.d...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> Yao,
> > Jiewen <jiewen@intel.com>; Kinney, Michael D
> > <michael.d.kin...@intel.com>
> > Subject: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> >
> > > v2:
> > >Add code to reserve resources and initialize AP exception with stack
> > >switch besides BSP, if PcdCpuStackGuard is enabled.
> >
> > In current MP implementation, BSP and AP shares the same exception
> > configuration. Stack switch required by Stack Guard feature needs that BSP
> > and AP have their own configuration. This patch adds code to ask BSP and AP
> > to do exception handler initialization separately.
> >
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.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>
> > ---
> >  UefiCpuPkg/CpuDxe/CpuDxe.inf |   3 +
> >  UefiCpuPkg/CpuDxe/CpuMp.c| 168
> > +++
> >  UefiCpuPkg/CpuDxe/CpuMp.h|  12 
> >  3 files changed, 183 insertions(+)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > index 3e8d196739..02f86b774c 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > +++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
> > @@ -81,6 +81,9 @@
> >
> >  [Pcd]
> >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
> > ## CONSUMES
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard
> > ## CONSUMES
> > +  gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList
> > ## CONSUMES
> > +  gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize
> > ## CONSUMES
> >
> >  [Depex]
> >TRUE
> > diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
> > index b3c0178d07..6b2ceacb39 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuMp.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
> > @@ -601,6 +601,169 @@ CollectBistDataFromHob (
> >}
> >  }
> >
> > +/**
> > +  Get GDT register content.
> > +
> > +  This function is mainly for AP purpose because AP may have different GDT
> > +  table than BSP.
> > +
> > +**/
> > +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 InitializeCpuExceptionStackSwitchHandlers.
> > +  It's mainly for AP purpose because of EFI_AP_PROCEDURE API requirement.
> > +
> > +**/
> > +VOID
> > +EFIAPI
> > +InitializeExceptionStackSwi

Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP

[Wang, Jian J]

About 1), the code is in [PATCH v2 7/8]. Following is part of it.

@@ -63,10 +67,34 @@ InitializeCpuExceptionHandlers (
   IN EFI_VECTOR_HANDOFF_INFO   *VectorInfo OPTIONAL
   )
 {
+  EFI_STATUSStatus;
+  EXCEPTION_STACK_SWITCH_DATA   StackSwitchData;
+  IA32_DESCRIPTOR   Idtr;
+  IA32_DESCRIPTOR   Gdtr;
+
   mExceptionHandlerData.ReservedVectors  = mReservedVectorsData;
   mExceptionHandlerData.ExternalInterruptHandler = 
mExternalInterruptHandlerTable;
   InitializeSpinLock ();
-  return InitializeCpuExceptionHandlersWorker (VectorInfo, 
);
+  Status = InitializeCpuExceptionHandlersWorker (VectorInfo, 
);
+  if (!EFI_ERROR (Status) && PcdGetBool (PcdCpuStackGuard)) {
+AsmReadIdtr ();
+AsmReadGdtr ();
+
+StackSwitchData.StackTop = (UINTN)mNewStack;
+StackSwitchData.StackSize = CPU_KNOWN_GOOD_STACK_SIZE;
+StackSwitchData.Exceptions = CPU_STACK_SWITCH_EXCEPTION_LIST;
+StackSwitchData.ExceptionNumber = CPU_STACK_SWITCH_EXCEPTION_NUMBER;
+StackSwitchData.IdtTable = (IA32_IDT_GATE_DESCRIPTOR *)Idtr.Base;
+StackSwitchData.GdtTable = (IA32_SEGMENT_DESCRIPTOR *)mNewGdt;
+StackSwitchData.GdtSize = sizeof (mNewGdt);
+StackSwitchData.TssDesc = (IA32_TSS_DESCRIPTOR *)(mNewGdt + Gdtr.Limit + 
1);
+StackSwitchData.Tss = (IA32_TASK_STATE_SEGMENT *)(mNewGdt + Gdtr.Limit + 1 
+
+  CPU_TSS_DESC_SIZE);
+Status = InitializeCpuExceptionStackSwitchHandlers (
+   
+   );
+  }
+  return Status;
 }

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Thursday, November 23, 2017 1:04 PM
> To: Yao, Jiewen <jiewen@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek
> <ler...@redhat.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch
> for MP
> 
> Hi,
> 
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Thursday, November 23, 2017 12:14 PM
> > 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>;
> > Kinney, Michael D <michael.d.kin...@intel.com>
> > Subject: RE: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for 
> > MP
> >
> > Hi
> > 1) Can we enable this feature in early DxeCore?
> >
> Yes. Intead of calling InitializeExceptionStackSwitchHandlers () directly in
> DxeCore,
> InitializeCpuExceptionHandlers() calls 
> InitializeExceptionStackSwitchHandlers().
> 
> I think it's reasonable to do this because 
> InitializeExceptionStackSwitchHandlers()
> is arch dependent. It'd be better not to call it in DxeCore. Another benefit 
> is that
> this can avoid backward compatibility issue introduced by new API, which 
> hasn't
> been implemented by cpu driver or lib of other archs.
> 
> > Current DxeCore still calling InitializeCpuExceptionHandlers().
> > But I hope InitializeExceptionStackSwitchHandlers() can be used here.
> >
> > In order to handle buffer from different arch, the DxeIpl can help provide 
> > some
> > data in hob and pass to DxeCore.
> >
> > 2) In addition, InitializeCpuExceptionHandlers () has VectorInfoList as
> parameter.
> > Do we also need that for InitializeExceptionStackSwitchHandlers()?
> >
> I don't see the need. Do you have any use cases in mind?
> 
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Wang, Jian J
> > > Sent: Wednesday, November 22, 2017 4:46 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Dong, Eric <eric.d...@intel.com>; Laszlo Ersek <ler...@redhat.com>;
> > Yao,
> > > Jiewen <jiewen@intel.com>; Kinney, Michael D
> > > <michael.d.kin...@intel.com>
> > > Subject: [PATCH v2 8/8] UefiCpuPkg/CpuDxe: Initialize stack switch for MP
> > >
> > > > v2:
> > > >Add code to reserve resources and initialize AP exception with stack
> > > >switch besides BSP, if PcdCpuStackGuard is enabled.
> > >
> > > In current MP implementation, BSP and AP shares the same exception
> > > configuration. Stack switch required by Stack Guard feature needs that BSP
> > > and AP have their own configuration. This patch adds code to ask BSP and 
> > > AP
> > > to do exception handler initialization separately.
> > >
> > > Cc: Eric Dong <eric.d...@intel.com>
> > > Cc: Laszlo E

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

[Wang, Jian J]

Yes, I validated them manually with JTAG debug tool. 

 if ((L3PageTable[Index3] & IA32_PG_PS) != 0) {
   // 1G page. Split to 2M.
   L2PageTable = AllocatePages (1);
   ASSERT (L2PageTable != NULL);
PhysicalAddress = L3PageTable[Index3] & PAGING_1G_ADDRESS_MASK_64;
for (Index = 0; Index < EFI_PAGE_SIZE/sizeof (UINT64); ++Index) {
 L2PageTable[Index] = PhysicalAddress  | AddressEncMask |
  IA32_PG_PS | IA32_PG_P | IA32_PG_RW;
 PhysicalAddress += SIZE_2MB;
   }
   L3PageTable[Index3] = (UINT64) (UINTN) L2PageTable | AddressEncMask |
  IA32_PG_P | IA32_PG_RW;
   SetPageReadOnly (PageTableBase, (EFI_PHYSICAL_ADDRESS)(UINTN)L2PageTable);
 }

The newly allocated page table is set in the SetPageReadOnly() itself 
recursively, like
above code in which L2PageTable is allocated and then set it to be read-only 
after
initializing the table content.

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, November 29, 2017 5:16 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> 
> Thanks.
> 
> May I know if this is validated in uefi shell, that all page table is 
> readonly?
> 
> I did not find the code to set new allocated split page to be readonly. Can 
> you
> give me a hand on that?
> 
> thank you!
> Yao, Jiewen
> 
> 
> > 在 2017年11月29日，下午4:47，Jian J Wang <jian.j.w...@intel.com> 写
> 道：
> >
> > 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):
> > UefiCpuPkg/CpuDxe: Check CR0.WP before changing page table
> > MdeModulePkg/DxeIpl: Mark page table as read-only
> >
> > MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 166
> +++
> > MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  14 ++
> > UefiCpuPkg/CpuDxe/CpuPageTable.c |  65 -
> > 3 files changed, 241 insertions(+), 4 deletions(-)
> >
> > --
> > 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 0/2] Enable page table write protection

[Wang, Jian J]

There's already issue found. So there must be v2. Please wait for it.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, November 29, 2017 8:39 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> 
> Hi Jian,
> 
> On 11/29/17 09:46, Jian J Wang wrote:
> > 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):
> >   UefiCpuPkg/CpuDxe: Check CR0.WP before changing page table
> >   MdeModulePkg/DxeIpl: Mark page table as read-only
> >
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 166
> +++
> >  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  14 ++
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c |  65 -
> >  3 files changed, 241 insertions(+), 4 deletions(-)
> >
> 
> thanks for the CC -- I'd like to test this feature.
> 
> Is it OK if I wait 1-2 days first, to see if there is review feedback
> that requires a v2?
> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Wang, Jian J]

It's in the DxeIplPeim.

By the way, there's an issue in this patch. I forgot to protect page table for 
32-bit mode.
So this patch works only for 64-bit mode. I'll add it in v2 patch. 

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, November 29, 2017 6:56 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> 
> Is this code in CPU driver?
> 
> thank you!
> Yao, Jiewen
> 
> 
> > 在 2017年11月29日，下午6:24，Wang, Jian J <jian.j.w...@intel.com> 写
> 道：
> >
> > Yes, I validated them manually with JTAG debug tool.
> >
> > if ((L3PageTable[Index3] & IA32_PG_PS) != 0) {
> >   // 1G page. Split to 2M.
> >   L2PageTable = AllocatePages (1);
> >   ASSERT (L2PageTable != NULL);
> >PhysicalAddress = L3PageTable[Index3] & PAGING_1G_ADDRESS_MASK_64;
> >for (Index = 0; Index < EFI_PAGE_SIZE/sizeof (UINT64); ++Index) {
> > L2PageTable[Index] = PhysicalAddress  | AddressEncMask |
> >  IA32_PG_PS | IA32_PG_P | IA32_PG_RW;
> > PhysicalAddress += SIZE_2MB;
> >   }
> >   L3PageTable[Index3] = (UINT64) (UINTN) L2PageTable | AddressEncMask |
> >  IA32_PG_P | IA32_PG_RW;
> >   SetPageReadOnly (PageTableBase,
> (EFI_PHYSICAL_ADDRESS)(UINTN)L2PageTable);
> > }
> >
> > The newly allocated page table is set in the SetPageReadOnly() itself
> recursively, like
> > above code in which L2PageTable is allocated and then set it to be read-only
> after
> > initializing the table content.
> >
> >> -Original Message-
> >> From: Yao, Jiewen
> >> Sent: Wednesday, November 29, 2017 5:16 PM
> >> To: Wang, Jian J <jian.j.w...@intel.com>
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> >>
> >> Thanks.
> >>
> >> May I know if this is validated in uefi shell, that all page table is 
> >> readonly?
> >>
> >> I did not find the code to set new allocated split page to be readonly. 
> >> Can you
> >> give me a hand on that?
> >>
> >> thank you!
> >> Yao, Jiewen
> >>
> >>
> >>> 在 2017年11月29日，下午4:47，Jian J Wang <jian.j.w...@intel.com>
> 写
> >> 道：
> >>>
> >>> 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):
> >>> UefiCpuPkg/CpuDxe: Check CR0.WP before changing page table
> >>> MdeModulePkg/DxeIpl: Mark page table as read-only
> >>>
> >>> MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 166
> >> +++
> >>> MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  14 ++
> >>> UefiCpuPkg/CpuDxe/CpuPageTable.c |  65 -
> >>> 3 files changed, 241 insertions(+), 4 deletions(-)
> >>>
> >>> --
> >>> 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 0/2] Enable page table write protection

[Wang, Jian J]

I did think of protecting new page table in cpu driver. But I think there's 
risks
to do it, which is that there might be a chance that, whenever you're trying to
mark one page used as page table to be read-only, you need to split its page
table in advance, and again and again, until all page tables are for 4KB pages.

Although this is a rare case, or the page table "split" will just happen for a 
few
times, it will slow down the boot process a little bit anyway. So I though  it's
safer not to protect new page tables created after DxeIpl.

Maybe it's just over worrying about it. Maybe we just need to add a PCD to 
turn on/off it just in case. Do you have any ideas in mind?

> -Original Message-
> From: Yao, Jiewen
> Sent: Wednesday, November 29, 2017 9:35 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> 
> I do think we need update CPU driver to protect new allocated split page.
> 
> If you verified in shell env, I think it will exposed, please add a test to 
> trigger
> page split in CPU driver.
> 
> I recommend to write some unit test to parse page table in shell.
> 
> thank you!
> Yao, Jiewen
> 
> 
> > 在 2017年11月29日，下午8:15，Wang, Jian J <jian.j.w...@intel.com> 写
> 道：
> >
> > It's in the DxeIplPeim.
> >
> > By the way, there's an issue in this patch. I forgot to protect page table 
> > for 32-
> bit mode.
> > So this patch works only for 64-bit mode. I'll add it in v2 patch.
> >
> >> -Original Message-
> >> From: Yao, Jiewen
> >> Sent: Wednesday, November 29, 2017 6:56 PM
> >> To: Wang, Jian J <jian.j.w...@intel.com>
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> >>
> >> Is this code in CPU driver?
> >>
> >> thank you!
> >> Yao, Jiewen
> >>
> >>
> >>> 在 2017年11月29日，下午6:24，Wang, Jian J <jian.j.w...@intel.com>
> 写
> >> 道：
> >>>
> >>> Yes, I validated them manually with JTAG debug tool.
> >>>
> >>> if ((L3PageTable[Index3] & IA32_PG_PS) != 0) {
> >>>  // 1G page. Split to 2M.
> >>>  L2PageTable = AllocatePages (1);
> >>>  ASSERT (L2PageTable != NULL);
> >>>   PhysicalAddress = L3PageTable[Index3] & PAGING_1G_ADDRESS_MASK_64;
> >>>   for (Index = 0; Index < EFI_PAGE_SIZE/sizeof (UINT64); ++Index) {
> >>>L2PageTable[Index] = PhysicalAddress  | AddressEncMask |
> >>> IA32_PG_PS | IA32_PG_P | IA32_PG_RW;
> >>>PhysicalAddress += SIZE_2MB;
> >>>  }
> >>>  L3PageTable[Index3] = (UINT64) (UINTN) L2PageTable | AddressEncMask |
> >>> IA32_PG_P | IA32_PG_RW;
> >>>  SetPageReadOnly (PageTableBase,
> >> (EFI_PHYSICAL_ADDRESS)(UINTN)L2PageTable);
> >>> }
> >>>
> >>> The newly allocated page table is set in the SetPageReadOnly() itself
> >> recursively, like
> >>> above code in which L2PageTable is allocated and then set it to be 
> >>> read-only
> >> after
> >>> initializing the table content.
> >>>
> >>>> -Original Message-
> >>>> From: Yao, Jiewen
> >>>> Sent: Wednesday, November 29, 2017 5:16 PM
> >>>> To: Wang, Jian J <jian.j.w...@intel.com>
> >>>> Cc: edk2-devel@lists.01.org
> >>>> Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> >>>>
> >>>> Thanks.
> >>>>
> >>>> May I know if this is validated in uefi shell, that all page table is 
> >>>> readonly?
> >>>>
> >>>> I did not find the code to set new allocated split page to be readonly. 
> >>>> Can
> you
> >>>> give me a hand on that?
> >>>>
> >>>> thank you!
> >>>> Yao, Jiewen
> >>>>
> >>>>
> >>>>> 在 2017年11月29日，下午4:47，Jian J Wang <jian.j.w...@intel.com>
> >> 写
> >>>> 道：
> >>>>>
> >>>>> 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
> t

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

[Wang, Jian J]

When you split page tables, you need to allocate new pages for new page table.
Since you have new page tables added, you need to mark them to be read-only
as well, right? When you do this, the page table for the memory newly allocated
might still needs to be split. This is the worst case but there's still chance 
of it,
right? We cannot guarantee, theoretically, the page table for the newly 
allocated
page tables is in the same as just split ones. So, in worst case, once we want 
to
mark new page table to be read-only, we need to split the page table managing
those memory, and if we need to do split, we need to allocate more new pages.
This might fall into a recursive situation until all the smallest page table 
are created.
In practice it's almost impossible to let it happen but the chances are we will 
fall into 
such recursive situation more than one level.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 30, 2017 8:52 AM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> 
> -- whenever you're trying to mark one page used as page table to be read-only,
> you need to split its page table in advance
> [Jiewen] Sorry, I do not quite understand the problem statement.
> To set a page to be ReadOnly, you just flip the R/W bit in the page entry.
> The step I expect is:
> 1) You split page table.
> 2) Fill the data structure in the new entry.
> 3) Flip R/W bit (<== This is the new step).
> 4) FlushPageTable.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 30, 2017 8:44 AM
> > To: Yao, Jiewen <jiewen@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> >
> > I did think of protecting new page table in cpu driver. But I think there's 
> > risks
> > to do it, which is that there might be a chance that, whenever you're 
> > trying to
> > mark one page used as page table to be read-only, you need to split its page
> > table in advance, and again and again, until all page tables are for 4KB 
> > pages.
> >
> > Although this is a rare case, or the page table "split" will just happen 
> > for a few
> > times, it will slow down the boot process a little bit anyway. So I though  
> > it's
> > safer not to protect new page tables created after DxeIpl.
> >
> > Maybe it's just over worrying about it. Maybe we just need to add a PCD to
> > turn on/off it just in case. Do you have any ideas in mind?
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Wednesday, November 29, 2017 9:35 PM
> > > To: Wang, Jian J <jian.j.w...@intel.com>
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> > >
> > > I do think we need update CPU driver to protect new allocated split page.
> > >
> > > If you verified in shell env, I think it will exposed, please add a test 
> > > to trigger
> > > page split in CPU driver.
> > >
> > > I recommend to write some unit test to parse page table in shell.
> > >
> > > thank you!
> > > Yao, Jiewen
> > >
> > >
> > > > 在 2017年11月29日，下午8:15，Wang, Jian J <jian.j.w...@intel.com>
> > 写
> > > 道：
> > > >
> > > > It's in the DxeIplPeim.
> > > >
> > > > By the way, there's an issue in this patch. I forgot to protect page 
> > > > table for
> > 32-
> > > bit mode.
> > > > So this patch works only for 64-bit mode. I'll add it in v2 patch.
> > > >
> > > >> -Original Message-
> > > >> From: Yao, Jiewen
> > > >> Sent: Wednesday, November 29, 2017 6:56 PM
> > > >> To: Wang, Jian J <jian.j.w...@intel.com>
> > > >> Cc: edk2-devel@lists.01.org
> > > >> Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> > > >>
> > > >> Is this code in CPU driver?
> > > >>
> > > >> thank you!
> > > >> Yao, Jiewen
> > > >>
> > > >>
> > > >>> 在 2017年11月29日，下午6:24，Wang, Jian J
> <jian.j.w...@intel.com>
> > > 写
> > > >> 道：
> > > >>>
> > > >>> Yes, I validated them manually with JTAG debug tool.
> > > >>>
> > > >>> if ((L3PageTable[Index

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

[Wang, Jian J]

Good idea. I think it will highly reduce the possibility but not solve it still.
The dilemma here is: do we need to take care of it? This issue exists in theory
but has not yet been encountered in practice.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 30, 2017 9:36 AM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> 
> Can you just allocate 1 more page for split?
> If new one need split, you can just use the additional page.
> If not, you can free it later.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 30, 2017 9:17 AM
> > To: Yao, Jiewen <jiewen@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> >
> > When you split page tables, you need to allocate new pages for new page
> table.
> > Since you have new page tables added, you need to mark them to be read-only
> > as well, right? When you do this, the page table for the memory newly
> allocated
> > might still needs to be split. This is the worst case but there's still 
> > chance of it,
> > right? We cannot guarantee, theoretically, the page table for the newly
> allocated
> > page tables is in the same as just split ones. So, in worst case, once we 
> > want to
> > mark new page table to be read-only, we need to split the page table
> managing
> > those memory, and if we need to do split, we need to allocate more new
> pages.
> > This might fall into a recursive situation until all the smallest page 
> > table are
> > created.
> > In practice it's almost impossible to let it happen but the chances are we 
> > will
> fall
> > into
> > such recursive situation more than one level.
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Thursday, November 30, 2017 8:52 AM
> > > To: Wang, Jian J <jian.j.w...@intel.com>
> > > Cc: edk2-devel@lists.01.org
> > > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> > >
> > > -- whenever you're trying to mark one page used as page table to be read-
> only,
> > > you need to split its page table in advance
> > > [Jiewen] Sorry, I do not quite understand the problem statement.
> > > To set a page to be ReadOnly, you just flip the R/W bit in the page entry.
> > > The step I expect is:
> > > 1) You split page table.
> > > 2) Fill the data structure in the new entry.
> > > 3) Flip R/W bit (<== This is the new step).
> > > 4) FlushPageTable.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > > -Original Message-
> > > > From: Wang, Jian J
> > > > Sent: Thursday, November 30, 2017 8:44 AM
> > > > To: Yao, Jiewen <jiewen@intel.com>
> > > > Cc: edk2-devel@lists.01.org
> > > > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> > > >
> > > > I did think of protecting new page table in cpu driver. But I think 
> > > > there's
> risks
> > > > to do it, which is that there might be a chance that, whenever you're 
> > > > trying
> to
> > > > mark one page used as page table to be read-only, you need to split its
> page
> > > > table in advance, and again and again, until all page tables are for 4KB
> pages.
> > > >
> > > > Although this is a rare case, or the page table "split" will just 
> > > > happen for a
> few
> > > > times, it will slow down the boot process a little bit anyway. So I 
> > > > though
> it's
> > > > safer not to protect new page tables created after DxeIpl.
> > > >
> > > > Maybe it's just over worrying about it. Maybe we just need to add a PCD 
> > > > to
> > > > turn on/off it just in case. Do you have any ideas in mind?
> > > >
> > > > > -Original Message-
> > > > > From: Yao, Jiewen
> > > > > Sent: Wednesday, November 29, 2017 9:35 PM
> > > > > To: Wang, Jian J <jian.j.w...@intel.com>
> > > > > Cc: edk2-devel@lists.01.org
> > > > > Subject: Re: [edk2] [PATCH 0/2] Enable page table write protection
> > > > >
> > > > > I do think we need update CPU driver to protect new allocated split 
> > > > > p

Re: [edk2] [PATCH] MdeModulePkg/Core: Merge memory map after filtering paging capability

[Wang, Jian J]

Make sense. Thanks for the comment.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 28, 2017 2:21 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: Re: [edk2] [PATCH] MdeModulePkg/Core: Merge memory map after
> filtering paging capability
> 
> Hello Jian,
> 
> On 11/27/17 06:34, Jian J Wang wrote:
> > Once the paging capabilities were filtered out, there might be some adjacent
> entries
> > sharing the same capabilities. It's recommended to merge those entries for 
> > the
> OS
> > compatibility purpose.
> >
> > This patch makes use of existing method MergeMemoryMap() to do it. This is
> done by
> > simply turning this method from static to extern, and call it after filter 
> > code.
> >
> > This patch is related to an issue described at
> >https://bugzilla.tianocore.org/show_bug.cgi?id=753
> >
> > This patch is also passed test of booting follow OSs:
> > Windows 10
> > Windows Server 2016
> > Fedora 26
> > Fedora 25
> >
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Star Zeng <star.z...@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>
> > ---
> >  MdeModulePkg/Core/Dxe/DxeMain.h  | 18 ++
> >  MdeModulePkg/Core/Dxe/Mem/Page.c |  1 +
> >  MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c |  1 -
> >  3 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h
> b/MdeModulePkg/Core/Dxe/DxeMain.h
> > index 1a0babba71..07b86ba696 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
> > @@ -2948,4 +2948,22 @@ ApplyMemoryProtectionPolicy (
> >IN  UINT64Length
> >);
> >
> > +/**
> > +  Merge continous memory map entries whose have same attributes.
> > +
> > +  @param  MemoryMap   A pointer to the buffer in which firmware places
> > +  the current memory map.
> > +  @param  MemoryMapSize   A pointer to the size, in bytes, of the
> > +  MemoryMap buffer. On input, this is the size of
> > +  the current memory map.  On output,
> > +  it is the size of new memory map after merge.
> > +  @param  DescriptorSize  Size, in bytes, of an individual
> EFI_MEMORY_DESCRIPTOR.
> > +**/
> > +VOID
> > +MergeMemoryMap (
> > +  IN OUT EFI_MEMORY_DESCRIPTOR  *MemoryMap,
> > +  IN OUT UINTN  *MemoryMapSize,
> > +  IN UINTN  DescriptorSize
> > +  );
> > +
> >  #endif
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > index 962ae90d3d..ca4ce69a3f 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > @@ -1915,6 +1915,7 @@ CoreGetMemoryMap (
> >EFI_MEMORY_XP);
> >  MemoryMap = NEXT_MEMORY_DESCRIPTOR (MemoryMap, Size);
> >}
> > +  MergeMemoryMap (MemoryMapStart, , Size);
> >
> >Status = EFI_SUCCESS;
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> > index 6cf5edcbe5..75d9b14c1f 100644
> > --- a/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> > +++ b/MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c
> > @@ -182,7 +182,6 @@ SortMemoryMap (
> >   it is the size of new memory map after 
> > merge.
> >@param  DescriptorSize Size, in bytes, of an individual
> EFI_MEMORY_DESCRIPTOR.
> >  **/
> > -STATIC
> >  VOID
> >  MergeMemoryMap (
> >IN OUT EFI_MEMORY_DESCRIPTOR  *MemoryMap,
> >
> 
> This patch looks good to me -- I expect merging the memmap can only
> collapse more entries into fewer entries, so the repro / test
> instructions that I added to the BZ earlier, and the expected OS
> behavior should remain unchanged.
> 
> I have one small suggestion: like before, I suggest keeping the local
> variables up-to-date after adding the new code, so that further code
> need not hunt down invariants as a starting step. Therefore, after the
> MergeMemoryMap() call, how about updating MemoryMapEnd, like this:
> 
>   MemoryMapEnd = (EFI_MEMORY_DESCRIPTOR *)(
>(UINT8 *)MemoryMapStart + BufferSize
>);
> 
> I think (if Jiewen and Star agree with this suggestion) that you don't
> need to post a v2 just for this.
> 
> I'm also fine with the patch if the MemoryMapEnd update is rejected.
> 
> Acked-by: Laszlo Ersek <ler...@redhat.com>
> 
> Can you please add a note to TianoCore BZ#753 when you push this?
> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

Sorry, 1.3 should be for your 1.4. I just noticed I missed your 1.3 comment.
Here's my opinion for it:

Current changes (use global variables to reserve resources) to  
InitializeCpuExceptionHandlers() is for DXE only. For PEI, if we really need to 
worry 
about the stack overflow and stack switch, we can have a different way to do 
it. For
example, we don't need to call InitializeCpuExceptionStackSwitchHandlers() 
inside
InitializeCpuExceptionHandlers(). We could call it whenever we can reserve 
memory blocks
and pass them to InitializeCpuExceptionStackSwitchHandlers() via parameter. I 
think this
is one of reason we have a separate method to initialize the exception handlers 
for the
sake of stack switch.

Calling InitializeCpuExceptionStackSwitchHandlers() inside 
InitializeCpuExceptionHandlers()
is just for the consideration of backward compatibility. Because this new API 
is just
implemented for IA32 processor at this time, calling it in DXE core will break 
the build of
other type of processors. This is another reason we have a separate method to do
exception handler initialization in a different way.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Thursday, November 23, 2017 2:44 PM
> To: 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 v2 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add
> stack switch support
> 
> 1.1) Got your point. I'll add dummy function in this patch.
> 1.2) Yep, we're on the same page.
> 1.3) Here's my opinion:
> 
> Actually almost all MP code has such assumption: any AP configuration will 
> copy
>  from BSP. If we allow AP to call InitializeCpuExceptionHandlers(), we have 
> to do
> a lot
> of other changes than just updating InitializeCpuExceptionHandlers(). If so, 
> it
> may
> be premature to figure out a solution at this patch.
> 
> In addition, CpuDxe actually calls InitializeCpuInterruptHandlers() which 
> covers
> the
> functionalities of InitializeCpuExceptionHandlers() (its settings will be
> overwritten).
> If we want AP to initialize interrupt and exception individually, maybe we 
> should
> let AP call InitializeCpuInterruptHandlers() instead.
> 
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Thursday, November 23, 2017 2:16 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 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch support
> >
> > Here is my thought for 1)
> >
> > 1.1) We must provide the InitializeCpuExceptionStackSwitchHandlers()
> > implementation in Pei instance and Smm instance.
> >
> > The basic requirement is a library instance must provide symbol for 
> > functions
> > declared in header file.
> > It is ok to return unsupported. But we MUST provide the symbol.
> >
> > 1.2) For SMM, I think our ultimate goal is to remove SMM specific stack 
> > guard,
> > and use the common one. Duplicating code is completely unnecessary, and it 
> > is
> > easy to introduce bug. And unfortunately, we already have bug in existing
> SMM
> > exception handler. -- That is a good reason to remove duplication.
> >
> > Again, it is not necessary to do it in this patch. I am totally OK to do it 
> > in
> another
> > patch.
> >
> > 1.3) For PEI, I do not think we can use current way to allocate stack in 
> > data
> > section, because it might be readonly in pre-mem phase. We must use some
> > other way.
> >
> > 1.4) I believe this patch has a hidden assumption is that:
> > InitializeCpuExceptionHandlers() won't be called by multiple APs.
> > If 2 or more APs call the it at same time, it might be broken because you 
> > use
> > mNewStack for all the callers
> > Is that right?
> >
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > > -Original Message-
> > > From: Wang, Jian J
> > > Sent: Thursday, November 23, 2017 2:06 PM
> > > To: Yao, Jiewen <jiewen@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 7/8] UefiCpuPkg/CpuExceptionHandlerLib: Add

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

[Wang, Jian J]

That's a better idea. Maybe we don't to free them but just reserve it for 
future uses.
The reserved 2MB page table can manage 1GB memory. I think in BIOS time typical
memory usage I observed is far less than that.

> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, November 30, 2017 9:59 AM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> 
> Clarify my word below:
> 
> Can you just predict and pre-allocate additional pages for future split in 
> worst
> case?
> If new one need split, you can just use the additional pages.
> If not, you can free them later.
> 
> For example, you can allocate 2M aligned memory for new pages, for make sure
> they are in same page directory.
> 
> I think it can resolve the problem.
> The key is to pre-calculate how many pages are involved in the worst case.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 30, 2017 9:47 AM
> > To: Yao, Jiewen <jiewen@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> >
> > Good idea. I think it will highly reduce the possibility but not solve it 
> > still.
> > The dilemma here is: do we need to take care of it? This issue exists in 
> > theory
> > but has not yet been encountered in practice.
> >
> > > -Original Message-
> > > From: Yao, Jiewen
> > > Sent: Thursday, November 30, 2017 9:36 AM
> > > To: Wang, Jian J <jian.j.w...@intel.com>
> > > Cc: edk2-devel@lists.01.org
> > > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> > >
> > > Can you just allocate 1 more page for split?
> > > If new one need split, you can just use the additional page.
> > > If not, you can free it later.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > > > -Original Message-
> > > > From: Wang, Jian J
> > > > Sent: Thursday, November 30, 2017 9:17 AM
> > > > To: Yao, Jiewen <jiewen@intel.com>
> > > > Cc: edk2-devel@lists.01.org
> > > > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> > > >
> > > > When you split page tables, you need to allocate new pages for new page
> > > table.
> > > > Since you have new page tables added, you need to mark them to be
> > read-only
> > > > as well, right? When you do this, the page table for the memory newly
> > > allocated
> > > > might still needs to be split. This is the worst case but there's still 
> > > > chance of
> it,
> > > > right? We cannot guarantee, theoretically, the page table for the newly
> > > allocated
> > > > page tables is in the same as just split ones. So, in worst case, once 
> > > > we
> want
> > to
> > > > mark new page table to be read-only, we need to split the page table
> > > managing
> > > > those memory, and if we need to do split, we need to allocate more new
> > > pages.
> > > > This might fall into a recursive situation until all the smallest page 
> > > > table are
> > > > created.
> > > > In practice it's almost impossible to let it happen but the chances are 
> > > > we
> will
> > > fall
> > > > into
> > > > such recursive situation more than one level.
> > > >
> > > > > -Original Message-
> > > > > From: Yao, Jiewen
> > > > > Sent: Thursday, November 30, 2017 8:52 AM
> > > > > To: Wang, Jian J <jian.j.w...@intel.com>
> > > > > Cc: edk2-devel@lists.01.org
> > > > > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> > > > >
> > > > > -- whenever you're trying to mark one page used as page table to be
> read-
> > > only,
> > > > > you need to split its page table in advance
> > > > > [Jiewen] Sorry, I do not quite understand the problem statement.
> > > > > To set a page to be ReadOnly, you just flip the R/W bit in the page 
> > > > > entry.
> > > > > The step I expect is:
> > > > > 1) You split page table.
> > > > > 2) Fill the data structure in the new entry.
> > > > > 3) Flip R/W bit (<== This is the new step).
>

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

[Wang, Jian J]

I also noticed that, in the cpu driver, there's a potential recursive calling 
of 
CpuArchProtocol->SetMemoryAttributes() which is caused by page table allocation:

(cpu)SetMemoryAttributes() -> (cpu) AssignMemoryPageAttributes () ->
-> (cpu) 
ConvertMemoryPageAttributes() ->
-> (cpu) SplitPage() ->
-> (cpu) 
AllocatePagesFunc() ->
-> (core) 
CoreAllocatePages() ->
-> 
(core)ApplyMemoryProtectionPolicy() -> 
-> (cpu)SetMemoryAttributes()

This has caused a problem in protecting page tables. Maybe your idea can help
to solve it too.


> -----Original Message-
> From: Wang, Jian J
> Sent: Thursday, November 30, 2017 10:02 AM
> To: Yao, Jiewen <jiewen@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> 
> That's a better idea. Maybe we don't to free them but just reserve it for 
> future
> uses.
> The reserved 2MB page table can manage 1GB memory. I think in BIOS time
> typical
> memory usage I observed is far less than that.
> 
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Thursday, November 30, 2017 9:59 AM
> > To: Wang, Jian J <jian.j.w...@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> >
> > Clarify my word below:
> >
> > Can you just predict and pre-allocate additional pages for future split in 
> > worst
> > case?
> > If new one need split, you can just use the additional pages.
> > If not, you can free them later.
> >
> > For example, you can allocate 2M aligned memory for new pages, for make
> sure
> > they are in same page directory.
> >
> > I think it can resolve the problem.
> > The key is to pre-calculate how many pages are involved in the worst case.
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > > -Original Message-
> > > From: Wang, Jian J
> > > Sent: Thursday, November 30, 2017 9:47 AM
> > > To: Yao, Jiewen <jiewen@intel.com>
> > > Cc: edk2-devel@lists.01.org
> > > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> > >
> > > Good idea. I think it will highly reduce the possibility but not solve it 
> > > still.
> > > The dilemma here is: do we need to take care of it? This issue exists in 
> > > theory
> > > but has not yet been encountered in practice.
> > >
> > > > -Original Message-
> > > > From: Yao, Jiewen
> > > > Sent: Thursday, November 30, 2017 9:36 AM
> > > > To: Wang, Jian J <jian.j.w...@intel.com>
> > > > Cc: edk2-devel@lists.01.org
> > > > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> > > >
> > > > Can you just allocate 1 more page for split?
> > > > If new one need split, you can just use the additional page.
> > > > If not, you can free it later.
> > > >
> > > > Thank you
> > > > Yao Jiewen
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wang, Jian J
> > > > > Sent: Thursday, November 30, 2017 9:17 AM
> > > > > To: Yao, Jiewen <jiewen@intel.com>
> > > > > Cc: edk2-devel@lists.01.org
> > > > > Subject: RE: [edk2] [PATCH 0/2] Enable page table write protection
> > > > >
> > > > > When you split page tables, you need to allocate new pages for new
> page
> > > > table.
> > > > > Since you have new page tables added, you need to mark them to be
> > > read-only
> > > > > as well, right? When you do this, the page table for the memory newly
> > > > allocated
> > > > > might still needs to be split. This is the worst case but there's 
> > > > > still chance
> of
> > it,
> > > > > right? We cannot guarantee, theoretically, the page table for the 
> > > > > newly
> > > > allocated
> > > > > page tables is in the same as just split ones. So, in worst case, 
> > > > > once we
> > want
> > > to
> > > > > mark new page table to be read-only, we need to split the page table
> > > > managing
&

Re: [edk2] [PATCH v3 07/11] ArmPkg/ArmExceptionLib: Add implementation of new API

[Wang, Jian J]

Sure. Thanks for the feedback.

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, December 04, 2017 9:59 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org; Leif Lindholm <leif.lindh...@linaro.org>; Yao,
> Jiewen <jiewen@intel.com>
> Subject: Re: [PATCH v3 07/11] ArmPkg/ArmExceptionLib: Add implementation of
> new API
> 
> On 1 December 2017 at 02:37, Jian J Wang <jian.j.w...@intel.com> wrote:
> >> v3:
> >>Newly added
> >
> > This patch add implementation of following new API introduced into
> > CpuExceptionHandlerLib. Since this lib hasn't support Stack Guard
> > and stack switch, the new method just calls original
> > InitializeCpuExceptionHandlers.
> >
> >   EFI_STATUS
> >   EFIAPI
> >   InitializeCpuExceptionHandlersEx (
> > IN EFI_VECTOR_HANDOFF_INFO*VectorInfo OPTIONAL,
> > IN CPU_EXCEPTION_INIT_DATA_EX *InitDataEx OPTIONAL
> > );
> >
> > Cc: Leif Lindholm <leif.lindh...@linaro.org>
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > 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>
> > ---
> >  ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c | 33
> 
> >  1 file changed, 33 insertions(+)
> >
> > diff --git a/ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c
> b/ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c
> > index e8ea1f159d..9fb4a05845 100644
> > --- a/ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c
> > +++ b/ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c
> > @@ -320,3 +320,36 @@ CommonCExceptionHandler(
> >
> >DefaultExceptionHandler(ExceptionType, SystemContext);
> >  }
> > +
> > +/**
> > +  Initializes all CPU exceptions entries with optional extra 
> > initializations.
> > +
> > +  By default, this method should include all functionalities implemented by
> > +  InitializeCpuExceptionHandlers(), plus extra initialization works, if 
> > any.
> > +  This is could be done by calling InitializeCpuExceptionHandlers() 
> > directly
> > +  in this method besides the extra works.
> > +
> > +  InitDataEx is optional and its use and content are processor arch 
> > dependent.
> > +  The typical usage of it is to convey resources which have to be reserved
> > +  elsewhere and are necessary for the extra initializations of exception.
> > +
> > +  @param[in]  VectorInfoPointer to reserved vector list.
> > +  @param[in]  InitDataExPointer to data optional for extra 
> > initializations
> > +of exception.
> > +
> > +  @retval EFI_SUCCESS The exceptions have been successfully
> > +  initialized.
> > +  @retval EFI_INVALID_PARAMETER   VectorInfo or InitDataEx contains
> invalid
> > +  content.
> > +
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +InitializeCpuExceptionHandlersEx (
> > +  IN EFI_VECTOR_HANDOFF_INFO*VectorInfo OPTIONAL,
> > +  IN CPU_EXCEPTION_INIT_DATA_EX *InitDataEx OPTIONAL
> > +  )
> > +{
> > +  return InitializeCpuExceptionHandlers (VectorInfo);
> > +}
> > +
> 
> I would appreciate it if you could clean up the grammar in the comment block.
> 
> Other than that,
> 
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Wang, Jian J]

Jiewen,

Thanks for the comments.

1) It's only used for Ex version of the API so I added Ex. But I don't have 
strong opinion on the name.
2) Do you mean we need to use separate the definition for IA32 and X64 even 
they share the same data?
3) Sure.
4) I'm not sure if it's necessary. But a version field won't do any harm.
5) You're right it's just for exceptions needing stack switch. I'll change the 
wording.
6) Yes. ExceptionTss is better.
7) You're right. I'll add sanity checks.
8) Yes. I think current data meets SMM requirement. Let me know if you find 
anything missing.

Jian
> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, December 05, 2017 10:03 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [edk2] [PATCH v3 00/11] Implement stack guard feature
> 
> Good enhancement. I think it resolved my compatibility concern for the old 
> API.
> 
> Some comment:
> 
> 1) Can we just use CPU_EXCEPTION_INIT_DATA instead of
> CPU_EXCEPTION_INIT_DATA_EX? I am not sure why we add _EX here.
> 
> 2) Is CPU_EXCEPTION_INIT_DATA_EX for IA32 only or both IA32/X64? I found
> "Ia32" may bring confusing here. See EFI_DEBUG_SUPPORT_PROTOCOL, we
> have Ia32 for IA32 arch, X64 for X64 arch.
> 
> //
> // Flag to indicate if default handlers should be initialized or not.
> //
> BOOLEAN   InitDefaultHandlers;
>   } Ia32;
> } CPU_EXCEPTION_INIT_DATA_EX;
> 
> 3) Can we add IdtTableSize in CPU_EXCEPTION_INIT_DATA_EX?
> 
> 4) Can we add Version field in CPU_EXCEPTION_INIT_DATA_EX? I am not sure if
> we need add more entry later.
> 
> 5) You mentioned "KnownGoodStackTop is for *ALL* exceptions".
> Does ALL here mean StackSwitchExceptionNumber, or arch specific number such
> as 0x20 for X86 system?
> I think StackSwitchExceptionNumber is enough.
> 
> 6) There might be more than one TSS entry in GDT.
> Does TssDesc/Tss in CPU_EXCEPTION_INIT_DATA_EX mean the exception Tss?
> (normal TSS does not need be reported here)
> If so, I suggest we use ExceptionTss as the keyword.
> 
> 7) Below code may cause buffer overrun on IST.
> 
>   for (Index = 0; Index < StackSwitchData->Ia32.StackSwitchExceptionNumber;
> ++Index) {
> //
> // Fixup IST
> //
> Tss->IST[Index] = StackTop;
> 
> I suggest we add some basic check for StackSwitchExceptionNumber.
> 
> 8) Do you think we need mention the TssDesc/Tss size requirement for that?
> 
>   TssDesc = StackSwitchData->Ia32.TssDesc;
>   Tss = StackSwitchData->Ia32.Tss;
>   for (Index = 0; Index < StackSwitchData->Ia32.StackSwitchExceptionNumber;
> ++Index) {
> TssDesc += 1;
> Tss += 1;
> 
> I suggest we add TssDescSize and TssSize in CPU_EXCEPTION_INIT_DATA_EX
> and check the size in the code.
> 
> 9) Last but not least important, have you evaluated if current
> CPU_EXCEPTION_INIT_DATA_EX is enough for SMM version stack guard
> exception?
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian
> J
> > Wang
> > Sent: Friday, December 1, 2017 10:37 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] [PATCH v3 00/11] Implement stack guard feature
> >
> > > 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.
&

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

[Wang, Jian J]

It's for sharing the pool between the DxeIpl and CpuDxe. If we don't care about 
wasting a little bit memory, it's ok to drop this definition. CpuDxe can reserve
a block of memory for page table for its own uses.

> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, December 05, 2017 10:27 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; Zeng, Star <star.z...@intel.com>;
> edk2-devel@lists.01.org
> Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: RE: [edk2] [PATCH v2 0/4] Enable page table write protection
> 
> I do not suggest we define PAGE_TABLE_POOL_HEADER.
> If we can figure out other way, that will be better.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Monday, December 4, 2017 5:26 PM
> > To: Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>;
> Dong,
> > Eric <eric.d...@intel.com>
> > Subject: RE: [edk2] [PATCH v2 0/4] Enable page table write protection
> >
> > 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 v2 0/4] Enable page table write protection

[Wang, Jian J]

I haven't got time to do it in automatic way. V1 may need a shell app to
check it, but current implementation might not need it because we now
have 2 or 3 continuous 2MB pages to hold all page tables. We just
need to verify the page attribute of those 2 or 3 page tables. It's easy
to do it in a JTAG debugger manually.

> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, December 05, 2017 10:32 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>
> Subject: RE: [edk2] [PATCH v2 0/4] Enable page table write protection
> 
> Hi Jian
> In V1 review, I suggest to test in UEFI shell env to make sure all page table 
> is
> read only, with PageTable split in CPU driver.
> 
> May I know if that is done?
> 
> Thank you
> Yao Jiewen
> 
> > -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] UefiCpuPkg/CpuDxe: Add initialization to local variable

[Wang, Jian J]

Got it. Thanks for the feedback.

Regards,
Jian

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, December 12, 2017 5:27 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Wu, Hao A <hao.a...@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: Add initialization to local
> variable
> 
> Hello Jian,
> 
> On 12/12/17 04:28, Jian J Wang wrote:
> > The purpose of the patch is just to avoid complaining from compiler and
> > static check tool.
> >
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Wu Hao <hao.a...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/CpuDxe/CpuMp.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
> > index 56ba026152..61018c9950 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuMp.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuMp.c
> > @@ -695,6 +695,8 @@ InitializeMpExceptionStackSwitchHandlers (
> >EssData.Ia32.StackSwitchExceptionNumber = ExceptionNumber;
> >EssData.Ia32.KnownGoodStackSize =
> FixedPcdGet32(PcdCpuKnownGoodStackSize);
> >
> > +  Gdtr.Base = 0;
> > +  Gdtr.Limit = 0;
> >MpInitLibWhoAmI ();
> >for (Index = 0; Index < mNumberOfProcessors; ++Index) {
> >  //
> >
> 
> (1) Please add a separate comment, in the style that is described in
> <https://bugzilla.tianocore.org/show_bug.cgi?id=607>:
> 
>   //
>   // set Gdtr to suppress incorrect compiler/analyzer warnings
>   //
>   Gdtr.Base = 0;
>   Gdtr.Limit = 0;
> 
> 
> (2) I suggest updating the subject line like this:
> 
> UefiCpuPkg/CpuDxe: suppress invalid warning about uninitialized variable
> 
> (72 characters)
> 
> With those changes:
> 
> Reviewed-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 v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in memory map

[Wang, Jian J]

AE476000-AE479FFF 0004 
8002000F
RT_CodeAE47A000-AE47 0006 
8000400F
RT_CodeAE48-AE481FFF 0002 
8002000F
RT_CodeAE482000-AE487FFF 0006 
8000400F
RT_CodeAE488000-AE489FFF 0002 
8002000F
RT_CodeAE48A000-AE48EFFF 0005 
8000400F
Reserved   AE48F000-AE58EFFF 0100 
000F

You may notice that 4) will fail but 6) will succeed. Taking into account the 
fact that failure
always happened in the runtime service api (set_variable), I think it must be 
that the kernel will
mark the memory block to be RO/XP/RP memory according to its capabilities but 
not its current
attributes. 

This can explain why 4) will fail but 6) will succeed. Although memmap shows 
all runtime 
driver image memory as RT_Code, but they're not all code segment. Instead some 
of them are 
actually data segment.

It's normal to mark code segment to be RO and data segment to be XP. But mark 
data segment
to be RO will cause runtime services failure. 4) shows all RT_Code to be 
XXX24XXX, which means
Fedora kernel will mark all code segment and data segment to be RO and XP 
mistakenly, based 
on my previous hypothesis. This can also explain why 1), 2), 3) will fail the 
boot because XXX26XXX
will let Fedora kernel to mark RT_Code memory block to be not-present.

I haven't got time to look into the Linux kernel source so I can't confirm 
above analysis yet.
I think you're more familiar with kernel source than us. Maybe you could help 
to take a look.

Thanks,
Jian

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, November 10, 2017 8:24 PM
> To: Wang, Jian J <jian.j.w...@intel.com>
> Cc: edk2-devel@lists.01.org; Dong, Eric <eric.d...@intel.com>; Yao, Jiewen
> <jiewen@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>; Matt
> Fleming <m...@codeblueprint.co.uk>
> Subject: Re: [PATCH v5] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE in
> memory map
> 
> Hi Jian,
> 
> I'm CC'ing Ard and Matt, and commenting at the bottom.
> 
> On 11/10/17 02:02, Jian J Wang wrote:
> >> 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 <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 | 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 (

Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Wang, Jian J]

Thanks for the comments. V7 patch has added one more variable so that
MemoryMapStart will be kept intact.

V7 added code to merge memory map after filtering. I have verified that
the output keeps the same as v6 on both OVMF and our real platform
(default platform configuration). I think it may be not necessary to validate
all OS boot again. But if you want and have time, you can do it anyway.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 21, 2017 4:23 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>;
> Ard Biesheuvel <ard.biesheu...@linaro.org>
> Subject: Re: [edk2] [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all
> paging capabilities
> 
> On 11/16/17 08:26, Jian J Wang wrote:
> > Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
> > set attributes and change memory paging attribute accordingly.
> > But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> > value from Capabilities in GCD memory map. This might cause
> > boot problems. Clearing all paging related capabilities can
> > workaround it. The code added in this patch is supposed to
> > be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
> > is clarified in UEFI spec and adopted by both EDK-II Core and
> > all supported OSs.
> >
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > index c9219cc068..783b576e35 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
> >//
> >BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
> >
> > +  //
> > +  // WORKAROUND: Some OSs will treat
> EFI_MEMORY_DESCRIPTOR.Attribute as really
> > +  // set attributes and change memory paging attribute 
> > accordingly.
> > +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> > +  // value from Capabilities in GCD memory map. This might 
> > cause
> > +  // boot problems. Clearing all paging related capabilities 
> > can
> > +  // workaround it. Following code is supposed to be removed 
> > once
> > +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified 
> > in
> > +  // UEFI spec and adopted by both EDK-II Core and all 
> > supported
> > +  // OSs.
> > +  //
> > +  while (MemoryMapStart < MemoryMap) {
> > +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP |
> EFI_MEMORY_RO |
> > +   EFI_MEMORY_XP);
> > +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart, Size);
> > +  }
> > +
> >Status = EFI_SUCCESS;
> >
> >  Done:
> >
> 
> OK, let me check if I understand the discussion thus far, for this patch:
> 
> - Ard asked about EFI_MEMORY_WP, but clearing that bit is not necessary
> because CpuDxe does not add it anyway, in the GCD memory space map.
> 
> - The code comment might be updated (according to Jiewen's suggestion)
> before pushing the patch. I don't have any particular opinion about the
> comment.
> 
> - If I understand correctly, Jiewen agrees with applying both patches in
> this series.
> 
> 
> I have one superficial comment on this patch: in the CoreGetMemoryMap()
> function, we keep "MemoryMapStart" unchanged (after the initial
> assignment), and keep incrementing "MemoryMap". At the location where
> the new code is being added, "MemoryMap" points one past the last
> descriptor, and "MemoryMapStart" still points to the first one.
> 
> In order to keep this property for possible future "scans" of the full
> map, I would prefer keeping "MemoryMapStart" unchanged in this location,
> and using an independent loop variable.
> 
> ... On the other hand, we can easily restore "MemoryMapStart", should it
> be necessary, with the help of "BufferSize". So, I guess the function
> does not become more difficult to work with after this patch.
> 
> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
> 
> (I hope that Star and/or Jiewen will also R-b this patch, possibly with
> the updated code comment.)
> 
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Wang, Jian J]

You're right about XP/NX in this function. But from DxeCore or other drivers
perspective, they have no knowledge of current capability of NX. I think it's 
the
responsibility of cpu driver to add/remove it for the sake of GCD.

Actually Star has filed a bz to use GCD service instead of CPU arch protocol to
change memory attributes in DxeCore (like enforce image protection). If the 
knowledge between GCD and cpu mismatch, the GCD may not do right thing
upon requests. For example, if we always add XP to capability but current cpu
doesn't support it, the DxeCore or other drivers may still try to enable image
protection which won't take into effect actually.

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 21, 2017 4:32 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>; Ard Biesheuvel <ard.biesheu...@linaro.org>
> Subject: Re: [edk2] [PATCH 2/2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> On 11/16/17 08:27, Jian J Wang wrote:
> >> v6:
> >>Add ExecuteDisable feature check to include/exclude EFI_MEMORY_XP
> 
> Another change relative to v5 is the fixing of the first DEBUG_WARN
> message -- in my v5 review I had missed that the DEBUG_WARN arguments
> didn't match the preceding gDS->SetMemorySpaceCapabilities() arguments.
> 
> Yet another change that could have been (maybe) possible for this patch
> is to replace the remaining occurrences of EFI_MEMORY_PAGETYPE_MASK with
> "Capabilities". Namely, in v6, the attributes are enforced on a mask
> that is possibly wider than supported by the hardware (i.e., in case NX
> is not supported).
> 
> However, this should not be a functionality problem, because with NX
> unavailable, the GetAttributesFromPageEntry() function should never
> return EFI_MEMORY_XP. Thus, the "wider than needed" attribute setting
> will just clear EFI_MEMORY_XP.
> 
> Reviewed-by: Laszlo Ersek <ler...@redhat.com>
> 
> (I hope that Star and/or Jiewen will also R-b this patch.)
> 
> In addition, I will follow up with test results for the series.
> 
> Thanks
> Laszlo
> 
> >> 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 <eric.d...@intel.com>
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  UefiCpuPkg/CpuDxe/CpuPageTable.c | 94
> +++-
> >  1 file changed, 73 insertions(+), 21 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index d312eb66f8..3297c1900b 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -769,6 +769,20 @@ AssignMemoryPageAttributes (
> >return Status;
> >  }
> >
> > +/**
> > + Check if Execute Disable feature is enabled or not.
> > +**/
> > +BOOLEAN
> > +IsExecuteDisableEnabled (
> > +  VOID
> > +  )
> > +{
> > +  MSR_CORE_IA32_EFER_REGISTERMsrEfer;
> > +
> > +  MsrEfer.Uint64 = AsmReadMsr64 (MSR_IA32_EFER);
> > +  return (MsrEfer.Bits.NXE == 1);
> > +}
> > +

Re: [edk2] [PATCH] MdeModulePkg/Core: Fix build error with old Visual Studio

[Wang, Jian J]

Yes, MACRO should be better. It will be updated in v2 patch. Thanks for the 
comments.

> -Original Message-
> From: Zeng, Star
> Sent: Monday, November 20, 2017 1:04 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Bi, Dandan <dandan...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/Core: Fix build error with old Visual Studio
> 
> How about to use bit instead of decimal, for example BIT0 for 001, BIT2 for 
> 100
> and BIT0+BIT2 for 101, etc.
> 
> And please add detailed comments for return value of GetGuardedMemoryBits(),
> it has only VOID currently.
> 
>   @return VOID.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Monday, November 20, 2017 11:44 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Bi,
> Dandan <dandan...@intel.com>
> Subject: [PATCH] MdeModulePkg/Core: Fix build error with old Visual Studio
> 
> The build error is introduced by following check in:
>   2930ef9809976ce693d1d377851344c3b06bd926
>   235a4490c8ce8b6dbac49e6ae3559cb73d6bf620
> 
> The Visual Studio older than 2015 doesn't support constant integer
> in binary format (0bxxx). This patch change them to decimal to fix
> it.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@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>
> ---
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c   | 11 ---
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.c | 11 ---
>  2 files changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 98d597b180..259aa6c500 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -501,8 +501,13 @@ IsGuardPage (
>  {
>UINTN   BitMap;
> 
> +  //
> +  // There must be at least one guarded page before and/or after given
> +  // address if it's a Guard page. The bitmap pattern should be one of
> +  // 001, 100 and 101
> +  //
>BitMap = GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 3);
> -  return ((BitMap == 0b001) || (BitMap == 0b100) || (BitMap == 0b101));
> +  return ((BitMap == 1) || (BitMap == 4) || (BitMap == 5));
>  }
> 
>  /**
> @@ -519,7 +524,7 @@ IsHeadGuard (
>IN EFI_PHYSICAL_ADDRESSAddress
>)
>  {
> -  return (GetGuardedMemoryBits (Address, 2) == 0b10);
> +  return (GetGuardedMemoryBits (Address, 2) == 2);
>  }
> 
>  /**
> @@ -536,7 +541,7 @@ IsTailGuard (
>IN EFI_PHYSICAL_ADDRESSAddress
>)
>  {
> -  return (GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 2) == 0b01);
> +  return (GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 2) == 1);
>  }
> 
>  /**
> diff --git a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> index 6fda9ba430..676521c489 100644
> --- a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> +++ b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> @@ -513,8 +513,13 @@ IsGuardPage (
>  {
>UINTN   BitMap;
> 
> +  //
> +  // There must be at least one guarded page before and/or after given
> +  // address if it's a Guard page. The bitmap pattern should be one of
> +  // 001, 100 and 101
> +  //
>BitMap = GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 3);
> -  return ((BitMap == 0b001) || (BitMap == 0b100) || (BitMap == 0b101));
> +  return ((BitMap == 1) || (BitMap == 4) || (BitMap == 5));
>  }
> 
>  /**
> @@ -531,7 +536,7 @@ IsHeadGuard (
>IN EFI_PHYSICAL_ADDRESSAddress
>)
>  {
> -  return (GetGuardedMemoryBits (Address, 2) == 0b10);
> +  return (GetGuardedMemoryBits (Address, 2) == 2);
>  }
> 
>  /**
> @@ -548,7 +553,7 @@ IsTailGuard (
>IN EFI_PHYSICAL_ADDRESSAddress
>)
>  {
> -  return (GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 2) == 0b01);
> +  return (GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 2) == 1);
>  }
> 
>  /**
> --
> 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 v2] MdeModulePkg/Core: Fix build error with old Visual Studio

[Wang, Jian J]

Sure. Thanks.

> -Original Message-
> From: Zeng, Star
> Sent: Monday, November 20, 2017 2:16 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH v2] MdeModulePkg/Core: Fix build error with old
> Visual Studio
> 
> Please also update the "This patch change them to decimal to fix it" in the
> commit log accordingly, with that fixed, Reviewed-by: Star Zeng
> <star.z...@intel.com>.
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Monday, November 20, 2017 1:41 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: [edk2] [PATCH v2] MdeModulePkg/Core: Fix build error with old Visual
> Studio
> 
> > v2
> > a. Change an incorrect comment on return value
> > b. Change constants to macros
> 
> The build error is introduced by following check in:
>   2930ef9809976ce693d1d377851344c3b06bd926
>   235a4490c8ce8b6dbac49e6ae3559cb73d6bf620
> 
> The Visual Studio older than 2015 doesn't support constant integer
> in binary format (0bxxx). This patch change them to decimal to fix
> it.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@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>
> ---
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c   | 13 +
>  MdeModulePkg/Core/PiSmmCore/HeapGuard.c | 13 +
>  2 files changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 98d597b180..752befa44d 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -373,7 +373,7 @@ ClearGuardedMemoryBits (
>@param[in]  Address   Memory address to retrieve from.
>@param[in]  NumberOfPages Number of pages to retrieve.
> 
> -  @return VOID.
> +  @return An integer containing the guarded memory bitmap.
>  **/
>  UINTN
>  GetGuardedMemoryBits (
> @@ -501,8 +501,13 @@ IsGuardPage (
>  {
>UINTN   BitMap;
> 
> +  //
> +  // There must be at least one guarded page before and/or after given
> +  // address if it's a Guard page. The bitmap pattern should be one of
> +  // 001, 100 and 101
> +  //
>BitMap = GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 3);
> -  return ((BitMap == 0b001) || (BitMap == 0b100) || (BitMap == 0b101));
> +  return ((BitMap == BIT0) || (BitMap == BIT2) || (BitMap == (BIT2 | BIT0)));
>  }
> 
>  /**
> @@ -519,7 +524,7 @@ IsHeadGuard (
>IN EFI_PHYSICAL_ADDRESSAddress
>)
>  {
> -  return (GetGuardedMemoryBits (Address, 2) == 0b10);
> +  return (GetGuardedMemoryBits (Address, 2) == BIT1);
>  }
> 
>  /**
> @@ -536,7 +541,7 @@ IsTailGuard (
>IN EFI_PHYSICAL_ADDRESSAddress
>)
>  {
> -  return (GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 2) == 0b01);
> +  return (GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 2) == BIT0);
>  }
> 
>  /**
> diff --git a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> index 6fda9ba430..c7a1408562 100644
> --- a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> +++ b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
> @@ -385,7 +385,7 @@ ClearGuardedMemoryBits (
>@param[in]  Address   Memory address to retrieve from.
>@param[in]  NumberOfPages Number of pages to retrieve.
> 
> -  @return VOID
> +  @return An integer containing the guarded memory bitmap.
>  **/
>  UINTN
>  GetGuardedMemoryBits (
> @@ -513,8 +513,13 @@ IsGuardPage (
>  {
>UINTN   BitMap;
> 
> +  //
> +  // There must be at least one guarded page before and/or after given
> +  // address if it's a Guard page. The bitmap pattern should be one of
> +  // 001, 100 and 101
> +  //
>BitMap = GetGuardedMemoryBits (Address - EFI_PAGE_SIZE, 3);
> -  return ((BitMap == 0b001) || (BitMap == 0b100) || (BitMap == 0b101));
> +  return ((BitMap == BIT0) || (BitMap == BIT2) || (BitMap == (BIT2 | BIT0)));
>  }
> 
>  /**
> @@ -531,7 +536,7 @@ IsHeadGuard (
>IN EFI_PHYSICAL_ADDRESSAddress
>)
>  {
> -  return (GetGuardedMemoryBits (Address, 2) == 0b10);
> +  return (GetGuardedMemoryBits (Address, 2) == BIT1);
>  }
> 
>  /**
> @@ -548,7 +553,7 @@ IsTai

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: Fix an assert issue in pool free

[Wang, Jian J]

Sure. Thanks for reminding.

> -Original Message-
> From: Zeng, Star
> Sent: Monday, November 20, 2017 10:54 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Wu, Hao A <hao.a...@intel.com>; Zeng,
> Star <star.z...@intel.com>
> Subject: RE: [PATCH] MdeModulePkg/PiSmmCore: Fix an assert issue in pool free
> 
> Reviewed-by: Star Zeng <star.z...@intel.com>
> 
> By the way, could you add comments in the commit log to say which commit is
> causing this issue?
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Monday, November 20, 2017 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Wu,
> Hao A <hao.a...@intel.com>
> Subject: [PATCH] MdeModulePkg/PiSmmCore: Fix an assert issue in pool free
> 
> This issue is caused by assigning incorrect value to PoolHdr.Size if the 
> requested
> size is more than MAX_POOL_SIZE, because the SMM core will actually allocate
> page memory instead of pool memory in this situation.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Wu Hao <hao.a...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> ---
>  MdeModulePkg/Core/PiSmmCore/Pool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/PiSmmCore/Pool.c
> b/MdeModulePkg/Core/PiSmmCore/Pool.c
> index e77caa8853..e98ce01b0f 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Pool.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Pool.c
> @@ -287,7 +287,7 @@ SmmInternalAllocatePool (
> 
>  PoolHdr = (POOL_HEADER*)(UINTN)Address;
>  PoolHdr->Signature = POOL_HEAD_SIGNATURE;
> -PoolHdr->Size = Size;
> +PoolHdr->Size = EFI_PAGES_TO_SIZE (NoPages);
>  PoolHdr->Available = FALSE;
>  PoolHdr->Type = PoolType;
> 
> --
> 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 v6 1/2] MdeModulePkg/DxeCore: Filter out all paging capabilities

[Wang, Jian J]

1) Sure. I'll update the wording.
2) I still think this is just a workaround . In the long run, I don't think the 
merge is a good idea. It looks like it will "fix" more issues, but actually it 
just "hide" them and would cause more and more workaround in the future. 
Anyway, if no one else has objections, I'll update the code.

> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, November 17, 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>; Laszlo Ersek <ler...@redhat.com>; Ard
> Biesheuvel <ard.biesheu...@linaro.org>
> Subject: RE: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging
> capabilities
> 
> HI
> I have 2 comments:
> 
> 1) I do not think we need mention: WORKAROUND.
> I suggest we just use "NOTE".
> 
> We have similar example before, see
> MdePkg\Library\BasePeCoffLib\BasePeCoff.c
>   //
>   // NOTE: Some versions of Linux ELILO for Itanium have an incorrect magic
> value
>   //   in the PE/COFF Header.  If the MachineType is Itanium(IA64) and the
>   //   Magic value in the OptionalHeader is
> EFI_IMAGE_NT_OPTIONAL_HDR32_MAGIC
>   //   then override the returned value to
> EFI_IMAGE_NT_OPTIONAL_HDR64_MAGIC
>   //
> 
> 2) I agree with Star. I think we should merge the final result.
> The suggestion before is: *Keep current UEFI memory map unchanged.*
> Changing it brings lots of risk without validating all UEFI OS.
> 
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Thursday, November 16, 2017 3:27 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen@intel.com>; Zeng, Star <star.z...@intel.com>;
> > Laszlo Ersek <ler...@redhat.com>; Ard Biesheuvel
> <ard.biesheu...@linaro.org>
> > Subject: [PATCH v6 1/2] MdeModulePkg/DxeCore: Filter out all paging
> capabilities
> >
> > Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
> > set attributes and change memory paging attribute accordingly.
> > But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
> > value from Capabilities in GCD memory map. This might cause
> > boot problems. Clearing all paging related capabilities can
> > workaround it. The code added in this patch is supposed to
> > be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
> > is clarified in UEFI spec and adopted by both EDK-II Core and
> > all supported OSs.
> >
> > Cc: Jiewen Yao <jiewen@intel.com>
> > Cc: Star Zeng <star.z...@intel.com>
> > Cc: Laszlo Ersek <ler...@redhat.com>
> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
> > ---
> >  MdeModulePkg/Core/Dxe/Mem/Page.c | 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> > b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > index c9219cc068..783b576e35 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> > @@ -1829,6 +1829,23 @@ CoreGetMemoryMap (
> >//
> >BufferSize = ((UINT8 *)MemoryMap - (UINT8 *)MemoryMapStart);
> >
> > +  //
> > +  // WORKAROUND: Some OSs will treat
> EFI_MEMORY_DESCRIPTOR.Attribute
> > as really
> > +  // set attributes and change memory paging attribute
> > accordingly.
> > +  // But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned
> > by
> > +  // value from Capabilities in GCD memory map. This might
> > cause
> > +  // boot problems. Clearing all paging related capabilities 
> > can
> > +  // workaround it. Following code is supposed to be removed
> > once
> > +  // the usage of EFI_MEMORY_DESCRIPTOR.Attribute is clarified
> > in
> > +  // UEFI spec and adopted by both EDK-II Core and all
> > supported
> > +  // OSs.
> > +  //
> > +  while (MemoryMapStart < MemoryMap) {
> > +MemoryMapStart->Attribute &= ~(UINT64)(EFI_MEMORY_RP |
> > EFI_MEMORY_RO |
> > +   EFI_MEMORY_XP);
> > +MemoryMapStart = NEXT_MEMORY_DESCRIPTOR(MemoryMapStart,
> > Size);
> > +  }
> > +
> >Status = EFI_SUCCESS;
> >
> >  Done:
> > --
> > 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 v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message

[Wang, Jian J]

I agree. Thanks for the comment.

> -Original Message-
> From: Zeng, Star
> Sent: Friday, November 17, 2017 10:31 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 v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message
> 
> According to the definitions, DEBUG_POOL and DEBUG_PAGE are for alloc &
> free pool/page.
> 
> #define DEBUG_POOL  0x0010  // Alloc & Free (pool)
> #define DEBUG_PAGE  0x0020  // Alloc & Free (page)
> 
> How about changing the debug level to DEBUG_VERBOSE?
> If you agree, you do not need send a new patch, we can update it when
> pushing. :)
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Tuesday, November 14, 2017 11:11 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen@intel.com>; Dong, Eric <eric.d...@intel.com>
> Subject: [edk2] [PATCH v6 3/7] UefiCpuPkg/CpuDxe: Reduce debug message
> 
> Heap guard feature will frequently update page attributes. The debug message
> in CpuDxe driver will slow down the boot performance noticeably. Changing the
> debug level to DEBUG_POOL and DEBUG_PAGE to reduce the message output
> for normal debug configuration.
> 
> 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>
> Reviewed-by: Jiewen Yao <jiewen@intel.com>
> Regression-tested-by: Laszlo Ersek <ler...@redhat.com>
> ---
>  UefiCpuPkg/CpuDxe/CpuPageTable.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> index d312eb66f8..5270a1124f 100644
> --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> @@ -442,8 +442,9 @@ ConvertPageEntryAttribute (
>*PageEntry = NewPageEntry;
>if (CurrentPageEntry != NewPageEntry) {
>  *IsModified = TRUE;
> -DEBUG ((DEBUG_INFO, "ConvertPageEntryAttribute 0x%lx",
> CurrentPageEntry));
> -DEBUG ((DEBUG_INFO, "->0x%lx\n", NewPageEntry));
> +DEBUG ((DEBUG_POOL | DEBUG_PAGE, "ConvertPageEntryAttribute 0x%lx",
> +CurrentPageEntry));
> +DEBUG ((DEBUG_POOL | DEBUG_PAGE, "->0x%lx\n", NewPageEntry));
>} else {
>  *IsModified = FALSE;
>}
> --
> 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 2/3] ShellPkg: Fix misuses of AllocateCopyPool

[Wang, Jian J]

Jim,

RellocatePool() will free old buffer but AllocateCopyPool() will not. So not 
all cases in which they can be replaced for each other.

Thanks,
Jian

> -Original Message-
> From: jim.dai...@dell.com [mailto:jim.dai...@dell.com]
> Sent: Friday, November 03, 2017 7:44 PM
> To: Ni, Ruiyu <ruiyu...@intel.com>; Wang, Jian J <jian.j.w...@intel.com>;
> edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Bi, Dandan <dandan...@intel.com>
> Subject: RE: [PATCH 2/3] ShellPkg: Fix misuses of AllocateCopyPool
> 
> Isn't ReallocatePool is the correct function to use in these cases?
> For example:
> 
> NewCommandLine1 = ReallocatePool(NewSize, StrSize(OriginalCommandLine),
> OriginalCommandLine;
> 
> Regards,
> Jim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni,
> Ruiyu
> Sent: Friday, November 3, 2017 3:23 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Bi, Dandan <dandan...@intel.com>
> Subject: Re: [edk2] [PATCH 2/3] ShellPkg: Fix misuses of AllocateCopyPool
> 
> 2 comments below.
> 
> -Original Message-
> From: Wang, Jian J
> Sent: Friday, November 3, 2017 12:58 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 2/3] ShellPkg: Fix misuses of AllocateCopyPool
> 
> 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.
> 
> The solution is to allocate pool first then copy the necessary bytes to new
> memory. This can avoid copying extra bytes from unknown memory range.
> 
> 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 | 6
> --
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/ShellPkg/Application/Shell/Shell.c 
> b/ShellPkg/Application/Shell/Shell.c
> index 5471930ba1..24a04ca323 100644
> --- a/ShellPkg/Application/Shell/Shell.c
> +++ b/ShellPkg/Application/Shell/Shell.c
> @@ -1646,7 +1646,9 @@ ShellConvertVariables (
>//
>// now do the replacements...
>//
> -  NewCommandLine1 = AllocateCopyPool(NewSize, OriginalCommandLine);
> +  NewCommandLine1 = AllocatePool(NewSize);
> +  ASSERT (NewCommandLine1 != NULL);
> [Ray] 1. Please do not use assertion because there is NULL check in the below 
> if-
> statement.
> The rule in ShellPkg is avoid using assertion.
> 
> +  CopyMem (NewCommandLine1, OriginalCommandLine, StrSize
> (OriginalCommandLine));
>NewCommandLine2 = AllocateZeroPool(NewSize);
>ItemTemp= AllocateZeroPool(ItemSize+(2*sizeof(CHAR16)));
>if (NewCommandLine1 == NULL || NewCommandLine2 == NULL || ItemTemp
> == NULL) {
> diff --git
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> index 1122c89b8b..5de62219b3 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,12 @@ 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(EFI_INPUT_KEY) * NewKeyOption.KeyData.Options.InputKeyCount),
> );
> +KeyOptio

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

[Wang, Jian J]

Jeff,

That’s a good suggestion. Do you know if there’s any pitfall in using data 
segment memory as stack?

Thanks,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Friday, November 03, 2017 4:59 PM
To: Yao, Jiewen <jiewen@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; 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: 答复: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch 
support


Jian,



For example, you could use the global variable UINT8 NewStack[256] instead of 
allocate memory for stack and try to use the other global variables for other 
allocated data.



Does it work for your case?



Thanks!

Jeff




From: edk2-devel 
<edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>> on 
behalf of Fan Jeff <vanjeff_...@hotmail.com<mailto:vanjeff_...@hotmail.com>>
Sent: Friday, November 3, 2017 4:21:22 PM
To: Yao, Jiewen; Kinney, Michael D; Wang, Jian J; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Dong, Eric; Zeng, Star
Subject: [edk2] 答复: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack 
switch support

Jian,

Could you use some global variables in 
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
 to avoid adding new API?

Jeff
发件人: Yao, Jiewen<mailto:jiewen@intel.com>
发送时间: 2017年11月3日 9:24
收件人: Kinney, Michael D<mailto:michael.d.kin...@intel.com>; Fan 
Jeff<mailto:vanjeff_...@hotmail.com>; Wang, Jian 
J<mailto:jian.j.w...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org%3cmailto:edk2-devel@lists.01.org>>
抄送: 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 Jian
There is another potential problem.

This feature is enabled in InitializeCpuInterruptHandlers(). However, we expect 
this is enabled in InitializeCpuExceptionHandlers().

In order to get the exception stack in InitializeCpuExceptionHandlers(). We can 
have 2 ways:
A) Let InitializeCpuExceptionHandlers() allocate the exception stack.
B) Let caller to pass the exception stack to InitializeCpuExceptionHandlers().

For A), it is hard, because DxeCore calls InitializeCpuExceptionHandlers() 
earlier than CoreInitializeMemoryServices().
For B), InitializeCpuExceptionHandlers() interface does not contain such 
information. We might need add a new API to add the exception stack 
information, such as InitializeCpuSwitchStackExceptionHandlers ().

Once this feature is done, can we clean up the SMM code to use the new API, 
instead of duplicate the SMM copy of exception handler ? The existing SMM copy 
has some assumption on CR4 and FXSAVE/RESTORE, and it broke Quark platform.

Thank you
Yao Jiewen



> -Original Message-
> From: Kinney, Michael D
> Sent: Wednesday, November 1, 2017 11:43 PM
> To: Fan Jeff <vanjeff_...@hotmail.com<mailto:vanjeff_...@hotmail.com>>; 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>; Kinney, Michael
> D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
> Cc: Dong, Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>; Zeng, Star 
> <star.z...@intel.com<mailto:star.z...@intel.com>>
> Subject: RE: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> support
>
> I agree that adding AsmWriteTr, IA32_TASK_STATE_SEGMENT,
> IA32_TSS_DESCRIPTOR to MdePkg BaseLib is a good idea.
>
> Mike
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fan
> Jeff
> Sent: Tuesday, October 31, 2017 7:33 PM
> 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: [edk2] 答复: [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,
> IA3

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

[Wang, Jian J]

Jiwen,

For 1), the stack is used for exception only. Is there any chance that the same 
exception is triggered by both BSP and AP at the same time?
For 2), separate stack is used mainly for Stack Guard feature which is 
supported only by DXE (because it needs paging to work). I think we don’t need 
to take care of PEI code. The global can be just defined in DxeException.c file.

Thanks,
Jian

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

I think we need consider 2 additional things:
1) how to support different stack for ap?
2) how to support pei phase, when the global variable is read only?

thank you!
Yao, Jiewen


在 2017年11月6日，上午8:30，Wang, Jian J 
<jian.j.w...@intel.com<mailto:jian.j.w...@intel.com>> 写道：
Jeff,

That’s a good suggestion. Do you know if there’s any pitfall in using data 
segment memory as stack?

Thanks,
Jian

From: Fan Jeff [mailto:vanjeff_...@hotmail.com]
Sent: Friday, November 03, 2017 4:59 PM
To: Yao, Jiewen <jiewen@intel.com<mailto:jiewen@intel.com>>; Kinney, 
Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@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: 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


Jian,



For example, you could use the global variable UINT8 NewStack[256] instead of 
allocate memory for stack and try to use the other global variables for other 
allocated data.



Does it work for your case?



Thanks!

Jeff




From: edk2-devel 
<edk2-devel-boun...@lists.01.org<mailto:edk2-devel-boun...@lists.01.org>> on 
behalf of Fan Jeff <vanjeff_...@hotmail.com<mailto:vanjeff_...@hotmail.com>>
Sent: Friday, November 3, 2017 4:21:22 PM
To: Yao, Jiewen; Kinney, Michael D; Wang, Jian J; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Dong, Eric; Zeng, Star
Subject: [edk2] 答复: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack 
switch support

Jian,

Could you use some global variables in 
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c
 to avoid adding new API?

Jeff
发件人: Yao, Jiewen<mailto:jiewen....@intel.com>
发送时间: 2017年11月3日 9:24
收件人: Kinney, Michael D<mailto:michael.d.kin...@intel.com>; Fan 
Jeff<mailto:vanjeff_...@hotmail.com>; Wang, Jian 
J<mailto:jian.j.w...@intel.com>; 
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org%3cmailto:edk2-devel@lists.01.org>>
抄送: 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 Jian
There is another potential problem.

This feature is enabled in InitializeCpuInterruptHandlers(). However, we expect 
this is enabled in InitializeCpuExceptionHandlers().

In order to get the exception stack in InitializeCpuExceptionHandlers(). We can 
have 2 ways:
A) Let InitializeCpuExceptionHandlers() allocate the exception stack.
B) Let caller to pass the exception stack to InitializeCpuExceptionHandlers().

For A), it is hard, because DxeCore calls InitializeCpuExceptionHandlers() 
earlier than CoreInitializeMemoryServices().
For B), InitializeCpuExceptionHandlers() interface does not contain such 
information. We might need add a new API to add the exception stack 
information, such as InitializeCpuSwitchStackExceptionHandlers ().

Once this feature is done, can we clean up the SMM code to use the new API, 
instead of duplicate the SMM copy of exception handler ? The existing SMM copy 
has some assumption on CR4 and FXSAVE/RESTORE, and it broke Quark platform.

Thank you
Yao Jiewen



> -Original Message-
> From: Kinney, Michael D
> Sent: Wednesday, November 1, 2017 11:43 PM
> To: Fan Jeff <vanjeff_...@hotmail.com<mailto:vanjeff_...@hotmail.com>>; 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>; Kinney, Michael
> D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>
> Cc: Dong, Eric <eric.d...@intel.com<mailto:eric.d...@intel.com>>; Zeng, Star 
> <star.z...@intel.

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

[Wang, Jian J]

Ruiyu,

Thanks for the comments.

> -Original Message-
> From: Ni, Ruiyu
> Sent: Friday, November 03, 2017 4:23 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Carsey, Jaben <jaben.car...@intel.com>; Bi, Dandan <dandan...@intel.com>
> Subject: RE: [PATCH 2/3] ShellPkg: Fix misuses of AllocateCopyPool
> 
> 2 comments below.
> 
> -Original Message-
> From: Wang, Jian J
> Sent: Friday, November 3, 2017 12:58 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 2/3] ShellPkg: Fix misuses of AllocateCopyPool
> 
> 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.
> 
> The solution is to allocate pool first then copy the necessary bytes to new
> memory. This can avoid copying extra bytes from unknown memory range.
> 
> 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 | 6
> --
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/ShellPkg/Application/Shell/Shell.c 
> b/ShellPkg/Application/Shell/Shell.c
> index 5471930ba1..24a04ca323 100644
> --- a/ShellPkg/Application/Shell/Shell.c
> +++ b/ShellPkg/Application/Shell/Shell.c
> @@ -1646,7 +1646,9 @@ ShellConvertVariables (
>//
>// now do the replacements...
>//
> -  NewCommandLine1 = AllocateCopyPool(NewSize, OriginalCommandLine);
> +  NewCommandLine1 = AllocatePool(NewSize);
> +  ASSERT (NewCommandLine1 != NULL);
> [Ray] 1. Please do not use assertion because there is NULL check in the below 
> if-
> statement.
> The rule in ShellPkg is avoid using assertion.
> 

Got it. It'll be removed.

> +  CopyMem (NewCommandLine1, OriginalCommandLine, StrSize
> (OriginalCommandLine));
>NewCommandLine2 = AllocateZeroPool(NewSize);
>ItemTemp= AllocateZeroPool(ItemSize+(2*sizeof(CHAR16)));
>if (NewCommandLine1 == NULL || NewCommandLine2 == NULL || ItemTemp
> == NULL) {
> diff --git
> a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> b/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c
> index 1122c89b8b..5de62219b3 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,12 @@ 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(EFI_INPUT_KEY) * NewKeyOption.KeyData.Options.InputKeyCount),
> );
> +KeyOptionBuffer = AllocatePool (sizeof(EFI_KEY_OPTION) +
> (sizeof(EFI_INPUT_KEY) * NewKeyOption.KeyData.Options.InputKeyCount));
>  if (KeyOptionBuffer == NULL) {
>ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_GEN_NO_MEM),
> gShellBcfgHiiHandle, L"bcfg");
>ShellStatus = SHELL_OUT_OF_RESOURCES;
>  }
> [Ray] 2. Should the above NULL check return?

It's original code not my change. But I think it should return if NULL is got.

> +CopyMem (KeyOptionBuffer, , sizeof(EFI_KEY_OPTION));
>}
>for (LoopCounter = 0 ; ShellStatus == SHELL_SUCCESS && LoopCounter <
> NewKeyOption.KeyData.Options.InputKeyCount; LoopCounter++) {
>  //
> --
> 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 1/3] MdeModulePkg: Fix misuses of AllocateCopyPool

[Wang, Jian J]

Star,

Thanks for the comments. It's a good suggestion. I didn't know ReallocatePool() 
can do that.

Thanks
Jian

> -Original Message-
> From: Zeng, Star
> Sent: Friday, November 03, 2017 5:14 PM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Bi, Dandan <dandan...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH 1/3] MdeModulePkg: Fix misuses of AllocateCopyPool
> 
> Some of the change can reuse ReallocatePool() to make the code more simpler.
> 
> For example, the change in FrontPageCustomizedUiSupport.c.
> 
>  Count++;
>  if (Count >= CurrentSize) {
>   DriverListPtr = AllocatePool ((Count + UI_HII_DRIVER_LIST_SIZE) * sizeof
> (UI_HII_DRIVER_INSTANCE));
>ASSERT (DriverListPtr != NULL);
>   CopyMem (DriverListPtr, gHiiDriverList, CurrentSize * sizeof
> (UI_HII_DRIVER_INSTANCE));
>FreePool (gHiiDriverList);
>gHiiDriverList = DriverListPtr;
>CurrentSize += UI_HII_DRIVER_LIST_SIZE;
> 
> Could be
> 
>  Count++;
>  if (Count >= CurrentSize) {
>   gHiiDriverList = ReallocatePool (
>  CurrentSize * sizeof (UI_HII_DRIVER_INSTANCE),
>  (CurrentSize + UI_HII_DRIVER_LIST_SIZE) * sizeof
> (UI_HII_DRIVER_INSTANCE),
>  gHiiDriverList
>  );
>   ASSERT (gHiiDriverList != NULL);
>CurrentSize += UI_HII_DRIVER_LIST_SIZE;
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Friday, November 3, 2017 12:58 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Bi,
> Dandan <dandan...@intel.com>
> Subject: [PATCH 1/3] MdeModulePkg: Fix misuses of AllocateCopyPool
> 
> 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.
> 
> The solution is to allocate pool first then copy the necessary bytes to new
> memory. This can avoid copying extra bytes from unknown memory range.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@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>
> ---
>  MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c  |  3 ++-
>  .../BootMaintenanceManagerCustomizedUiSupport.c|  3 ++-
>  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c|  4 +++-
>  MdeModulePkg/Library/UefiHiiLib/HiiLib.c   | 10 
> ++
>  .../Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c   |  3 ++-
>  MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c   |  3 ++-
>  6 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
> b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
> index 1505ef9319..74d890441b 100644
> --- a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
> +++ b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
> @@ -639,8 +639,9 @@ UiListThirdPartyDrivers (
> 
>  Count++;
>  if (Count >= CurrentSize) {
> -  DriverListPtr = AllocateCopyPool ((Count + UI_HII_DRIVER_LIST_SIZE) *
> sizeof (UI_HII_DRIVER_INSTANCE), gHiiDriverList);
> +  DriverListPtr = AllocatePool ((Count + UI_HII_DRIVER_LIST_SIZE) * 
> sizeof
> (UI_HII_DRIVER_INSTANCE));
>ASSERT (DriverListPtr != NULL);
> +  CopyMem (DriverListPtr, gHiiDriverList, CurrentSize * sizeof
> (UI_HII_DRIVER_INSTANCE));
>FreePool (gHiiDriverList);
>gHiiDriverList = DriverListPtr;
>CurrentSize += UI_HII_DRIVER_LIST_SIZE;
> diff --git
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceM
> anagerCustomizedUiSupport.c
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceM
> anagerCustomizedUiSupport.c
> index b25bc67c06..512c340741 100644
> ---
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceM
> anagerCustomizedUiSupport.c
> +++
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceM
> anagerCustomizedUiSupport.c
> @@ -435,8 +435,9 @@ BmmListThirdPartyDrivers (
> 
>  Count++;
>  if (Count >= CurrentSize) {
> -  DriverListPtr = AllocateCopyPool ((Count + UI_HII_DRIVER_LIST_SIZE) *
> sizeof (UI_HII_DRIVER_INSTANCE), gHiiDriverList)

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

[Wang, Jian J]

Thanks for the review. And I agree that GCD.SetMemoryAttributes should be
used all the time in DxeCore. Let's fix it in another patch.

> -Original Message-
> From: Zeng, Star
> Sent: Monday, November 06, 2017 5:16 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>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [edk2] [PATCH v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> I am ok to this code approach.
> 
> Acknowledged-by: Star Zeng <star.z...@intel.com>
> 
> Besides, I think except GCD services, DxeCore should not call gCpu-
> >SetMemoryAttributes() directly, for example ApplyMemoryProtectionPolicy(), it
> should have no assumption of the CPU code (to set capabilities), and call GCD
> setcapabilities first, and then call GCD setattributes since
> 14dde9e903bb9a719ebb8f3381da72b19509bc36 "MdeModulePkg/Core: Fix out-
> of-sync issue in GCD", otherwise there may be mismatch of page attributes
> between GCD and gCPU after RefreshGcdMemoryAttributesFromPaging() by the
> calling gCpu->SetMemoryAttributes() in ApplyMemoryProtectionPolicy().
> 
> Anyway, that could be in a separated patch. :)
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Friday, November 3, 2017 8:57 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 v2] UefiCpuPkg/CpuDxe: Fix multiple entries of RT_CODE
> in memory map
> 
> > 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;
>  }
> 
> @@ -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);
> +
>  while (MemorySpaceLength > 0) {
>if (PageLength == 0) {
>  PageEntry = GetPageTableEntry (, BaseAddress,
> ); @@ -846,7 +857,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 +864,8 @@ RefreshGcdMemoryAttributesFromPaging (
> 
>Length = MIN (PageLength, MemorySpaceLength);
>if (DoUpdate) {
> -gDS->SetMemorySpaceCapabilities (BaseAddress, Length, Capabilities);
> -gDS->SetMemorySpaceAtt

Re: [edk2] [PATCH 2/2] CryptoPkg/BaseCryptLib: Fix mismatched memory allocation/free

[Wang, Jian J]

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

> -Original Message-
> From: Long, Qin
> Sent: Tuesday, October 31, 2017 4:40 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting <ting...@intel.com>; ler...@redhat.com; Wang, Jian J
> <jian.j.w...@intel.com>; Long, Qin <qin.l...@intel.com>
> Subject: [PATCH 2/2] CryptoPkg/BaseCryptLib: Fix mismatched memory
> allocation/free
> 
> The malloc/free (instead of AllocatePool/FreePool) were used directly
> in some wrapper implementations, which was designed to leverage the
> light-weight memory management routines at Runtime phase.
> The malloc/free and AllocatePool/FreePool usages are required to be
> matched, after extra memory size info header was introduced in malloc
> wrapper.
> 
> This patch corrects two memory allocation cases, which requires the
> caller to free the buffer with FreePool() outside the function call.
> 
> And some comments were also added to clarify the correct memory
> release functions if it's the caller's responsibility to free the
> memory buffer.
> 
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Ting Ye <ting...@intel.com>
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long <qin.l...@intel.com>
> ---
>  CryptoPkg/Include/Library/BaseCryptLib.h | 16 
> ++--
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Sign.c   |  5 +++--
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7SignNull.c   |  3 ++-
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7Verify.c | 15 +--
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyNull.c | 13 -
>  5 files changed, 32 insertions(+), 20 deletions(-)
> 
> diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h
> b/CryptoPkg/Include/Library/BaseCryptLib.h
> index 5f67ecb709..e2b6a95666 100644
> --- a/CryptoPkg/Include/Library/BaseCryptLib.h
> +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
> @@ -2388,10 +2388,12 @@ Pkcs5HashPassword (
>@param[in]  P7Data   Pointer to the PKCS#7 message to verify.
>@param[in]  P7Length Length of the PKCS#7 message in bytes.
>@param[out] CertStackPointer to Signer's certificates retrieved from 
> P7Data.
> -   It's caller's responsibility to free the buffer.
> +   It's caller's responsibility to free the buffer 
> with
> +   Pkcs7FreeSigners().
>@param[out] StackLength  Length of signer's certificates in bytes.
>@param[out] TrustedCert  Pointer to a trusted certificate from Signer's
> certificates.
> -   It's caller's responsibility to free the buffer.
> +   It's caller's responsibility to free the buffer 
> with
> +   Pkcs7FreeSigners().
>@param[out] CertLength   Length of the trusted certificate in bytes.
> 
>@retval  TRUEThe operation is finished successfully.
> @@ -2433,10 +2435,11 @@ Pkcs7FreeSigners (
>@param[in]  P7DataPointer to the PKCS#7 message.
>@param[in]  P7Length  Length of the PKCS#7 message in bytes.
>@param[out] SignerChainCerts  Pointer to the certificates list chained to
> signer's
> -certificate. It's caller's responsibility to 
> free the buffer.
> +certificate. It's caller's responsibility to 
> free the buffer
> +with Pkcs7FreeSigners().
>@param[out] ChainLength   Length of the chained certificates list 
> buffer in
> bytes.
>@param[out] UnchainCerts  Pointer to the unchained certificates lists. 
> It's
> caller's
> -responsibility to free the buffer.
> +responsibility to free the buffer with 
> Pkcs7FreeSigners().
>@param[out] UnchainLength Length of the unchained certificates list 
> buffer
> in bytes.
> 
>@retval  TRUE The operation is finished successfully.
> @@ -2472,7 +2475,8 @@ Pkcs7GetCertificatesList (
>@param[in]  OtherCerts   Pointer to an optional additional set of 
> certificates
> to
> include in the PKCS#7 signedData (e.g. any 
> intermediate
> CAs in the chain).
> -  @param[out] SignedData   Pointer to output PKCS#7 signedData.
> +  @param[out] SignedData   Pointer to output PKCS#7 signedData. It's 
> caller's
> +   responsibility to free the buffer with 
> FreePool().
>@param[out] SignedDataSize   Size of SignedData in bytes.
> 
&

Re: [edk2] [PATCH 1/2] CryptoPkg/BaseCryptLib: Fix buffer overflow issue in realloc wrapper

[Wang, Jian J]

Hi Qin,

Thanks for fixing this issue. Please find my comments below.

Besides that, the patch has been passed the boot validation.

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

Thanks,
Jian

> -Original Message-
> From: Long, Qin
> Sent: Tuesday, October 31, 2017 4:39 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting <ting...@intel.com>; ler...@redhat.com; Wang, Jian J
> <jian.j.w...@intel.com>; Long, Qin <qin.l...@intel.com>
> Subject: [PATCH 1/2] CryptoPkg/BaseCryptLib: Fix buffer overflow issue in
> realloc wrapper
> 
> There is one long-standing problem in CRT realloc wrapper, which will
> cause the obvious buffer overflow issue when re-allocating one bigger
> memory block:
> void *realloc (void *ptr, size_t size)
> {
>   //
>   // BUG: hardcode OldSize == size! We have no any knowledge about
>   // memory size of original pointer ptr.
>   //
>   return ReallocatePool ((UINTN) size, (UINTN) size, ptr);
> }
> This patch introduces one extra header to record the memory buffer size
> information when allocating memory block from malloc routine, and re-wrap
> the realloc() and free() routines to remove this BUG.
> 
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Ting Ye <ting...@intel.com>
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long <qin.l...@intel.com>
> ---
>  .../BaseCryptLib/SysCall/BaseMemAllocation.c   | 72 +++-
> --
>  1 file changed, 65 insertions(+), 7 deletions(-)
> 
> diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c
> b/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c
> index f390e0d449..ed37a0ff39 100644
> --- a/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c
> +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c
> @@ -16,6 +16,18 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
> 
> +//
> +// Extra header to record the memory buffer size from malloc routine.
> +//
> +#define CRYPTMEM_HEAD_SIGNATURESIGNATURE_32('c','m','h','d')
> +typedef struct {
> +  UINT32Signature;
> +  UINT32Reserved;
> +  UINTN Size;
> +} CRYPTMEM_HEAD;
> +
> +#define CRYPTMEM_OVERHEAD  sizeof(CRYPTMEM_HEAD)

Any consideration of the "Reserved" field, Padding? Alignment? Future 
extendibility?

> +
>  //
>  // -- Memory-Allocation Routines --
>  //
> @@ -23,27 +35,73 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  /* Allocates memory blocks */
>  void *malloc (size_t size)
>  {
> -  return AllocatePool ((UINTN) size);
> +  CRYPTMEM_HEAD  *PoolHdr;
> +  UINTN  NewSize;
> +  VOID   *Data;
> +
> +  //
> +  // Adjust the size by the buffer header overhead
> +  //
> +  NewSize = (UINTN)(size) + CRYPTMEM_OVERHEAD;
> +
> +  Data  = AllocatePool (NewSize);
> +  if (Data != NULL) {
> +PoolHdr = (CRYPTMEM_HEAD *)Data;
> +//
> +// Record the memory brief information
> +//
> +PoolHdr->Signature = CRYPTMEM_HEAD_SIGNATURE;
> +PoolHdr->Size  = size;
> +  }
> +  return (VOID *)(PoolHdr + 1);
>  }
> 

Although it's very rare, the logic of code above doesn't consider case of Data 
== NULL.
And above code might not pass GCC build because there's a chance that PoolHdr 
is not
initialized.

>  /* Reallocate memory blocks */
>  void *realloc (void *ptr, size_t size)
>  {
> -  //
> -  // BUG: hardcode OldSize == size! We have no any knowledge about
> -  // memory size of original pointer ptr.
> -  //
> -  return ReallocatePool ((UINTN) size, (UINTN) size, ptr);
> +  CRYPTMEM_HEAD  *OldPoolHdr;
> +  CRYPTMEM_HEAD  *NewPoolHdr;
> +  UINTN  OldSize;
> +  UINTN  NewSize;
> +  VOID   *Data;
> +
> +  NewSize = (UINTN)size + CRYPTMEM_OVERHEAD;
> +  Data = AllocatePool (NewSize);
> +  if (Data != NULL) {
> +NewPoolHdr = (CRYPTMEM_HEAD *)Data;
> +NewPoolHdr->Signature = CRYPTMEM_HEAD_SIGNATURE;
> +NewPoolHdr->Size  = size;
> +if (ptr != NULL) {
> +  //
> +  // Retrieve the original size from the buffer header.
> +  //
> +  OldPoolHdr = (CRYPTMEM_HEAD *)ptr - 1;
> +  ASSERT (OldPoolHdr->Signature == CRYPTMEM_HEAD_SIGNATURE);
> +  OldSize = OldPoolHdr->Size;
> +
> +  //
> +  // Duplicate the buffer content.
> +  //
> +  CopyMem ((VOID *)(NewPoolHdr + 1), ptr, MIN (OldSize, size));
> +  FreePool ((VOID *)OldPoolHdr);
> +}
> +  }
> +
> +  return (VOID *)(NewPoolHdr + 

Re: [edk2] [PATCH v2 1/2] CryptoPkg/BaseCryptLib: Fix buffer overflow issue in realloc wrapper

[Wang, Jian J]

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


> -Original Message-
> From: Long, Qin
> Sent: Wednesday, November 01, 2017 4:19 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J <jian.j.w...@intel.com>; Ye, Ting <ting...@intel.com>;
> ler...@redhat.com; Long, Qin <qin.l...@intel.com>
> Subject: [PATCH v2 1/2] CryptoPkg/BaseCryptLib: Fix buffer overflow issue in
> realloc wrapper
> 
> There is one long-standing problem in CRT realloc wrapper, which will
> cause the obvious buffer overflow issue when re-allocating one bigger
> memory block:
> void *realloc (void *ptr, size_t size)
> {
>   //
>   // BUG: hardcode OldSize == size! We have no any knowledge about
>   // memory size of original pointer ptr.
>   //
>   return ReallocatePool ((UINTN) size, (UINTN) size, ptr);
> }
> This patch introduces one extra header to record the memory buffer size
> information when allocating memory block from malloc routine, and re-wrap
> the realloc() and free() routines to remove this BUG.
> 
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Ting Ye <ting...@intel.com>
> Cc: Jian J Wang <jian.j.w...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long <qin.l...@intel.com>
> ---
>  .../BaseCryptLib/SysCall/BaseMemAllocation.c   | 83
> --
>  1 file changed, 76 insertions(+), 7 deletions(-)
> 
> diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c
> b/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c
> index f390e0d449..19c071e2bf 100644
> --- a/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c
> +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/BaseMemAllocation.c
> @@ -16,6 +16,18 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
>  #include 
> 
> +//
> +// Extra header to record the memory buffer size from malloc routine.
> +//
> +#define CRYPTMEM_HEAD_SIGNATURESIGNATURE_32('c','m','h','d')
> +typedef struct {
> +  UINT32Signature;
> +  UINT32Reserved;
> +  UINTN Size;
> +} CRYPTMEM_HEAD;
> +
> +#define CRYPTMEM_OVERHEAD  sizeof(CRYPTMEM_HEAD)
> +
>  //
>  // -- Memory-Allocation Routines --
>  //
> @@ -23,27 +35,84 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  /* Allocates memory blocks */
>  void *malloc (size_t size)
>  {
> -  return AllocatePool ((UINTN) size);
> +  CRYPTMEM_HEAD  *PoolHdr;
> +  UINTN  NewSize;
> +  VOID   *Data;
> +
> +  //
> +  // Adjust the size by the buffer header overhead
> +  //
> +  NewSize = (UINTN)(size) + CRYPTMEM_OVERHEAD;
> +
> +  Data  = AllocatePool (NewSize);
> +  if (Data != NULL) {
> +PoolHdr = (CRYPTMEM_HEAD *)Data;
> +//
> +// Record the memory brief information
> +//
> +PoolHdr->Signature = CRYPTMEM_HEAD_SIGNATURE;
> +PoolHdr->Size  = size;
> +
> +return (VOID *)(PoolHdr + 1);
> +  } else {
> +//
> +// The buffer allocation failed.
> +//
> +return NULL;
> +  }
>  }
> 
>  /* Reallocate memory blocks */
>  void *realloc (void *ptr, size_t size)
>  {
> -  //
> -  // BUG: hardcode OldSize == size! We have no any knowledge about
> -  // memory size of original pointer ptr.
> -  //
> -  return ReallocatePool ((UINTN) size, (UINTN) size, ptr);
> +  CRYPTMEM_HEAD  *OldPoolHdr;
> +  CRYPTMEM_HEAD  *NewPoolHdr;
> +  UINTN  OldSize;
> +  UINTN  NewSize;
> +  VOID   *Data;
> +
> +  NewSize = (UINTN)size + CRYPTMEM_OVERHEAD;
> +  Data = AllocatePool (NewSize);
> +  if (Data != NULL) {
> +NewPoolHdr = (CRYPTMEM_HEAD *)Data;
> +NewPoolHdr->Signature = CRYPTMEM_HEAD_SIGNATURE;
> +NewPoolHdr->Size  = size;
> +if (ptr != NULL) {
> +  //
> +  // Retrieve the original size from the buffer header.
> +  //
> +  OldPoolHdr = (CRYPTMEM_HEAD *)ptr - 1;
> +  ASSERT (OldPoolHdr->Signature == CRYPTMEM_HEAD_SIGNATURE);
> +  OldSize = OldPoolHdr->Size;
> +
> +  //
> +  // Duplicate the buffer content.
> +  //
> +  CopyMem ((VOID *)(NewPoolHdr + 1), ptr, MIN (OldSize, size));
> +  FreePool ((VOID *)OldPoolHdr);
> +}
> +
> +return (VOID *)(NewPoolHdr + 1);
> +  } else {
> +//
> +// The buffer allocation failed.
> +//
> +return NULL;
> +  }
>  }
> 
>  /* De-allocates or frees a memory block */
>  void free (void *ptr)
>  {
> +  CRYPTMEM_HEAD  *PoolHdr;
> +
>//
>// In Standard C, free() handles a null pointer argument transparently. 
> This
>// is not true of FreePool() below, so protect it.
>//
>if (ptr != NULL) {
> -FreePool (ptr);
> +PoolHdr = (CRYPTMEM_HEAD *)ptr - 1;
> +ASSERT (PoolHdr->Signature == CRYPTMEM_HEAD_SIGNATURE);
> +FreePool (PoolHdr);
>}
>  }
> --
> 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 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support

[Wang, Jian J]

I see. Thanks for the explanation.

> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, November 03, 2017 10:27 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; Kinney, Michael D
> <michael.d.kin...@intel.com>; Fan Jeff <vanjeff_...@hotmail.com>; edk2-
> de...@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch
> support
> 
> Jian
> That is for compatibility consideration.
> 
> Once there is UDK release, we never change API. We can only add new one.
> Or you may break an old platform, that may use new UDK release.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Wang, Jian J
> > Sent: Friday, November 3, 2017 10:10 AM
> > To: Yao, Jiewen <jiewen@intel.com>; Kinney, Michael D
> > <michael.d.kin...@intel.com>; Fan Jeff <vanjeff_...@hotmail.com>;
> > edk2-devel@lists.01.org
> > Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > Subject: RE: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> switch
> > support
> >
> > Hi Jiewen,
> >
> > > -----Original Message-
> > > From: Yao, Jiewen
> > > Sent: Friday, November 03, 2017 9:25 AM
> > > To: Kinney, Michael D <michael.d.kin...@intel.com>; Fan Jeff
> > > <vanjeff_...@hotmail.com>; Wang, Jian J <jian.j.w...@intel.com>; edk2-
> > > de...@lists.01.org
> > > Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > > Subject: RE: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > switch
> > > support
> > >
> > > HI Jian
> > > There is another potential problem.
> > >
> > > This feature is enabled in InitializeCpuInterruptHandlers(). However, we
> expect
> > > this is enabled in InitializeCpuExceptionHandlers().
> > >
> > > In order to get the exception stack in InitializeCpuExceptionHandlers(). 
> > > We
> can
> > > have 2 ways:
> > > A) Let InitializeCpuExceptionHandlers() allocate the exception stack.
> > > B) Let caller to pass the exception stack to 
> > > InitializeCpuExceptionHandlers().
> > >
> > > For A), it is hard, because DxeCore calls InitializeCpuExceptionHandlers()
> earlier
> > > than CoreInitializeMemoryServices().
> > > For B), InitializeCpuExceptionHandlers() interface does not contain such
> > > information. We might need add a new API to add the exception stack
> > > information, such as InitializeCpuSwitchStackExceptionHandlers ().
> >
> > You're right. Enabling stack switch in InitializeCpuExceptionHandlers() is 
> > a bit
> > late for exception handling. But I don't see the difference between adding
> > parameters to existing API (InitializeCpuExceptionHandlers) and adding a new
> > API (InitializeCpuSwitchStackExceptionHandlers) in this case. If we have to
> > change library interface anyway, I'd suggest to add parameters to existing
> > API to carry information needed to setup new stack for exceptions.
> >
> > >
> > > Once this feature is done, can we clean up the SMM code to use the new 
> > > API,
> > > instead of duplicate the SMM copy of exception handler ? The existing SMM
> > > copy has some assumption on CR4 and FXSAVE/RESTORE, and it broke Quark
> > > platform.
> >
> > I agree.
> >
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Kinney, Michael D
> > > > Sent: Wednesday, November 1, 2017 11:43 PM
> > > > To: Fan Jeff <vanjeff_...@hotmail.com>; Yao, Jiewen
> > > <jiewen....@intel.com>;
> > > > Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org; Kinney,
> > > Michael
> > > > D <michael.d.kin...@intel.com>
> > > > Cc: Dong, Eric <eric.d...@intel.com>; Zeng, Star <star.z...@intel.com>
> > > > Subject: RE: [PATCH 3/3] UefiCpuPkg/CpuExceptionHandlerLib: Add stack
> > > switch
> > > > support
> > > >
> > > > I agree that adding AsmWriteTr, IA32_TASK_STATE_SEGMENT,
> > > > IA32_TSS_DESCRIPTOR to MdePkg BaseLib is a good idea.
> > > >
> > > > Mike
> > > >
> > > > -Original Message-
> > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.

Re: [edk2] [PATCH v2] 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 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.

> >
> > @@ -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 (apparently) it is
> considered safe.
> 

Yes. I've validated different OSs boot. It's safe to stay this way.

> >  while (MemorySpaceLength > 0) {
> >if (PageLength == 0) {
> >  PageEntry = GetPageTableEntry (, BaseAddress,
> );
> > @@ -846,7 +857,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 +864,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));
> >
> 
> I'll let you decide about the EFI_PAGE_MASK conditions near the top.
> 
> Acked-by: Laszlo Ersek <ler...@redhat.com>
> 

Thanks.

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

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

[Wang, Jian J]

Make sense. Thanks for the comment.

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, November 08, 2017 12:42 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 v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> Jian,
> Can you add more comments to explain why changing the capabilities of GCD
> entry?
> 
> The background is clear by checking the Bugzilla. But it would be great to 
> know
> the issue
> by just reading the code.
> 
> Thanks/Ray
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jian J Wang
> > Sent: Friday, November 3, 2017 8:57 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 v2] UefiCpuPkg/CpuDxe: Fix multiple entries of
> > RT_CODE in memory map
> >
> > > 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;
> >  }
> >
> > @@ -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);
> > +
> >  while (MemorySpaceLength > 0) {
> >if (PageLength == 0) {
> >  PageEntry = GetPageTableEntry (, BaseAddress,
> > ); @@ -846,7 +857,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 +864,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));
> > --
> > 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 v3 1/3] MdeModulePkg: Fix misuses of AllocateCopyPool

[Wang, Jian J]

Hi Star,

I agree the issues you mentioned. But they're already there before this patch.
I'd suggest to file a new bug tracker for them instead of fixing them in this 
one.

Thanks,
Jian

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, November 08, 2017 10:38 AM
> To: Wang, Jian J <jian.j.w...@intel.com>; edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Bi, Dandan <dandan...@intel.com>;
> Zeng, Star <star.z...@intel.com>
> Subject: RE: [PATCH v3 1/3] MdeModulePkg: Fix misuses of AllocateCopyPool
> 
> In FrontPageCustomizedUiSupport.c, suggest to use "(CurrentSize +
> UI_HII_DRIVER_LIST_SIZE)" instead of "(Count + UI_HII_DRIVER_LIST_SIZE)" to
> be consistent with the following code "CurrentSize +=
> UI_HII_DRIVER_LIST_SIZE".
> 
> Same comment to BootMaintenanceManagerCustomizedUiSupport.c
> 
> In HiiLib.c, suggest removing "FormSetBuffer = NULL".
> And the code logic below in HiiLib.c is strange and suggest refining the code.
> TempBuffer = AllocatePool (TempSize + ((EFI_IFR_OP_HEADER *) OpCodeData)-
> >Length);
> ...
> CopyMem (TempBuffer, OpCodeData, ((EFI_IFR_OP_HEADER *) OpCodeData)-
> >Length);
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, November 8, 2017 10:12 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Bi,
> Dandan <dandan...@intel.com>
> Subject: [PATCH v3 1/3] MdeModulePkg: Fix misuses of AllocateCopyPool
> 
> >v3:
> > a. Add ASSERT for returned pointer
> > b. Correct DestMax parameter in calling StrCpyS
> > c. Fix coding style
> 
> >v2:
> > a. Use ReallocatePool to replace AllocateCopyPool 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: Star Zeng <star.z...@intel.com>
> Cc: Eric Dong <eric.d...@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>
> ---
>  .../Application/UiApp/FrontPageCustomizedUiSupport.c |  8 ++--
>  .../BootMaintenanceManagerCustomizedUiSupport.c  |  8 ++--
>  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c  | 10 +--
> ---
>  MdeModulePkg/Library/UefiHiiLib/HiiLib.c | 12 
> 
>  .../Universal/FvSimpleFileSystemDxe/FvSimpleFileSystem.c |  3 ++-
>  MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c |  9
> ++---
>  6 files changed, 33 insertions(+), 17 deletions(-)
> 
> diff --git a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
> b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
> index 1505ef9319..17fc3db507 100644
> --- a/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
> +++ b/MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupport.c
> @@ -639,9 +639,13 @@ UiListThirdPartyDrivers (
> 
>  Count++;
>  if (Count >= CurrentSize) {
> -  DriverListPtr = AllocateCopyPool ((Count + UI_HII_DRIVER_LIST_SIZE) *
> sizeof (UI_HII_DRIVER_INSTANCE), gHiiDriverList);
> +  DriverListPtr = ReallocatePool (
> +CurrentSize * sizeof (UI_HII_DRIVER_INSTANCE),
> +(Count + UI_HII_DRIVER_LIST_SIZE)
> +  * sizeof (UI_HII_DRIVER_INSTANCE),
> +gHiiDriverList
> +);
>ASSERT (DriverListPtr != NULL);
> -  FreePool (gHiiDriverList);
>gHiiDriverList = DriverListPtr;
>CurrentSize += UI_HII_DRIVER_LIST_SIZE;
>  }
> diff --git
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceM
> anagerCustomizedUiSupport.c
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceM
> anagerCustomizedUiSupport.c
> index b25bc67c06..6dd4fce139 100644
> ---
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceM
> anagerCustomizedUiSupport.c
> +++
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceM
> anagerCustomizedUiSupport.c
> @@ -435,9 +435,13 @@ BmmListThirdPartyDrivers (
> 
>  Count++;
>  if (Count >= CurrentSize) {
> -  DriverListPtr

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

[Wang, Jian J]

Thanks for catching them. There'll be v5 today:)

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, November 09, 2017 10:13 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 v3] UefiCpuPkg/CpuDxe: Fix multiple entries of
> RT_CODE in memory map
> 
> Hi Jian,
> 
> this is v4, but the subject says v3 :) If you post a new version, please
> make sure that it says "v5" in the subject.
> 
> The logic looks OK to me; I've got some comments on style:
> 
> On 11/09/17 02:39, Jian J Wang wrote:
> >> 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 <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 | 69
> +---
> >  1 file changed, 50 insertions(+), 19 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index d312eb66f8..a1d804caed 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: [%d] %016lx - %016lx (%016lx -
> > %016lx)\r\n",
> > +Index, BaseAddress, BaseAddress + Length - 1,
> 
> (1) I think