Re: [edk2] [PATCH v3 11/12] CryptoPkg/IntrinsicLib: Remove .S files for IA32 arch
Reviewed-by: Jian J Wang > -Original Message- > From: Zhang, Shenglei > Sent: Friday, March 29, 2019 3:31 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Gang Wei ; Wang, Jian > J > Subject: [PATCH v3 11/12] CryptoPkg/IntrinsicLib: Remove .S files for IA32 > arch > > .nasm file has been added for X86 arch. .S assembly code > is not required any more. > https://bugzilla.tianocore.org/show_bug.cgi?id=1594 > > Cc: Ting Ye > Cc: Gang Wei > Cc: Jian Wang > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > .../Library/IntrinsicLib/Ia32/MathLShiftS64.S | 62 - > .../Library/IntrinsicLib/Ia32/MathRShiftU64.S | 66 --- > .../Library/IntrinsicLib/IntrinsicLib.inf | 2 - > 3 files changed, 130 deletions(-) > delete mode 100644 CryptoPkg/Library/IntrinsicLib/Ia32/MathLShiftS64.S > delete mode 100644 CryptoPkg/Library/IntrinsicLib/Ia32/MathRShiftU64.S > > diff --git a/CryptoPkg/Library/IntrinsicLib/Ia32/MathLShiftS64.S > b/CryptoPkg/Library/IntrinsicLib/Ia32/MathLShiftS64.S > deleted file mode 100644 > index 7031a59a71..00 > --- a/CryptoPkg/Library/IntrinsicLib/Ia32/MathLShiftS64.S > +++ /dev/null > @@ -1,62 +0,0 @@ > -#-- > -# > -# Copyright (c) 2014, Intel Corporation. All rights reserved. > -# This program and the accompanying materials > -# are licensed and made available under the terms and conditions of the BSD > License > -# which accompanies this distribution. The full text of the license may be > found > at > -# http://opensource.org/licenses/bsd-license.php. > -# > -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > -# > -# Module Name: > -# > -# MathLShiftS64.S > -# > -# Abstract: > -# > -# 64-bit Math Worker Function. > -# Shifts a 64-bit signed value left by a certain number of bits. > -# > -#-- > - > -.686: > -.code: > - > -ASM_GLOBAL ASM_PFX(__ashldi3) > - > -#-- > -# > -# void __cdecl __ashldi3 (void) > -# > -#-- > -ASM_PFX(__ashldi3): > -# > -# Handle shifting of 64 or more bits (return 0) > -# > -cmpb$64, %cl > -jae ReturnZero > - > -# > -# Handle shifting of between 0 and 31 bits > -# > -cmpb$32, %cl > -jae More32 > -shld%cl, %eax, %edx > -shl %cl, %eax > -ret > - > -# > -# Handle shifting of between 32 and 63 bits > -# > -More32: > -movl%eax, %edx > -xor %eax, %eax > -and $31, %cl > -shl %cl, %edx > -ret > - > -ReturnZero: > -xor %eax, %eax > -xor %edx, %edx > -ret > diff --git a/CryptoPkg/Library/IntrinsicLib/Ia32/MathRShiftU64.S > b/CryptoPkg/Library/IntrinsicLib/Ia32/MathRShiftU64.S > deleted file mode 100644 > index 24142b088e..00 > --- a/CryptoPkg/Library/IntrinsicLib/Ia32/MathRShiftU64.S > +++ /dev/null > @@ -1,66 +0,0 @@ > -#-- > -# > -# Copyright (c) 2014, Intel Corporation. All rights reserved. > -# This program and the accompanying materials > -# are licensed and made available under the terms and conditions of the BSD > License > -# which accompanies this distribution. The full text of the license may be > found > at > -# http://opensource.org/licenses/bsd-license.php. > -# > -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > -# > -# Module Name: > -# > -# MathRShiftU64.S > -# > -# Abstract: > -# > -# 64-bit Math Worker Function. > -# Shifts a 64-bit unsigned value right by a certain number of bits. > -# > -#-- > - > - > -.686: > -.code: > - > -ASM_GLOBAL ASM_PFX(__ashrdi3) > - > -#-- > -# > -# void __cdecl __ashrdi3 (void) > -# > -#-- > -ASM_PFX(__ashrdi3): > -# > -# Checking: Only handle 64bit shifting or mor
Re: [edk2] [PATCH v3 11/12] CryptoPkg/IntrinsicLib: Remove .S files for IA32 arch
Reviewed-by: Jian J Wang > -Original Message- > From: Zhang, Shenglei > Sent: Friday, March 29, 2019 3:32 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Wang, Jian J > Subject: [PATCH v3 11/12] CryptoPkg/IntrinsicLib: Remove .S files for IA32 > arch > > .nasm file has been added for X86 arch. .S assembly code > is not required any more. > https://bugzilla.tianocore.org/show_bug.cgi?id=1594 > > Cc: Ting Ye > Cc: Jian Wang > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > .../Library/IntrinsicLib/Ia32/MathLShiftS64.S | 62 - > .../Library/IntrinsicLib/Ia32/MathRShiftU64.S | 66 --- > .../Library/IntrinsicLib/IntrinsicLib.inf | 2 - > 3 files changed, 130 deletions(-) > delete mode 100644 CryptoPkg/Library/IntrinsicLib/Ia32/MathLShiftS64.S > delete mode 100644 CryptoPkg/Library/IntrinsicLib/Ia32/MathRShiftU64.S > > diff --git a/CryptoPkg/Library/IntrinsicLib/Ia32/MathLShiftS64.S > b/CryptoPkg/Library/IntrinsicLib/Ia32/MathLShiftS64.S > deleted file mode 100644 > index 7031a59a71..00 > --- a/CryptoPkg/Library/IntrinsicLib/Ia32/MathLShiftS64.S > +++ /dev/null > @@ -1,62 +0,0 @@ > -#-- > -# > -# Copyright (c) 2014, Intel Corporation. All rights reserved. > -# This program and the accompanying materials > -# are licensed and made available under the terms and conditions of the BSD > License > -# which accompanies this distribution. The full text of the license may be > found > at > -# http://opensource.org/licenses/bsd-license.php. > -# > -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > -# > -# Module Name: > -# > -# MathLShiftS64.S > -# > -# Abstract: > -# > -# 64-bit Math Worker Function. > -# Shifts a 64-bit signed value left by a certain number of bits. > -# > -#-- > - > -.686: > -.code: > - > -ASM_GLOBAL ASM_PFX(__ashldi3) > - > -#-- > -# > -# void __cdecl __ashldi3 (void) > -# > -#-- > -ASM_PFX(__ashldi3): > -# > -# Handle shifting of 64 or more bits (return 0) > -# > -cmpb$64, %cl > -jae ReturnZero > - > -# > -# Handle shifting of between 0 and 31 bits > -# > -cmpb$32, %cl > -jae More32 > -shld%cl, %eax, %edx > -shl %cl, %eax > -ret > - > -# > -# Handle shifting of between 32 and 63 bits > -# > -More32: > -movl%eax, %edx > -xor %eax, %eax > -and $31, %cl > -shl %cl, %edx > -ret > - > -ReturnZero: > -xor %eax, %eax > -xor %edx, %edx > -ret > diff --git a/CryptoPkg/Library/IntrinsicLib/Ia32/MathRShiftU64.S > b/CryptoPkg/Library/IntrinsicLib/Ia32/MathRShiftU64.S > deleted file mode 100644 > index 24142b088e..00 > --- a/CryptoPkg/Library/IntrinsicLib/Ia32/MathRShiftU64.S > +++ /dev/null > @@ -1,66 +0,0 @@ > -#-- > -# > -# Copyright (c) 2014, Intel Corporation. All rights reserved. > -# This program and the accompanying materials > -# are licensed and made available under the terms and conditions of the BSD > License > -# which accompanies this distribution. The full text of the license may be > found > at > -# http://opensource.org/licenses/bsd-license.php. > -# > -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > -# > -# Module Name: > -# > -# MathRShiftU64.S > -# > -# Abstract: > -# > -# 64-bit Math Worker Function. > -# Shifts a 64-bit unsigned value right by a certain number of bits. > -# > -#-- > - > - > -.686: > -.code: > - > -ASM_GLOBAL ASM_PFX(__ashrdi3) > - > -#-- > -# > -# void __cdecl __ashrdi3 (void) > -# > -#-- > -ASM_PFX(__ashrdi3): > -# > -# Checking: Only handle 64bit shifting or more > -# > -cmpb
Re: [edk2] [PATCH v3 2/3] SecurityPkg/SecurityPkg.uni: Add the prompt and help information
Reviewed-by: Jian J Wang > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Shenglei Zhang > Sent: Wednesday, March 13, 2019 11:24 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v3 2/3] SecurityPkg/SecurityPkg.uni: Add the prompt and > help information > > The prompt and help information are missing in SecurityPkg.uni. > https://bugzilla.tianocore.org/show_bug.cgi?id=1600 > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > Reviewed-by: Star Zeng > --- > SecurityPkg/SecurityPkg.uni | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/SecurityPkg/SecurityPkg.uni b/SecurityPkg/SecurityPkg.uni > index 400fe6015e..5f387672e8 100644 > --- a/SecurityPkg/SecurityPkg.uni > +++ b/SecurityPkg/SecurityPkg.uni > @@ -248,6 +248,12 @@ > #string STR_gEfiSecurityPkgTokenSpaceGuid_PcdTpm2PossibleIrqNumBuf_HELP > #language en-US "This PCD defines possible TPM2 interrupt number in a > platform reported by _PRS control method.\n" > > "If PcdTpm2CurrentIrqNum set > to 0, _PRS will not report any possible TPM2 interrupt numbers." > > +#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipOpalDxeUnlock_PROMPT > #language en-US "Skip Opal DXE driver unlock device flow." > + > +#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdSkipOpalDxeUnlock_HELP > #language en-US "Indicates if Opal DXE driver skip unlock device > flow.\n" > + > "TRUE - Skip unlock device > flow.\n" > + > "FALSE - Does not skip unlock > device flow." > + > #string > STR_gEfiSecurityPkgTokenSpaceGuid_PcdActiveTpmInterfaceType_PROMPT > #language en-US "Current active TPM interface type" > > #string STR_gEfiSecurityPkgTokenSpaceGuid_PcdActiveTpmInterfaceType_HELP > #language en-US "This PCD indicates current active TPM interface type.\n" > -- > 2.18.0.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] Maintainers.txt: remove unexpected unicode BOM
> On 03/08/19 10:07, Wang, Jian J wrote: > > Pushed at c2c4b919caa297fbe83f02b897c125b87eb1fd58 > > > > Regards, > > Jian > > (I didn't ignore the fixup patch, I was just busy with something else.) > I know you won't. Just someone was pushing me behind... Jian > Thanks for this! > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainers.txt: remove unexpected unicode BOM
Pushed at c2c4b919caa297fbe83f02b897c125b87eb1fd58 Regards, Jian > -Original Message- > From: Zhang, Chao B > Sent: Friday, March 08, 2019 4:58 PM > To: Wang, Jian J ; edk2-devel@lists.01.org > Cc: Laszlo Ersek ; Yao, Jiewen ; > zh...@ml01.01.org > Subject: RE: [edk2] [PATCH] Maintainers.txt: remove unexpected unicode BOM > > HI Jian: > Tks for the fix. > Reviewed-by: Chao Zhang > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J > Wang > Sent: Friday, March 8, 2019 4:56 PM > To: edk2-devel@lists.01.org > Cc: Laszlo Ersek ; Yao, Jiewen ; > Zhang, Chao B ; zh...@ml01.01.org > Subject: [edk2] [PATCH] Maintainers.txt: remove unexpected unicode BOM > > The BOM was introduced by commit > 6c05b958df532345a35b418b05effcf7fd51fc4e > accidentally. > > Cc: Yao Jiewen > Cc: Zhang, Chao B > Cc: Laszlo Ersek > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Jian J Wang > --- > Maintainers.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt index 08a676b236..61c57587a6 > 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -1,4 +1,4 @@ > -EDK II Maintainers > +EDK II Maintainers > == > > This file provides information about the primary maintainers for > -- > 2.17.1.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/2] Fix bugs in HiiDatabase driver
Hi all, This is a very important fix for this issue. If no objection, I'd like the patch be part of this stable tag. As to this patch series, Reviewed-by: Jian J Wang > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ray Ni > Sent: Friday, March 08, 2019 10:35 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v2 0/2] Fix bugs in HiiDatabase driver > > v2: put the CVE number in patch title. > > Ray Ni (2): > MdeModulePkg/HiiDatabase: Fix potential integer overflow > (CVE-2018-12181) > MdeModulePkg/HiiImage: Fix stack overflow when corrupted BMP is parsed > (CVE-2018-12181) > > MdeModulePkg/Universal/HiiDatabaseDxe/Image.c | 130 ++ > 1 file changed, 105 insertions(+), 25 deletions(-) > > -- > 2.20.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] Maintainers.txt: Change package maintainer and reviewer of SecurityPkg.
Reviewed-by: Jian J Wang > -Original Message- > From: Zhang, Chao B > Sent: Friday, March 08, 2019 10:57 AM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Wang, Jian J > Subject: [Patch] Maintainers.txt: Change package maintainer and reviewer of > SecurityPkg. > > Cc: Yao Jiewen > Cc: Jian Wang > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Zhang, Chao B > --- > Maintainers.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 7772926b2f..08a676b236 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -1,6 +1,6 @@ > -EDK II Maintainers > +EDK II Maintainers > == > > This file provides information about the primary maintainers for > EDK II. > > @@ -237,10 +237,11 @@ M: Kelly Steele > > SecurityPkg > W: https://github.com/tianocore/tianocore.github.io/wiki/SecurityPkg > M: Chao Zhang > M: Jiewen Yao > +M: Jian Wang > > ShellBinPkg > W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg > M: Jaben Carsey (Ia32/X64) > M: Ray Ni (Ia32/X64) > -- > 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2] UefiCpuPkg: restore strict page attributes via #DB in nonstop mode only
Thanks. To catch cold freeze, pushed earlier
(2a9324cfca12c66f13a41d52fb0a82fb924e)
Regards,
Jian
> -Original Message-
> From: Dong, Eric
> Sent: Friday, March 01, 2019 9:55 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Ni, Ray ; Laszlo Ersek ; Zeng, Star
>
> Subject: RE: [edk2] [PATCH 2] UefiCpuPkg: restore strict page attributes via
> #DB
> in nonstop mode only
>
> Reviewed-by: Eric Dong
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jian J Wang
> > Sent: Friday, March 1, 2019 8:58 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ray ; Laszlo Ersek ; Dong,
> > Eric ; Zeng, Star
> > Subject: [edk2] [PATCH 2] UefiCpuPkg: restore strict page attributes via #DB
> > in nonstop mode only
> >
> > > v2: Per Laszlo's comments, repack origianl two patches into one with
> > > title changed and relevant commits added
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1576
> >
> > The root cause of this issue is that non-stop mode of Heap Guard and NULL
> > Detection set TF bit (single-step) in EFLAG unconditionally in the common
> > handler in CpuExceptionLib.
> >
> > If PcdCpuSmmStaticPageTable is FALSE, the SMM will only create page table
> > for memory below 4G. If SMM tries to access memory beyond 4G, a page
> > fault exception will be triggered and the memory to access will be added to
> > page table so that SMM code can continue the access.
> >
> > Because of above issue, the TF bit is set after the page fault is handled
> > and
> > then fall into another DEBUG exception. Since non-stop mode of Heap Guard
> > and NULL Detection are not enabled, no special DEBUG exception handler is
> > registered. The default handler just prints exception context and go into
> > dead loop.
> >
> > Actually EFLAGS can be changed in any standard exception handler.
> > There's no need to do single-step setup in assembly code. So the fix is to
> > move the logic to C code part of page fault exception handler so that we can
> > fully validate the configuration and prevent TF bit from being set
> > unexpectedly.
> >
> > Fixes: dcc026217fdc363f55c217039fc43d344f69fed6
> >16b918bbaf51211a32ae04d9d8a5ba6ccca25a6a
> > Test:
> > - Pass special test of accessing memory beyond 4G in SMM mode
> > - Boot to OS with Qemu emulator platform (Fedora27, Ubuntu18.04,
> >Windows7, Windows10)
> >
> > Cc: Eric Dong
> > Cc: Laszlo Ersek
> > Cc: Ruiyu Ni
> > Cc: Star Zeng
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > Acked-by: Laszlo Ersek
> > ---
> > UefiCpuPkg/CpuDxe/CpuPageTable.c | 11 ++-
> > .../Ia32/ExceptionHandlerAsm.nasm | 7 ---
> > .../X64/ExceptionHandlerAsm.nasm | 4
> > 3 files changed, 10 insertions(+), 12 deletions(-)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index 4bee8c7772..812537417d 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -1300,7 +1300,16 @@ PageFaultExceptionHandler (
> >// Display ExceptionType, CPU information and Image information
> >//
> >DumpCpuContext (ExceptionType, SystemContext);
> > - if (!NonStopMode) {
> > + if (NonStopMode) {
> > +//
> > +// Set TF in EFLAGS
> > +//
> > +if (mPagingContext.MachineType == IMAGE_FILE_MACHINE_I386) {
> > + SystemContext.SystemContextIa32->Eflags |= (UINT32)BIT8;
> > +} else {
> > + SystemContext.SystemContextX64->Rflags |= (UINT64)BIT8;
> > +}
> > + } else {
> > CpuDeadLoop ();
> >}
> > }
> > diff --git
> > a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.
> > nasm
> > b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.
> > nasm
> > index 6fcf5fb23f..45d6474091 100644
> > ---
> > a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm.
> > nasm
> > +++
> > b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ExceptionHandlerAsm
> > +++ .nasm
> > @@ -383,13 +383,6 @@ ErrorCodeAndVectorOnStack:
> > pop dword [ebp - 4]
> > mov esp, ebp
> > pop ebp
> > -
> > -; Enable TF bit after page fault handler runs
> > -cmp dword [esp], 14 ; #
Re: [edk2] [PATCH 0/2] Fix SMM driver hang at accessing memory beyond 4G
Laszlo, Sure. It'll be added Regards, Jian > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, February 28, 2019 10:10 PM > To: Wang, Jian J ; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH 0/2] Fix SMM driver hang at accessing memory > beyond 4G > > On 02/28/19 15:07, Laszlo Ersek wrote: > > > (4) I also suggest adding: > > > > Fixes: dcc026217fdc363f55c217039fc43d344f69fed6 > > Additionally append: > > Fixes: 16b918bbaf51211a32ae04d9d8a5ba6ccca25a6a > > Thanks, > Laszlo > > > > > near the end of the commit message. > > > > > > With (2) through (4) addressed: > > > > Acked-by: Laszlo Ersek > > > > Thanks > > Laszlo > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/2] Fix SMM driver hang at accessing memory beyond 4G
Laszlo,
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, February 28, 2019 10:07 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 0/2] Fix SMM driver hang at accessing memory
> beyond 4G
>
> Hi Jian,
>
> On 02/28/19 11:10, Jian J Wang wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1576
> > Test:
> > - Pass special test of accessing memory beyond 4G
> > - Boot to OS with Qemu emulator platform (Fedora27, Ubuntu18.04,
> > Windows7, Windows10)
> >
> > Jian J Wang (2):
> > UefiCpuPkg/CpuDxe: set TF bit in EFLAGS in C code
> > UefiCpuPkg/CpuDxe: remove code to set TF bit in EFLAGS
> >
> > UefiCpuPkg/CpuDxe/CpuPageTable.c | 11 ++-
> > .../Ia32/ExceptionHandlerAsm.nasm | 7 ---
> > .../X64/ExceptionHandlerAsm.nasm | 4
> > 3 files changed, 10 insertions(+), 12 deletions(-)
> >
>
> thanks for the good description in the BZ and the patches.
>
> Also thanks for the good commit message on commit dcc026217fdc
> ("UefiCpuPkg/CpuDxe: implement non-stop mode for uefi", 2018-08-30),
> which is a handy reminder about nonstop mode.
>
>
> (1) My understanding is that, for the problem to arise, it is necessary
> for a platform to set
>
> PcdCpuSmmStaticPageTable = FALSE
>
> Because of that, I expect the code changes as well to be restricted to
> such code paths (i.e. I expect the code changes to be invisible with
> PcdCpuSmmStaticPageTable=TRUE). Therefore I'll skip regression testing
> this series.
>
Correct.
>
> (2) Both commit messages say,
>
> "the fix is to *move* the logic to C code part of page fault exception
> handler"
>
> (In fact, the commit messages are identical.)
>
> Therefore I think the two patches should be squashed into one. It should
> be one atomic code movement. For example, if someone bisects the git
> history, and they check out the tree between the two patches, they will
> have the TF bit logic in both places. That's probably not good.
>
>
Agree. I'll merge them.
> (3) I think this is my most important comment for this series:
>
> The subject lines of the patches do not state the *actual* change. The
> actual change is not that we move the TF bit manipulation from assembly
> code to C code. Instead, the change is that we make the TF setting
> *conditional*. In other words, we restrict the setting of TF (--> the
> single stepping, = the debug exception after re-executing the originally
> faulting instruction) only if we *need* the debug exception, for
> restoring the strict page attributes, after the faulting instruction is
> allowed to pass.
>
> In other words, we enable the "restore page attributes" logic (#DB
> exception handler) only if there is a reason for that (= we are in
> nonstop mode).
>
> My apologies if the above paragraph is too verbose. I simply suggest
> that the squashed patch have the following subject:
>
> UefiCpuPkg: restore strict page attributes via #DB in nonstop mode only
>
> (71 characters).
>
>
Very good explanation and abstraction. Agree.
> (4) I also suggest adding:
>
> Fixes: dcc026217fdc363f55c217039fc43d344f69fed6
>
> near the end of the commit message.
>
>
> With (2) through (4) addressed:
>
> Acked-by: Laszlo Ersek
>
It'll be added. Thanks for the great feedback.
Jian
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/3] MdeModulePkg/PeiCore: Ensure FfsFileHeader 8 bytes aligned [CVE-2018-3630]
Reviewed-by: Jian J Wang
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Wednesday, February 27, 2019 12:04 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen ;
> Gao, Liming ; Zeng, Star
> Subject: [edk2] [PATCH 1/3] MdeModulePkg/PeiCore: Ensure FfsFileHeader 8
> bytes aligned [CVE-2018-3630]
>
> From: Star Zeng
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=864
>
> To follow PI spec, ensure FfsFileHeader 8 bytes aligned.
>
> Current code only handles (FwVolHeader->ExtHeaderOffset != 0) path,
> update code to also handle (FwVolHeader->ExtHeaderOffset == 0) path.
>
> Cc: Jiewen Yao
> Cc: Liming Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Core/Pei/FwVol/FwVol.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> index 0a67b96bf1..56440eacf0 100644
> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> @@ -2,7 +2,7 @@
>Pei Core Firmware File System service routines.
>
> Copyright (c) 2015 HP Development Company, L.P.
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, 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
> @@ -316,10 +316,10 @@ FindFileEx (
>//
>FwVolExtHeader = (EFI_FIRMWARE_VOLUME_EXT_HEADER *) ((UINT8 *)
> FwVolHeader + FwVolHeader->ExtHeaderOffset);
>FfsFileHeader = (EFI_FFS_FILE_HEADER *) ((UINT8 *) FwVolExtHeader +
> FwVolExtHeader->ExtHeaderSize);
> - FfsFileHeader = (EFI_FFS_FILE_HEADER *) ALIGN_POINTER (FfsFileHeader,
> 8);
> } else {
>FfsFileHeader = (EFI_FFS_FILE_HEADER *)((UINT8 *) FwVolHeader +
> FwVolHeader->HeaderLength);
> }
> +FfsFileHeader = (EFI_FFS_FILE_HEADER *) ALIGN_POINTER (FfsFileHeader, 8);
>} else {
> if (IS_FFS_FILE2 (*FileHeader)) {
>if (!IsFfs3Fv) {
> --
> 2.17.1.windows.2
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/3] MdeModulePkg/DxeCore: Ensure FfsFileHeader 8 bytes aligned [CVE-2018-3630]
Reviewed-by: Jian J Wang
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Wednesday, February 27, 2019 12:04 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Yao, Jiewen ;
> Gao, Liming ; Zeng, Star
> Subject: [edk2] [PATCH 2/3] MdeModulePkg/DxeCore: Ensure FfsFileHeader 8
> bytes aligned [CVE-2018-3630]
>
> From: Star Zeng
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=864
>
> To follow PI spec, ensure FfsFileHeader 8 bytes aligned.
>
> For the integrity of FV(especially non-MemoryMapped FV) layout,
> let CachedFv point to FV beginning, but not (FV + FV header).
>
> And current code only handles (FwVolHeader->ExtHeaderOffset != 0) path,
> update code to also handle (FwVolHeader->ExtHeaderOffset == 0) path.
>
> Cc: Jiewen Yao
> Cc: Liming Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Core/Dxe/FwVol/FwVol.c | 65 +++--
> 1 file changed, 14 insertions(+), 51 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/FwVol/FwVol.c
> b/MdeModulePkg/Core/Dxe/FwVol/FwVol.c
> index 93ddcc3591..28fce46a95 100644
> --- a/MdeModulePkg/Core/Dxe/FwVol/FwVol.c
> +++ b/MdeModulePkg/Core/Dxe/FwVol/FwVol.c
> @@ -3,7 +3,7 @@
>Layers on top of Firmware Block protocol to produce a file abstraction
>of FV based files.
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, 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
> @@ -329,8 +329,6 @@ FvCheck (
>FFS_FILE_LIST_ENTRY *FfsFileEntry;
>EFI_FFS_FILE_HEADER *FfsHeader;
>UINT8 *CacheLocation;
> - UINTN LbaOffset;
> - UINTN HeaderSize;
>UINTN Index;
>EFI_LBA LbaIndex;
>UINTN Size;
> @@ -353,11 +351,7 @@ FvCheck (
> return Status;
>}
>
> - //
> - // Size is the size of the FV minus the head. We have already allocated
> - // the header to check to make sure the volume is valid
> - //
> - Size = (UINTN)(FwVolHeader->FvLength - FwVolHeader->HeaderLength);
> + Size = (UINTN) FwVolHeader->FvLength;
>if ((FvbAttributes & EFI_FVB2_MEMORY_MAPPED) != 0) {
> FvDevice->IsMemoryMapped = TRUE;
>
> @@ -369,7 +363,7 @@ FvCheck (
> //
> // Don't cache memory mapped FV really.
> //
> -FvDevice->CachedFv = (UINT8 *) (UINTN) (PhysicalAddress + FwVolHeader-
> >HeaderLength);
> +FvDevice->CachedFv = (UINT8 *) (UINTN) PhysicalAddress;
>} else {
> FvDevice->IsMemoryMapped = FALSE;
> FvDevice->CachedFv = AllocatePool (Size);
> @@ -380,52 +374,27 @@ FvCheck (
>}
>
>//
> - // Remember a pointer to the end fo the CachedFv
> + // Remember a pointer to the end of the CachedFv
>//
>FvDevice->EndOfCachedFv = FvDevice->CachedFv + Size;
>
>if (!FvDevice->IsMemoryMapped) {
> //
> -// Copy FV minus header into memory using the block map we have all ready
> -// read into memory.
> +// Copy FV into memory using the block map.
> //
> BlockMap = FwVolHeader->BlockMap;
> CacheLocation = FvDevice->CachedFv;
> LbaIndex = 0;
> -LbaOffset = 0;
> -HeaderSize = FwVolHeader->HeaderLength;
> while ((BlockMap->NumBlocks != 0) || (BlockMap->Length != 0)) {
> - Index = 0;
> - Size = BlockMap->Length;
> - if (HeaderSize > 0) {
> -//
> -// Skip header size
> -//
> -for (; Index < BlockMap->NumBlocks && HeaderSize >= BlockMap->Length;
> Index ++) {
> - HeaderSize -= BlockMap->Length;
> - LbaIndex ++;
> -}
> -
> -//
> -// Check whether FvHeader is crossing the multi block range.
> -//
> -if (Index >= BlockMap->NumBlocks) {
> - BlockMap++;
> - continue;
> -} else if (HeaderSize > 0) {
> - LbaOffset = HeaderSize;
> - Size = BlockMap->Length - HeaderSize;
> - HeaderSize = 0;
> -}
> - }
> -
>//
>// read the FV data
>//
> - for (; Index < BlockMap->NumBlocks; Index ++) {
> -Status = Fvb->Read (Fvb,
> + Size = BlockMap->Length;
> + for (Index = 0; Index < BlockMap->NumBlocks; Index++) {
> +Status = Fvb->Read (
> +Fvb,
> LbaIndex,
> -LbaOffset,
> +0,
> &Size,
> CacheLocation
> );
> @@ -
Re: [edk2] [PATCH 3/3] IntelFrameworkModulePkg/FwVolDxe: Ensure FfsFileHeader 8 bytes aligned [CVE-2018-3630]
Reviewed-by: Jian J Wang
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Wednesday, February 27, 2019 12:04 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Gao, Liming ;
> Zeng, Star
> Subject: [edk2] [PATCH 3/3] IntelFrameworkModulePkg/FwVolDxe: Ensure
> FfsFileHeader 8 bytes aligned [CVE-2018-3630]
>
> From: Star Zeng
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=864
>
> To follow PI spec, ensure FfsFileHeader 8 bytes aligned.
>
> Current code only handles (FwVolHeader->ExtHeaderOffset != 0) path,
> update code to also handle (FwVolHeader->ExtHeaderOffset == 0) path.
>
> Cc: Jiewen Yao
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/FirmwareVolume/FwVolDxe/FwVol.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/IntelFrameworkModulePkg/Universal/FirmwareVolume/FwVolDxe/FwVol.c
> b/IntelFrameworkModulePkg/Universal/FirmwareVolume/FwVolDxe/FwVol.c
> index 9a031bab14..9a892240b4 100644
> --- a/IntelFrameworkModulePkg/Universal/FirmwareVolume/FwVolDxe/FwVol.c
> +++
> b/IntelFrameworkModulePkg/Universal/FirmwareVolume/FwVolDxe/FwVol.c
> @@ -4,7 +4,7 @@
>Layers on top of Firmware Block protocol to produce a file abstraction
>of FV based files.
>
> - Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>
>This program and the accompanying materials
>are licensed and made available under the terms and conditions
> @@ -510,10 +510,10 @@ FvCheck (
> //
> FwVolExtHeader = (EFI_FIRMWARE_VOLUME_EXT_HEADER *) (UINTN)
> (FvDevice->CachedFv + FvDevice->FwVolHeader->ExtHeaderOffset);
> Ptr = (UINT8 *) FwVolExtHeader + FwVolExtHeader->ExtHeaderSize;
> -Ptr = (UINT8 *) ALIGN_POINTER (Ptr, 8);
>} else {
> Ptr = (UINT8 *) (UINTN) (FvDevice->CachedFv + FvDevice->FwVolHeader-
> >HeaderLength);
>}
> + Ptr = (UINT8 *) ALIGN_POINTER (Ptr, 8);
>TopFvAddress = (UINT8 *) (UINTN) (FvDevice->CachedFv + FvDevice-
> >FwVolHeader->FvLength);
>
>//
> --
> 2.17.1.windows.2
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check for FilePath device path
Hi Ray,
> -Original Message-
> From: Ni, Ray
> Sent: Tuesday, February 19, 2019 5:34 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Kinney, Michael D
>
> Subject: RE: [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check for
> FilePath device path
>
>
>
> > -----Original Message-
> > From: Wang, Jian J
> > Sent: Tuesday, February 19, 2019 5:22 PM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Ni, Ray ; Kinney,
> > Michael D
> > Subject: [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check for
> > FilePath device path
> >
> > > v2: fix wrong detection of FilePath device path
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1497
> >
> > Current implementation of IsDevicePathValid() is not enough for type of
> > MEDIA_FILEPATH_DP, which has NULL-terminated string in the device path.
> > This patch add a simple NULL character check at Length position.
> >
> > Cc: Liming Gao
> > Cc: Ray Ni
> > Cc: Michael D Kinney
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> > b/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> > index 5d7635fe3e..dd1bddc1c2 100644
> > --- a/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> > +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> > @@ -95,6 +95,15 @@ IsDevicePathValid (
> > return FALSE;
> >}
> > }
> > +
> > +//
> > +// FilePath must be a NULL-terminated string.
> > +//
> > +if (DevicePathType (DevicePath) == MEDIA_DEVICE_PATH &&
> > +DevicePathSubType (DevicePath) == MEDIA_FILEPATH_DP &&
> > +*(CHAR16 *)((UINT8 *)DevicePath + NodeLength - 2) != 0) {
> Can we assume the device path node buffer contains exact the null terminated
> string?
> What if the buffer contains some padding bytes after null terminated string?
>
> To handle this case, can we convert the DevicePath to FILEPATH_DEVICE_PATH
> and use logic similar as below?
>
> FILEPATH_DEVICE_PATH *FilePath;
> FilePath = (FILEPATH_DEVICE_PATH *) DevicePath;
> MaxSize = (NodeLength - sizeof (EFI_DEVICE_PATH_PROTOCOL)) / sizeof
> (CHAR16);
> If (StrnLenS (FilePath->PathName, MaxSize) == MaxSize) {
> Return FALSE;
> }
>
I did think about your implementation and I agree it might be the best way
from compatibility perspective. But I have three considerations:
1. It's not a good programming habit to pass unwanted data around and should not
be encouraged to do so.
2. It might leave potential security hole (maybe I'm a little too cautious)
3. The UEFI spec has following statement on this type of device path
(ch10.3.6.4).
" A NULL-terminated Path string including directory and file names. The length
of
this string n can be determined by subtracting 4 from the Length entry."
But I'm still open to your suggestion, if all agree that compatibility is more
important.
Regards,
Jian
>
>
> > + return FALSE;
> > +}
> >}
> >
> >//
> > --
> > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/PropertiesTableAttributesDxe: Remove this driver
Reviewed-by: Jian J Wang
> -Original Message-
> From: Zhang, Shenglei
> Sent: Monday, February 18, 2019 4:53 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Zeng, Star
> Subject: [PATCH] MdeModulePkg/PropertiesTableAttributesDxe: Remove this
> driver
>
> This functionality of this driver has been deprecated and
> no platform employs this driver. It can be removed completely.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1475
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> MdeModulePkg/MdeModulePkg.dsc | 1 -
> .../PropertiesTableAttributesDxe.c| 208 --
> .../PropertiesTableAttributesDxe.inf | 56 -
> .../PropertiesTableAttributesDxe.uni | 23 --
> .../PropertiesTableAttributesDxeExtra.uni | 23 --
> 5 files changed, 311 deletions(-)
> delete mode 100644
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttribu
> tesDxe.c
> delete mode 100644
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttribu
> tesDxe.inf
> delete mode 100644
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttribu
> tesDxe.uni
> delete mode 100644
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttribu
> tesDxeExtra.uni
>
> diff --git a/MdeModulePkg/MdeModulePkg.dsc
> b/MdeModulePkg/MdeModulePkg.dsc
> index 4f2ac8ae89..388bca25bd 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -413,7 +413,6 @@
>MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
>MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
>
> -
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttribu
> tesDxe.inf
>MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf {
>
>
> FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> diff --git
> a/MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttri
> butesDxe.c
> b/MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttri
> butesDxe.c
> deleted file mode 100644
> index 4d1a46f64c..00
> ---
> a/MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAttri
> butesDxe.c
> +++ /dev/null
> @@ -1,208 +0,0 @@
> -/** @file
> - This module sets default policy for attributes of EfiACPIMemoryNVS and
> EfiReservedMemoryType.
> -
> - This module sets EFI_MEMORY_XP for attributes of EfiACPIMemoryNVS and
> EfiReservedMemoryType
> - in UEFI memory map, if and only of PropertiesTable is published and has
> BIT0
> set.
> -
> -Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
> -This program and the accompanying materials
> -are licensed and made available under the terms and conditions of the BSD
> License
> -which accompanies this distribution. The full text of the license may be
> found
> at
> -http://opensource.org/licenses/bsd-license.php
> -
> -THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
> OR IMPLIED.
> -
> -**/
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -/**
> - Converts a number of EFI_PAGEs to a size in bytes.
> -
> - NOTE: Do not use EFI_PAGES_TO_SIZE because it handles UINTN only.
> -
> - @param Pages The number of EFI_PAGES.
> -
> - @return The number of bytes associated with the number of EFI_PAGEs
> specified
> - by Pages.
> -**/
> -UINT64
> -EfiPagesToSize (
> - IN UINT64 Pages
> - )
> -{
> - return LShiftU64 (Pages, EFI_PAGE_SHIFT);
> -}
> -
> -/**
> - Set memory attributes according to default policy.
> -
> - @param MemoryMapA pointer to the buffer in which firmware places
> the current memory map.
> - @param MemoryMapSizeSize, in bytes, of the MemoryMap buffer.
> - @param DescriptorSize size, in bytes, of an individual
> EFI_MEMORY_DESCRIPTOR.
> -**/
> -VOID
> -SetMemorySpaceAttributesDefault (
> - IN EFI_MEMORY_DESCRIPTOR *MemoryMap,
> - IN UINTN MemoryMapSize,
> - IN UINTN DescriptorSize
> - )
> -{
> - EFI_MEMORY_DESCRIPTOR *MemoryMapEntry;
> - EFI_MEMORY_DESCRIPTOR *MemoryMapEnd;
> - EFI_STATUS Status;
> -
> - DEBUG ((EFI_D_INFO, "SetMemorySpaceAttributesDefault\n"));
> -
> - MemoryMapEntry =
Re: [edk2] [PATCH v2 2/3] MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI
Reviewed-by: Jian J Wang
> -Original Message-
> From: Chiu, Chasel
> Sent: Wednesday, February 13, 2019 5:47 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Zeng, Star ; Gao, Liming
> ; Chiu, Chasel
> Subject: [PATCH v2 2/3] MdeModulePkg/PeiMain: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI
> should be checked to see if PeiCore not in BFV, otherwise
> just shadowing PeiCore from BFV.
>
> Test: Verified on internal platform and booting successfully.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 58
> +-
> MdeModulePkg/Core/Pei/PeiMain.h | 3 ++-
> MdeModulePkg/Core/Pei/PeiMain.inf | 3 ++-
> 3 files changed, 49 insertions(+), 15 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> index 4da80a8222..ba0f2b7b69 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> +++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> @@ -1,7 +1,7 @@
> /** @file
>Pei Core Main Entry Point
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, 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
> @@ -80,23 +80,55 @@ ShadowPeiCore (
>IN PEI_CORE_INSTANCE *PrivateData
>)
> {
> - EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> - EFI_PHYSICAL_ADDRESS EntryPoint;
> - EFI_STATUS Status;
> - UINT32 AuthenticationState;
> + EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> + EFI_PHYSICAL_ADDRESS EntryPoint;
> + EFI_STATUS Status;
> + UINT32 AuthenticationState;
> + UINTNIndex;
> + EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
>
>PeiCoreFileHandle = NULL;
>
>//
> - // Find the PEI Core in the BFV
> + // Find the PEI Core either from EFI_PEI_CORE_FV_LOCATION_PPI indicated
> FV or BFV
>//
> - Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> - PrivateData->Fv[0].FvPpi,
> - EFI_FV_FILETYPE_PEI_CORE,
> - PrivateData->Fv[0].FvHandle,
> - &PeiCoreFileHandle
> - );
> - ASSERT_EFI_ERROR (Status);
> + Status = PeiServicesLocatePpi (
> + &gEfiPeiCoreFvLocationPpiGuid,
> + 0,
> + NULL,
> + (VOID **) &PeiCoreFvLocationPpi
> + );
> + if (!EFI_ERROR (Status) && (PeiCoreFvLocationPpi->PeiCoreFvLocation !=
> NULL)) {
> +//
> +// If PeiCoreFvLocation present, the PEI Core should be found from
> indicated
> FV.
> +//
> +for (Index = 0; Index < PrivateData->FvCount; Index ++) {
> + if (PrivateData->Fv[Index].FvHandle != PeiCoreFvLocationPpi-
> >PeiCoreFvLocation) {
> +continue;
> + }
> + Status = PrivateData->Fv[Index].FvPpi->FindFileByType (
> + PrivateData->Fv[Index].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> +
> PrivateData->Fv[Index].FvHandle,
> + &PeiCoreFileHandle
> + );
> + if (!EFI_ERROR (Status)) {
> +break;
> + }
> +}
> +ASSERT (Index < PrivateData->FvCount);
> + } else {
> +//
> +// Find PEI Core from BFV
> +//
> +Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> + PrivateData->Fv[0].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> + PrivateData->Fv[0].FvHandle,
> + &PeiCoreFileHandle
> + );
> +ASSERT_EFI_ERROR (Status);
> + }
>
>//
>// Shadow PEI Core into memory so it will run fas
Re: [edk2] [PATCH 2/3] MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI
Chasel,
> -Original Message-
> From: Chiu, Chasel
> Sent: Tuesday, February 12, 2019 9:20 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Zeng, Star ; Gao, Liming
> ; Chiu, Chasel
> Subject: [PATCH 2/3] MdeModulePkg/PeiMain: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI
> should be checked to see if PeiCore not in BFV, otherwise
> just shadowing PeiCore from BFV.
>
> Test: Verified on internal platform and booting successfully.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 58
> +-
> MdeModulePkg/Core/Pei/PeiMain.h | 3 ++-
> MdeModulePkg/Core/Pei/PeiMain.inf | 3 ++-
> 3 files changed, 49 insertions(+), 15 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> index 4da80a8222..408f24c216 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> +++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> @@ -1,7 +1,7 @@
> /** @file
>Pei Core Main Entry Point
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, 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
> @@ -80,23 +80,55 @@ ShadowPeiCore (
>IN PEI_CORE_INSTANCE *PrivateData
>)
> {
> - EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> - EFI_PHYSICAL_ADDRESS EntryPoint;
> - EFI_STATUS Status;
> - UINT32 AuthenticationState;
> + EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> + EFI_PHYSICAL_ADDRESS EntryPoint;
> + EFI_STATUS Status;
> + UINT32 AuthenticationState;
> + UINTNIndex;
> + EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
>
>PeiCoreFileHandle = NULL;
>
>//
> - // Find the PEI Core in the BFV
> + // Find the PEI Core either from EFI_PEI_CORE_FV_LOCATION_PPI indicated
> FV or BFV
>//
> - Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> - PrivateData->Fv[0].FvPpi,
> - EFI_FV_FILETYPE_PEI_CORE,
> - PrivateData->Fv[0].FvHandle,
> - &PeiCoreFileHandle
> - );
> - ASSERT_EFI_ERROR (Status);
> + Status = PeiServicesLocatePpi (
> + &gEfiPeiCoreFvLocationPpiGuid,
> + 0,
> + NULL,
> + (VOID **) &PeiCoreFvLocationPpi
> + );
> + if (!EFI_ERROR (Status) && (PeiCoreFvLocationPpi->PeiCoreFvLocation !=
> NULL)) {
> +//
> +// If PeiCoreFvLocation present, the PEI Core should be found from
> indicated
> FV.
> +//
> +for (Index = 0; Index < PrivateData->FvCount; Index ++) {
> + if ((UINT32) PrivateData->Fv[Index].FvHandle != (UINT32)
> PeiCoreFvLocationPpi->PeiCoreFvLocation) {
I think the UINT32 type cast is not necessary. FvHandle and PeiCoreFvLocation
are
actually type of VOID*. Do you encounter any compiler error here?
Regards,
Jian
> +continue;
> + }
> + Status = PrivateData->Fv[Index].FvPpi->FindFileByType (
> + PrivateData->Fv[Index].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> +
> PrivateData->Fv[Index].FvHandle,
> + &PeiCoreFileHandle
> + );
> + if (!EFI_ERROR (Status)) {
> +break;
> + }
> +}
> +ASSERT (Index < PrivateData->FvCount);
> + } else {
> +//
> +// Find PEI Core from BFV
> +//
> +Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> + PrivateData->Fv[0].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> + PrivateData->Fv[0].FvHandle,
> + &PeiCoreFileHandle
>
Re: [edk2] [PATCH v2] CryptoPkg: Fix various typos
Pushed@2a784a2cc356df5a8958afe88bc7e844dc0fb7cc Regards, Jian > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, > Ting > Sent: Monday, February 11, 2019 9:52 AM > To: Antoine Coeur ; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH v2] CryptoPkg: Fix various typos > > Reviewed-by: Ye Ting > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Antoine Coeur > Sent: Friday, February 8, 2019 12:12 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v2] CryptoPkg: Fix various typos > > Fix various typos in CryptoPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 2 +- > CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > index d63c23df09..540c5715cb 100644 > --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > @@ -142,7 +142,7 @@ IMPLEMENT_ASN1_FUNCTIONS (TS_TST_INFO) >@param[in] Asn1Time Pointer to the ASN.1 GeneralizedTime to be > converted. >@param[out] SigningTime Return the corresponding EFI Time. > > - @retval TRUE The time convertion succeeds. > + @retval TRUE The time conversion succeeds. >@retval FALSE Invalid parameters. > > **/ > diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > index 9510a4a383..80f5c2578e 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > @@ -84,14 +84,14 @@ QuickSortWorker ( > } >} >// > - // Swap pivot to it's final position (NextSwapLocaiton) > + // Swap pivot to its final position (NextSwapLocation) >// >CopyMem (Buffer, Pivot, ElementSize); >CopyMem (Pivot, (UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), > ElementSize); >CopyMem ((UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), Buffer, > ElementSize); > >// > - // Now recurse on 2 paritial lists. Neither of these will have the 'pivot' > element. > + // Now recurse on 2 partial lists. Neither of these will have the 'pivot' > element. >// IE list is sorted left half, pivot element, sorted right half... >// >QuickSortWorker ( > -- > 2.17.2 (Apple Git-113) > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] CryptoPkg: Fix various typos
Reviewed-by: Jian J Wang > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Antoine Coeur > Sent: Friday, February 08, 2019 12:12 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v2] CryptoPkg: Fix various typos > > Fix various typos in CryptoPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 2 +- > CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > index d63c23df09..540c5715cb 100644 > --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > @@ -142,7 +142,7 @@ IMPLEMENT_ASN1_FUNCTIONS (TS_TST_INFO) >@param[in] Asn1Time Pointer to the ASN.1 GeneralizedTime to be > converted. >@param[out] SigningTime Return the corresponding EFI Time. > > - @retval TRUE The time convertion succeeds. > + @retval TRUE The time conversion succeeds. >@retval FALSE Invalid parameters. > > **/ > diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > index 9510a4a383..80f5c2578e 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > @@ -84,14 +84,14 @@ QuickSortWorker ( > } >} >// > - // Swap pivot to it's final position (NextSwapLocaiton) > + // Swap pivot to its final position (NextSwapLocation) >// >CopyMem (Buffer, Pivot, ElementSize); >CopyMem (Pivot, (UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), > ElementSize); >CopyMem ((UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), Buffer, > ElementSize); > >// > - // Now recurse on 2 paritial lists. Neither of these will have the 'pivot' > element. > + // Now recurse on 2 partial lists. Neither of these will have the 'pivot' > element. >// IE list is sorted left half, pivot element, sorted right half... >// >QuickSortWorker ( > -- > 2.17.2 (Apple Git-113) > > ___ > 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] CryptoPkg: Fix various typos
Coeur, > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Antoine Coeur > Sent: Thursday, February 07, 2019 1:25 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH] CryptoPkg: Fix various typos > > Fix various typos in CryptoPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 2 +- > CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > index d63c23df09..540c5715cb 100644 > --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > @@ -142,7 +142,7 @@ IMPLEMENT_ASN1_FUNCTIONS (TS_TST_INFO) >@param[in] Asn1Time Pointer to the ASN.1 GeneralizedTime to be > converted. >@param[out] SigningTime Return the corresponding EFI Time. > > - @retval TRUE The time convertion succeeds. > + @retval TRUE The time conversion succeeds. >@retval FALSE Invalid parameters. > > **/ > diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > index 9510a4a383..929e3fcd1e 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > @@ -84,14 +84,14 @@ QuickSortWorker ( > } >} >// > - // Swap pivot to it's final position (NextSwapLocaiton) > + // Swap pivot to it's final position (NextSwapLocation) Thanks for the fixes. Please also change it's to its. Regards, Jian >// >CopyMem (Buffer, Pivot, ElementSize); >CopyMem (Pivot, (UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), > ElementSize); >CopyMem ((UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), Buffer, > ElementSize); > >// > - // Now recurse on 2 paritial lists. Neither of these will have the 'pivot' > element. > + // Now recurse on 2 partial lists. Neither of these will have the 'pivot' > element. >// IE list is sorted left half, pivot element, sorted right half... >// >QuickSortWorker ( > -- > 2.17.2 (Apple Git-113) > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 0/4] Introduce CapsuleApp patch v4
Chen, I just noticed that there's another patch series in which a new interface CharToUpper() is introduced in BaseLib which can be used to replace your local equivalent one UpperCaseString(). I would suggest to hold your patch for a while and use the new interface instead once that patch series is pushed. Sorry for the late remind. Regards, Jian > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen > A Chen > Sent: Thursday, January 31, 2019 10:34 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v4 0/4] Introduce CapsuleApp patch v4 > > No functionality change. > Fix ECC and code style issue. > Already pass CR process. > https://git-amr-7.devtools.intel.com/gerrit/#/c/39023/ > > Chen A Chen (4): > MdePkg/UefiSpec.h: Add definition to support Capsule-on-Disk feature > MdeModulePkg/CapsuleApp: Add a function used to get next DevicePath > MdeModulePkg/CapsuleApp: Add functions to support Capsule-on-Disk > MdeModulePkg/CapsuleApp: Enhance CapsuleApp to support Capsule-on-Disk > > MdeModulePkg/Application/CapsuleApp/CapsuleApp.c | 160 +++- > MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf | 8 + > MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 538 > +- > .../Application/CapsuleApp/CapsuleOnDisk.c | 808 > + > MdeModulePkg/Include/Library/UefiBootManagerLib.h | 21 +- > MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 24 +- > MdeModulePkg/MdeModulePkg.dsc | 1 + > MdePkg/Include/Uefi/UefiSpec.h | 5 + > 8 files changed, 1546 insertions(+), 19 deletions(-) > create mode 100644 MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c > > -- > 2.16.2.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 4/4] MdeModulePkg/CapsuleApp: Enhance CapsuleApp to support Capsule-on-Disk
Reviewed-by: Jian J Wang
> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, January 29, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Wang, Jian J
> ; Wu, Hao A ; Zhang, Chao B
>
> Subject: [PATCH v3 4/4] MdeModulePkg/CapsuleApp: Enhance CapsuleApp to
> support Capsule-on-Disk
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
>
> CapsuleApp is used for trigger capsule update.
> Add -OD option in CapsuleApp to support doing capsule update via storage.
> Add -F and -L options to support dumping information feature.
> Finish unit test for -F and -L options.
> Already verify this feature on Denlow platform, success to update capsule
> via hard disk with -OD option.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleApp.c | 155 +-
> MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf | 8 +
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 538
> -
> 3 files changed, 684 insertions(+), 17 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> index 4d907242f3..258e6995bc 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> @@ -1,7 +1,7 @@
> /** @file
>A shell application that triggers capsule update process.
>
> - Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2016 - 2019, 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
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -105,6 +106,44 @@ DumpEsrtData (
>VOID
>);
>
> +/**
> + Dump Provisioned Capsule.
> +
> + @param[in] DumpCapsuleInfo The flag to indicate whether to dump the
> capsule inforomation.
> +**/
> +VOID
> +DumpProvisionedCapsule (
> + IN BOOLEAN DumpCapsuleInfo
> + );
> +
> +/**
> + Dump all EFI System Partition.
> +**/
> +VOID
> +DumpAllEfiSysPartition (
> + VOID
> + );
> +
> +/**
> + Process Capsule On Disk.
> +
> + @param[in] CapsuleBufferAn array of pointer to capsule images
> + @param[in] FileSize An array of UINTN to capsule images size
> + @param[in] OrgFileName An array of orginal capsule images name
> + @param[in] NewFileName An array of new capsule images name
> + @param[in] CapsuleNum The count of capsule images
> +
> + @retval EFI_SUCCESS Capsule on disk success.
> +**/
> +EFI_STATUS
> +ProcessCapsuleOnDisk (
> + IN VOID **CapsuleBuffer,
> + IN UINTN *CapsuleBufferSize,
> + IN CHAR16**FilePath,
> + IN CHAR16*Map,
> + IN UINTN CapsuleNum
> + );
> +
> /**
>Read a file.
>
> @@ -799,19 +838,22 @@ PrintUsage (
>)
> {
>Print(L"CapsuleApp: usage\n");
> - Print(L" CapsuleApp [-NR]\n");
> + Print(L" CapsuleApp [-NR] [-OD [FSx]]\n");
>Print(L" CapsuleApp -S\n");
>Print(L" CapsuleApp -C\n");
>Print(L" CapsuleApp -P\n");
>Print(L" CapsuleApp -E\n");
> + Print(L" CapsuleApp -L\n");
> + Print(L" CapsuleApp -L INFO\n");
> + Print(L" CapsuleApp -F\n");
>Print(L" CapsuleApp -G -O \n");
>Print(L" CapsuleApp -N -O \n");
>Print(L" CapsuleApp -D \n");
>Print(L" CapsuleApp -P GET -O \n");
>Print(L"Parameter:\n");
> - Print(L" -NR: No reset will be triggered for the capsule with\n");
> - Print(L" CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without\n");
> - Print(L" CAPSULE_FLAGS_INITIATE_RESET.\n");
> + Print(L" -NR: No reset will be triggered for the capsule\n");
> + Print(L" with CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without
> CAPSULE_FLAGS_INITIATE_RESET.\n");
> + Print(L" -OD: Delivery of Capsules via file on Mass Storage device.");
>Print(L" -S: Dump capsule report variable (EFI_CAPSULE_REPORT_GUID),\n");
>Print(L" which is defined in
Re: [edk2] [PATCH v3 2/4] MdeModulePkg/CapsuleApp: Add a function used to get next DevicePath
Reviewed-by: Jian J Wang
> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, January 29, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Wang, Jian J
> ; Wu, Hao A ; Zhang, Chao B
>
> Subject: [PATCH v3 2/4] MdeModulePkg/CapsuleApp: Add a function used to get
> next DevicePath
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
>
> Add a new function to support Capsule-on-Disk feature.
> This function is used to get next full DevicePath from a load option.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Include/Library/UefiBootManagerLib.h | 21
> +++-
> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 24
> ++-
> 2 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> index bfc0cb86f8..64347ff160 100644
> --- a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> +++ b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -1,7 +1,7 @@
> /** @file
>Provide Boot Manager related library APIs.
>
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
> (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -445,6 +445,25 @@ EfiBootManagerGetBootManagerMenu (
>EFI_BOOT_MANAGER_LOAD_OPTION *BootOption
>);
>
> +/**
> + Get the next possible full path pointing to the load option.
> + The routine doesn't guarantee the returned full path points to an existing
> + file, and it also doesn't guarantee the existing file is a valid load
> option.
> + BmGetNextLoadOptionBuffer() guarantees.
> +
> + @param FilePath The device path pointing to a load option.
> + It could be a short-form device path.
> + @param FullPath The full path returned by the routine in last call.
> + Set to NULL in first call.
> +
> + @return The next possible full path pointing to the load option.
> + Caller is responsible to free the memory.
> +**/
> +EFI_DEVICE_PATH_PROTOCOL *
> +EfiBootManagerGetNextFullDevicePath (
> + IN EFI_DEVICE_PATH_PROTOCOL *FilePath,
> + IN EFI_DEVICE_PATH_PROTOCOL *FullPath
> + );
>
> /**
>Get the load option by its device path.
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 6a23477eb8..684d7b8b1b 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1,7 +1,7 @@
> /** @file
>Library functions which relates with booting.
>
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
> (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -2461,3 +2461,25 @@ EfiBootManagerGetBootManagerMenu (
>}
> }
>
> +/**
> + Get the next possible full path pointing to the load option.
> + The routine doesn't guarantee the returned full path points to an existing
> + file, and it also doesn't guarantee the existing file is a valid load
> option.
> + BmGetNextLoadOptionBuffer() guarantees.
> +
> + @param FilePath The device path pointing to a load option.
> + It could be a short-form device path.
> + @param FullPath The full path returned by the routine in last call.
> + Set to NULL in first call.
> +
> + @return The next possible full path pointing to the load option.
> + Caller is responsible to free the memory.
> +**/
> +EFI_DEVICE_PATH_PROTOCOL *
> +EfiBootManagerGetNextFullDevicePath (
> + IN EFI_DEVICE_PATH_PROTOCOL *FilePath,
> + IN EFI_DEVICE_PATH_PROTOCOL *FullPath
> + )
> +{
> + return BmGetNextLoadOptionDevicePath(FilePath, FullPath);
> +}
> --
> 2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 3/4] MdeModulePkg/CapsuleApp: Add functions to support Capsule-on-Disk
Reviewed-by: Jian J Wang
> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, January 29, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Wang, Jian J
> ; Wu, Hao A ; Zhang, Chao B
>
> Subject: [PATCH v3 3/4] MdeModulePkg/CapsuleApp: Add functions to support
> Capsule-on-Disk
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
>
> This file provide some basic function to support Capsule-on-Disk.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> .../Application/CapsuleApp/CapsuleOnDisk.c | 806
> +
> 1 file changed, 806 insertions(+)
> create mode 100644 MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> new file mode 100644
> index 00..16ce9519b2
> --- /dev/null
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> @@ -0,0 +1,806 @@
> +/** @file
> + Process Capsule On Disk.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD
> License
> + which accompanies this distribution. The full text of the license may be
> found
> at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +EFI_GUID mCapsuleOnDiskBootOptionGuid = { 0x4CC29BB7, 0x2413, 0x40A2,
> { 0xB0, 0x6D, 0x25, 0x3E, 0x37, 0x10, 0xF5, 0x32 } };
> +
> +/**
> + Get shell protocol.
> +
> + @return Pointer to shell protocol.
> +
> +**/
> +EFI_SHELL_PROTOCOL *
> +GetShellProtocol (
> + VOID
> + );
> +
> +/**
> + Get file name from file path.
> +
> + @param FilePathFile path.
> +
> + @return Pointer to file name.
> +
> +**/
> +CHAR16 *
> +GetFileNameFromPath (
> + CHAR16*FilePath
> + )
> +{
> + EFI_STATUSStatus;
> + EFI_SHELL_PROTOCOL*ShellProtocol;
> + SHELL_FILE_HANDLE Handle;
> + EFI_FILE_INFO *FileInfo;
> +
> + ShellProtocol = GetShellProtocol ();
> + if (ShellProtocol == NULL) {
> +return NULL;
> + }
> +
> + //
> + // Open file by FileName.
> + //
> + Status = ShellProtocol->OpenFileByName (
> +FilePath,
> +&Handle,
> +EFI_FILE_MODE_READ
> +);
> + if (EFI_ERROR (Status)) {
> +return NULL;
> + }
> +
> + //
> + // Get file name from EFI_FILE_INFO.
> + //
> + FileInfo = ShellProtocol->GetFileInfo (Handle);
> + ShellProtocol->CloseFile (Handle);
> + if (FileInfo == NULL) {
> +return NULL;
> + }
> +
> + return FileInfo->FileName;
> +}
> +
> +/**
> + Check if the device path is EFI system Partition.
> +
> + @param DevicePathThe ESP device path.
> +
> + @retval TRUEDevicePath is a device path for ESP.
> + @retval FALSE DevicePath is not a device path for ESP.
> +
> +**/
> +BOOLEAN
> +IsEfiSysPartitionDevicePath (
> + EFI_DEVICE_PATH_PROTOCOL *DevicePath
> + )
> +{
> + EFI_STATUS Status;
> + EFI_DEVICE_PATH_PROTOCOL *TempDevicePath;
> + HARDDRIVE_DEVICE_PATH *Hd;
> + EFI_HANDLE Handle;
> +
> + //
> + // Check if the device path contains GPT node
> + //
> + TempDevicePath = DevicePath;
> +
> + while (!IsDevicePathEnd (TempDevicePath)) {
> +if ((DevicePathType (TempDevicePath) == MEDIA_DEVICE_PATH) &&
> + (DevicePathSubType (TempDevicePath) == MEDIA_HARDDRIVE_DP)) {
> + Hd = (HARDDRIVE_DEVICE_PATH *)TempDevicePath;
> + if (Hd->MBRType == MBR_TYPE_EFI_PARTITION_TABLE_HEADER) {
> +break;
> + }
> +}
> +TempDevicePath = NextDevicePathNode (TempDevicePath);
> + }
> +
> + if (!IsDevicePathEnd (TempDevicePath)) {
> +//
> +// Search for EFI system partition protocol on full device path in Boot
>
Re: [edk2] [PATCH 0/2] Add sanity check for FilePath device path
Miss the test info: - Boot shell - Boot to Fedora 26 (Qemu/x64) - Boot to Ubuntu 18.04 (Qemu/x64) - Boot to Windows 10 (Qemu/x64) - Boot to Windows 7 (Qemu/x64) Regards, Jian > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J > Wang > Sent: Tuesday, January 29, 2019 1:10 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH 0/2] Add sanity check for FilePath device path > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1497 > > Jian J Wang (2): > MdePkg/UefiDevicePathLib: Add sanity check for FilePath device path > MdePkg/UefiDevicePathLibDevicePathProtocol: Add sanity check for > FilePath device path > > MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c| 8 > .../UefiDevicePathLib.c | 8 > 2 files changed, 16 insertions(+) > > -- > 2.19.0.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] MdeModulePkg/SdMmcPciHcDxe: Update comment for spec compliance status
Just two typos (see below). With them addressed, Reviewed-by: Jian J Wang > -Original Message- > From: Wu, Hao A > Sent: Tuesday, January 29, 2019 11:14 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A ; Wang, Jian J ; > Ni, Ray > Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Update comment for spec > compliance status > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1441 > > This commit will update the file-level comments within the SdMmcPciHcDxe > to reflect the latest specification compliance status of the driver. > > Cc: Jian J Wang > Cc: Ray Ni > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Hao Wu > --- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 5 +++-- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 6 -- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 6 -- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.uni | 5 +++-- > 4 files changed, 14 insertions(+), 8 deletions(-) > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf > index 1246e1d88d..025fb7faba 100644 > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf > @@ -1,11 +1,12 @@ > ## @file > # SdMmcPciHcDxe driver is used to manage those host controllers which > comply with SD > -# Host Controller Simplified Specifiction version 3.0. > +# Host Controller Simplified Specifiction version 3.0 plus the 64-bit System Typo: Specifiction > Addressing > +# support in SD Host Controller Simplified Specification version 4.20. > # > # It will produce EFI_SD_MMC_PASS_THRU_PROTOCOL to allow sending > SD/MMC/eMMC cmds > # to specified devices from upper layer. > # > -# Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved. > +# Copyright (c) 2015 - 2019, 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 > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c > index 76c32a4dcd..b474f8decd 100644 > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c > @@ -1,11 +1,13 @@ > /** @file >This driver is used to manage SD/MMC PCI host controllers which are > compliance > - with SD Host Controller Simplified Specification version 3.00. > + with SD Host Controller Simplified Specification version 3.00 plus the > 64-bit > + System Addressing support in SD Host Controller Simplified Specification > version > + 4.20. > >It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use. > >Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved. > - Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved. > + Copyright (c) 2015 - 2019, 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 > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c > index 5aec8c6992..4c64da3b20 100644 > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c > @@ -1,11 +1,13 @@ > /** @file >This driver is used to manage SD/MMC PCI host controllers which are > compliance > - with SD Host Controller Simplified Specification version 3.00. > + with SD Host Controller Simplified Specification version 3.00 plus the > 64-bit > + System Addressing support in SD Host Controller Simplified Specification > version > + 4.20. > >It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use. > >Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved. > - Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved. > + Copyright (c) 2015 - 2019, 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 > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.uni > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.uni > index 57f9fa76a1..497d2cc9f0 100644 > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.uni > +++ b/MdeModulePkg/Bus/Pci/SdMmcPci
Re: [edk2] [PATCH v2 2/2] MdeModulePkg/CapsuleApp: Enhance CapsuleApp to support Capsule-on-Disk.
Hi Chen,
Here're some overall comments:
1. Update all copyright year to 2019
2. Split this patch to smaller granularity (in public standalone file unit or
module unit),
and keep in mind that the patch order also matters. This patch can be split
into 3
patches.
3. Provide test information you've done.
See my other comments below.
> -Original Message-
> From: Chen, Chen A
> Sent: Monday, January 28, 2019 9:21 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Wang, Jian J
> ; Wu, Hao A ; Zhang, Chao B
>
> Subject: [PATCH v2 2/2] MdeModulePkg/CapsuleApp: Enhance CapsuleApp to
> support Capsule-on-Disk.
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
>
> CapsuleApp is used for trigger capsule update.
> Add -OD option in CapsuleApp to support doing capsule update via storage.
> Add -F and -L options to support dumping information feature.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleApp.c | 153 +++-
> MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf | 8 +
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 535
> +-
> .../Application/CapsuleApp/CapsuleOnDisk.c | 802
> +
> MdeModulePkg/Include/Library/UefiBootManagerLib.h | 19 +
> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 22 +
> 6 files changed, 1524 insertions(+), 15 deletions(-)
> create mode 100644 MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> index 4d907242f3..ca9baa0a6a 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -105,6 +106,44 @@ DumpEsrtData (
>VOID
>);
>
> +/**
> + Dump Provisioned Capsule.
> +
> + @param[in] DumpCapsuleInfo The flag to indicate whether to dump the
> capsule inforomation.
> +**/
> +VOID
> +DumpProvisionedCapsule (
> + IN BOOLEAN DumpCapsuleInfo
> + );
> +
> +/**
> + Dump all EFI System Parition.
> +**/
> +VOID
> +DumpAllEfiSysPartition (
> + VOID
> + );
> +
> +/**
> + Process Capsule On Disk.
> +
> + @param[in] CapsuleBufferAn array of pointer to capsule images
> + @param[in] FileSize An array of UINTN to capsule images size
> + @param[in] OrgFileName An array of orginal capsule images name
> + @param[in] NewFileName An array of new capsule images name
> + @param[in] CapsuleNum The count of capsule images
> +
> + @retval EFI_SUCCESS Capsule on disk secceed.
> +**/
> +EFI_STATUS
> +ProcessCapsuleOnDisk (
> + IN VOID **CapsuleBuffer,
> + IN UINTN *CapsuleBufferSize,
> + IN CHAR16**FilePath,
> + IN CHAR16*Map,
> + IN UINTN CapsuleNum
> + );
> +
> /**
>Read a file.
>
> @@ -799,19 +838,22 @@ PrintUsage (
>)
> {
>Print(L"CapsuleApp: usage\n");
> - Print(L" CapsuleApp [-NR]\n");
> + Print(L" CapsuleApp [-NR] [-OD [FSx]]\n");
>Print(L" CapsuleApp -S\n");
>Print(L" CapsuleApp -C\n");
>Print(L" CapsuleApp -P\n");
>Print(L" CapsuleApp -E\n");
> + Print(L" CapsuleApp -L\n");
> + Print(L" CapsuleApp -L INFO\n");
> + Print(L" CapsuleApp -F\n");
>Print(L" CapsuleApp -G -O \n");
>Print(L" CapsuleApp -N -O \n");
>Print(L" CapsuleApp -D \n");
>Print(L" CapsuleApp -P GET -O \n");
>Print(L"Parameter:\n");
> - Print(L" -NR: No reset will be triggered for the capsule with\n");
> - Print(L" CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without\n");
> - Print(L" CAPSULE_FLAGS_INITIATE_RESET.\n");
> + Print(L" -NR: No reset will be triggered for the capsule\n");
> + Print(L" with CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without
> CAPSULE_FLAGS_INITIATE_RESET.\n");
> + Print(L" -OD: Delivery of Capsules via file on Mass Storage device.");
>Print(L" -S: Dump capsule report variable (EFI_CAPSULE_REPORT_GUID),\n");
>Print(L" which is defined in UEFI specification.\n");
>Print(L" -C
Re: [edk2] [PATCH v2 2/2] MdeModulePkg/CapsuleApp: Enhance CapsuleApp to support Capsule-on-Disk.
Chen,
Did you just sent this patch for v2? If yes, I think you should send all
patches in series even the one with title [PATCH 0/2]. It'd be better to add
change description since last version.
Regards,
Jian
> -Original Message-
> From: Chen, Chen A
> Sent: Monday, January 28, 2019 9:21 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Wang, Jian J
> ; Wu, Hao A ; Zhang, Chao B
>
> Subject: [PATCH v2 2/2] MdeModulePkg/CapsuleApp: Enhance CapsuleApp to
> support Capsule-on-Disk.
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
>
> CapsuleApp is used for trigger capsule update.
> Add -OD option in CapsuleApp to support doing capsule update via storage.
> Add -F and -L options to support dumping information feature.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleApp.c | 153 +++-
> MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf | 8 +
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 535
> +-
> .../Application/CapsuleApp/CapsuleOnDisk.c | 802
> +
> MdeModulePkg/Include/Library/UefiBootManagerLib.h | 19 +
> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 22 +
> 6 files changed, 1524 insertions(+), 15 deletions(-)
> create mode 100644 MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> index 4d907242f3..ca9baa0a6a 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -105,6 +106,44 @@ DumpEsrtData (
>VOID
>);
>
> +/**
> + Dump Provisioned Capsule.
> +
> + @param[in] DumpCapsuleInfo The flag to indicate whether to dump the
> capsule inforomation.
> +**/
> +VOID
> +DumpProvisionedCapsule (
> + IN BOOLEAN DumpCapsuleInfo
> + );
> +
> +/**
> + Dump all EFI System Parition.
> +**/
> +VOID
> +DumpAllEfiSysPartition (
> + VOID
> + );
> +
> +/**
> + Process Capsule On Disk.
> +
> + @param[in] CapsuleBufferAn array of pointer to capsule images
> + @param[in] FileSize An array of UINTN to capsule images size
> + @param[in] OrgFileName An array of orginal capsule images name
> + @param[in] NewFileName An array of new capsule images name
> + @param[in] CapsuleNum The count of capsule images
> +
> + @retval EFI_SUCCESS Capsule on disk secceed.
> +**/
> +EFI_STATUS
> +ProcessCapsuleOnDisk (
> + IN VOID **CapsuleBuffer,
> + IN UINTN *CapsuleBufferSize,
> + IN CHAR16**FilePath,
> + IN CHAR16*Map,
> + IN UINTN CapsuleNum
> + );
> +
> /**
>Read a file.
>
> @@ -799,19 +838,22 @@ PrintUsage (
>)
> {
>Print(L"CapsuleApp: usage\n");
> - Print(L" CapsuleApp [-NR]\n");
> + Print(L" CapsuleApp [-NR] [-OD [FSx]]\n");
>Print(L" CapsuleApp -S\n");
>Print(L" CapsuleApp -C\n");
>Print(L" CapsuleApp -P\n");
>Print(L" CapsuleApp -E\n");
> + Print(L" CapsuleApp -L\n");
> + Print(L" CapsuleApp -L INFO\n");
> + Print(L" CapsuleApp -F\n");
>Print(L" CapsuleApp -G -O \n");
>Print(L" CapsuleApp -N -O \n");
>Print(L" CapsuleApp -D \n");
>Print(L" CapsuleApp -P GET -O \n");
>Print(L"Parameter:\n");
> - Print(L" -NR: No reset will be triggered for the capsule with\n");
> - Print(L" CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without\n");
> - Print(L" CAPSULE_FLAGS_INITIATE_RESET.\n");
> + Print(L" -NR: No reset will be triggered for the capsule\n");
> + Print(L" with CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without
> CAPSULE_FLAGS_INITIATE_RESET.\n");
> + Print(L" -OD: Delivery of Capsules via file on Mass Storage device.");
>Print(L" -S: Dump capsule report variable (EFI_CAPSULE_REPORT_GUID),\n");
>Print(L" which is defined in UEFI specification.\n");
>Print(L" -C: Clear capsule report variable
> (EFI_CAPSULE_REPORT_GUID),\n");
> @@ -820,6 +862,8 @@ PrintUsage (
>Print
Re: [edk2] [Patch] MdeModulePkg DxeCapsuleLibFmp: Update SupportCapsuleImage() for Fake Capsule
Reviewed-by: Jian J Wang
> -Original Message-
> From: Gao, Liming
> Sent: Monday, January 14, 2019 10:31 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J
> Subject: [Patch] MdeModulePkg DxeCapsuleLibFmp: Update
> SupportCapsuleImage() for Fake Capsule
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1088
> Per UEFI spec, the fake capsule image with the header only is a valid case
> in QueryCapsuleCpapbilities(). So, SupportCapsuleImage() is updated to
> support this case.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao
> Cc: Star Zeng
> Cc: Jian J Wang
> ---
> MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> index fa557b61ae..f56809bb70 100644
> --- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> +++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
> @@ -1422,6 +1422,12 @@ SupportCapsuleImage (
>
>if (IsFmpCapsule(CapsuleHeader)) {
> //
> +// Fake capsule header is valid case in QueryCapsuleCpapbilities().
> +//
> +if (CapsuleHeader->HeaderSize == CapsuleHeader->CapsuleImageSize) {
> + return EFI_SUCCESS;
> +}
> +//
> // Check layout of FMP capsule
> //
> return ValidateFmpCapsule(CapsuleHeader, NULL);
> --
> 2.13.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg VariableStandaloneMm: Add PcdEmuVariableNvModeEnable in inf
Reviewed-by: Jian J Wang > -Original Message- > From: Zeng, Star > Sent: Friday, January 25, 2019 9:23 AM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Wang, Jian J ; > Wu, Hao A ; Ard Biesheuvel ; > Bi, Dandan > Subject: [PATCH] MdeModulePkg VariableStandaloneMm: Add > PcdEmuVariableNvModeEnable in inf > > It was missed in 7cd69959463ac9c761163ed8e8a93907b68e70da when rebasing > the patches after 688b2cad7b712493f2cf8b6948ab795545e13961 added > VariableStandaloneMm. > > Cc: Jian J Wang > Cc: Hao Wu > Cc: Ard Biesheuvel > Cc: Dandan Bi > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf | 4 > +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > index efb84ed87832..07436d3cb6ae 100644 > --- > a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > +++ > b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf > @@ -18,7 +18,7 @@ > # may not be modified without authorization. If platform fails to protect > these > resources, > # the authentication service provided in this driver will be broken, and the > behavior is undefined. > # > -# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved. > +# Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved. > # Copyright (c) 2018, Linaro, Ltd. All rights reserved. > # This program and the accompanying materials > # are licensed and made available under the terms and conditions of the BSD > License > @@ -127,6 +127,8 @@ [FixedPcd] >gEfiMdeModulePkgTokenSpaceGuid.PcdMaxUserNvVariableSpaceSize ## > CONSUMES > > gEfiMdeModulePkgTokenSpaceGuid.PcdBoottimeReservedNvVariableSpaceSize > ## CONSUMES >gEfiMdeModulePkgTokenSpaceGuid.PcdReclaimVariableSpaceAtEndOfDxe ## > CONSUMES > + gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable ## > SOMETIMES_CONSUMES > + gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved ## > SOMETIMES_CONSUMES > > [FeaturePcd] >gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics## > CONSUMES # statistic the information of variable. > -- > 2.13.3.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 12/12] MdeModule: Remove EmuVariableRuntimeDxe
Reviewed-by: Jian J Wang > -Original Message- > From: Zeng, Star > Sent: Sunday, January 13, 2019 11:38 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Wang, Jian J ; > Wu, Hao A > Subject: [PATCH 12/12] MdeModule: Remove EmuVariableRuntimeDxe > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > Merge EmuVariable and Real variable driver. > > The real variable driver has been updated to support emulated > variable NV mode. > This patch removes EmuVariableRuntimeDxe after platforms are > migrated to use the merged variable driver. > > Cc: Jian J Wang > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > MdeModulePkg/MdeModulePkg.dsc |5 +- > .../Universal/Variable/EmuRuntimeDxe/EmuVariable.c | 1820 > > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.inf| 88 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.uni| 22 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxeExtra.uni | 19 - > .../Variable/EmuRuntimeDxe/InitVariable.c | 259 --- > .../Universal/Variable/EmuRuntimeDxe/Variable.h| 277 --- > 7 files changed, 1 insertion(+), 2489 deletions(-) > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.i > nf > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.u > ni > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxeE > xtra.uni > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/InitVariable.c > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/Variable.h > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > b/MdeModulePkg/MdeModulePkg.dsc > index 5d042be3a862..3186f35a1a48 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -2,7 +2,7 @@ > # EFI/PI Reference Module Package for All Architectures > # > # (C) Copyright 2014 Hewlett-Packard Development Company, L.P. > -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > +# Copyright (c) 2007 - 2019, 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 > @@ -433,9 +433,6 @@ [Components.IA32, Components.X64, > Components.ARM, Components.AARCH64] > > NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32Guid > edSectionExtractLib.inf >} > > -[Components.IA32, Components.X64, Components.Ebc] > - > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.i > nf > - > [Components.IA32, Components.X64] >MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo.inf >MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf > diff --git a/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > b/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > deleted file mode 100644 > index 1bcf931b96a6.. > --- a/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > +++ /dev/null > @@ -1,1820 +0,0 @@ > -/** @file > - > - Emulation Variable services operate on the runtime volatile memory. > - The nonvolatile variable space doesn't exist. > - > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. > -This program and the accompanying materials > -are licensed and made available under the terms and conditions of the BSD > License > -which accompanies this distribution. The full text of the license may be > found > at > -http://opensource.org/licenses/bsd-license.php > - > -THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > -WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS > OR IMPLIED. > - > -**/ > - > -#include "Variable.h" > - > -/// > -/// Don't use module globals after the SetVirtualAddress map is signaled > -/// > -ESAL_VARIABLE_GLOBAL *mVariableModuleGlobal; > - > -VARIABLE_INFO_ENTRY *gVariableInfo = NULL; > - > -/// > -/// The size of a 3 character ISO639 language code. > -/// > -#define ISO_639_2_ENTRY_SIZE3 > - > -/** > - Update the variable region with Variable information. These are the same > - arguments as the EFI Variable services. > - > - @param[in] VariableName Name of variable > - > - @param[in] VendorGuid Guid of variable > - > - @param[in] Data Variable data > - > - @param[in] DataSize Size of data. 0 means dele
Re: [edk2] [PATCH 3/4] MdeModulePkg/VarCheckLib: permit use by MM_STANDALONE modules
Reviewed-by: Jian J Wang
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, January 17, 2019 5:22 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael D
> ; Gao, Liming ; Ye, Ting
> ; Wei, Gang ; Wang, Jian J
> ; Zhang, Chao B ; Yao,
> Jiewen ; Wu, Hao A ; Zeng, Star
> ; Achin Gupta ; Jagadeesh Ujja
>
> Subject: [PATCH 3/4] MdeModulePkg/VarCheckLib: permit use by
> MM_STANDALONE modules
>
> Permit VarCheckLib and VarCheckUefiLib to be used by MM_STANDALONE
> modules.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf| 4 ++--
> MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c | 9
> +
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> index 128c44d695e1..8873fd51a02a 100644
> --- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> +++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> @@ -19,9 +19,9 @@ [Defines]
>BASE_NAME = VarCheckUefiLib
>MODULE_UNI_FILE= VarCheckUefiLib.uni
>FILE_GUID = AC24A4C7-F845-4665-90E5-6431D6E28DC0
> - MODULE_TYPE= DXE_RUNTIME_DRIVER
> + MODULE_TYPE= BASE
>VERSION_STRING = 1.0
> - LIBRARY_CLASS = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER
> + LIBRARY_CLASS = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER
> MM_STANDALONE
>CONSTRUCTOR= VarCheckUefiLibNullClassConstructor
>
> #
> diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
> b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
> index 80dc6341adcf..5e419831e8cc 100644
> --- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
> +++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
> @@ -12,6 +12,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> **/
>
> +#include
> +
> #include
> #include
> #include
> @@ -927,15 +929,14 @@ VariablePropertySetUefiDefined (
>@retval EFI_SUCCESS The constructor executed correctly.
>
> **/
> -EFI_STATUS
> +RETURN_STATUS
> EFIAPI
> VarCheckUefiLibNullClassConstructor (
> - IN EFI_HANDLE ImageHandle,
> - IN EFI_SYSTEM_TABLE *SystemTable
> + VOID
>)
> {
>VariablePropertySetUefiDefined ();
>VarCheckLibRegisterSetVariableCheckHandler
> (SetVariableCheckHandlerUefiDefined);
>
> - return EFI_SUCCESS;
> + return RETURN_SUCCESS;
> }
> --
> 2.17.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/4] CryptoPkg/SmmCryptLib: permit use by MM_STANDALONE modules
Reviewed-by: Jian J Wang > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Thursday, January 17, 2019 5:22 AM > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel ; Kinney, Michael D > ; Gao, Liming ; Ye, Ting > ; Wei, Gang ; Wang, Jian J > ; Zhang, Chao B ; Yao, > Jiewen ; Wu, Hao A ; Zeng, Star > ; Achin Gupta ; Jagadeesh Ujja > > Subject: [PATCH 1/4] CryptoPkg/SmmCryptLib: permit use by MM_STANDALONE > modules > > Permit SmmCryptLib to be used by MM_STANDALONE modules > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > index c34699cd62bf..a681fe2f36b8 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > @@ -30,7 +30,7 @@ [Defines] >MODULE_TYPE= DXE_SMM_DRIVER >VERSION_STRING = 1.0 >PI_SPECIFICATION_VERSION = 0x0001000A > - LIBRARY_CLASS = BaseCryptLib|DXE_SMM_DRIVER SMM_CORE > + LIBRARY_CLASS = BaseCryptLib|DXE_SMM_DRIVER SMM_CORE > MM_STANDALONE > > # > # The following information is for reference only and not required by the > build > tools. > -- > 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/4] SecurityPkg/PlatformSecureLibNull: permit use by MM_STANDALONE modules
Reviewed-by: Jian J Wang
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, January 17, 2019 5:22 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael D
> ; Gao, Liming ; Ye, Ting
> ; Wei, Gang ; Wang, Jian J
> ; Zhang, Chao B ; Yao,
> Jiewen ; Wu, Hao A ; Zeng, Star
> ; Achin Gupta ; Jagadeesh Ujja
>
> Subject: [PATCH 2/4] SecurityPkg/PlatformSecureLibNull: permit use by
> MM_STANDALONE modules
>
> Add MM_STANDALONE to the list of module types that are permitted to
> link to this library. Also, since the constructor prototype is
> different between MM_STANDALONE and DXE_DRIVER type libraries,
> convert the library into BASE type.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c | 9
> +-
> ---
> SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf | 4 ++--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> index 0c6ded22f3e6..b2493a029393 100644
> --- a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> +++ b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> @@ -15,6 +15,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> **/
>
> +#include
> +
> BOOLEAN mUserPhysicalPresence = FALSE;
>
> /**
> @@ -53,15 +55,14 @@ UserPhysicalPresent (
>@retval EFI_SUCCESS PcdUserPhysicalPresence is got successfully.
>
> **/
> -EFI_STATUS
> +RETURN_STATUS
> EFIAPI
> PlatformSecureLibNullConstructor (
> - IN EFI_HANDLEImageHandle,
> - IN EFI_SYSTEM_TABLE *SystemTable
> + VOID
>)
> {
>
>mUserPhysicalPresence = PcdGetBool(PcdUserPhysicalPresence);
>
> - return EFI_SUCCESS;
> + return RETURN_SUCCESS;
> }
> diff --git
> a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> index 979a33705de0..70051a27a0a9 100644
> --- a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> +++ b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> @@ -21,9 +21,9 @@ [Defines]
>BASE_NAME = PlatformSecureLibNull
>MODULE_UNI_FILE= PlatformSecureLibNull.uni
>FILE_GUID = 7FA68D82-10A4-4e71-9524-D3D9500D3CDF
> - MODULE_TYPE= DXE_DRIVER
> + MODULE_TYPE= BASE
>VERSION_STRING = 1.0
> - LIBRARY_CLASS = PlatformSecureLib|DXE_RUNTIME_DRIVER
> DXE_SMM_DRIVER DXE_DRIVER
> + LIBRARY_CLASS = PlatformSecureLib|DXE_RUNTIME_DRIVER
> DXE_SMM_DRIVER DXE_DRIVER MM_STANDALONE
>CONSTRUCTOR= PlatformSecureLibNullConstructor
>
> #
> --
> 2.17.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 00/17] Merge EmuVariable and Real variable driver
For patch 1-12,17 Reviewed-by: Jian J Wang > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star > Zeng > Sent: Tuesday, January 15, 2019 6:29 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: [edk2] [PATCH V3 00/17] Merge EmuVariable and Real variable driver > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > > Purpose: > 1. Add emulated variable NV mode support in >MdeModulePkg\Universal\Variable\RuntimeDxe. >Platform can configure PCD statically (build time) or >dynamically (boot time) to support emulated variable NV mode. > 2. Remove MdeModulePkg\Universal\Variable\EmuRuntimeDxe whose >most codes are duplicated. > > > V3: > Addressed all the great feedbacks from Jian, Hao, Laszlo and Leif, thanks. > Pick up RB and AB tags. > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode_V3 > > Patches 1~9: Preparation > Patch 3 and 9 are new added based on feedbacks. > Patch 10~11: Real work > Patch 12~17: Migration for platforms and cleanup > > > V2: Addressed all the feedbacks from Laszlo, thanks. > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode_V2 > > Patches 1~7: Preparation > Patch 6 and 7 are new separated. > Patch 8~9: Real work > Patch 10~15: Migration for platforms and cleanup > Patch 11 is new added to let ArmVirtXen be aligned with ArmVirtQemuXXX. > > > V1: > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode > > Patches 1~5: Preparation > Patch 6~7: Real work > Patch 8~12: Migration for platforms and cleanup > > Test done: > Build code with VS2012, VS2015 and GCC49. > Regression: Boot Nt32, Ovmf (including 32, 3264 and 64 with no SMM) to UEFI > SHELL. > Boot some internal platform to UEFI SHELL and Windows. > Functionality: Boot Nt32, Ovmf (including 32, 3264 and 64 with no SMM) to UEFI > SHELL >with PcdEmuVariableNvModeEnable == TRUE. > > More test will be welcome and appreciated. :) > > Patches to update edk2-platforms Repo will be sent out separately. > > Star Zeng (17): > MdeModulePkg Variable: Add some missing changes for 9b18845 > MdeModulePkg Variable: Abstract InitRealNonVolatileVariableStore > MdeModulePkg Variable: Move "extern XXX" to Variable.h > MdeModulePkg Variable: Not get NV PCD in > VariableWriteServiceInitialize > MdeModulePkg Variable: Abstract VariableWriteServiceInitializeDxe/Smm > MdeModulePkg Variable: Remove CacheOffset in UpdateVariable() > MdeModulePkg Variable: type case VolatileBase to UINTN directly > MdeModulePkg: Add PcdEmuVariableNvModeEnable in dec > MdeModulePkg: Refine description a little for > PcdEmuVariableNvStoreReserved > MdeModulePkg Variable: Add emulated variable NV mode support > MdeModulePkg VariablePei: Don't check BOOT_IN_RECOVERY_MODE > ArmVirtXen: Use merged variable driver for emulated NV mode > ArmVirtXen: Link VarCheckUefiLib NULL class library instance > BeagleBoardPkg: Use merged variable driver for emulated NV mode > QuarkMin: Use merged variable driver for emulated NV mode > CorebootPayloadPkg: Use merged variable driver for emulated NV mode > MdeModulePkg: Remove EmuVariableRuntimeDxe > > ArmVirtPkg/ArmVirtXen.dsc | 12 +- > ArmVirtPkg/ArmVirtXen.fdf |4 +- > BeagleBoardPkg/BeagleBoardPkg.dsc | 14 +- > BeagleBoardPkg/BeagleBoardPkg.fdf |4 +- > CorebootPayloadPkg/CorebootPayloadPkg.fdf |4 +- > CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc | 11 +- > CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 11 +- > MdeModulePkg/MdeModulePkg.dec | 16 +- > MdeModulePkg/MdeModulePkg.dsc |5 +- > MdeModulePkg/MdeModulePkg.uni | 14 +- > .../Universal/Variable/EmuRuntimeDxe/EmuVariable.c | 1820 > > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.inf| 88 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.uni| 22 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxeExtra.uni | 19 - > .../Variable/EmuRuntimeDxe/InitVariable.c | 259 --- > .../Universal/Variable/EmuRuntimeDxe/Variable.h| 277 --- > MdeModulePkg/Universal/Variable/Pei/Variable.c |8 +- > .../Universal/Variable/Pei/VariablePei.inf |3 +- > .../Universal/Variable/RuntimeDxe/Variable.c | 431 +++-- > .../Universal/Variable/RuntimeDxe/Variable.h | 19 +- > .../Universal/Variable/RuntimeDxe/VariableDxe.c| 103 +- > .../Variable/RuntimeDxe/VariableRuntimeDxe.inf |4 +- > .../Universal/Variable/RuntimeDxe/VariableSmm.c| 90 +- > .../Universal/Variable/RuntimeDxe/VariableSmm.inf |4 +- > QuarkPlatformPkg/QuarkMin.dsc |8 +- > QuarkPlatformPkg/QuarkMin.fdf |4 +- > 26 files changed, 51
Re: [edk2] [PATCH v2 00/17] implement standalone MM versions of the variable runtime drivers
Ard, For patch 1,5,6,7,8,12,13,14,15,16,17 Reviewed-by: Jian J Wang > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, January 14, 2019 9:28 PM > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel ; Laszlo Ersek > ; Leif Lindholm ; Kinney, > Michael D ; Gao, Liming ; > Wang, Jian J ; Wu, Hao A ; > Jagadeesh Ujja ; Achin Gupta > ; Thomas Panakamattam Abraham > ; Sami Mujawar ; > Zeng, Star > Subject: [PATCH v2 00/17] implement standalone MM versions of the variable > runtime drivers > > This v2 series is a followup to [0], and updates the SMM implementations of > the fault tolerant write and variable runtime drivers to provide standalone > MM versions that share as much of the existing code as possible with the > traditional SMM implementations. > > The meat is in patches #5 - #8, which were part of v1. I updated them > according > to the received feedback, and added tags that were given on list. > > Patches #1 - #4 add library class resolutions for MmServiceTableLib, which was > introduced in v1 of the series, and has already been merged (at the request of > Liming) so that downstream platforms can add the resolution as well. > > The remaining patches #9 - #17 are new, and have been added so that the new > standalone MM drivers can be added to and built from MdeModulePkg.dsc, but > for coverage only (the resulting binaries won't actually work) > - patches #9 and #10 add a definition and implementation of > StandaloneMmDriverEntryPoint, which is rather straight-forward and has no > dependencies on the standalone MM core, so it is reasonable to add it to > MdePkg directly. Note that this version contains the _gMmVersion check that > is missing from the one in StandaloneMmPkg > - patch #11 adds a standalone MM implementation of MmServicesTableLib to > MdePkg, > which -again- does not depend on the standalone MM core at all, so added > here > for simplicity > - patches #12 and #13 add NULL implementations of MemoryAllocationLib and > HobLib > so that the FTW and variable MM_STANDALONE modules can be built without > depending on StandaloneMmPkg > - patch #14 is an unrelated fix so that MdeModulePkg.dsc can be built for > AARCH64 > - patches #15 and #16 add MM_STANDALONE support to a couple of libraries > that > the new modules depend on > - patch #17 adds the FTW and variable standalone MM drivers to > MdeModulePkg.dsc > > NOTE: the drivers added in patches #10 and #11 supersede the ones that reside > in > or have been proposed for StandaloneMmPkg > > Patches can be found here: > https://github.com/ardbiesheuvel/edk2/tree/variable-ftw-standalone-mm- > conversion > > Cc: Laszlo Ersek > Cc: Leif Lindholm > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Jian J Wang > Cc: Hao Wu > Cc: Jagadeesh Ujja > Cc: Achin Gupta > Cc: Thomas Panakamattam Abraham > Cc: Sami Mujawar > Cc: Star Zeng > > [0] https://lists.01.org/pipermail/edk2-devel/2019-January/034608.html > > Ard Biesheuvel (17): > MdeModulePkg/MdeModulePkg.dsc: add MmServicesTableLib resolution > OvmfPkg: add MmServicesTableLib resolution > QuarkPlatformPkg: add MmServicesTableLib resolution > Vlv2TbltDevicePkg: add MmServicesTableLib resolution > MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses > MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version > MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses > MdeModulePkg/VariableRuntimeDxe: implement standalone MM version > MdePkg: introduce standalone MM entry point library class > MdePkg: introduce standalone MM entry point library implementation > MdePkg: add MM_STANDALONE implementation of MmServicesTableLib > MdeModulePkg: implement NULL instance of HobLib library class > MdeModulePkg: implement NULL instance of MemoryAllocationLib library > class > MdeModulePkg/MdeModulePkg/dsc: move DxeDebugSupportDxe to x86 only > section > MdeModulePkg/AuthVariableLibNull: add MM_STANDALONE support > MdeModulePkg/VarCheckLib: add MM_STANDALONE support > MdeModulePkg/MdeModulePkg.dsc: add MM_STANDALONE FTW and variable > modules > > MdePkg/MdePkg.dec > | 3 + > MdeModulePkg/MdeModulePkg.dsc > | 12 +- > MdePkg/MdePkg.dsc > | 3 + > OvmfPkg/OvmfPkgIa32.dsc > | 1 > + > OvmfPkg/OvmfPkgIa32X64.dsc >
Re: [edk2] [PATCH V2 07/15] MdeModulePkg Variable: type case VolatileBase to UINTN directly
Reviewed-by: Jian J Wang
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A ; Laszlo Ersek
> Subject: [PATCH V2 07/15] MdeModulePkg Variable: type case VolatileBase to
> UINTN directly
>
> Simplify
> ((UINTN) ((UINT8 *) VolatileBase + VolatileBase->Size))
> to
> ((UINTN) VolatileBase + VolatileBase->Size)
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 4d524db30fec..4c8e1d8cf4f1 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -301,7 +301,7 @@ UpdateVariableStore (
>DataPtr += mVariableModuleGlobal->VariableGlobal.VolatileVariableBase;
> }
>
> -if ((DataPtr + DataSize) > ((UINTN) ((UINT8 *) VolatileBase +
> VolatileBase-
> >Size))) {
> +if ((DataPtr + DataSize) > ((UINTN) VolatileBase + VolatileBase->Size)) {
>return EFI_OUT_OF_RESOURCES;
> }
>
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2 06/15] MdeModulePkg Variable: Remove CacheOffset in UpdateVariable()
Star,
Just a tiny comment below. With it's addressed,
Reviewed-by: Jian J Wang
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A ; Laszlo Ersek
> Subject: [PATCH V2 06/15] MdeModulePkg Variable: Remove CacheOffset in
> UpdateVariable()
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> CacheOffset could be removed in UpdateVariable() after
> //
> // update the memory copy of Flash region.
> //
> CopyMem (
> (UINT8 *)mNvVariableCache + CacheOffset,
> (UINT8 *)NextVariable, VarSize
>);
>
> is moved to be before mVariableModuleGlobal->NonVolatileLastVariableOffset
> value is updated, like right before
>
> mVariableModuleGlobal->NonVolatileLastVariableOffset +=
> HEADER_ALIGN (VarSize);
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 424f92a53757..4d524db30fec 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -2139,7 +2139,6 @@ UpdateVariable (
>VARIABLE_POINTER_TRACK *Variable;
>VARIABLE_POINTER_TRACK NvVariable;
>VARIABLE_STORE_HEADER *VariableStoreHeader;
> - UINTN CacheOffset;
>UINT8 *BufferForMerge;
>UINTN MergedBufSize;
>BOOLEAN DataReady;
> @@ -2577,7 +2576,6 @@ UpdateVariable (
> //
> // Step 1:
> //
> -CacheOffset = mVariableModuleGlobal->NonVolatileLastVariableOffset;
> Status = UpdateVariableStore (
> &mVariableModuleGlobal->VariableGlobal,
> FALSE,
> @@ -2643,6 +2641,11 @@ UpdateVariable (
>goto Done;
> }
>
> +//
> +// update the memory copy of Flash region.
> +//
The first character of comment is not capitalized.
> +CopyMem ((UINT8 *)mNvVariableCache + mVariableModuleGlobal-
> >NonVolatileLastVariableOffset, (UINT8 *)NextVariable, VarSize);
> +
> mVariableModuleGlobal->NonVolatileLastVariableOffset += HEADER_ALIGN
> (VarSize);
>
> if ((Attributes & EFI_VARIABLE_HARDWARE_ERROR_RECORD) != 0) {
> @@ -2653,10 +2656,6 @@ UpdateVariable (
> mVariableModuleGlobal->CommonUserVariableTotalSize +=
> HEADER_ALIGN (VarSize);
>}
> }
> -//
> -// update the memory copy of Flash region.
> -//
> -CopyMem ((UINT8 *)mNvVariableCache + CacheOffset, (UINT8
> *)NextVariable, VarSize);
>} else {
> //
> // Create a volatile variable.
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2 04/15] MdeModulePkg Variable: Abstract VariableWriteServiceInitializeDxe/Smm
Reviewed-by: Jian J Wang
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A
> Subject: [PATCH V2 04/15] MdeModulePkg Variable: Abstract
> VariableWriteServiceInitializeDxe/Smm
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Abstract VariableWriteServiceInitializeDxe/Smm from
> FtwNotificationEvent/SmmFtwNotificationEvent, then
> VariableWriteServiceInitializeDxe/Smm could be not aware
> the NV storage is real or emulated.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/Variable/RuntimeDxe/VariableDxe.c| 55 ++---
> -
> .../Universal/Variable/RuntimeDxe/VariableSmm.c| 43 -
> 2 files changed, 66 insertions(+), 32 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> index baba6729c1c2..5131e6f351e4 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> @@ -346,6 +346,40 @@ OnEndOfDxe (
> }
>
> /**
> + Initializes variable write service for DXE.
> +
> +**/
> +VOID
> +VariableWriteServiceInitializeDxe (
> + VOID
> + )
> +{
> + EFI_STATUSStatus;
> +
> + Status = VariableWriteServiceInitialize ();
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "Variable write service initialization failed.
> Status
> = %r\n", Status));
> + }
> +
> + //
> + // Some Secure Boot Policy Var (SecureBoot, etc) updates following other
> + // Secure Boot Policy Variable change. Record their initial value.
> + //
> + RecordSecureBootPolicyVarData();
> +
> + //
> + // Install the Variable Write Architectural protocol.
> + //
> + Status = gBS->InstallProtocolInterface (
> + &mHandle,
> + &gEfiVariableWriteArchProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> + ASSERT_EFI_ERROR (Status);
> +}
> +
> +/**
>Fault Tolerant Write protocol notification event handler.
>
>Non-Volatile variable write may needs FTW protocol to reclaim when
> @@ -428,27 +462,10 @@ FtwNotificationEvent (
> }
>}
>
> - Status = VariableWriteServiceInitialize ();
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "Variable write service initialization failed.
> Status
> = %r\n", Status));
> - }
> -
>//
> - // Some Secure Boot Policy Var (SecureBoot, etc) updates following other
> - // Secure Boot Policy Variable change. Record their initial value.
> + // Initializes variable write service after FTW was ready.
>//
> - RecordSecureBootPolicyVarData();
> -
> - //
> - // Install the Variable Write Architectural protocol.
> - //
> - Status = gBS->InstallProtocolInterface (
> - &mHandle,
> - &gEfiVariableWriteArchProtocolGuid,
> - EFI_NATIVE_INTERFACE,
> - NULL
> - );
> - ASSERT_EFI_ERROR (Status);
> + VariableWriteServiceInitializeDxe ();
>
>//
>// Close the notify event to avoid install
> gEfiVariableWriteArchProtocolGuid
> again.
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> index 018587ed7373..e63af812534e 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> @@ -846,6 +846,34 @@ SmmEndOfDxeCallback (
> }
>
> /**
> + Initializes variable write service for SMM.
> +
> +**/
> +VOID
> +VariableWriteServiceInitializeSmm (
> + VOID
> + )
> +{
> + EFI_STATUSStatus;
> +
> + Status = VariableWriteServiceInitialize ();
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "Variable write service initialization failed.
> Status
> = %r\n", Status));
> + }
> +
> + //
> + // Notify the variable wrapper driver the variable write service is ready
> + //
> + Status = gBS->InstallProtocolInterface (
> + &mSmmVariableHandle,
> + &gSmmVariableWriteGuid,
> + EFI_NATIVE_INTERFACE,
> + NU
Re: [edk2] [PATCH V2 03/15] MdeModulePkg Variable: Not get NV PCD in VariableWriteServiceInitialize
Hi Star,
One comment below.
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A
> Subject: [PATCH V2 03/15] MdeModulePkg Variable: Not get NV PCD in
> VariableWriteServiceInitialize
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Add macro NV_STORAGE_VARIABLE_BASE.
> Not get NV PCD in VariableWriteServiceInitialize, but in
> FtwNotificationEvent/SmmFtwNotificationEvent, then
> VariableWriteServiceInitialize could be not aware the NV
> storage is real or emulated.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/Variable/RuntimeDxe/Variable.c | 20
> ++--
> .../Universal/Variable/RuntimeDxe/Variable.h | 9 +++--
> .../Universal/Variable/RuntimeDxe/VariableDxe.c | 12
> .../Universal/Variable/RuntimeDxe/VariableSmm.c | 16 +++-
> 4 files changed, 28 insertions(+), 29 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 0b675c8f36df..424f92a53757 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -3770,10 +3770,7 @@ InitRealNonVolatileVariableStore (
> return EFI_OUT_OF_RESOURCES;
>}
>
> - NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet64
> (PcdFlashNvStorageVariableBase64);
> - if (NvStorageBase == 0) {
> -NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
> - }
> + NvStorageBase = NV_STORAGE_VARIABLE_BASE;
>ASSERT (NvStorageBase != 0);
>
>//
> @@ -4027,7 +4024,7 @@ FlushHobVariableToFlash (
> }
>
> /**
> - Initializes variable write service after FTW was ready.
> + Initializes variable write service.
>
>@retval EFI_SUCCESS Function successfully executed.
>@retval Others Fail to initialize the variable service.
> @@ -4041,23 +4038,10 @@ VariableWriteServiceInitialize (
>EFI_STATUS Status;
>UINTN Index;
>UINT8 Data;
> - EFI_PHYSICAL_ADDRESSVariableStoreBase;
> - EFI_PHYSICAL_ADDRESSNvStorageBase;
>VARIABLE_ENTRY_PROPERTY *VariableEntry;
>
>AcquireLockOnlyAtBootTime(&mVariableModuleGlobal-
> >VariableGlobal.VariableServicesLock);
>
> - NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet64
> (PcdFlashNvStorageVariableBase64);
> - if (NvStorageBase == 0) {
> -NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
> - }
> - VariableStoreBase = NvStorageBase + (mNvFvHeaderCache->HeaderLength);
> -
> - //
> - // Let NonVolatileVariableBase point to flash variable store base directly
> after
> FTW ready.
> - //
> - mVariableModuleGlobal->VariableGlobal.NonVolatileVariableBase =
> VariableStoreBase;
> -
>//
>// Check if the free area is really free.
>//
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> index 938eb5de61fa..566e7268d187 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> @@ -2,7 +2,7 @@
>The internal header file includes the common header files, defines
>internal structure and functions used by Variable modules.
>
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, 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
> @@ -46,6 +46,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "PrivilegePolymorphic.h"
>
> +#define NV_STORAGE_VARIABLE_BASE (EFI_PHYSICAL_ADDRESS) \
> + (PcdGet64
> (PcdFlashNvStorageVariableBase64) != 0 ? \
> +PcdGet64
> (PcdFlashNvStorageVariableBase64) : \
> +PcdGet32 (PcdFlashNvStorageVariableBase))
> +
> #define EFI_VARIABLE_A
Re: [edk2] [PATCH V2 08/15] MdeModulePkg Variable: Add emulated variable NV mode support
Hi Star,
Just two minor comments below.
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A ; Kinney, Michael D
> ; Gao, Liming ; Ni, Ray
> ; Laszlo Ersek ; Ard Biesheuvel
>
> Subject: [PATCH V2 08/15] MdeModulePkg Variable: Add emulated variable NV
> mode support
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Add emulated variable NV mode support in real variable driver.
> Platform can configure PcdEmuVariableNvModeEnable statically
> (build time) or dynamically (boot time) to support emulated
> variable NV mode.
>
It would be better to mention, although it could be dynamically
configured, it's just a one-shot action before this driver is loaded,
just in case of any misunderstanding.
> Then EmuVariableRuntimeDxe could be removed, the removal of
> EmuVariableRuntimeDxe will be done after platforms are migrated
> to use the merged variable driver.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/Variable/RuntimeDxe/Variable.c | 318
> +++--
> .../Universal/Variable/RuntimeDxe/Variable.h | 1 +
> .../Universal/Variable/RuntimeDxe/VariableDxe.c| 27 +-
> .../Variable/RuntimeDxe/VariableRuntimeDxe.inf | 4 +-
> .../Universal/Variable/RuntimeDxe/VariableSmm.c| 29 +-
> .../Universal/Variable/RuntimeDxe/VariableSmm.inf | 4 +-
> 6 files changed, 271 insertions(+), 112 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 4c8e1d8cf4f1..845276d891ae 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -34,6 +34,7 @@ VARIABLE_MODULE_GLOBAL *mVariableModuleGlobal;
>
> ///
> /// Define a memory cache that improves the search performance for a
> variable.
> +/// For EmuNvMode == TRUE, it will be equal to NonVolatileVariableBase.
> ///
> VARIABLE_STORE_HEADER *mNvVariableCache = NULL;
>
> @@ -273,7 +274,7 @@ UpdateVariableStore (
>//
>// Check if the Data is Volatile.
>//
> - if (!Volatile) {
> + if (!Volatile && !mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> if (Fvb == NULL) {
>return EFI_UNSUPPORTED;
> }
> @@ -296,17 +297,30 @@ UpdateVariableStore (
> // Data Pointer should point to the actual Address where data is to be
> // written.
> //
> -VolatileBase = (VARIABLE_STORE_HEADER *) ((UINTN)
> mVariableModuleGlobal->VariableGlobal.VolatileVariableBase);
> -if (SetByIndex) {
> - DataPtr += mVariableModuleGlobal->VariableGlobal.VolatileVariableBase;
> -}
> +if (Volatile) {
> + VolatileBase = (VARIABLE_STORE_HEADER *) ((UINTN)
> mVariableModuleGlobal->VariableGlobal.VolatileVariableBase);
> + if (SetByIndex) {
> +DataPtr +=
> mVariableModuleGlobal->VariableGlobal.VolatileVariableBase;
> + }
>
> -if ((DataPtr + DataSize) > ((UINTN) VolatileBase + VolatileBase->Size)) {
> - return EFI_OUT_OF_RESOURCES;
> + if ((DataPtr + DataSize) > ((UINTN) VolatileBase +
> VolatileBase->Size)) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> +} else {
> + //
> + // Emulated non-volatile variable mode.
> + //
> + if (SetByIndex) {
> +DataPtr += (UINTN) mNvVariableCache;
> + }
> +
> + if ((DataPtr + DataSize) > ((UINTN) mNvVariableCache +
> mNvVariableCache-
> >Size)) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> }
>
> //
> -// If Volatile Variable just do a simple mem copy.
> +// If Volatile/Emulated Non-volatile Variable just do a simple mem copy.
> //
> CopyMem ((UINT8 *)(UINTN)DataPtr, Buffer, DataSize);
> return EFI_SUCCESS;
> @@ -987,7 +1001,7 @@ Reclaim (
>CommonUserVariableTotalSize = 0;
>HwErrVariableTotalSize = 0;
>
> - if (IsVolatile) {
> + if (IsVolatile || mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> //
> // Start Pointers for the variable.
> //
> @@ -1155,13 +1169,21 @@ Reclaim (
> CurrPtr += NewVariableSize;
>}
>
> - if (IsVolatile) {
> + if (IsVolatile || mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> //
>
Re: [edk2] [PATCH V2 05/15] MdeModulePkg: Add PcdEmuVariableNvModeEnable in dec
Hi Star, > -Original Message- > From: Zeng, Star > Sent: Monday, January 14, 2019 11:20 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Wang, Jian J ; > Wu, Hao A > Subject: [PATCH V2 05/15] MdeModulePkg: Add PcdEmuVariableNvModeEnable > in dec > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > Merge EmuVariable and Real variable driver. > > Add PcdEmuVariableNvModeEnable (support both static and > dynamic) to indicate if Variable driver will enable > emulated variable NV mode. > > This patch prepares for adding emulated variable NV mode > support in VariableRuntimeDxe. > > Cc: Jian J Wang > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > Reviewed-by: Laszlo Ersek > --- > MdeModulePkg/MdeModulePkg.dec | 10 -- > MdeModulePkg/MdeModulePkg.uni | 10 -- > 2 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > index 217ede1f7163..8fbc0af61365 100644 > --- a/MdeModulePkg/MdeModulePkg.dec > +++ b/MdeModulePkg/MdeModulePkg.dec > @@ -3,7 +3,7 @@ > # It also provides the definitions(including PPIs/PROTOCOLs/GUIDs and library > classes) > # and libraries instances, which are used for those modules. > # > -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > +# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved. > # Copyright (c) 2016, Linaro Ltd. All rights reserved. > # (C) Copyright 2016 Hewlett Packard Enterprise Development LP > # Copyright (c) 2017, AMD Incorporated. All rights reserved. > @@ -1586,7 +1586,13 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, > PcdsDynamic, PcdsDynamicEx] ># @Prompt 64-bit Base address of flash FTW working block range. > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0x0 > |UINT64|0x8010 > > - ## This PCD defines a reserved memory range for the EMU Variable driver's > NV > Variable Store. > + ## Indicates if Variable driver will enable emulated variable NV > mode. > + # TRUE - An EMU variable NV storage will be allocated or reserved for NV > variables. > + # FALSE - No EMU variable NV storage will be allocated or reserved for NV > variables. > + # @Prompt EMU variable NV mode enable. > + > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|FALSE|BO > OLEAN|0x0111 > + > + ## This PCD defines a reserved memory range for EMU variable NV storage. ># The range is valid if non-zero. The memory range size must be > PcdVariableStoreSize. ># @Prompt Reserved memory range for EMU variable NV storage. > The description is a little bit confuse to me. The value of this PCD is actually the base address of reserved memory range, but not the range (size). A complete memory range includes both base address and its size. But this PCD contains only base address information. Maybe something like below would be better (just for example): -- This PCD defines the base address of reserved memory range for EMU variable NV storage. A non-ZERO value indicates a valid range reserved with size given by PcdVariableStoreSize. @Prompt Base of reserved memory range for EMU variable NV storage. -- If you agree, please update the uni help string below as well. > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0|UINT6 > 4|0x4008 > diff --git a/MdeModulePkg/MdeModulePkg.uni > b/MdeModulePkg/MdeModulePkg.uni > index 35af744d89be..9c413a98f65d 100644 > --- a/MdeModulePkg/MdeModulePkg.uni > +++ b/MdeModulePkg/MdeModulePkg.uni > @@ -4,7 +4,7 @@ > // It also provides the definitions(including PPIs/PROTOCOLs/GUIDs and > library > classes) > // and libraries instances, which are used for those modules. > // > -// Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > +// Copyright (c) 2007 - 2019, 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 that accompanies this > distribution. > @@ -389,9 +389,15 @@ > > #string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdFlashNvStorageFtwWorkingBase6 > 4_HELP #language en-US "64-bit Base address of the FTW working block range > in flash device. If PcdFlashNvStorageFtwWorkingSize is larger than one block > size, this value should be block size aligned." > > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvModeEnable_PRO > MPT #language en-US "EMU variable NV mode enable" > + > +#stri
Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version
Star,
I think moving it to MdePkg would be better, just like UefiDriverEntryPoint. A
dummy
one may be not necessary.
Regards,
Jian
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng,
> Star
> Sent: Thursday, January 10, 2019 4:00 PM
> To: Ard Biesheuvel
> Cc: Wu, Hao A ; edk2-devel@lists.01.org; Gao, Liming
> ; Kinney, Michael D ;
> Laszlo Ersek ; Zeng, Star
> Subject: Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe:
> implement standalone MM version
>
> On 2019/1/10 15:33, Ard Biesheuvel wrote:
> > On Thu, 10 Jan 2019 at 08:30, Zeng, Star wrote:
> >>
> >> Hi Ard,
> >>
> >> Another minor feedback.
> >>
> >> On 2019/1/10 14:47, Zeng, Star wrote:
> >>> Hi Ard,
> >>>
> >>> Some minor feedback added inline.
> >>>
> >>> On 2019/1/4 2:28, Ard Biesheuvel wrote:
> Implement a new version of the fault tolerant write driver that can
> be used in the context of a standalone MM implementation.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
>
>
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> eMm.c
> | 70 +++
>
>
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> eMm.inf
> | 90
> 2 files changed, 160 insertions(+)
> >>
> >> Please add it into MdeModulePkg.dsc for package build verification.
> >>
> >
> > Hello Star,
> >
> > Thanks for all the feedback. I will respond in more detail later.
> >
> > However, to the point raised here: it is not possible to add these
> > drivers to MdeModulePkg.dsc unless we add a dummy implementation of
> > StandaloneMmDriverEntryPoint to MdeModulePkg. Do you think we should
> > do that?
>
> Oh, good information.
> To have full code building coverage for the package, personally I think
> we can move StandaloneMmDriverEntryPoint library class and instance into
> MdePkg, and even the MmServicesTableLib for MM_STANDALONE, they should
> be generic enough.
>
> I do not want to block this patch set because of this. So let's discuss
> this in parallel as separated topic.
>
> Mike, Liming, Laszlo, Jian and Hao,\
> What's your opinion?
>
>
> Thanks,
> Star
>
> >
> >
>
> diff --git
>
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
>
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
>
> new file mode 100644
> index ..b6fbf6c64f8a
> --- /dev/null
> +++
>
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
>
> @@ -0,0 +1,70 @@
> +/** @file
> +
> + Parts of the SMM/MM implementation that are specific to standalone
> MM
> +
> +Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the
> BSD License
> +which accompanies this distribution. The full text of the license
> may be found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR
> IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include "FaultTolerantWrite.h"
> +#include "FaultTolerantWriteSmmCommon.h"
> +
> +BOOLEAN
> +FtwSmmIsBufferOutsideSmmValid (
> + IN EFI_PHYSICAL_ADDRESS Buffer,
> + IN UINT64Length
> + )
> +{
> + return TRUE;
> +}
> >>>
> >>> Please add function comment header for it, otherwise some coding style
> >>> tool may report error.
> >>>
> +
> +/**
> + Internal implementation of CRC32. Depending on the execution context
> + (standalone SMM or DXE vs standalone MM), this function is
> implemented
> + via a call to the CalculateCrc32 () boot service, or via a library
> + call.
> +
> + If Buffer is NULL, then ASSERT().
> + If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> + @param[in] Buffer A pointer to the buffer on which the
> 32-bit CRC is to be computed.
> + @param[in] Length The number of bytes in the buffer Data.
> +
> + @retval Crc32The 32-bit CRC was computed for the data
> buffer.
> +
> +**/
> +UINT32
> +FtwCalculateCrc32 (
> + IN VOID *Buffer,
> + IN UINTNLength
> + )
> +{
> + return CalculateCrc32 (Buffer, Length);
> +}
> >>>
> >>> Please add function comment header for it, otherwise some coding style
> >>> tool ma
Re: [edk2] [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement standalone MM version
Reviewed-by: Jian J Wang
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar
> Subject: [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement
> standalone MM version
>
> Reuse most of the existing code to implement a variable runtime
> driver that will be able to execute in the context of standalone
> MM.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c |
> 69 ++
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf |
> 135
> 2 files changed, 204 insertions(+)
>
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> new file mode 100644
> index ..fbc99467c057
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> @@ -0,0 +1,69 @@
> +/** @file
> +
> + Parts of the SMM/MM implementation that are specific to standalone MM
> +
> +Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD
> License
> +which accompanies this distribution. The full text of the license may be
> found
> at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
> OR IMPLIED.
> +
> +**/
> +
> +#include "Variable.h"
> +
> +BOOLEAN
> +VariableSmmIsBufferOutsideSmmValid (
> + IN EFI_PHYSICAL_ADDRESS Buffer,
> + IN UINT64Length
> + )
> +{
> + return TRUE;
> +}
> +
> +/**
> + Notify the system that the SMM variable driver is ready
> +**/
> +VOID
> +VariableNotifySmmReady (
> + VOID
> + )
> +{
> +}
> +
> +/**
> + Notify the system that the SMM variable write driver is ready
> +**/
> +VOID
> +VariableNotifySmmWriteReady (
> + VOID
> + )
> +{
> +}
> +
> +EFI_STATUS
> +EFIAPI
> +VariableServiceInitialize (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_MM_SYSTEM_TABLE *MmSystemTable
> + )
> +{
> + return MmVariableServiceInitialize ();
> +}
> +
> +/**
> + Whether the TCG or TCG2 protocols are installed in the UEFI protocol
> database.
> + This information is used by the MorLock code to infer whether an existing
> + MOR variable is legitimate or not.
> +**/
> +BOOLEAN
> +VariableHaveTcgProtocols (
> + VOID
> + )
> +{
> + return FALSE;
> +}
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> new file mode 100644
> index ..54d647af914c
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> @@ -0,0 +1,135 @@
> +## @file
> +# Provides SMM variable service.
> +#
> +# This module installs SMM variable protocol into SMM protocol database,
> +# which can be used by SMM driver, and installs SMM variable protocol
> +# into BS protocol database, which can be used to notify the SMM Runtime
> +# Dxe driver that the SMM variable service is ready.
> +# This module should be used with SMM Runtime DXE module together. The
> +# SMM Runtime DXE module would install variable arch protocol and variable
> +# write arch protocol based on SMM variable module.
> +#
> +# Caution: This module requires additional review when modified.
> +# This driver will have external input - variable data and communicate
> buffer in
> SMM mode.
> +# This external input must be validated carefully to avoid security issues
> such
> as
> +# buffer overflow or integer overflow.
> +#The whole SMM authentication variable design relies on the integrity of
> flash part and SMM.
> +# which is assumed to be protected by platform. All variable code and
> metadata in flash/SMM Memory
> +# may not be modified without authorization. If platform fails to protect
> these
> resources,
> +# the authentication service provided in this driver will b
Re: [edk2] [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses
Laszlo,
Regards,
Jian
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, January 08, 2019 11:38 PM
> To: Ard Biesheuvel ; edk2-devel@lists.01.org
> Cc: Leif Lindholm ; Kinney, Michael D
> ; Gao, Liming ; Wang,
> Jian J ; Wu, Hao A ; Jagadeesh
> Ujja ; Achin Gupta ;
> Thomas Panakamattam Abraham ; Sami Mujawar
>
> Subject: Re: [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot
> service accesses
>
> On 01/03/19 19:28, Ard Biesheuvel wrote:
> > In preparation of providing a standalone MM based variable runtime
> > driver, move the existing SMM driver to the new MM services table,
> > and factor out some pieces that are specific to the traditional
> > driver, mainly related to the use of UEFI boot services, which are
> > not accessible to standalone MM drivers.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> > MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 18
> +---
> > MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h | 50
> +
> > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c | 59
> --
> > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf | 5 +-
> > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableTraditionalMm.c |
> 114
> > 5 files changed, 187 insertions(+), 59 deletions(-)
>
> I *vaguely* feel like we should extract the new functions to
> "PrivilegePolymorphic.h", rather than to "Variable.h".
>
> Please see initial commit 00663d047fc9
> ("MdeModulePkg/Variable/RuntimeDxe: move SecureBootHook() decl to new
> header", 2017-10-10), and other commits that touched that file.
>
> I realize this is not a 100% "constructive" suggestion, and I feel
> appropriately bad about that. It's just that "Variable.h" has so many
> internals that I feel it's not a good dumping ground for these new
> functions. And the other header we have, looks closer in purpose.
>
> For example, MorLockInitAtEndOfDxe() is already declared in
> "PrivilegePolymorphic.h" (see commit f1304280435f,
> "MdeModulePkg/Variable/RuntimeDxe: introduce MorLockInitAtEndOfDxe()
> hook", 2017-10-10).
>
> Admittedly, now that we're going to have three separate builds of this
> driver, dedicating a separate header file to each "shared between A and
> B" relationship is getting a bit too complex. In retrospect, introducing
> "PrivilegePolymorphic.h" may not have been a "scalable" idea, after all,
> and I should have just dumped those functions all in "Variable.h".
>
> IOW, I think
> - targeting "Variable.h" now is inconsistent with earlier code,
> - extending "PrivilegePolymorphic.h" is also suboptimal (although still
> better than the previous option),
> - adding yet another header might be technically correct, but it would
> be over-engineering,
> - asking you to merge "PrivilegePolymorphic.h" back into "Variable.h"
> feels awkward, especially after I argued *for* "PrivilegePolymorphic.h"
> at length, when I originally introduced it. :/
>
> Sigh. Can the variable driver maintainers comment please?
>
> (I still plan to regression-test this series, but I feel like I should
> force myself to at least skim the variable driver patches, beyond
> testing them. Because, next time I can't avoid working with this very
> complex driver, I wouldn't like to be *completely* lost.)
>
I agree "PrivilegePolymorphic.h" is more appropriate place for them.
Maybe Star have different opinion.
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement standalone MM version
Reviewed-by: Jian J Wang
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar
> Subject: [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement
> standalone MM version
>
> Reuse most of the existing code to implement a variable runtime
> driver that will be able to execute in the context of standalone
> MM.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c |
> 69 ++
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf |
> 135
> 2 files changed, 204 insertions(+)
>
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> new file mode 100644
> index ..fbc99467c057
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> @@ -0,0 +1,69 @@
> +/** @file
> +
> + Parts of the SMM/MM implementation that are specific to standalone MM
> +
> +Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD
> License
> +which accompanies this distribution. The full text of the license may be
> found
> at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
> OR IMPLIED.
> +
> +**/
> +
> +#include "Variable.h"
> +
> +BOOLEAN
> +VariableSmmIsBufferOutsideSmmValid (
> + IN EFI_PHYSICAL_ADDRESS Buffer,
> + IN UINT64Length
> + )
> +{
> + return TRUE;
> +}
> +
> +/**
> + Notify the system that the SMM variable driver is ready
> +**/
> +VOID
> +VariableNotifySmmReady (
> + VOID
> + )
> +{
> +}
> +
> +/**
> + Notify the system that the SMM variable write driver is ready
> +**/
> +VOID
> +VariableNotifySmmWriteReady (
> + VOID
> + )
> +{
> +}
> +
> +EFI_STATUS
> +EFIAPI
> +VariableServiceInitialize (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_MM_SYSTEM_TABLE *MmSystemTable
> + )
> +{
> + return MmVariableServiceInitialize ();
> +}
> +
> +/**
> + Whether the TCG or TCG2 protocols are installed in the UEFI protocol
> database.
> + This information is used by the MorLock code to infer whether an existing
> + MOR variable is legitimate or not.
> +**/
> +BOOLEAN
> +VariableHaveTcgProtocols (
> + VOID
> + )
> +{
> + return FALSE;
> +}
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> new file mode 100644
> index ..54d647af914c
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> @@ -0,0 +1,135 @@
> +## @file
> +# Provides SMM variable service.
> +#
> +# This module installs SMM variable protocol into SMM protocol database,
> +# which can be used by SMM driver, and installs SMM variable protocol
> +# into BS protocol database, which can be used to notify the SMM Runtime
> +# Dxe driver that the SMM variable service is ready.
> +# This module should be used with SMM Runtime DXE module together. The
> +# SMM Runtime DXE module would install variable arch protocol and variable
> +# write arch protocol based on SMM variable module.
> +#
> +# Caution: This module requires additional review when modified.
> +# This driver will have external input - variable data and communicate
> buffer in
> SMM mode.
> +# This external input must be validated carefully to avoid security issues
> such
> as
> +# buffer overflow or integer overflow.
> +#The whole SMM authentication variable design relies on the integrity of
> flash part and SMM.
> +# which is assumed to be protected by platform. All variable code and
> metadata in flash/SMM Memory
> +# may not be modified without authorization. If platform fails to protect
> these
> resources,
> +# the authentication service provided in this driver will b
Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version
Forget the previous comment, multiple comments for usage are allowed in INF.
Reviewed-by: Jian J Wang
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang,
> Jian J
> Sent: Thursday, January 10, 2019 9:42 AM
> To: Ard Biesheuvel ; edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Gao, Liming ;
> Kinney, Michael D ; Laszlo Ersek
>
> Subject: Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe:
> implement standalone MM version
>
> Ard,
>
>
> Regards,
> Jian
>
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Friday, January 04, 2019 2:28 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel ; Laszlo Ersek
> > ; Leif Lindholm ; Kinney,
> > Michael D ; Gao, Liming
> ;
> > Wang, Jian J ; Wu, Hao A ;
> > Jagadeesh Ujja ; Achin Gupta
> > ; Thomas Panakamattam Abraham
> > ; Sami Mujawar
> > Subject: [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement
> > standalone MM version
> >
> > Implement a new version of the fault tolerant write driver that can
> > be used in the context of a standalone MM implementation.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> >
> >
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> > eMm.c | 70 +++
> >
> >
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> > eMm.inf | 90
> > 2 files changed, 160 insertions(+)
> >
> > diff --git
> >
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.c
> >
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.c
> > new file mode 100644
> > index ..b6fbf6c64f8a
> > --- /dev/null
> > +++
> >
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> > oneMm.c
> > @@ -0,0 +1,70 @@
> > +/** @file
> > +
> > + Parts of the SMM/MM implementation that are specific to standalone MM
> > +
> > +Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> > +Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> > +This program and the accompanying materials
> > +are licensed and made available under the terms and conditions of the BSD
> > License
> > +which accompanies this distribution. The full text of the license may be
> > found
> > at
> > +http://opensource.org/licenses/bsd-license.php
> > +
> > +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> > +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS
> > OR IMPLIED.
> > +
> > +**/
> > +
> > +#include
> > +#include
> > +#include "FaultTolerantWrite.h"
> > +#include "FaultTolerantWriteSmmCommon.h"
> > +
> > +BOOLEAN
> > +FtwSmmIsBufferOutsideSmmValid (
> > + IN EFI_PHYSICAL_ADDRESS Buffer,
> > + IN UINT64Length
> > + )
> > +{
> > + return TRUE;
> > +}
> > +
> > +/**
> > + Internal implementation of CRC32. Depending on the execution context
> > + (standalone SMM or DXE vs standalone MM), this function is implemented
> > + via a call to the CalculateCrc32 () boot service, or via a library
> > + call.
> > +
> > + If Buffer is NULL, then ASSERT().
> > + If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> > +
> > + @param[in] Buffer A pointer to the buffer on which the 32-bit CRC
> > is to
> be
> > computed.
> > + @param[in] Length The number of bytes in the buffer Data.
> > +
> > + @retval Crc32The 32-bit CRC was computed for the data buffer.
> > +
> > +**/
> > +UINT32
> > +FtwCalculateCrc32 (
> > + IN VOID *Buffer,
> > + IN UINTNLength
> > + )
> > +{
> > + return CalculateCrc32 (Buffer, Length);
> > +}
> > +
> > +VOID
> > +FtwNotifySmmReady (
> > + VOID
> > + )
> > +{
> > +}
> > +
> > +EFI_STATUS
> > +EFIAPI
> > +StandaloneMmFaultTolerantWriteInitialize (
> > + IN EFI_HANDLEImageHandle,
> > + IN EFI_MM_SYSTEM_TABLE *MmSystemTable
> > + )
> > +{
> > + return MmFaultTolerantWriteInitialize ();
> > +}
> > diff --git
> >
> a/MdeModulePkg/
Re: [edk2] [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version
Ard,
Regards,
Jian
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar
> Subject: [PATCH 4/6] MdeModulePkg/FaultTolerantWriteDxe: implement
> standalone MM version
>
> Implement a new version of the fault tolerant write driver that can
> be used in the context of a standalone MM implementation.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
>
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> eMm.c | 70 +++
>
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandalon
> eMm.inf | 90
> 2 files changed, 160 insertions(+)
>
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> new file mode 100644
> index ..b6fbf6c64f8a
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> @@ -0,0 +1,70 @@
> +/** @file
> +
> + Parts of the SMM/MM implementation that are specific to standalone MM
> +
> +Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD
> License
> +which accompanies this distribution. The full text of the license may be
> found
> at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS
> OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include "FaultTolerantWrite.h"
> +#include "FaultTolerantWriteSmmCommon.h"
> +
> +BOOLEAN
> +FtwSmmIsBufferOutsideSmmValid (
> + IN EFI_PHYSICAL_ADDRESS Buffer,
> + IN UINT64Length
> + )
> +{
> + return TRUE;
> +}
> +
> +/**
> + Internal implementation of CRC32. Depending on the execution context
> + (standalone SMM or DXE vs standalone MM), this function is implemented
> + via a call to the CalculateCrc32 () boot service, or via a library
> + call.
> +
> + If Buffer is NULL, then ASSERT().
> + If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> + @param[in] Buffer A pointer to the buffer on which the 32-bit CRC
> is to be
> computed.
> + @param[in] Length The number of bytes in the buffer Data.
> +
> + @retval Crc32The 32-bit CRC was computed for the data buffer.
> +
> +**/
> +UINT32
> +FtwCalculateCrc32 (
> + IN VOID *Buffer,
> + IN UINTNLength
> + )
> +{
> + return CalculateCrc32 (Buffer, Length);
> +}
> +
> +VOID
> +FtwNotifySmmReady (
> + VOID
> + )
> +{
> +}
> +
> +EFI_STATUS
> +EFIAPI
> +StandaloneMmFaultTolerantWriteInitialize (
> + IN EFI_HANDLEImageHandle,
> + IN EFI_MM_SYSTEM_TABLE *MmSystemTable
> + )
> +{
> + return MmFaultTolerantWriteInitialize ();
> +}
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.inf
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.inf
> new file mode 100644
> index ..99bd62ad5ceb
> --- /dev/null
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.inf
> @@ -0,0 +1,90 @@
> + ## @file
> +# Fault Tolerant Write Smm Driver.
> +#
> +# This driver installs SMM Fault Tolerant Write (FTW) protocol, which
> provides
> fault
> +# tolerant write capability in SMM environment for block devices. Its
> implementation
> +# depends on the full functionality SMM FVB protocol that support read,
> write/erase
> +# flash access.
> +#
> +# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +#
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD
> License
> +# which accompanies this distribution. The full text of the license may be
> found
> at
> +# http://opensource.org/licenses/bsd-license.php
> +# THE PROGRAM IS DISTRIB
Re: [edk2] [PATCH 3/6] MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses
Reviewed-by: Jian J Wang > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, January 04, 2019 2:28 AM > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel ; Laszlo Ersek > ; Leif Lindholm ; Kinney, > Michael D ; Gao, Liming ; > Wang, Jian J ; Wu, Hao A ; > Jagadeesh Ujja ; Achin Gupta > ; Thomas Panakamattam Abraham > ; Sami Mujawar > Subject: [PATCH 3/6] MdeModulePkg/FaultTolerantWriteDxe: factor out boot > service accesses > > In preparation of providing a standalone MM based FTW driver, move > the existing SMM driver to the new MM services table, and factor out > some pieces that are specific to the traditional driver, mainly > related to the use of UEFI boot services, which are not accessible > to standalone MM drivers. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > MdeModulePkg/MdeModulePkg.dsc > | 1 + > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h > | 22 - > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c > | 31 +++ > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c > | 54 +-- > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf > | 5 +- > > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCom > mon.h | 31 +++ > > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.c > | 1 + > > MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditiona > lMm.c | 94 > MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c > | 10 +-- > 9 files changed, 205 insertions(+), 44 deletions(-) > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > b/MdeModulePkg/MdeModulePkg.dsc > index 5d042be3a862..ef3c144ed524 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -153,6 +153,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER] >DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf > > MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemory > AllocationLib.inf > > SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTable > Lib.inf > + > MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib > .inf >LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf >SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf > > diff --git > a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h > b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h > index 844cf3bee04d..8d146264b129 100644 > --- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h > +++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h > @@ -31,7 +31,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY > KIND, EITHER EXPRESS OR IMPLIED. > #include > #include > #include > -#include > #include > > // > @@ -766,4 +765,25 @@ WriteWorkSpaceData ( >IN UINT8 *Buffer >); > > +/** > + Internal implementation of CRC32. Depending on the execution context > + (traditional SMM or DXE vs standalone MM), this function is implemented > + via a call to the CalculateCrc32 () boot service, or via a library > + call. > + > + If Buffer is NULL, then ASSERT(). > + If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT(). > + > + @param[in] Buffer A pointer to the buffer on which the 32-bit CRC > is to be > computed. > + @param[in] Length The number of bytes in the buffer Data. > + > + @retval Crc32The 32-bit CRC was computed for the data buffer. > + > +**/ > +UINT32 > +FtwCalculateCrc32 ( > + IN VOID *Buffer, > + IN UINTNLength > + ); > + > #endif > diff --git > a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c > b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c > index 094e40f9d86c..24e507104bbe 100644 > --- > a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c > +++ > b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c > @@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY > KIND, EITHER EXPRESS OR IMPLIED. > > **/ > > +#include > #include "FaultTolerantWrite.h" > EFI_EVENT mFvbRegistration = NULL; > > @@ -250,3 +251,33 @@ FaultTolerantWriteInitialize ( > >return EFI_SUCCESS; > } > + > +/** > + Internal impl
Re: [edk2] [PATCH 2/6] MdePkg: implement MmServicesTableLib based on traditional SMM
Ard,
Regards,
Jian
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 04, 2019 2:28 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Laszlo Ersek
> ; Leif Lindholm ; Kinney,
> Michael D ; Gao, Liming ;
> Wang, Jian J ; Wu, Hao A ;
> Jagadeesh Ujja ; Achin Gupta
> ; Thomas Panakamattam Abraham
> ; Sami Mujawar
> Subject: [PATCH 2/6] MdePkg: implement MmServicesTableLib based on
> traditional SMM
>
> The definitions of the rebranded MM protocol stack were chosen such
> that the existing SMM based core drivers can be reused. So let's
> implement MmServicesTableLib based on gEfiMmBaseProtocolGuid, which
> is simply gEfiSmmBase2ProtocolGuid under the hood.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c | 63
>
> MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf | 45
> ++
> MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni | 22 +++
> MdePkg/MdePkg.dsc| 1 +
> 4 files changed, 131 insertions(+)
>
> diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
> b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
> new file mode 100644
> index ..f41d25e59805
> --- /dev/null
> +++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
> @@ -0,0 +1,63 @@
> +/** @file
> + MM Services Table Library.
> +
> + Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD
> License
> + which accompanies this distribution. The full text of the license may be
> found
> at
> + http://opensource.org/licenses/bsd-license.php.
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +
> +EFI_MM_SYSTEM_TABLE *gMmst = NULL;
> +
> +/**
> + The constructor function caches the pointer of SMM Services Table.
> +
> + @param ImageHandle The firmware allocated handle for the EFI image.
> + @param SystemTable A pointer to the EFI System Table.
> +
> + @retval EFI_SUCCESS The constructor always returns EFI_SUCCESS.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +MmServicesTableLibConstructor (
> + IN EFI_HANDLEImageHandle,
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + EFI_STATUS Status;
> + EFI_MM_BASE_PROTOCOL*InternalMmBase;
> +
> + InternalMmBase = NULL;
> + //
> + // Retrieve MM Base Protocol, Do not use gBS from
> UefiBootServicesTableLib on purpose
> + // to prevent inclusion of gBS, gST, and gImageHandle from SMM Drivers
> unless the
> + // MM driver explicity declares that dependency.
> + //
> + Status = SystemTable->BootServices->LocateProtocol (
> +&gEfiMmBaseProtocolGuid,
> +NULL,
> +(VOID **)&InternalMmBase
> +);
> + ASSERT_EFI_ERROR (Status);
> + ASSERT (InternalMmBase != NULL);
> +
> + //
> + // We are in MM, retrieve the pointer to MM System Table
> + //
> + InternalMmBase->GetMmstLocation (InternalMmBase, &gMmst);
> + ASSERT (gMmst != NULL);
> +
> + return EFI_SUCCESS;
> +}
> diff --git a/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> new file mode 100644
> index ..4418cc2f1464
> --- /dev/null
> +++ b/MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
> @@ -0,0 +1,45 @@
> +## @file
> +# MM Services Table Library.
> +#
> +# Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
> +# Copyright (c) 2018, Linaro, Ltd. All rights reserved.
> +#
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD
> License
> +# which accompanies this distribution. The full text of the license may be
> found
> at
> +# http://opensource.org/licenses/bsd-license.php.
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
>
Re: [edk2] [Patch v1 1/1] MdeModulePkg: fix comments in BaseSortLib
Reviewed-by: Jian J Wang > -Original Message- > From: Carsey, Jaben > Sent: Wednesday, January 09, 2019 5:58 AM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Wang, Jian J > Subject: [Patch v1 1/1] MdeModulePkg: fix comments in BaseSortLib > > The comments are incorrect for the base version of this lib. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Jaben Carsey > Cc: Star Zeng > Cc: Jian J Wang > --- > MdeModulePkg/Library/BaseSortLib/BaseSortLib.c | 22 > 1 file changed, 9 insertions(+), 13 deletions(-) > > diff --git a/MdeModulePkg/Library/BaseSortLib/BaseSortLib.c > b/MdeModulePkg/Library/BaseSortLib/BaseSortLib.c > index ab8a60585ee2..8f30c00971eb 100644 > --- a/MdeModulePkg/Library/BaseSortLib/BaseSortLib.c > +++ b/MdeModulePkg/Library/BaseSortLib/BaseSortLib.c > @@ -1,7 +1,7 @@ > /** @file >Library used for sorting routines. > > - Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved. > + Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved. >This program and the accompanying materials >are licensed and made available under the terms and conditions of the BSD > License >which accompanies this distribution. The full text of the license may be > found > at > @@ -193,14 +193,12 @@ DevicePathCompare ( > } > > /** > - Function to compare 2 strings without regard to case of the characters. > + Not supported in Base version. > > - @param[in] Buffer1Pointer to String to compare. > - @param[in] Buffer2Pointer to second String to compare. > + @param[in] Buffer1 Ignored. > + @param[in] Buffer2 Ignored. > > - @retval 0 Buffer1 equal to Buffer2. > - @return < 0 Buffer1 is less than Buffer2. > - @return > 0 Buffer1 is greater than Buffer2. > + ASSERT and return 0. > **/ > INTN > EFIAPI > @@ -215,14 +213,12 @@ StringNoCaseCompare ( > > > /** > - Function to compare 2 strings. > + Not supported in Base version. > > - @param[in] Buffer1Pointer to String to compare (CHAR16**). > - @param[in] Buffer2Pointer to second String to compare > (CHAR16**). > + @param[in] Buffer1 Ignored. > + @param[in] Buffer2 Ignored. > > - @retval 0 Buffer1 equal to Buffer2. > - @return < 0 Buffer1 is less than Buffer2. > - @return > 0 Buffer1 is greater than Buffer2. > + ASSERT and return 0. > **/ > INTN > EFIAPI > -- > 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failure
Reviewed-by: Jian J Wang
> -Original Message-
> From: Wu, Hao A
> Sent: Friday, January 04, 2019 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Bi, Dandan ;
> Wang, Jian J ; Ni, Ray
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT
> build failure
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425
>
> This commit will resolve the VS2015 IA32 NOOPT build failure within
> SdMmcPciHcDxe.
>
> More specifically, this commit will use BaseLib API RShiftU64() to perform
> right-shift operations for UINT64 type operators.
>
> Cc: Dandan Bi
> Cc: Jian J Wang
> Cc: Ruiyu Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 6086720fa1..5aec8c6992 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1505,7 +1505,7 @@ BuildAdmaDescTable (
> Trb->Adma32Desc[Index].Valid = 1;
> Trb->Adma32Desc[Index].Act = 2;
> if (DataLength26) {
> - Trb->Adma32Desc[Index].UpperLength = (UINT16)(Remaining >> 16);
> + Trb->Adma32Desc[Index].UpperLength = (UINT16)RShiftU64 (Remaining,
> 16);
> }
> Trb->Adma32Desc[Index].LowerLength = (UINT16)(Remaining &
> MAX_UINT16);
> Trb->Adma32Desc[Index].Address = (UINT32)Address;
> @@ -1524,11 +1524,11 @@ BuildAdmaDescTable (
> Trb->Adma64Desc[Index].Valid = 1;
> Trb->Adma64Desc[Index].Act = 2;
> if (DataLength26) {
> - Trb->Adma64Desc[Index].UpperLength = (UINT16)(Remaining >> 16);
> + Trb->Adma64Desc[Index].UpperLength = (UINT16)RShiftU64 (Remaining,
> 16);
> }
> Trb->Adma64Desc[Index].LowerLength = (UINT16)(Remaining &
> MAX_UINT16);
> Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
> -Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
> +Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64 (Address,
> 32);
> break;
>} else {
> Trb->Adma64Desc[Index].Valid = 1;
> @@ -1538,7 +1538,7 @@ BuildAdmaDescTable (
> }
> Trb->Adma64Desc[Index].LowerLength = 0;
> Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
> -Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
> +Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64 (Address,
> 32);
>}
> }
>
> --
> 2.12.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 25/26] CryptoPkg/BaseCryptLib: drop build flags specific to GCC44
Reviewed-by: Jian J Wang > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, January 03, 2019 10:48 AM > To: edk2-devel-01 > Cc: Wei, Gang ; Wang, Jian J ; > Ye, Ting > Subject: [PATCH 25/26] CryptoPkg/BaseCryptLib: drop build flags specific to > GCC44 > > We've removed BaseTools support for GCC44..GCC47. Drop > CryptoPkg/BaseCryptLib build flags that are specific to any of those gcc > versions. > > No GCC44..GCC47 references remain under CryptoPkg after this patch. > > Cc: Gang Wei > Cc: Jian Wang > Cc: Ting Ye > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377 > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Laszlo Ersek > --- > > Notes: > Build tested with: > > ( > set -e > for INF in CryptoPkg/Library/BaseCryptLib/*.inf; do > build -t GCC48 -a IA32 -b DEBUG -p CryptoPkg/CryptoPkg.dsc \ > -m "$INF" > done > ) > > CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf| 2 -- > CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf | 2 -- > CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 2 -- > CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 1 - > 4 files changed, 7 deletions(-) > > diff --git a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > index f29445ce3402..0d81db2fbd7f 100644 > --- a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf > @@ -96,8 +96,6 @@ [BuildOptions] ># >MSFT:*_*_*_CC_FLAGS = /wd4090 > > - GCC:*_GCC44_IA32_CC_FLAGS = "-D__cdecl=__attribute__((cdecl))" "- > D__declspec(t)=__attribute__((t))" > - ># -JCryptoPkg/Include : To disable the use of the system includes provided > by > RVCT ># --diag_remark=1 : Reduce severity of "#1-D: last line of file ends > without a > newline" >RVCT:*_*_ARM_CC_FLAGS = -JCryptoPkg/Include --diag_remark=1 > diff --git a/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf > index e7b4b2f61855..4bcf064c5623 100644 > --- a/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf > @@ -93,8 +93,6 @@ [BuildOptions] ># >MSFT:*_*_*_CC_FLAGS = /wd4090 /wd4718 > > - GCC:*_GCC44_IA32_CC_FLAGS = "-D__cdecl=__attribute__((cdecl))" "- > D__declspec(t)=__attribute__((t))" > - ># -JCryptoPkg/Include : To disable the use of the system includes provided > by > RVCT ># --diag_remark=1 : Reduce severity of "#1-D: last line of file ends > without a > newline" >RVCT:*_*_ARM_CC_FLAGS = -JCryptoPkg/Include --diag_remark=1 > diff --git a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > index 32628c8835a6..a6e433f6ced1 100644 > --- a/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf > @@ -102,8 +102,6 @@ [BuildOptions] ># >MSFT:*_*_*_CC_FLAGS = /wd4090 > > - GCC:*_GCC44_IA32_CC_FLAGS = "-D__cdecl=__attribute__((cdecl))" "- > D__declspec(t)=__attribute__((t))" > - ># -JCryptoPkg/Include : To disable the use of the system includes provided > by > RVCT ># --diag_remark=1 : Reduce severity of "#1-D: last line of file ends > without a > newline" >RVCT:*_*_ARM_CC_FLAGS = -JCryptoPkg/Include --diag_remark=1 > diff --git a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > index 4829669c1f3f..c34699cd62bf 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > +++ b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > @@ -100,5 +100,4 @@ [BuildOptions] ># >MSFT:*_*_*_CC_FLAGS = /wd4090 > > - GCC:*_GCC44_IA32_CC_FLAGS = "-D__cdecl=__attribute__((cdecl))" "- > D__declspec(t)=__attribute__((t))" >XCODE:*_*_*_CC_FLAGS = -mmmx -msse > -- > 2.19.1.3.g30247aa5d201 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable from Standalone MM
Hi Jagadeesh,
Since those code are used in different drivers, a new library would be better.
For
example, we could have a CommonMmServicesLibrary, in which following interfaces
are defined ((just for example)
EFI_STATUS
MmstLocateProtocol(
IN EFI_GUID *Protocol,
IN VOID *Registration, OPTIONAL
OUT VOID **Interface
)
{
EFI_STATUS Status;
if (!PcdGetBool (PcdStandaloneMmVariableEnabled)) {
Status = gSmst->SmmLocateProtocol (
&gEfiSmmSwapAddressRangeProtocolGuid,
NULL,
SarProtocol
);
} else {
Status = gMmst->MmLocateProtocol (
&gEfiSmmSwapAddressRangeProtocolGuid,
NULL,
SarProtocol
);
}
return Status;
}
Then you can use MmstLocateProtocol() in FaultTolerantWriteDxe, Variable
driver, etc.
This applies to other interfaces like InstallProtocolInterface, AllocatePage in
SMM/MM
system table.
Regards,
Jian
> -Original Message-
> From: Jagadeesh Ujja [mailto:jagadeesh.u...@arm.com]
> Sent: Wednesday, January 02, 2019 9:19 PM
> To: Wang, Jian J
> Cc: edk2-devel@lists.01.org; Gao, Liming ; Zhang, Chao
> B ; leif.lindh...@linaro.org;
> ard.biesheu...@linaro.org
> Subject: Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable
> from Standalone MM
>
> hi Jian,
>
> On Fri, Dec 21, 2018 at 8:27 AM Wang, Jian J wrote:
> >
> > Jagadeesh,
> >
> > There're many places in this patch series where code similar to following is
> added.
> > It'd better to wrap them into module private functions or even a library, if
> necessary.
> > This can make the code cleaner (no if/else) and easier (central place) to
> maintain in
> > the future.
> >
> > + if (!PcdGetBool (PcdStandaloneMmVariableEnabled)) {
> > +Status = gSmst->SmmLocateProtocol (
> > + &gEfiSmmSwapAddressRangeProtocolGuid,
> > + NULL,
> > + SarProtocol
> > + );
> > + } else {
> > +Status = gMmst->MmLocateProtocol (
> > + &gEfiSmmSwapAddressRangeProtocolGuid,
> > + NULL,
> > + SarProtocol
> > + );
> > + }
> >
> Thank you for your comment. This patch series try to reuse code as
> much as possible between MM and non-MM code. So, in some changes,
> if..else was used which helps to reuse most of the other bits of code.
> To address your comment, can you please let me know how we could avoid
> this if..else without duplicating the too much code. I am not clear
> about " module private functions or even a library" comment that you
> have made. Can you please help me with this.
>
> Thanks,
> Jagadeesh.
>
> > Regards,
> > Jian
> >
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > > Jagadeesh Ujja
> > > Sent: Friday, December 14, 2018 8:13 PM
> > > To: edk2-devel@lists.01.org; Gao, Liming ; Zhang,
> Chao
> > > B ; leif.lindh...@linaro.org;
> > > ard.biesheu...@linaro.org
> > > Subject: [edk2] [PATCH 00/13] Extend secure variable service to be usable
> from
> > > Standalone MM
> > >
> > > Changes since RFC v4:
> > > - Addressed all the comments from Liming Gao
> > > - Added an additional PCD 'PcdStandaloneMmCodeEnabled' to indicate
> > > presence of StandaloneMM support.
> > > - MdePkg.dec file updated to include StandaloneMmServiceTableLib and
> > > StandaloneMmRuntimeDxe library.
> > > - Platform specific changes will be posted in a seperate patchset.
> > > - AsmLfence wrapper function is supported for AArch64 platforms.
> > > - All the patches in this series can be pulled from
> > > https://github.com/jagadeeshujja/edk2 (branch:
> topics/aarch64_secure_vars)
> > >
> > > Changes since RFC v3:
> > > - Addressed all the comments from Liming Gao
> > > - Added a AArch64 implementation of AsmLfence which is a wrapper for
> > > MemoryFence. The changes in variable service driver in v3 of this
> > > patchset that used MemoryFence instead of AsmLfence have been
> removed.
> > > - Added StandaloneMmServicesTableLib.h and StandaloneMmRuntimeDxe
> > > library into MdePkg.
> > > - Renamed PcdStandaloneMmEnable as PcdStandaloneMmVariableEnabled
> and
> > > added to in to MdePkg.
> >
Re: [edk2] [patch] MdeModulePkg/NonDiscoverable: Use compare operator for comparison
Reviewed-by: Jian J Wang
> -Original Message-
> From: Bi, Dandan
> Sent: Friday, December 28, 2018 4:54 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A
> Subject: [patch] MdeModulePkg/NonDiscoverable: Use compare operator for
> comparison
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1422
>
> According to EDK II C Coding Standards Specification,
> Non-Boolean comparisons must use a compare operator.
> This patch is to update the code to follow EDKII coding style.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi
> ---
> .../NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c| 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> index f0d3472ea5..a0fe3b9ffa 100644
> ---
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> +++
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> @@ -1274,11 +1274,11 @@ PciIoAttributes (
>#define DEV_SUPPORTED_ATTRIBUTES \
> (EFI_PCI_DEVICE_ENABLE | EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE)
>
>Dev = NON_DISCOVERABLE_PCI_DEVICE_FROM_PCI_IO(This);
>
> - if (Attributes) {
> + if (Attributes != 0) {
>if ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0) {
> return EFI_UNSUPPORTED;
>}
> }
>
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 4/5] MdeModulePkg/Variable: Update to consume SpeculationBarrier
Reviewed-by: Jian J Wang
> -Original Message-
> From: Wu, Hao A
> Sent: Friday, December 21, 2018 11:11 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ard Biesheuvel
> ; Yao, Jiewen ; Gao,
> Liming ; Wang, Jian J ; Zeng,
> Star
> Subject: [PATCH v1 4/5] MdeModulePkg/Variable: Update to consume
> SpeculationBarrier
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417
>
> Since BaseLib API AsmLfence() is a x86 arch specific API and should be
> avoided using in generic codes, this commit replaces the usage of
> AsmLfence() with arch-generic API SpeculationBarrier().
>
> Please note that speculation execution barriers are intended to be
> asserted for SMM codes, hence, this commit still preserve an empty
> implementation of the speculation execution barrier for the DXE codes.
>
> Cc: Ard Biesheuvel
> Cc: Jiewen Yao
> Cc: Liming Gao
> Cc: Jian J Wang
> Cc: Star Zeng
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> | 2 +-
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> | 2 +-
> MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> | 10
> MdeModulePkg/Universal/Variable/RuntimeDxe/{LoadFenceDxe.c =>
> SpeculationBarrierDxe.c} | 12 ++
> MdeModulePkg/Universal/Variable/RuntimeDxe/{LoadFenceSmm.c =>
> SpeculationBarrierSmm.c} | 14 +++-
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> |
> 6 ++---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> | 24 ++--
> 7 files changed, 38 insertions(+), 32 deletions(-)
>
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> index 868981ccaf..7ef8a97f5d 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> @@ -46,7 +46,7 @@
>TcgMorLockDxe.c
>VarCheck.c
>VariableExLib.c
> - LoadFenceDxe.c
> + SpeculationBarrierDxe.c
>
> [Packages]
>MdePkg/MdePkg.dec
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> index 2fe72ff8a4..db7d220e06 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> @@ -54,7 +54,7 @@
>PrivilegePolymorphic.h
>VariableExLib.c
>TcgMorLockSmm.c
> - LoadFenceSmm.c
> + SpeculationBarrierSmm.c
>
> [Packages]
>MdePkg/MdePkg.dec
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> index a324ad2365..7af22a4ad6 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> @@ -85,13 +85,15 @@ SetVariableCheckHandlerMor (
>);
>
> /**
> - This service is consumed by the variable modules to perform a serializing
> - operation on all load-from-memory instructions that were issued prior to
> the
> - call of this function.
> + This service is consumed by the variable modules to place a barrier to stop
> + speculative execution.
> +
> + Ensures that no later instruction will execute speculatively, until all
> prior
> + instructions have completed.
>
> **/
> VOID
> -MemoryLoadFence (
> +VariableSpeculationBarrier (
>VOID
>);
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierDxe.c
> similarity index 62%
> rename from MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c
> rename to
> MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierDxe.c
> index 0f64ee093b..bc3f695335 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/LoadFenceDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/SpeculationBarrierDxe.c
> @@ -1,5 +1,5 @@
> /** @file
> - Serialize operation on all load-from-memory instructions (DXE version).
> + Barrier to stop speculative execution (DXE version).
>
> Copyright (c) 2018, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> @@ -15,13 +15,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> #include "Variable.h"
>
> /**
> - This service is consumed by the variable modules to perform a ser
Re: [edk2] [PATCH v1 3/5] MdeModulePkg/SmmLockBox: Update to consume SpeculationBarrier
Reviewed-by: Jian J Wang > -Original Message- > From: Wu, Hao A > Sent: Friday, December 21, 2018 11:11 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A ; Ard Biesheuvel > ; Yao, Jiewen ; Gao, > Liming ; Wang, Jian J > Subject: [PATCH v1 3/5] MdeModulePkg/SmmLockBox: Update to consume > SpeculationBarrier > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417 > > Since BaseLib API AsmLfence() is a x86 arch specific API and should be > avoided using in generic codes, this commit replaces the usage of > AsmLfence() with arch-generic API SpeculationBarrier(). > > Cc: Ard Biesheuvel > Cc: Jiewen Yao > Cc: Liming Gao > Cc: Jian J Wang > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Hao Wu > --- > MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c | 12 ++- > - > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c > b/MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c > index c1c9aa5663..a743129539 100644 > --- a/MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c > +++ b/MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.c > @@ -77,10 +77,10 @@ SmmLockBoxSave ( > return ; >} >// > - // The AsmLfence() call here is to ensure the above range check for the > - // CommBuffer have been completed before calling into SaveLockBox(). > + // The SpeculationBarrier() call here is to ensure the above range check > for > + // the CommBuffer have been completed before calling into SaveLockBox(). >// > - AsmLfence (); > + SpeculationBarrier (); > >// >// Save data > @@ -166,10 +166,10 @@ SmmLockBoxUpdate ( > return ; >} >// > - // The AsmLfence() call here is to ensure the above range check for the > - // CommBuffer have been completed before calling into UpdateLockBox(). > + // The SpeculationBarrier() call here is to ensure the above range check > for > + // the CommBuffer have been completed before calling into UpdateLockBox(). >// > - AsmLfence (); > + SpeculationBarrier (); > >// >// Update data > -- > 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 2/5] MdeModulePkg/FaultTolerantWrite: Update to consume SpeculationBarrier
Reviewed-by: Jian J Wang
> -Original Message-
> From: Wu, Hao A
> Sent: Friday, December 21, 2018 11:11 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ard Biesheuvel
> ; Yao, Jiewen ; Gao,
> Liming ; Wang, Jian J
> Subject: [PATCH v1 2/5] MdeModulePkg/FaultTolerantWrite: Update to
> consume SpeculationBarrier
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1417
>
> Since BaseLib API AsmLfence() is a x86 arch specific API and should be
> avoided using in generic codes, this commit replaces the usage of
> AsmLfence() with arch-generic API SpeculationBarrier().
>
> Cc: Ard Biesheuvel
> Cc: Jiewen Yao
> Cc: Liming Gao
> Cc: Jian J Wang
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c | 8
>
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> index 27fcab19b6..481fea3f1f 100644
> ---
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
> @@ -419,11 +419,11 @@ SmmFaultTolerantWriteHandler (
> );
>if (!EFI_ERROR (Status)) {
> //
> -// The AsmLfence() call here is to ensure the previous range/content
> -// checks for the CommBuffer have been completed before calling into
> -// FtwWrite().
> +// The SpeculationBarrier() call here is to ensure the previous
> +// range/content checks for the CommBuffer have been completed before
> +// calling into FtwWrite().
> //
> -AsmLfence ();
> +SpeculationBarrier ();
> Status = FtwWrite(
> &mFtwDevice->FtwInstance,
> SmmFtwWriteHeader->Lba,
> --
> 2.12.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable from Standalone MM
Jagadeesh,
There're many places in this patch series where code similar to following is
added.
It'd better to wrap them into module private functions or even a library, if
necessary.
This can make the code cleaner (no if/else) and easier (central place) to
maintain in
the future.
+ if (!PcdGetBool (PcdStandaloneMmVariableEnabled)) {
+Status = gSmst->SmmLocateProtocol (
+ &gEfiSmmSwapAddressRangeProtocolGuid,
+ NULL,
+ SarProtocol
+ );
+ } else {
+Status = gMmst->MmLocateProtocol (
+ &gEfiSmmSwapAddressRangeProtocolGuid,
+ NULL,
+ SarProtocol
+ );
+ }
Regards,
Jian
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jagadeesh Ujja
> Sent: Friday, December 14, 2018 8:13 PM
> To: edk2-devel@lists.01.org; Gao, Liming ; Zhang, Chao
> B ; leif.lindh...@linaro.org;
> ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH 00/13] Extend secure variable service to be usable from
> Standalone MM
>
> Changes since RFC v4:
> - Addressed all the comments from Liming Gao
> - Added an additional PCD 'PcdStandaloneMmCodeEnabled' to indicate
> presence of StandaloneMM support.
> - MdePkg.dec file updated to include StandaloneMmServiceTableLib and
> StandaloneMmRuntimeDxe library.
> - Platform specific changes will be posted in a seperate patchset.
> - AsmLfence wrapper function is supported for AArch64 platforms.
> - All the patches in this series can be pulled from
> https://github.com/jagadeeshujja/edk2 (branch: topics/aarch64_secure_vars)
>
> Changes since RFC v3:
> - Addressed all the comments from Liming Gao
> - Added a AArch64 implementation of AsmLfence which is a wrapper for
> MemoryFence. The changes in variable service driver in v3 of this
> patchset that used MemoryFence instead of AsmLfence have been removed.
> - Added StandaloneMmServicesTableLib.h and StandaloneMmRuntimeDxe
> library into MdePkg.
> - Renamed PcdStandaloneMmEnable as PcdStandaloneMmVariableEnabled and
> added to in to MdePkg.
> - Now with above changes, edk2 packages don't need to depend on
> StandaloneMmPkg/StandaloneMmPkg.dec
> - Addressed comments from Ting Ye
> - Removed the hacks in the v3 version.
> - Will relook into the “TimerWrapp.c” file and add a appropriate
> implementation of this for MM Standalone mode code.
>
> Changes since RFC v2:
> - Added 'Contributed-under' tag, removed Change-ID tag and
> maintained a single signed-off-by for the all the patches.
>
> Changes since RFC v1:
> - Addressed all the comments from Liming Gao
> - Removed the use of #ifdef/#else/#endif and used a Pcd instead to
> select between MM and non-MM paths.
> - Removed all dependencies on edk2-platforms.
> - Dropped the use of mMmst and used gSmst instead.
> - Added a dummy implementation UefiRuntimeServiceTableLib for
> MM_STANDALONE usage
> - Replaced all uses of AsmLfence with MemoryFence from variable
> service code.
> - Add a new StandaloneMmRuntimeDxe library to for use by non-MM code.
>
> This patch series extends the existing secure variable service support for
> use with Standalone MM. This is applicable to paltforms that use Standalone
> Management Mode to protect access to non-volatile memory (NOR flash in case
> of these patches) used to store the secure EFI variables.
>
> The first patch pulls in additional libraries from the staging branch of
> StandaloneMmPkg into the edk2's StandaloneMmPkg. The existing secure
> variable
> service implementation supports only the traditional MM mode and so the rest
> of the patches extends the existing secure variable service support to be
> useable with Standalone MM mode as well.
>
> Jagadeesh Ujja (13):
> StandaloneMmPkg: Pull in additonal libraries from staging branch
> MdePkg: Add a PCD that indicates presence of Standalone MM mode
> MdeModulePkg: Add a PCD to indicate Standalone MM supports secure
> variable
> MdePkg/Include: add StandaloneMmServicesTableLib header file
> MdePkg/Library/BaseLib/AArch64: Add AsmLfence function
> MdePkg/Library: Add StandaloneMmRuntimeDxe library
> MdeModulePkg/FaultTolerantWriteDxe: allow reusability as a MM driver
> MdeModulePkg/Variable/RuntimeDxe: adapt for usability with MM
> Standalone
> MdeModulePkg/Variable/RuntimeDxe: adapt as a MM Standalone driver
> MdeModulePkg/VarCheckLib: allow MM_STANDALONE drivers to use this
> library
> ArmPlatformPkg/NorFlashDxe: allow reusability as a MM driver
> SecurityPkg/AuthVariableLib: allow MM_STANDALONE drivers to use this
> library
> CryptoPkg/BaseCryptLib: allow MM_STANDALONE drivers to use this
> library
>
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashBlockIoDxe.c
> | 2 +-
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
>
Re: [edk2] [PATCH] Upgrade OpenSSL to 1.1.0j
Pushed @ a18f784cfdbe17855ec4376e80db927e1a81aaca
To whom it may concern, please remember to update the openssl submodule before
building any modules from CryptoPkg.
Regards,
Jian
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Wednesday, December 19, 2018 11:03 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting
> Subject: [edk2] [PATCH] Upgrade OpenSSL to 1.1.0j
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1393
>
> BZ#1089 (https://bugzilla.tianocore.org/show_bug.cgi?id=1089) requests
> to upgrade the OpenSSL to the latest 1.1.1 release. Since OpenSSL-1.1.1
> has many changes, more porting efforts and feature evaluation are needed.
> This might lead to a situation that it cannot catch the Q1'19 stable tag.
>
> One of the solution is upgrade current version (1.1.0h) to 1.1.0j.
> According to following web page in openssl.org, all security issues
> solved in 1.1.1 have been also back-ported to 1.1.0.j. This can make
> sure that no security vulnerabilities left in edk2 master before 1.1.1.
>
> https://www.openssl.org/news/vulnerabilities-1.1.1.html
>
> Cc: Ting Ye
> Cc: Gang Wei
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang
> ---
> CryptoPkg/CryptoPkg.dsc | 1 +
> .../Library/Include/openssl/opensslconf.h | 20 ---
> CryptoPkg/Library/OpensslLib/OpensslLib.inf | 3 +++
> .../Library/OpensslLib/OpensslLibCrypto.inf | 3 +++
> CryptoPkg/Library/OpensslLib/openssl | 2 +-
> CryptoPkg/Library/OpensslLib/process_files.pl | 0
> 6 files changed, 21 insertions(+), 8 deletions(-)
> mode change 100644 => 100755 CryptoPkg/Library/OpensslLib/process_files.pl
>
> diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc
> index a0334d628b..321abe4d4c 100644
> --- a/CryptoPkg/CryptoPkg.dsc
> +++ b/CryptoPkg/CryptoPkg.dsc
> @@ -121,6 +121,7 @@
>CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
>CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
>CryptoPkg/Library/TlsLib/TlsLib.inf
> + CryptoPkg/Library/OpensslLib/OpensslLib.inf
>
> [Components.IA32, Components.X64]
>CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
> diff --git a/CryptoPkg/Library/Include/openssl/opensslconf.h
> b/CryptoPkg/Library/Include/openssl/opensslconf.h
> index 1917d7ab24..28dd9ab93c 100644
> --- a/CryptoPkg/Library/Include/openssl/opensslconf.h
> +++ b/CryptoPkg/Library/Include/openssl/opensslconf.h
> @@ -2,7 +2,7 @@
> * WARNING: do not edit!
> * Generated from include/openssl/opensslconf.h.in
> *
> - * Copyright 2016 The OpenSSL Project Authors. All Rights Reserved.
> + * Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved.
> *
> * Licensed under the OpenSSL license (the "License"). You may not use
> * this file except in compliance with the License. You can obtain a copy
> @@ -235,12 +235,18 @@ extern "C" {
> * still won't see them if the library has been built to disable deprecated
> * functions.
> */
> -#if defined(OPENSSL_NO_DEPRECATED)
> -# define DECLARE_DEPRECATED(f)
> -#elif __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 0)
> -# define DECLARE_DEPRECATED(f)f __attribute__ ((deprecated));
> -#else
> -# define DECLARE_DEPRECATED(f) f;
> +#ifndef DECLARE_DEPRECATED
> +# if defined(OPENSSL_NO_DEPRECATED)
> +# define DECLARE_DEPRECATED(f)
> +# else
> +# define DECLARE_DEPRECATED(f) f;
> +# ifdef __GNUC__
> +# if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 0)
> +#undef DECLARE_DEPRECATED
> +#define DECLARE_DEPRECATED(f)f __attribute__ ((deprecated));
> +# endif
> +# endif
> +# endif
> #endif
>
> #ifndef OPENSSL_FILE
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> index 0300856cf2..6162d29143 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> @@ -175,6 +175,7 @@
>$(OPENSSL_PATH)/crypto/conf/conf_mall.c
>$(OPENSSL_PATH)/crypto/conf/conf_mod.c
>$(OPENSSL_PATH)/crypto/conf/conf_sap.c
> + $(OPENSSL_PATH)/crypto/conf/conf_ssl.c
>$(OPENSSL_PATH)/crypto/cpt_err.c
>$(OPENSSL_PATH)/crypto/cryptlib.c
>$(OPENSSL_PATH)/crypto/cversion.c
> @@ -281,6 +282,7 @@
>$(OPENSSL_PATH)/crypto/evp/pmeth_lib.c
>$(OPENSSL_PATH)/crypto/evp/scrypt.c
>$(OPENSSL_PATH)/crypto/ex_data.c
> + $(OPENSSL_PATH)/crypto/getenv.c
>$(OPENSSL_PATH)/crypto/hmac/hm_ameth.c
>$(OPENSSL_PATH)/crypto/hmac/hm_pmeth.c
>$(OPENSSL_PATH)/crypto/hmac/hmac.c
> @@ -418,6 +420,7 @@
>$(OPENSSL_PATH)/crypto/x509/x509_err.c
>$(OPENSSL_PATH)/crypto/x509/x509_ext.c
>$(OPENSSL_PATH)/crypto/x509/x509_lu.c
> + $(OPENSSL_PATH)/crypto/x509/x509_meth.c
>$(OPENSSL_PATH)/crypto/x509/x509_obj.c
>$(OPENSSL_PATH)/crypto/x509/x509_r2x.c
>$(OPENSSL_PATH)/crypto/x509/x509_req.c
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibC
Re: [edk2] [PATCH v2 3/6] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account
Reviewed-by: Jian J Wang
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 20, 2018 4:57 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael D
> ; Gao, Liming ; Wang,
> Jian J ; Wu, Hao A ; Leif
> Lindholm ; Laszlo Ersek ; Eric
> Auger ; Andrew Jones ;
> Philippe Mathieu-Daude
> Subject: [PATCH v2 3/6] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS
> into account
>
> Take MAX_ALLOC_ADDRESS into account in the implementation of the
> page allocation routines, so that they will only return memory
> that is addressable by the CPU at boot time, even if more memory
> is available in the GCD memory map.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> MdeModulePkg/Core/Dxe/Mem/Page.c | 52 ++--
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index 961c5b833546..5ad8e1171ef7 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -52,26 +52,26 @@ LIST_ENTRY mFreeMemoryMapEntryList =
> INITIALIZE_LIST_HEAD_VARIABLE (mFreeMemor
> BOOLEAN mMemoryTypeInformationInitialized = FALSE;
>
> EFI_MEMORY_TYPE_STATISTICS mMemoryTypeStatistics[EfiMaxMemoryType +
> 1] = {
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiReservedMemoryType
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiConventionalMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiUnusableMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIReclaimMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIMemoryNVS
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIO
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIOPortSpace
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiPalCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiPersistentMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE } //
> EfiMaxMemoryType
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiReservedMemoryType
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiConventionalMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiUnusableMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIReclaimMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIMemoryNVS
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIO
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIOPortSpace
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiPalCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiPersistentMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE } //
> EfiMaxMemoryType
> };
>
> -EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ADDRESS;
> -EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ADDRESS;
> +EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ALLOC_ADDRESS;
> +EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ALLOC_ADDRESS;
>
> EFI_MEMORY_TYPE_INFORMATION
> gMemoryTypeInformation[EfiMaxMemoryType + 1] = {
>{ EfiReservedMemoryType,
Re: [edk2] [PATCH V2 0/7] Remove PcdPeiCoreMaxXXX PCDs
For patch 1,3,4,7, Reviewed-by: Jian J Wang > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star > Zeng > Sent: Tuesday, December 18, 2018 2:08 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: [edk2] [PATCH V2 0/7] Remove PcdPeiCoreMaxXXX PCDs > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405 > > V2: > 1. Pick up some RB tags. > 2. Handle the great comment from Jian for patch 1/7 at > https://lists.01.org/pipermail/edk2-devel/2018-December/034121.html. > > Repo: g...@github.com:lzeng14/edk2.git > Branch: RemovePcdPeiCoreMaxXXX_V2 > > Test done: > Make sure the Private->CurrentFvFileHandles content could be same. > > V1: > Repo: g...@github.com:lzeng14/edk2.git > Branch: RemovePcdPeiCoreMaxXXX > > Background as below. > > Problem: > As static configuration from the PCDs, the binary PeiCore (for example > in FSP binary with dispatch mode) could not predict how many FVs, > Files or PPIs for different platforms. > > Burden: > Platform developers need configure the PCDs accordingly for different > platforms. > > To solve the problem and remove the burden, we can update code to > remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv > and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV, > File and PPI management. > > Test done: > Build code with VS2012, VS2015 and GCC49. > Boot Nt32, Ovmf (including 32, 3264 and 64 with no SMM) to UEFI SHELL. > Boot some internal platforms (including a platform with dispatch mode > FSP binary) to UEFI SHELL and Windows. > > More test will be welcome and appreciated. :) > > Patches to update edk2-platforms Repo will be sent out separately. > > Star Zeng (7): > MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxPeimPerFv > SecurityPkg Tcg(2)Pei: Remove the using of PcdPeiCoreMaxFvSupported > MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxFvSupported > MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxPpiSupported > OvmfPkg: Remove PcdPeiCoreMaxXXX PCDs' statement > Vlv2TbltDevicePkg: Remove PcdPeiCoreMaxXXX PCDs' statement > MdeModulePkg: Remove PcdPeiCoreMaxXXX PCDs > > MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 181 +++-- > MdeModulePkg/Core/Pei/FwVol/FwVol.c | 67 - > MdeModulePkg/Core/Pei/PeiMain.h | 96 +-- > MdeModulePkg/Core/Pei/PeiMain.inf | 3 - > MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 94 +++ > MdeModulePkg/Core/Pei/Ppi/Ppi.c | 355 > ++ > MdeModulePkg/MdeModulePkg.dec | 13 - > MdeModulePkg/MdeModulePkg.uni | 12 - > OvmfPkg/OvmfPkgIa32.dsc | 2 - > OvmfPkg/OvmfPkgIa32X64.dsc| 2 - > OvmfPkg/OvmfPkgX64.dsc| 2 - > SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | 59 +++-- > SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf | 1 - > SecurityPkg/Tcg/TcgPei/TcgPei.c | 59 +++-- > SecurityPkg/Tcg/TcgPei/TcgPei.inf | 1 - > Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 2 - > Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 2 - > Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 2 - > 18 files changed, 539 insertions(+), 414 deletions(-) > > -- > 2.7.0.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/7] MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxPpiSupported
Star,
Please consider to extract the code to expand PPI buffer as a function or macro.
I found it repeated 3 times in this patch.
Regards,
Jian
> -Original Message-
> From: Zeng, Star
> Sent: Friday, December 14, 2018 6:29 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A ; Gao, Liming ; Ni,
> Ruiyu ; Kinney, Michael D ;
> Desimone, Nathaniel L ; Chiu, Chasel
>
> Subject: [PATCH 4/7] MdeModulePkg PeiCore: Remove the using of
> PcdPeiCoreMaxPpiSupported
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405
>
> Background as below.
>
> Problem:
> As static configuration from the PCDs, the binary PeiCore (for example
> in FSP binary with dispatch mode) could not predict how many FVs,
> Files or PPIs for different platforms.
>
> Burden:
> Platform developers need configure the PCDs accordingly for different
> platforms.
>
> To solve the problem and remove the burden, we can update code to
> remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
> and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
> File and PPI management.
>
> This patch removes the using of PcdPeiCoreMaxPpiSupported in PeiCore.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Liming Gao
> Cc: Ruiyu Ni
> Cc: Michael D Kinney
> Cc: Nate DeSimone
> Cc: Chasel Chiu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 8 +-
> MdeModulePkg/Core/Pei/PeiMain.h | 59 +++--
> MdeModulePkg/Core/Pei/PeiMain.inf | 1 -
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 30 ++-
> MdeModulePkg/Core/Pei/Ppi/Ppi.c | 355
> ++
> 5 files changed, 254 insertions(+), 199 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> index 71440bab9488..55a300adbdb8 100644
> --- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> +++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> @@ -1062,7 +1062,7 @@ PeiDispatcher (
>// Process the Notify list and dispatch any notifies for
>// newly installed PPIs.
>//
> - ProcessNotifyList (Private);
> + ProcessDispatchNotifyList (Private);
> }
>}
> }
> @@ -1209,10 +1209,10 @@ PeiDispatcher (
> // Process the Notify list and dispatch any notifies for
> // newly installed PPIs.
> //
> -ProcessNotifyList (Private);
> +ProcessDispatchNotifyList (Private);
>
> //
> -// Recheck SwitchStackSignal after ProcessNotifyList()
> +// Recheck SwitchStackSignal after ProcessDispatchNotifyList()
> // in case PeiInstallPeiMemory() is done in a callback with
> // EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH.
> //
> @@ -1253,7 +1253,7 @@ PeiDispatcher (
>// Process the Notify list and dispatch any notifies for
>// newly installed PPIs.
>//
> - ProcessNotifyList (Private);
> + ProcessDispatchNotifyList (Private);
> }
>}
> }
> diff --git a/MdeModulePkg/Core/Pei/PeiMain.h
> b/MdeModulePkg/Core/Pei/PeiMain.h
> index b248118087ad..c6c932c3e233 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain.h
> +++ b/MdeModulePkg/Core/Pei/PeiMain.h
> @@ -66,37 +66,60 @@ typedef union {
> } PEI_PPI_LIST_POINTERS;
>
> ///
> -/// PPI database structure which contains two link: PpiList and NotifyList.
> PpiList
> -/// is in head of PpiListPtrs array and notify is in end of PpiListPtrs.
> +/// Number of PEI_PPI_LIST_POINTERS to grow by each time we run out of
> room
> ///
> +#define PPI_GROWTH_STEP 64
> +#define CALLBACK_NOTIFY_GROWTH_STEP 32
> +#define DISPATCH_NOTIFY_GROWTH_STEP 8
> +
> typedef struct {
> + UINTN CurrentCount;
> + UINTN MaxCount;
> + UINTN LastDispatchedCount;
>///
> - /// index of end of PpiList link list.
> + /// MaxCount number of entries.
>///
> - INTNPpiListEnd;
> + PEI_PPI_LIST_POINTERS *PpiPtrs;
> +} PEI_PPI_LIST;
> +
> +typedef struct {
> + UINTN CurrentCount;
> + UINTN MaxCount;
>///
> - /// index of end of notify link list.
> + /// MaxCount number of entries.
>///
> - INTNNotifyListEnd;
> + PEI_PPI_LIST_POINTERS *NotifyPtrs;
> +} PEI_CALLBACK_NOTIFY_LIST;
> +
> +typedef struct {
>
Re: [edk2] [PATCH 3/7] MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxFvSupported
Reviewed-by: Jian J Wang
> -Original Message-
> From: Zeng, Star
> Sent: Friday, December 14, 2018 6:29 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A ; Gao, Liming ; Ni,
> Ruiyu ; Kinney, Michael D ;
> Desimone, Nathaniel L ; Chiu, Chasel
>
> Subject: [PATCH 3/7] MdeModulePkg PeiCore: Remove the using of
> PcdPeiCoreMaxFvSupported
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405
>
> Background as below.
>
> Problem:
> As static configuration from the PCDs, the binary PeiCore (for example
> in FSP binary with dispatch mode) could not predict how many FVs,
> Files or PPIs for different platforms.
>
> Burden:
> Platform developers need configure the PCDs accordingly for different
> platforms.
>
> To solve the problem and remove the burden, we can update PeiCore to
> remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
> and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
> File and PPI management.
>
> This patch removes the using of PcdPeiCoreMaxFvSupported in PeiCore.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Liming Gao
> Cc: Ruiyu Ni
> Cc: Michael D Kinney
> Cc: Nate DeSimone
> Cc: Chasel Chiu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Core/Pei/FwVol/FwVol.c | 67
> ++---
> MdeModulePkg/Core/Pei/PeiMain.h | 15 +++-
> MdeModulePkg/Core/Pei/PeiMain.inf | 1 -
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 16
> 4 files changed, 75 insertions(+), 24 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> index 5629c9a1ce20..0a67b96bf1e3 100644
> --- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> +++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
> @@ -503,6 +503,10 @@ PeiInitializeFv (
> );
>ASSERT_EFI_ERROR (Status);
>
> + PrivateData->Fv = AllocateZeroPool (sizeof (PEI_CORE_FV_HANDLE) *
> FV_GROWTH_STEP);
> + ASSERT (PrivateData->Fv != NULL);
> + PrivateData->MaxFvCount = FV_GROWTH_STEP;
> +
>//
>// Update internal PEI_CORE_FV array.
>//
> @@ -560,6 +564,7 @@ FirmwareVolmeInfoPpiNotifyCallback (
>VOID *DepexData;
>BOOLEAN IsFvInfo2;
>UINTN CurFvCount;
> + VOID *TempPtr;
>
>Status = EFI_SUCCESS;
>PrivateData = PEI_CORE_INSTANCE_FROM_PS_THIS (PeiServices);
> @@ -626,10 +631,21 @@ FirmwareVolmeInfoPpiNotifyCallback (
>}
> }
>
> -if (PrivateData->FvCount >= PcdGet32 (PcdPeiCoreMaxFvSupported)) {
> - DEBUG ((EFI_D_ERROR, "The number of Fv Images (%d) exceed the max
> supported FVs (%d) in Pei", PrivateData->FvCount + 1, PcdGet32
> (PcdPeiCoreMaxFvSupported)));
> - DEBUG ((EFI_D_ERROR, "PcdPeiCoreMaxFvSupported value need be
> reconfigurated in DSC"));
> - ASSERT (FALSE);
> +if (PrivateData->FvCount >= PrivateData->MaxFvCount) {
> + //
> + // Run out of room, grow the buffer.
> + //
> + TempPtr = AllocateZeroPool (
> + sizeof (PEI_CORE_FV_HANDLE) * (PrivateData->MaxFvCount +
> FV_GROWTH_STEP)
> + );
> + ASSERT (TempPtr != NULL);
> + CopyMem (
> +TempPtr,
> +PrivateData->Fv,
> +sizeof (PEI_CORE_FV_HANDLE) * PrivateData->MaxFvCount
> +);
> + PrivateData->Fv = TempPtr;
> + PrivateData->MaxFvCount = PrivateData->MaxFvCount +
> FV_GROWTH_STEP;
> }
>
> //
> @@ -2157,7 +2173,6 @@ FindNextCoreFvHandle (
> }
>}
>
> - ASSERT (Private->FvCount <= PcdGet32 (PcdPeiCoreMaxFvSupported));
>if (Instance >= Private->FvCount) {
> return NULL;
>}
> @@ -2205,7 +2220,7 @@ PeiReinitializeFv (
>//
>// Fixup all FvPpi pointers for the implementation in flash to permanent
> memory.
>//
> - for (Index = 0; Index < PcdGet32 (PcdPeiCoreMaxFvSupported); Index ++) {
> + for (Index = 0; Index < PrivateData->FvCount; Index ++) {
> if (PrivateData->Fv[Index].FvPpi == OldFfsFvPpi) {
>PrivateData->Fv[Index].FvPpi = &mPeiFfs2FwVol.Fv;
> }
> @@ -2233,7 +2248,7 @@ PeiReinitializeFv (
>//
>// Fixup all FvPpi pointers for the implementation in flash to permanent
> memory.
>//
> - for (Index = 0; Index < PcdGet32 (PcdPeiCoreMaxFvSupported); Index ++) {
> + for (Index = 0; Index < PrivateData->
Re: [edk2] [PATCH 1/7] MdeModulePkg PeiCore: Remove the using of PcdPeiCoreMaxPeimPerFv
Star,
Just one place which might need refine. Please see it below.
Regards,
Jian
> -Original Message-
> From: Zeng, Star
> Sent: Friday, December 14, 2018 6:29 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A ; Gao, Liming ; Ni,
> Ruiyu ; Kinney, Michael D ;
> Desimone, Nathaniel L ; Chiu, Chasel
>
> Subject: [PATCH 1/7] MdeModulePkg PeiCore: Remove the using of
> PcdPeiCoreMaxPeimPerFv
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405
>
> Background as below.
>
> Problem:
> As static configuration from the PCDs, the binary PeiCore (for example
> in FSP binary with dispatch mode) could not predict how many FVs,
> Files or PPIs for different platforms.
>
> Burden:
> Platform developers need configure the PCDs accordingly for different
> platforms.
>
> To solve the problem and remove the burden, we can update code to
> remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
> and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
> File and PPI management.
>
> This patch removes the using of PcdPeiCoreMaxPeimPerFv in PeiCore.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Liming Gao
> Cc: Ruiyu Ni
> Cc: Michael D Kinney
> Cc: Nate DeSimone
> Cc: Chasel Chiu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 199
> --
> MdeModulePkg/Core/Pei/PeiMain.h | 17 ++-
> MdeModulePkg/Core/Pei/PeiMain.inf | 1 -
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 48 +++
> 4 files changed, 157 insertions(+), 108 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> index f6bb35a5fe8d..71440bab9488 100644
> --- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> +++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> @@ -41,7 +41,8 @@ DiscoverPeimsAndOrderWithApriori (
>UINTN PeimCount;
>EFI_GUID*Guid;
>EFI_PEI_FILE_HANDLE *TempFileHandles;
> - EFI_GUID*FileGuid;
> + EFI_GUID*TempFileGuid;
> + UINTN TempPeimCount;
>EFI_PEI_FIRMWARE_VOLUME_PPI *FvPpi;
>EFI_FV_FILE_INFOFileInfo;
>
> @@ -51,38 +52,106 @@ DiscoverPeimsAndOrderWithApriori (
>// Walk the FV and find all the PEIMs and the Apriori file.
>//
>AprioriFileHandle = NULL;
> - Private->CurrentFvFileHandles[0] = NULL;
> + Private->CurrentFvFileHandles = NULL;
>Guid = NULL;
> - FileHandle = NULL;
> - TempFileHandles = Private->FileHandles;
> - FileGuid= Private->FileGuid;
>
>//
> - // If the current Fv has been scanned, directly get its cachable record.
> + // If the current Fv has been scanned, directly get its cached records.
>//
> - if (Private->Fv[Private->CurrentPeimFvCount].ScanFv) {
> -CopyMem (Private->CurrentFvFileHandles, Private->Fv[Private-
> >CurrentPeimFvCount].FvFileHandles, sizeof (EFI_PEI_FILE_HANDLE) * PcdGet32
> (PcdPeiCoreMaxPeimPerFv));
> + if (CoreFileHandle->ScanFv) {
> +Private->CurrentFvFileHandles = CoreFileHandle->FvFileHandles;
> return;
>}
>
> + if (Private->TempPeimCount == 0) {
> +//
> +// Initialize the temp buffers.
> +//
> +Private->TempPeimCount = 32;
> +Private->TempFileHandles = AllocatePool (sizeof (EFI_PEI_FILE_HANDLE) *
> 32);
> +ASSERT (Private->TempFileHandles != NULL);
> +Private->TempFileGuid= AllocatePool (sizeof (EFI_GUID) * 32);
> +ASSERT (Private->TempFileGuid != NULL);
> + }
> + TempFileHandles = Private->TempFileHandles;
> + TempFileGuid= Private->TempFileGuid;
> +
>//
> - // Go ahead to scan this Fv, and cache FileHandles within it.
> + // Go ahead to scan this Fv, get PeimCount and cache FileHandles within it
> to
> TempFileHandles.
>//
> - Status = EFI_NOT_FOUND;
> - for (PeimCount = 0; PeimCount <= PcdGet32 (PcdPeiCoreMaxPeimPerFv);
> PeimCount++) {
> + PeimCount = 0;
> + FileHandle = NULL;
> + TempPeimCount = 0;
> + do {
> Status = FvPpi->FindFileByType (FvPpi,
> PEI_CORE_INTERNAL_FFS_FILE_DISPATCH_TYPE, CoreFileHandle->FvHandle,
> &FileHandle);
> -if (Status != EFI_SUCCESS || PeimCount == PcdGet32
> (PcdPeiCoreMaxPeimPerFv)) {
> - break;
> +if (!EFI_ERROR (Status)) {
> + if (TempPeimCount < Private->
Re: [edk2] [PATCH 3/3] MdeModulePkg/NonDiscoverablePciDeviceDxe: add missing validation
Push @ c8c3c53669bea887ecc093167d64d1fbe63c213f
Regards,
Jian
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Saturday, December 15, 2018 9:37 PM
> To: Ard Biesheuvel
> Cc: Vladimir Olovyannikov ; Zeng, Star
> ; edk2-devel@lists.01.org; Ni, Ruiyu
> ; Wang, Jian J ; Wu, Hao A
>
> Subject: Re: [PATCH 3/3] MdeModulePkg/NonDiscoverablePciDeviceDxe: add
> missing validation
>
> Jian, Hao,
>
> I guess Ray and Star are no longer maintainers of this package.
> This patch never got pushed - could you have a look please?
>
> Regards,
>
> Leif
>
> On Fri, Sep 07, 2018 at 12:36:32PM +0200, Ard Biesheuvel wrote:
> > On 6 September 2018 at 20:55, Vladimir Olovyannikov
> > wrote:
> > > UEFI SCT crashed and failed in NonDiscoverablePciDeviceDxe becase
> > > required checks were not performed. Perform parameters validation in
> > > NonDiscoverablePciDeviceDxe.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Vladimir Olovyannikov
>
> >
> > Reviewed-by: Ard Biesheuvel
> >
> > > ---
> > > .../NonDiscoverablePciDeviceIo.c | 50 ++-
> > > 1 file changed, 49 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> > > index 0e42ae4bf6ec..07118d59fd68 100644
> > > ---
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> > > +++
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> > > @@ -52,6 +52,10 @@ GetBarResource (
> > >
> > >BarIndex -= (UINT8)Dev->BarOffset;
> > >
> > > + if (BarIndex >= Dev->BarCount) {
> > > +return EFI_UNSUPPORTED;
> > > + }
> > > +
> > >for (Desc = Dev->Device->Resources;
> > > Desc->Desc != ACPI_END_TAG_DESCRIPTOR;
> > > Desc = (VOID *)((UINT8 *)Desc + Desc->Len + 3)) {
> > > @@ -597,6 +601,19 @@ CoherentPciIoMap (
> > >EFI_STATUSStatus;
> > >NON_DISCOVERABLE_PCI_DEVICE_MAP_INFO *MapInfo;
> > >
> > > + if (Operation != EfiPciIoOperationBusMasterRead &&
> > > + Operation != EfiPciIoOperationBusMasterWrite &&
> > > + Operation != EfiPciIoOperationBusMasterCommonBuffer) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > > + if (HostAddress == NULL ||
> > > + NumberOfBytes == NULL ||
> > > + DeviceAddress == NULL ||
> > > + Mapping == NULL) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > >//
> > >// If HostAddress exceeds 4 GB, and this device does not support 64-bit
> DMA
> > >// addressing, we need to allocate a bounce buffer and copy over the
> > > data.
> > > @@ -720,6 +737,11 @@ CoherentPciIoAllocateBuffer (
> > > return EFI_UNSUPPORTED;
> > >}
> > >
> > > + if ((MemoryType != EfiBootServicesData) &&
> > > + (MemoryType != EfiRuntimeServicesData)) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > >//
> > >// Allocate below 4 GB if the dual address cycle attribute has not
> > >// been set. If the system has no memory available below 4 GB, there
> > > @@ -877,6 +899,10 @@ NonCoherentPciIoAllocateBuffer (
> > >NON_DISCOVERABLE_DEVICE_UNCACHED_ALLOCATION *Alloc;
> > >VOID*AllocAddress;
> > >
> > > + if (HostAddress == NULL) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > >Dev = NON_DISCOVERABLE_PCI_DEVICE_FROM_PCI_IO(This);
> > >
> > >Status = CoherentPciIoAllocateBuffer (This, Type, MemoryType, Pages,
> > > @@ -995,6 +1021,19 @@ NonCoherentPciIoMap (
> > >EFI_GCD_MEMORY_SPACE_DESCRIPTOR GcdDescriptor;
> > >BOOLEAN Bounce;
> > >
> > > + if (HostAddress == NULL ||
> > > + NumberOfBytes == NULL ||
> > > + DeviceAddress == NULL ||
> > > + Mapping == NULL) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > > + if (O
Re: [edk2] [PATCH 3/3] MdeModulePkg/NonDiscoverablePciDeviceDxe: add missing validation
Leif,
Thanks for reminding. I'll take care of it.
Regards,
Jian
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Saturday, December 15, 2018 9:37 PM
> To: Ard Biesheuvel
> Cc: Vladimir Olovyannikov ; Zeng, Star
> ; edk2-devel@lists.01.org; Ni, Ruiyu
> ; Wang, Jian J ; Wu, Hao A
>
> Subject: Re: [PATCH 3/3] MdeModulePkg/NonDiscoverablePciDeviceDxe: add
> missing validation
>
> Jian, Hao,
>
> I guess Ray and Star are no longer maintainers of this package.
> This patch never got pushed - could you have a look please?
>
> Regards,
>
> Leif
>
> On Fri, Sep 07, 2018 at 12:36:32PM +0200, Ard Biesheuvel wrote:
> > On 6 September 2018 at 20:55, Vladimir Olovyannikov
> > wrote:
> > > UEFI SCT crashed and failed in NonDiscoverablePciDeviceDxe becase
> > > required checks were not performed. Perform parameters validation in
> > > NonDiscoverablePciDeviceDxe.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Vladimir Olovyannikov
>
> >
> > Reviewed-by: Ard Biesheuvel
> >
> > > ---
> > > .../NonDiscoverablePciDeviceIo.c | 50 ++-
> > > 1 file changed, 49 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> > > index 0e42ae4bf6ec..07118d59fd68 100644
> > > ---
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> > > +++
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciD
> eviceIo.c
> > > @@ -52,6 +52,10 @@ GetBarResource (
> > >
> > >BarIndex -= (UINT8)Dev->BarOffset;
> > >
> > > + if (BarIndex >= Dev->BarCount) {
> > > +return EFI_UNSUPPORTED;
> > > + }
> > > +
> > >for (Desc = Dev->Device->Resources;
> > > Desc->Desc != ACPI_END_TAG_DESCRIPTOR;
> > > Desc = (VOID *)((UINT8 *)Desc + Desc->Len + 3)) {
> > > @@ -597,6 +601,19 @@ CoherentPciIoMap (
> > >EFI_STATUSStatus;
> > >NON_DISCOVERABLE_PCI_DEVICE_MAP_INFO *MapInfo;
> > >
> > > + if (Operation != EfiPciIoOperationBusMasterRead &&
> > > + Operation != EfiPciIoOperationBusMasterWrite &&
> > > + Operation != EfiPciIoOperationBusMasterCommonBuffer) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > > + if (HostAddress == NULL ||
> > > + NumberOfBytes == NULL ||
> > > + DeviceAddress == NULL ||
> > > + Mapping == NULL) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > >//
> > >// If HostAddress exceeds 4 GB, and this device does not support 64-bit
> DMA
> > >// addressing, we need to allocate a bounce buffer and copy over the
> > > data.
> > > @@ -720,6 +737,11 @@ CoherentPciIoAllocateBuffer (
> > > return EFI_UNSUPPORTED;
> > >}
> > >
> > > + if ((MemoryType != EfiBootServicesData) &&
> > > + (MemoryType != EfiRuntimeServicesData)) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > >//
> > >// Allocate below 4 GB if the dual address cycle attribute has not
> > >// been set. If the system has no memory available below 4 GB, there
> > > @@ -877,6 +899,10 @@ NonCoherentPciIoAllocateBuffer (
> > >NON_DISCOVERABLE_DEVICE_UNCACHED_ALLOCATION *Alloc;
> > >VOID*AllocAddress;
> > >
> > > + if (HostAddress == NULL) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > >Dev = NON_DISCOVERABLE_PCI_DEVICE_FROM_PCI_IO(This);
> > >
> > >Status = CoherentPciIoAllocateBuffer (This, Type, MemoryType, Pages,
> > > @@ -995,6 +1021,19 @@ NonCoherentPciIoMap (
> > >EFI_GCD_MEMORY_SPACE_DESCRIPTOR GcdDescriptor;
> > >BOOLEAN Bounce;
> > >
> > > + if (HostAddress == NULL ||
> > > + NumberOfBytes == NULL ||
> > > + DeviceAddress == NULL ||
> > > + Mapping == NULL) {
> > > +return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > > +
Re: [edk2] [PATCH] Maintainers.txt: Change package maintainer and reviewer of CryptoPkg.
Reviewed-by: Jian J Wang > -Original Message- > From: Ye, Ting > Sent: Thursday, December 13, 2018 3:41 PM > To: edk2-devel@lists.01.org > Cc: Wei, Gang ; Wang, Jian J ; > Ye, Ting > Subject: [PATCH] Maintainers.txt: Change package maintainer and reviewer of > CryptoPkg. > > Cc: Gang Wei > Cc: Jian Wang > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ting Ye > --- > Maintainers.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 001d8ba010..d5cb305da9 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -102,8 +102,9 @@ S: Maintained > > CryptoPkg > W: https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg > -M: Qin Long > M: Ting Ye > +R: Gang Wei > +R: Jian Wang > > DynamicTablesPkg > W: https://github.com/tianocore/tianocore.github.io/wiki/DynamicTablesPkg > -- > 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/PciBus: Fix system hang when no PCI Option ROM exists
Reviewed-by: Jian J Wang
> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, December 12, 2018 11:10 PM
> To: edk2-devel@lists.01.org
> Cc: Chiu, Chasel ; Wu, Hao A ;
> Wang, Jian J
> Subject: [PATCH] MdeModulePkg/PciBus: Fix system hang when no PCI Option
> ROM exists
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1394
>
> When there is no PCI option ROM exists, today's logic still creates
> virtual BAR for option ROM using Length = 0, Alignment = (-1).
> It causes the final MEM32 alignment requirement is as big as
> 0x_.
>
> The patch fixes this issue by only creating virtual BAR for option
> ROM when there is PCI option ROM.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni
> Cc: Chiu Chasel
> Cc: Hao A Wu
> Cc: Jian J Wang
> ---
> MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> index 7255bcfbbc..ee5c77147e 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> @@ -515,10 +515,12 @@ PciHostBridgeResourceAllocator (
>// All devices' Option ROM share the same MEM32 resource.
>//
>MaxOptionRomSize = GetMaxOptionRomSize (RootBridgeDev);
> - RootBridgeDev->PciBar[0].BarType = PciBarTypeOpRom;
> - RootBridgeDev->PciBar[0].Length= MaxOptionRomSize;
> - RootBridgeDev->PciBar[0].Alignment = MaxOptionRomSize - 1;
> - GetResourceFromDevice (RootBridgeDev, IoBridge, Mem32Bridge,
> PMem32Bridge, Mem64Bridge, PMem64Bridge);
> + if (MaxOptionRomSize != 0) {
> +RootBridgeDev->PciBar[0].BarType = PciBarTypeOpRom;
> +RootBridgeDev->PciBar[0].Length= MaxOptionRomSize;
> +RootBridgeDev->PciBar[0].Alignment = MaxOptionRomSize - 1;
> +GetResourceFromDevice (RootBridgeDev, IoBridge, Mem32Bridge,
> PMem32Bridge, Mem64Bridge, PMem64Bridge);
> + }
>
>//
>// Create resourcemap by going through all the devices subject to this
> root
> bridge
> --
> 2.16.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC PATCH 2/7] MdeModulePkg/Dxe/Gcd: disregard memory above MAX_ALLOC_ADDRESS
Reviewed-by: Jian J Wang
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, December 07, 2018 7:23 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael D
> ; Gao, Liming ; Wang,
> Jian J ; Wu, Hao A ; Leif
> Lindholm ; Laszlo Ersek ; Eric
> Auger ; Andrew Jones ;
> Philippe Mathieu-Daude
> Subject: [RFC PATCH 2/7] MdeModulePkg/Dxe/Gcd: disregard memory above
> MAX_ALLOC_ADDRESS
>
> Update the GCD memory map initialization code so it disregards
> memory that is not addressable by the CPU at boot time. This
> only affects the first memory descriptor that is added, other
> memory descriptors are permitted that describe memory ranges
> that may be accessible to the CPU itself only when executing
> under the OS.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> index a76d2db73c46..504e14a74e1d 100644
> --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> @@ -2284,7 +2284,7 @@ CoreInitializeMemoryServices (
> // region that is big enough to initialize the DXE core. Always skip
> the PHIT
> Resource HOB.
> // The max address must be within the physically addressible range for
> the
> processor.
> //
> -HighAddress = MAX_ADDRESS;
> +HighAddress = MAX_ALLOC_ADDRESS;
> for (Hob.Raw = *HobStart; !END_OF_HOB_LIST(Hob); Hob.Raw =
> GET_NEXT_HOB(Hob)) {
>//
>// Skip the Resource Descriptor HOB that contains the PHIT
> @@ -2300,7 +2300,7 @@ CoreInitializeMemoryServices (
>}
>
>//
> - // Skip Resource Descriptor HOBs that do not describe tested system
> memory below MAX_ADDRESS
> + // Skip Resource Descriptor HOBs that do not describe tested system
> memory below MAX_ALLOC_ADDRESS
>//
>ResourceHob = Hob.ResourceDescriptor;
>if (ResourceHob->ResourceType != EFI_RESOURCE_SYSTEM_MEMORY) {
> @@ -2309,14 +2309,14 @@ CoreInitializeMemoryServices (
>if ((ResourceHob->ResourceAttribute & MEMORY_ATTRIBUTE_MASK) !=
> TESTED_MEMORY_ATTRIBUTES) {
> continue;
>}
> - if ((ResourceHob->PhysicalStart + ResourceHob->ResourceLength) >
> (EFI_PHYSICAL_ADDRESS)MAX_ADDRESS) {
> + if ((ResourceHob->PhysicalStart + ResourceHob->ResourceLength) >
> (EFI_PHYSICAL_ADDRESS)MAX_ALLOC_ADDRESS) {
> continue;
>}
>
>//
>// Skip Resource Descriptor HOBs that are below a previously found
> Resource Descriptor HOB
>//
> - if (HighAddress != (EFI_PHYSICAL_ADDRESS)MAX_ADDRESS &&
> ResourceHob->PhysicalStart <= HighAddress) {
> + if (HighAddress != (EFI_PHYSICAL_ADDRESS)MAX_ALLOC_ADDRESS &&
> ResourceHob->PhysicalStart <= HighAddress) {
> continue;
>}
>
> --
> 2.19.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account
Hi Ard,
I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough
test for them (IA32/X64 for my concern).
In addition, do you think it's safer to replace MAX_ADDRESS with
MAX_ALLOC_ADDRESS
in MemoryAllocationLib like following situation?
(MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c)
VOID *
InternalAllocateCopyPool (
IN EFI_MEMORY_TYPE PoolType,
IN UINTNAllocationSize,
IN CONST VOID *Buffer
)
{
VOID *Memory;
ASSERT (Buffer != NULL);
ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1));
...
}
Regards,
Jian
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, December 07, 2018 7:23 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Kinney, Michael D
> ; Gao, Liming ; Wang,
> Jian J ; Wu, Hao A ; Leif
> Lindholm ; Laszlo Ersek ; Eric
> Auger ; Andrew Jones ;
> Philippe Mathieu-Daude
> Subject: [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take
> MAX_ALLOC_ADDRESS into account
>
> Take MAX_ALLOC_ADDRESS into account in the implementation of the
> page allocation routines, so that they will only return memory
> that is addressable by the CPU at boot time, even if more memory
> is available in the GCD memory map.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> MdeModulePkg/Core/Dxe/Mem/Page.c | 52 ++--
> 1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c
> b/MdeModulePkg/Core/Dxe/Mem/Page.c
> index 961c5b833546..5ad8e1171ef7 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/Page.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
> @@ -52,26 +52,26 @@ LIST_ENTRY mFreeMemoryMapEntryList =
> INITIALIZE_LIST_HEAD_VARIABLE (mFreeMemor
> BOOLEAN mMemoryTypeInformationInitialized = FALSE;
>
> EFI_MEMORY_TYPE_STATISTICS mMemoryTypeStatistics[EfiMaxMemoryType +
> 1] = {
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiReservedMemoryType
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesData
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiConventionalMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiUnusableMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIReclaimMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIMemoryNVS
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIO
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIOPortSpace
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiPalCode
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiPersistentMemory
> - { 0, MAX_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE } //
> EfiMaxMemoryType
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiReservedMemoryType
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiLoaderData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiBootServicesData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesCode
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiRuntimeServicesData
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiConventionalMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiUnusableMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIReclaimMemory
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, //
> EfiACPIMemoryNVS
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIO
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, //
> EfiMemoryMappedIOPortSpace
> + { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, //
> EfiPalCode
> + { 0, MAX_ALLOC_AD
Re: [edk2] [RFC] Proposal to add edk2-apps repository
Hi Krishna and Mike, There might be applications which don't depend on ShellPkg or StdLib. I think an extra repo is necessary. For example, the MicroPythonPkg (currently in staging branch) doesn't depend on ShellPkg and StdLib. Maybe we can consider to put it in edk2-apps but not edk2-libc. Regards, Jian > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > krishnaLee > Sent: Friday, November 30, 2018 9:45 AM > To: edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository > > Kinney, > I always think there may be two kinds of apps: > 1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,...they > usually execute under uefi_shell),I would call them "uefi_shell_application"; > 2,some apps have no dependency on uefi_shell(such as apps in > MdeModulePkg/Application),I would call them "standard_uefi_application". > > The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used > by > uefi_shell_application,I think they can all move to ShellPkg,no need to create > new package ? > > > Thanks, > krishna. > > At 2018-11-30 08:46:58, "Kinney, Michael D" > wrote: > >Leif, > > > >I did consider the edk2-libc name. The port of Python 2.7 > >is in the AppPkg as well and it uses libc. > > > >So the content of this new package is a combination of libc > >And apps that use libc. > > > >I am definitely open to alternate names. 2 options so far: > > > >* edk2-apps > >* edk2-libc > > > >Thanks, > > > >Mike > > > >> -Original Message- > >> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > >> Sent: Thursday, November 29, 2018 2:41 PM > >> To: Kinney, Michael D > >> Cc: edk2-devel@lists.01.org > >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps > >> repository > >> > >> On Thu, Nov 29, 2018 at 05:58:08PM +, Kinney, Michael > >> D wrote: > >> > Hello, > >> > > >> > I would like to propose the creation of a new > >> > repository called edk2-apps. This repository > >> > would initially be used to host the following > >> > packages from the edk2 repository: > >> > > >> > * AppPkg > >> > * StdLib > >> > * StdLibPrivateInternalFiles > >> > >> Let me start by saying I 100% back moving these out of the > >> main edk2 > >> repository. > >> > >> > These 3 packages provide support for the libc along > >> > with applications that depend on libc. None of the > >> > other packages in the edk2 repository use these > >> > packages, so these 3 package can be safely moved > >> > without any impacts to platform firmware builds. > >> > Build configurations that do use libc features can > >> > clone the edk2-apps repository and add it to > >> > PACKAGES_PATH. > >> > >> I must confess to never having properly understood the > >> scope of AppPkg > >> to begin with. > >> > >> AppPkg/Applications/Hello does not appear to have any > >> further (real) > >> dependency on libc than > >> MdeModulePkg/Application/HelloWorld/, and . > >> > >> And certainly MdeModulePkg/Applications contain plenty of > >> ... applications. > >> > >> So, if the purpose is simply to provide some examples of > >> application > >> written to libc rather than UEFI - should this be edk2- > >> libc instead? > >> > >> Best Regards, > >> > >> Leif > >> > >> > The history of these 3 packages would be preserved > >> > when importing the content into edk2-apps. After > >> > The import is verified, these 3 packages would be > >> > deleted from the edk2 repository. > >> > > >> > This proposal helps reduce the size of the edk2 > >> > repository and focuses edk2 repository on packages > >> > used to provide UEFI/PI conformant firmware. > >> > > >> > If there are no concerns with this proposal, I will > >> > enter a Tianocore BZs for the two steps. > >> > > >> > Best regards, > >> > > >> > Mike > >> > ___ > >> > edk2-devel mailing list > >> > edk2-devel@lists.01.org > >> > https://lists.01.org/mailman/listinfo/edk2-devel > >___ > >edk2-devel mailing list > >edk2-devel@lists.01.org > >https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainers.txt: Update MdeModulePkg maintainers
Acked-by: Jian J Wang > -Original Message- > From: Zeng, Star > Sent: Wednesday, November 28, 2018 9:19 AM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Wang, Jian J ; > Wu, Hao A > Subject: [PATCH] Maintainers.txt: Update MdeModulePkg maintainers > > As Star has some other focus, change Star from maintainer > to reviewer, Jian will be the first maintainer, and add > Hao as the second maintainer. > > Cc: Jian J Wang > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > Maintainers.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 91a4657adcd1..371268822427 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -170,13 +170,14 @@ M: Rangasai V Chaganty > > > MdeModulePkg > W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg > -M: Star Zeng > M: Jian J Wang > +M: Hao Wu > M: NetworkPkg maintainers >(Universal/Network and related libraries, header files) > R: Ruiyu Ni >(especially for Bus, Universal/Console, Universal/Disk, > Universal/BdsDxe and related libraries, header files) > +R: Star Zeng > > MdePkg > W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg > -- > 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainers.txt: Update maintainer & reviewer info for MdeModulePkg
Thanks a lot to Star for his great works as MdeModulePkg maintainer. Reviewed-by: Jian J Wang > -Original Message- > From: Wu, Hao A > Sent: Tuesday, November 27, 2018 8:37 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A ; Zeng, Star ; > Wang, Jian J > Subject: [PATCH] Maintainers.txt: Update maintainer & reviewer info for > MdeModulePkg > > Update Star as the reviewer of MdeModulePkg; > Add Hao Wu as the 2nd maintainer of MdeModulePkg. > > Cc: Star Zeng > Cc: Jian J Wang > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Hao Wu > --- > Maintainers.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index f3ead7c504..39a2bf261e 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -170,13 +170,14 @@ M: Rangasai V Chaganty > > > MdeModulePkg > W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg > -M: Star Zeng > M: Jian J Wang > +M: Hao Wu > M: NetworkPkg maintainers >(Universal/Network and related libraries, header files) > R: Ruiyu Ni >(especially for Bus, Universal/Console, Universal/Disk, > Universal/BdsDxe and related libraries, header files) > +R: Star Zeng > > MdePkg > W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg > -- > 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/3] Remove S3Lib and RecoveryLib class
Shenglei, I think it would be better to split the patch series in following order: 1. package dec/dsc/uni 2. changes of each module (one patch per module) 3. public header files Regards, Jian > -Original Message- > From: Zhang, Shenglei > Sent: Monday, November 19, 2018 3:30 PM > To: edk2-devel@lists.01.org > Cc: Sun, Zailiang ; Zeng, Star ; > Wang, Jian J ; Ni, Ruiyu ; Gao, > Liming > Subject: [PATCH v2 0/3] Remove S3Lib and RecoveryLib class > > S3Lib and RecoveryLib have been deprecated since 2009. > There is no code using AcpiS3ResumeOs() interface in > S3Lib and PeiRecoverFirmware() interface in RecoveryLib. > So they can be removed from edk2 repo. > https://bugzilla.tianocore.org/show_bug.cgi?id=1299 > > v2:Remove S3Lib.h and RecoveryLib.h. in MdeModulePkg. > > Cc: Zailiang Sun > Cc: Star Zeng > Cc: Jian J Wang > Cc: Ruiyu Ni > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > Shenglei Zhang (3): > IntelFrameworkModulePkg: Remove PeiS3Lib and PeiRecoveryLib > Vlv2TbltDevicePkg: Remove PeiS3Lib in DSC > MdeModulePkg: Remove PeiS3LibNull and PeiRecoveryLibNull > > .../IntelFrameworkModulePkg.dsc | 2 - > .../Library/PeiRecoveryLib/PeiRecoveryLib.c | 50 -- > .../Library/PeiRecoveryLib/PeiRecoveryLib.inf | 50 -- > .../Library/PeiRecoveryLib/PeiRecoveryLib.uni | 23 - > .../Library/PeiS3Lib/PeiS3Lib.c | 51 --- > .../Library/PeiS3Lib/PeiS3Lib.inf | 49 -- > .../Library/PeiS3Lib/PeiS3Lib.uni | 23 - > MdeModulePkg/Core/DxeIplPeim/DxeIpl.h | 2 - > MdeModulePkg/Include/Library/RecoveryLib.h| 35 - > MdeModulePkg/Include/Library/S3Lib.h | 34 - > .../PeiRecoveryLibNull/PeiRecoveryLibNull.c | 34 - > .../PeiRecoveryLibNull/PeiRecoveryLibNull.inf | 39 -- > .../PeiRecoveryLibNull/PeiRecoveryLibNull.uni | 24 - > .../Library/PeiS3LibNull/PeiS3LibNull.c | 35 - > .../Library/PeiS3LibNull/PeiS3LibNull.inf | 40 --- > .../Library/PeiS3LibNull/PeiS3LibNull.uni | 24 - > MdeModulePkg/MdeModulePkg.dec | 10 > MdeModulePkg/MdeModulePkg.dsc | 2 - > Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 3 -- > Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 3 -- > Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 3 -- > 21 files changed, 536 deletions(-) > delete mode 100644 > IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.c > delete mode 100644 > IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.inf > delete mode 100644 > IntelFrameworkModulePkg/Library/PeiRecoveryLib/PeiRecoveryLib.uni > delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.c > delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.inf > delete mode 100644 IntelFrameworkModulePkg/Library/PeiS3Lib/PeiS3Lib.uni > delete mode 100644 MdeModulePkg/Include/Library/RecoveryLib.h > delete mode 100644 MdeModulePkg/Include/Library/S3Lib.h > delete mode 100644 > MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.c > delete mode 100644 > MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.inf > delete mode 100644 > MdeModulePkg/Library/PeiRecoveryLibNull/PeiRecoveryLibNull.uni > delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.c > delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.inf > delete mode 100644 MdeModulePkg/Library/PeiS3LibNull/PeiS3LibNull.uni > > -- > 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg: Remove PcdIdentifyMappingPageTablePtr
Reviewed-by: Jian J Wang > -Original Message- > From: Zhang, Shenglei > Sent: Thursday, November 15, 2018 3:46 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Wang, Jian J ; > Ni, > Ruiyu ; Zhang, Shenglei > Subject: [PATCH] MdeModulePkg: Remove PcdIdentifyMappingPageTablePtr > > PcdIdentifyMappingPageTablePtr is useless and could be > removed. > https://bugzilla.tianocore.org/show_bug.cgi?id=1304 > > Cc: Star Zeng > Cc: Jian J Wang > Cc: Ruiyu Ni > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: shenglei > --- > MdeModulePkg/MdeModulePkg.dec | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > index 428eeeb670..0abacc1a90 100644 > --- a/MdeModulePkg/MdeModulePkg.dec > +++ b/MdeModulePkg/MdeModulePkg.dec > @@ -2007,12 +2007,6 @@ ># @ValidList 0x8001 | 0x0 > > gEfiMdeModulePkgTokenSpaceGuid.PcdS3BootScriptTablePrivateSmmDataPtr| > 0x0|UINT64|0x00030001 > > - ## This dynamic PCD hold an address to point to the memory of page table. > The page table establishes a 1:1 > - # Virtual to Physical mapping according to the processor physical address > bits. > - # @Prompt Identify Mapping Page Table pointer. > - # @ValidList 0x8001 | 0x0 > - > gEfiMdeModulePkgTokenSpaceGuid.PcdIdentifyMappingPageTablePtr|0x0|UIN > T64|0x00030002 > - >## This dynamic PCD holds the information if there is any test key used by > the > platform. ># @Prompt If there is any test key used by the platform. > > gEfiMdeModulePkgTokenSpaceGuid.PcdTestKeyUsed|FALSE|BOOLEAN|0x0003 > 0003 > -- > 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 1/2] MdeModulePkg/Core: fill logic hole in MemoryProtectionCpuArchProtocolNotify
Leif,
Thanks for the comments. I'll push the patch after removing the change log
from the commit log.
Regards,
Jian
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Wednesday, November 07, 2018 3:53 PM
> To: Wang, Jian J
> Cc: edk2-devel@lists.01.org; Zeng, Star ; Yao, Jiewen
> ; Ni, Ruiyu
> Subject: Re: [PATCH v3 1/2] MdeModulePkg/Core: fill logic hole in
> MemoryProtectionCpuArchProtocolNotify
>
>
> On Wed, Nov 07, 2018 at 03:12:47PM +0800, Jian J Wang wrote:
> > > v3: fixed one more memory leak in the same function and updated
> > > commit message accordingly.
>
> No objection to the content, but comments not intended to be committed
> should go in the cover letter or below the ---.
>
> A changelog between revisions is best kept in the cover letter,
> including all changes in reverse chronological order, like:
>
> Changes since v2:
> - ...
>
> Changes since v1:
> - ...
>
> I expect whoever pushes the patches will edit the history out of the
> commit message, but putting it in the cover-letter means less work for
> them.
>
> (I won't give a reviewed-by since I have only been commenting on
> style, not functionality.)
>
> /
> Leif
>
> > At the end of of MemoryProtectionCpuArchProtocolNotify there's cleanup
> > code to free resource. But at line 978, 994, 1005 the function returns
> > directly. This patch use "goto" to replace "return" to make sure the
> > resource is freed before exit.
> >
> > 1029: CoreCloseEvent (Event);
> > 1030: return;
> >
> > There's another memory leak after calling gBS->LocateHandleBuffer() in
> > the same function:
> >
> > Status = gBS->LocateHandleBuffer (
> > ByProtocol,
> > &gEfiLoadedImageProtocolGuid,
> > NULL,
> > &NoHandles,
> > &HandleBuffer
> > );
> >
> > HandleBuffer is allocated in above call but never freed. This patch
> > will also add code to free it.
> >
> > Cc: Star Zeng
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Cc: Leif Lindholm
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > index 6298b67db1..8a93c5362a 100644
> > --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > @@ -975,7 +975,7 @@ MemoryProtectionCpuArchProtocolNotify (
> >DEBUG ((DEBUG_INFO, "MemoryProtectionCpuArchProtocolNotify:\n"));
> >Status = CoreLocateProtocol (&gEfiCpuArchProtocolGuid, NULL, (VOID
> **)&gCpu);
> >if (EFI_ERROR (Status)) {
> > -return;
> > +goto Done;
> >}
> >
> >//
> > @@ -991,7 +991,7 @@ MemoryProtectionCpuArchProtocolNotify (
> >HeapGuardCpuArchProtocolNotify ();
> >
> >if (mImageProtectionPolicy == 0) {
> > -return;
> > +goto Done;
> >}
> >
> >Status = gBS->LocateHandleBuffer (
> > @@ -1002,7 +1002,7 @@ MemoryProtectionCpuArchProtocolNotify (
> >&HandleBuffer
> >);
> >if (EFI_ERROR (Status) && (NoHandles == 0)) {
> > -return ;
> > +goto Done;
> >}
> >
> >for (Index = 0; Index < NoHandles; Index++) {
> > @@ -1025,9 +1025,10 @@ MemoryProtectionCpuArchProtocolNotify (
> >
> > ProtectUefiImage (LoadedImage, LoadedImageDevicePath);
> >}
> > + FreePool (HandleBuffer);
> >
> > +Done:
> >CoreCloseEvent (Event);
> > - return;
> > }
> >
> > /**
> > --
> > 2.16.2.windows.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] MdeModulePkg/Core: fix ineffective guard page issue
Leif,
Thanks for catching that. I'll re-generate the patch files.
Regards,
Jian
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, November 06, 2018 8:10 PM
> To: Wang, Jian J
> Cc: edk2-devel@lists.01.org; Ni, Ruiyu ; Yao, Jiewen
> ; Zeng, Star
> Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg/Core: fix ineffective guard page
> issue
>
> On Sat, Nov 03, 2018 at 02:42:21PM +0800, Jian J Wang wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1295
> >
> > This issue originates from following patch which allows to enable
> > paging if PcdImageProtectionPolicy and PcdDxeNxMemoryProtectionPolicy
> > (in addition to PcdSetNxForStack) are set to enable related features.
> >
> > 5267926134d17e86672b84fd57b438f05ffa68e1
> >
> > Due to above change, PcdImageProtectionPolicy will be set to 0 by
> > default in many platforms, which, in turn, cause following code in
> > MdeModulePkg\Core\Dxe\Misc\MemoryProtection.c fail the creation of
> > notify event of CpuArchProtocol.
> >
> > 1138: if (mImageProtectionPolicy != 0 ||
> >PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0) {
> > 1139: Status = CoreCreateEvent (
> > ...
> > 1142: MemoryProtectionCpuArchProtocolNotify,
> > ...
> > 1145: );
> >
> > Then following call flow won't be done and Guard pages will not be
> > set as not-present in SetAllGuardPages() eventually.
> >
> >MemoryProtectionCpuArchProtocolNotify()
> > => HeapGuardCpuArchProtocolNotify()
> > => SetAllGuardPages()
> >
> > The solution is removing the if(...) statement so that the notify
> > event will always be created and handler be registered. This won't
> > cause unnecessary code execution because, in the notify event handler,
> > the related PCDs like
> >
> > PcdImageProtectionPolicy and
> > PcdDxeNxMemoryProtectionPolicy
> >
> > will be checked again to do its job.
> >
> > Cc: Star Zeng
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > index 30e5c5153c..30798b05b9 100644
> > --- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
> > @@ -1135,7 +1135,6 @@ CoreInitializeMemoryProtection (
> >ASSERT (GetPermissionAttributeForMemoryType (EfiBootServicesData) ==
> >GetPermissionAttributeForMemoryType (EfiConventionalMemory));
> >
> > - if (mImageProtectionPolicy != 0 || PcdGet64
> (PcdDxeNxMemoryProtectionPolicy) != 0) {
> >Status = CoreCreateEvent (
> > EVT_NOTIFY_SIGNAL,
> > TPL_CALLBACK,
> > @@ -1154,7 +1153,6 @@ CoreInitializeMemoryProtection (
> > &Registration
> > );
> >ASSERT_EFI_ERROR(Status);
> > - }
>
> And here we see why.
> The indentation changes need to be part of this patch, not 1/2.
>
> /
> Leif
>
> >
> >//
> >// Register a callback to disable NULL pointer detection at EndOfDxe
> > --
> > 2.16.2.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support
Mike, Since we're pending on the documentation of those APIs and it seems it won't be solved soon, I'd suggest to drop this feature from the coming release event. https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning Regards, Jian > -Original Message- > From: Kinney, Michael D > Sent: Friday, October 19, 2018 7:17 AM > To: Wang, Jian J ; Gao, Liming ; > edk2-devel@lists.01.org; Kinney, Michael D > Cc: Yao, Jiewen ; Andrew Fish > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain > support > > Jian, > > I do not see a description of the parameters, return > values or required behavior for those APIs in the header > files. How do you know if they are implemented correctly? > > How would we write tests for these APIs? > > Mike > > > -Original Message- > > From: Wang, Jian J > > Sent: Wednesday, October 17, 2018 7:16 PM > > To: Kinney, Michael D ; Gao, > > Liming ; edk2-devel > boun...@lists.01.org>; edk2-devel@lists.01.org > > Cc: Yao, Jiewen ; Andrew Fish > > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add > > MSFT toolchain support > > > > Mike, > > > > All those functions are declared in source files in > > Visual Studio except to > > __GSHandlerCheck(). But I can't find there's online link > > or document to those files > > and APIs. Is it ok to just list the file names? > > > > VC\INCLUDE\vcruntime.h: > > __security_check_cookie > > __report_gsfailure > > > > VC\INCLUDE\rtcapi.h: > > _RTC_CheckEsp > > _RTC_CheckStackVars > > _RTC_Shutdown > > _RTC_InitBase > > > > VC\crt\src\vcruntime\gs_report.c > > __report_rangecheckfailure > > > > I built the lib with all supported VS toolchains and all > > passed, but only tested > > with VS2015. I think I need to do more tests. Thanks for > > pointing it out. > > > > Regards, > > Jian > > > > > > > -Original Message- > > > From: Kinney, Michael D > > > Sent: Thursday, October 18, 2018 9:36 AM > > > To: Gao, Liming ; Wang, Jian J > > ; > > > edk2-devel ; edk2- > > de...@lists.01.org; > > > Kinney, Michael D > > > Cc: Yao, Jiewen ; Andrew Fish > > > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add MSFT toolchain > > > support > > > > > > Jian, > > > > > > Is there a link to the documentation for these new > > > functions? We should put the link in the file > > > headers. > > > > > > The link to docs should also be added to the BZ. > > > > > > Also, which VS compilers was this tested with? Are > > > different implementations required for different VS > > > compilers? > > > > > > Mike > > > > > > > -Original Message- > > > > From: Gao, Liming > > > > Sent: Wednesday, October 17, 2018 6:22 PM > > > > To: Wang, Jian J ; edk2-devel > > > > ; edk2- > > > > de...@lists.01.org > > > > Cc: Kinney, Michael D ; > > Yao, > > > > Jiewen ; Andrew Fish > > > > > > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add > > > > MSFT toolchain support > > > > > > > > Jian: > > > > The patch is good to me. Reviewed-by: Liming Gao > > > > > > > > > > > > Thanks > > > > Liming > > > > >-Original Message- > > > > >From: Wang, Jian J > > > > >Sent: Thursday, October 18, 2018 9:19 AM > > > > >To: edk2-devel ; > > edk2- > > > > de...@lists.01.org > > > > >Cc: Kinney, Michael D ; > > Yao, > > > > Jiewen > > > > >; Andrew Fish > > ; > > > > Gao, Liming > > > > > > > > > >Subject: RE: [edk2] [PATCH] > > MdePkg/BaseStackCheckLib: > > > > add MSFT toolchain > > > > >support > > > > > > > > > >Ping ... :) > > > > > > > > > >Regards, > > > > >Jian > > > > > > > > > > > > > > >> -Original Message- > > > > >> From: edk2-devel [mailto:edk2-devel- > > > > boun...@lists.01.org] > > > > >> Sent: Tuesday, October 16, 2018 8:59 AM > > > > >> To:
Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: optimize TLB flush operation
Ray,
Thanks for the explanations. I misunderstood the work flow here. So I'll drop
this
patch and close the tracker.
Regards,
Jian
> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, October 29, 2018 11:06 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Laszlo Ersek ; Yao,
> Jiewen ; Zeng, Star
> Subject: Re: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: optimize TLB flush
> operation
>
> On 10/26/2018 8:40 PM, Jian J Wang wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1281
> >
> > This optimization has two purpose:
> >
> >1. fix BZ#1281 which caused by flushing TLB for AP
> >2. improve performance for SMM heap guard
> >
> > The code change is simple: just flush TLB for current processor.
> >
> > Since processor's (including AP) SMI entry code will always initialize
> > CR3, it looks like that there's no need to add extra code in AP handler,
> > called from SMI entry, to flush TLB again.
> >
> > Let each processor itself guarantee the TLB integrity can improve memory
> > operations performance if Heap Guard is enabled. This has been proved
> > by CpuDxe driver. Please check following patches for details.
> >
> >41a9c3fd110bed93c4fdf088eea18412bb2dfcde
> >0dbb0f1a5ce6a9ec5213c85e5d4244cf5b061417
> > Stop flush TLB for APs (DXE) upon change
> >
> >199de89677deff30eda7ad17793b30042cce
> > Let AP (DXE) flush TLB in its wake-up procedure
> >
> > Tests:
> >a. Verified that issue in BZ#1281 is gone
> >b. Verified SMM heap guard works well on any processor
> >c. OVMF boot (Fedora26, Ubuntu18.04, Windows 10)
> >
> > Cc: Eric Dong
> > Cc: Laszlo Ersek
> > Cc: Jiewen Yao
> > Cc: Star Zeng
> > Cc: Ruiyu Ni
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 45 +++
> ---
> > 1 file changed, 6 insertions(+), 39 deletions(-)
> >
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
> > index 684b14dc28..e0bf0cd5ac 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
> > @@ -464,41 +464,6 @@ ConvertMemoryPageAttributes (
> > return RETURN_SUCCESS;
> > }
> >
> > -/**
> > - FlushTlb on current processor.
> > -
> > - @param[in,out] Buffer Pointer to private data buffer.
> > -**/
> > -VOID
> > -EFIAPI
> > -FlushTlbOnCurrentProcessor (
> > - IN OUT VOID *Buffer
> > - )
> > -{
> > - CpuFlushTlb ();
> > -}
> > -
> > -/**
> > - FlushTlb for all processors.
> > -**/
> > -VOID
> > -FlushTlbForAll (
> > - VOID
> > - )
> > -{
> > - UINTN Index;
> > -
> > - FlushTlbOnCurrentProcessor (NULL);
> > -
> > - for (Index = 0; Index < gSmst->NumberOfCpus; Index++) {
> > -if (Index != gSmst->CurrentlyExecutingCpu) {
> > - // Force to start up AP in blocking mode,
> > - SmmBlockingStartupThisAp (FlushTlbOnCurrentProcessor, Index, NULL);
> > - // Do not check return status, because AP might not be present in
> > some
> corner cases.
> > -}
> > - }
> > -}
> > -
> > /**
> > This function sets the attributes for the memory region specified by
> BaseAddress and
> > Length from their current attributes to the attributes specified by
> > Attributes.
> > @@ -538,9 +503,10 @@ SmmSetMemoryAttributesEx (
> > if (!EFI_ERROR(Status)) {
> > if (IsModified) {
> > //
> > - // Flush TLB as last step
> > + // Flush TLB as last step. No need to do it for APs, which sould
> > take care
> > + // of it in the wake-up procedure.
> > //
> > - FlushTlbForAll();
> > + CpuFlushTlb ();
> > }
> > }
> >
> > @@ -586,9 +552,10 @@ SmmClearMemoryAttributesEx (
> > if (!EFI_ERROR(Status)) {
> > if (IsModified) {
> > //
> > - // Flush TLB as last step
> > + // Flush TLB as last step. No need to do it for APs, which sould
> > take care
> > + // of it in the wake-up procedure.
> > //
> > - FlushTlbForAll();
> > + CpuFlushTlb ();
> > }
> > }
> >
> >
>
> Jian,
> I see you are using the same optimization as that in DXE MP to improve
> performance.
> But considering AP already runs to ApHandler() when BSP calls
> SmmStartupAp(), this optimization cannot be used actually.
>
> The original code is safe. With your changes, the AP's TLB is not
> flushed and may use out-of-date page table settings.
>
> I think for the specific Bugzilla, it's caller's fault to use the wrong
> DebugLib instance. AP procedure shouldn't call any PI/UEFI interface.
> We do not need to fix it.
>
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/Core: fix an IA32 build failure
Thanks. Since this failure blocks others work, I'll check in this patch soon.
Regards,
Jian
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng,
> Star
> Sent: Friday, October 26, 2018 1:13 PM
> To: edk2-devel ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Gao, Liming
> Subject: Re: [edk2] [PATCH] MdeModulePkg/Core: fix an IA32 build failure
>
> Reviewed-by: Star Zeng
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> Sent: Friday, October 26, 2018 12:54 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zeng, Star
> Subject: [edk2] [PATCH] MdeModulePkg/Core: fix an IA32 build failure
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1277
>
> The failure is caused by data type conversion between UINTN and UINT64,
> which is checked in at 63ebde8ef6d4ff497d054ccc010904ecd4441198.
>
> Cc: Star Zeng
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang
> ---
> MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 449a022658..521e0d7b2a 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -463,7 +463,7 @@ IsGuardPage (
>IN EFI_PHYSICAL_ADDRESSAddress
>)
> {
> - UINTN BitMap;
> + UINT64BitMap;
>
>//
>// There must be at least one guarded page before and/or after given
> @@ -1368,7 +1368,7 @@ GuardAllFreedPages (
>UINT64Address;
>UINT64GuardPage;
>INTN Level;
> - UINTN BitIndex;
> + UINT64BitIndex;
>UINTN GuardPageNumber;
>
>if (mGuardedMemoryMap == 0 ||
> @@ -1475,12 +1475,12 @@ MergeGuardPages (
>}
>
>Bitmap = 0;
> - Pages = EFI_SIZE_TO_PAGES (MaxAddress - MemoryMapEntry->PhysicalStart);
> - Pages -= MemoryMapEntry->NumberOfPages;
> + Pages = EFI_SIZE_TO_PAGES ((UINTN)(MaxAddress - MemoryMapEntry-
> >PhysicalStart));
> + Pages -= (INTN)MemoryMapEntry->NumberOfPages;
>while (Pages > 0) {
> if (Bitmap == 0) {
>EndAddress = MemoryMapEntry->PhysicalStart +
> - EFI_PAGES_TO_SIZE (MemoryMapEntry->NumberOfPages);
> + EFI_PAGES_TO_SIZE ((UINTN)MemoryMapEntry->NumberOfPages);
>Bitmap = GetGuardedMemoryBits (EndAddress,
> GUARDED_HEAP_MAP_ENTRY_BITS);
> }
>
> --
> 2.19.0.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 6/6] MdeModulePkg/Core: add freed-memory guard feature
Sure. Thanks.
Regards,
Jian
> -Original Message-
> From: Zeng, Star
> Sent: Friday, October 26, 2018 9:19 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> ; Yao, Jiewen ; Laszlo Ersek
> ; Zeng, Star
> Subject: Re: [edk2] [PATCH v4 6/6] MdeModulePkg/Core: add freed-memory
> guard feature
>
> On 2018/10/25 15:18, Jian J Wang wrote:
> >> v4 changes:
> >> a. replace hard-coded memory attributes with the value got from
> >> CoreGetMemorySpaceDescriptor()
> >> b. remove the enclosure of CoreAcquireGcdMemoryLock() and
> >> CoreReleaseGcdMemoryLock() around CoreAddRange()
> >
> > Freed-memory guard is used to detect UAF (Use-After-Free) memory issue
> > which is illegal access to memory which has been freed. The principle
> > behind is similar to heap guard feature, that is we'll turn all pool
>
> Remember to use "pool/page heap guard feature" instead of "heap guard
> feature" here. No need to send new patch series for it.
>
> Thanks,
> Star
>
> > memory allocation to page allocation and mark them to be not-present
> > once they are freed.
> >
> > This also implies that, once a page is allocated and freed, it cannot
> > be re-allocated. This will bring another issue, which is that there's
> > risk that memory space will be used out. To address it, the memory
> > service add logic to put part (at most 64 pages a time) of freed pages
> > back into page pool, so that the memory service can still have memory
> > to allocate, when all memory space have been allocated once. This is
> > called memory promotion. The promoted pages are always from the eldest
> > pages which haven been freed.
> >
> > This feature brings another problem is that memory map descriptors will
> > be increased enormously (200+ -> 2000+). One of change in this patch
> > is to update MergeMemoryMap() in file PropertiesTable.c to allow merge
> > freed pages back into the memory map. Now the number can stay at around
> > 510.
> >
> > Cc: Star Zeng
> > Cc: Michael D Kinney
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 409
> +-
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.h | 65 +++-
> > MdeModulePkg/Core/Dxe/Mem/Page.c | 42 ++-
> > MdeModulePkg/Core/Dxe/Mem/Pool.c | 23 +-
> > MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 2 +-
> > MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 18 +-
> > 6 files changed, 525 insertions(+), 34 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > index 663f969c0d..449a022658 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > @@ -44,6 +44,11 @@ GLOBAL_REMOVE_IF_UNREFERENCED UINTN
> mLevelShift[GUARDED_HEAP_MAP_TABLE_DEPTH]
> > GLOBAL_REMOVE_IF_UNREFERENCED UINTN
> mLevelMask[GUARDED_HEAP_MAP_TABLE_DEPTH]
> > = GUARDED_HEAP_MAP_TABLE_DEPTH_MASKS;
> >
> > +//
> > +// Used for promoting freed but not used pages.
> > +//
> > +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PHYSICAL_ADDRESS
> mLastPromotedPage = BASE_4GB;
> > +
> > /**
> > Set corresponding bits in bitmap table to 1 according to the address.
> >
> > @@ -379,7 +384,7 @@ ClearGuardedMemoryBits (
> >
> > @return An integer containing the guarded memory bitmap.
> > **/
> > -UINTN
> > +UINT64
> > GetGuardedMemoryBits (
> > IN EFI_PHYSICAL_ADDRESSAddress,
> > IN UINTN NumberOfPages
> > @@ -387,7 +392,7 @@ GetGuardedMemoryBits (
> > {
> > UINT64*BitMap;
> > UINTN Bits;
> > - UINTN Result;
> > + UINT64Result;
> > UINTN Shift;
> > UINTN BitsToUnitEnd;
> >
> > @@ -660,15 +665,16 @@ IsPageTypeToGuard (
> > /**
> > Check to see if the heap guard is enabled for page and/or pool
> > allocation.
> >
> > + @param[in] GuardType Specify the sub-type(s) of Heap Guard.
> > +
> > @return TRUE/FALSE.
> > **/
> > BOOLEAN
> > IsHeapGuardEnabled (
> > - VOID
> > + UINT8 GuardType
> > )
> >
Re: [edk2] [PATCH v4 5/6] MdeModulePkg/Core: prevent re-acquire GCD memory lock
Sorry missing that one. I'll update it. Thanks for the comments.
Regards,
Jian
> -Original Message-
> From: Zeng, Star
> Sent: Friday, October 26, 2018 9:18 AM
> To: Wang, Jian J ; edk2-devel boun...@lists.01.org>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> ; Yao, Jiewen ; Laszlo Ersek
> ; Zeng, Star
> Subject: Re: [edk2] [PATCH v4 5/6] MdeModulePkg/Core: prevent re-acquire
> GCD memory lock
>
> On 2018/10/25 15:20, Wang, Jian J wrote:
> > Sorry, forgot to update commit message:
> >
> >> This issue is hidden in current code but exposed by introduction
> >> of freed-memory guard feature due to the fact that the feature
> >> will turn all pool allocation to page allocation.
> >>
> >> The solution is moving the memory allocation in CoreGetMemorySpaceMap()
> >> to be out of the GCD memory map lock.
> >
> > Regards,
> > Jian
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> >> Sent: Thursday, October 25, 2018 3:18 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Kinney, Michael D ; Ni, Ruiyu
> >> ; Yao, Jiewen ; Zeng, Star
> >> ; Laszlo Ersek
> >> Subject: [edk2] [PATCH v4 5/6] MdeModulePkg/Core: prevent re-acquire GCD
> >> memory lock
> >>
> >>> v4 changes:
> >>> a. add more comments from Laszlo
> >>
> >> This issue is hidden in current code but exposed by introduction
> >> of freed-memory guard feature due to the fact that the feature
> >> will turn all pool allocation to page allocation.
> >>
> >> The solution is move the memory allocation in CoreGetMemorySpaceMap()
> >> and CoreGetIoSpaceMap() to be out of the GCD memory map lock.
> >>
> >> CoreDumpGcdMemorySpaceMap()
> >> => CoreGetMemorySpaceMap()
> >> => CoreAcquireGcdMemoryLock () *
> >> AllocatePool()
> >> => InternalAllocatePool()
> >> => CoreAllocatePool()
> >> => CoreAllocatePoolI()
> >> => CoreAllocatePoolPagesI()
> >> => CoreAllocatePoolPages()
> >> => FindFreePages()
> >> => PromoteMemoryResource()
> >> => CoreAcquireGcdMemoryLock() **
> >>
> >> Cc: Star Zeng
> >> Cc: Michael D Kinney
> >> Cc: Jiewen Yao
> >> Cc: Ruiyu Ni
> >> Cc: Laszlo Ersek
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Jian J Wang
> >> ---
> >> MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 87
> +-
> >> ---
> >> 1 file changed, 62 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> >> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> >> index d9c65a8045..f99d6bb933 100644
> >> --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> >> +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> >> @@ -1691,10 +1691,10 @@ CoreGetMemorySpaceMap (
> >> OUT EFI_GCD_MEMORY_SPACE_DESCRIPTOR **MemorySpaceMap
> >> )
> >> {
> >> - EFI_STATUS Status;
> >> LIST_ENTRY *Link;
> >> EFI_GCD_MAP_ENTRY*Entry;
> >> EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Descriptor;
> >> + UINTNDescriptorCount;
> >>
> >> //
> >> // Make sure parameters are valid
> >> @@ -1706,38 +1706,75 @@ CoreGetMemorySpaceMap (
> >> return EFI_INVALID_PARAMETER;
> >> }
> >>
> >> - CoreAcquireGcdMemoryLock ();
> >> + *NumberOfDescriptors = 0;
> >> + *MemorySpaceMap = NULL;
> >>
> >> //
> >> - // Count the number of descriptors
> >> + // Take the lock, for entering the loop with the lock held.
> >> //
> >> - *NumberOfDescriptors = CoreCountGcdMapEntry
> (&mGcdMemorySpaceMap);
> >> + CoreAcquireGcdMemoryLock ();
> >> + while (TRUE) {
> >> +//
> >> +// Count the number of descriptors. It might be done more than once
>
> How about using "Count the descriptors" here? No need to send new patch
> series for it.
>
> >> because
> >> +// there's code which has to be running outside the GCD lock.
>
> I have given comment for this line at V3 series.
> How about using "AllocatePool() calling code below" instead of "there's
> code" to be more specific?
>
>
Re: [edk2] [PATCH v4 5/6] MdeModulePkg/Core: prevent re-acquire GCD memory lock
Sorry, forgot to update commit message:
> This issue is hidden in current code but exposed by introduction
> of freed-memory guard feature due to the fact that the feature
> will turn all pool allocation to page allocation.
>
> The solution is moving the memory allocation in CoreGetMemorySpaceMap()
> to be out of the GCD memory map lock.
Regards,
Jian
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> Sent: Thursday, October 25, 2018 3:18 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> ; Yao, Jiewen ; Zeng, Star
> ; Laszlo Ersek
> Subject: [edk2] [PATCH v4 5/6] MdeModulePkg/Core: prevent re-acquire GCD
> memory lock
>
> > v4 changes:
> > a. add more comments from Laszlo
>
> This issue is hidden in current code but exposed by introduction
> of freed-memory guard feature due to the fact that the feature
> will turn all pool allocation to page allocation.
>
> The solution is move the memory allocation in CoreGetMemorySpaceMap()
> and CoreGetIoSpaceMap() to be out of the GCD memory map lock.
>
>CoreDumpGcdMemorySpaceMap()
> => CoreGetMemorySpaceMap()
> => CoreAcquireGcdMemoryLock () *
>AllocatePool()
> => InternalAllocatePool()
> => CoreAllocatePool()
> => CoreAllocatePoolI()
> => CoreAllocatePoolPagesI()
> => CoreAllocatePoolPages()
> => FindFreePages()
> => PromoteMemoryResource()
> => CoreAcquireGcdMemoryLock() **
>
> Cc: Star Zeng
> Cc: Michael D Kinney
> Cc: Jiewen Yao
> Cc: Ruiyu Ni
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang
> ---
> MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 87 +-
> ---
> 1 file changed, 62 insertions(+), 25 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> index d9c65a8045..f99d6bb933 100644
> --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> @@ -1691,10 +1691,10 @@ CoreGetMemorySpaceMap (
>OUT EFI_GCD_MEMORY_SPACE_DESCRIPTOR **MemorySpaceMap
>)
> {
> - EFI_STATUS Status;
>LIST_ENTRY *Link;
>EFI_GCD_MAP_ENTRY*Entry;
>EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Descriptor;
> + UINTNDescriptorCount;
>
>//
>// Make sure parameters are valid
> @@ -1706,38 +1706,75 @@ CoreGetMemorySpaceMap (
> return EFI_INVALID_PARAMETER;
>}
>
> - CoreAcquireGcdMemoryLock ();
> + *NumberOfDescriptors = 0;
> + *MemorySpaceMap = NULL;
>
>//
> - // Count the number of descriptors
> + // Take the lock, for entering the loop with the lock held.
>//
> - *NumberOfDescriptors = CoreCountGcdMapEntry (&mGcdMemorySpaceMap);
> + CoreAcquireGcdMemoryLock ();
> + while (TRUE) {
> +//
> +// Count the number of descriptors. It might be done more than once
> because
> +// there's code which has to be running outside the GCD lock.
> +//
> +DescriptorCount = CoreCountGcdMapEntry (&mGcdMemorySpaceMap);
> +if (DescriptorCount == *NumberOfDescriptors) {
> + //
> + // Fill in the MemorySpaceMap if no memory space map change.
> + //
> + Descriptor = *MemorySpaceMap;
> + Link = mGcdMemorySpaceMap.ForwardLink;
> + while (Link != &mGcdMemorySpaceMap) {
> +Entry = CR (Link, EFI_GCD_MAP_ENTRY, Link, EFI_GCD_MAP_SIGNATURE);
> +BuildMemoryDescriptor (Descriptor, Entry);
> +Descriptor++;
> +Link = Link->ForwardLink;
> + }
> + //
> + // We're done; exit the loop with the lock held.
> + //
> + break;
> +}
>
> - //
> - // Allocate the MemorySpaceMap
> - //
> - *MemorySpaceMap = AllocatePool (*NumberOfDescriptors * sizeof
> (EFI_GCD_MEMORY_SPACE_DESCRIPTOR));
> - if (*MemorySpaceMap == NULL) {
> -Status = EFI_OUT_OF_RESOURCES;
> -goto Done;
> - }
> +//
> +// Release the lock before memory allocation, because it might cause
> +// GCD lock conflict in one of calling path in AllocatPool().
> +//
> +CoreReleaseGcdMemoryLock ();
> +
> +//
> +// Allocate memory to store the MemorySpaceMap. Note it might be already
> +// allocated if there's map descriptor change during memory allocation at
> +// last time.
> +//
> +if (*MemorySpaceMap != NULL) {
> + FreePool (*MemorySpaceMap);
> +}
>
> +*MemorySpaceMap = AllocatePool (DescriptorCount *
> +sizeof
> (EFI_GCD_MEMORY_SPACE_DESCRIPTOR));
> +if (*MemorySpaceMap == NULL) {
> + *NumberOfDescriptors = 0;
> + return EFI_OUT_OF_RESOURCES;
> +}
> +
> +//
> +// Save the descriptor count got before for another round of check to
> make
> +// sure we won't miss any, since we have code running outside the GCD
> lock.
> +//
> +*NumberOfDescriptors = DescriptorCount;
> +//
> +// Re-acquire the lock, for the next iteration.
> +//
> +CoreAcquir
Re: [edk2] [PATCH v3 6/6] MdeModulePkg/Core: add freed-memory guard feature
Star,
I think the CoreGetMemorySpaceDescriptor() can get the memory capabilities. So
we can remove those hard-coded ones. In addition, since CoreAddRange() doesn't
touch mGcdMemorySpaceMap, CoreAcquireGcdMemoryLock and
CoreReleaseGcdMemoryLock are not necessary to protect CoreAddRange(). I'll
drop them as well.
Regards,
Jian
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, October 25, 2018 11:37 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> ; Yao, Jiewen ; Laszlo Ersek
> ; Zeng, Star
> Subject: Re: [edk2] [PATCH v3 6/6] MdeModulePkg/Core: add freed-memory
> guard feature
>
> On 2018/10/24 13:26, Jian J Wang wrote:
> >> v3 changes:
> >> a. Merge from #4 and #5 of v2 patch
> >> b. Coding style cleanup
> >
> > Freed-memory guard is used to detect UAF (Use-After-Free) memory issue
> > which is illegal access to memory which has been freed. The principle
> > behind is similar to heap guard feature, that is we'll turn all pool
>
> Since we also regard UAF part of heap guard feature, better to use
> "pool/page heap guard feature" instead of "heap guard feature" here.
>
> I quoted a piece of code at below and have question that why it uses
> hard code Attribute parameter?
>
> + CoreAddRange (
> +EfiConventionalMemory,
> +StartAddress,
> +EndAddress,
> +EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
> EFI_MEMORY_WB
> +);
>
> Thanks,
> Star
>
> > memory allocation to page allocation and mark them to be not-present
> > once they are freed. The freed memory block will not be added back into
> > memory pool.
> >
> > This means that, once a page is allocated and freed, it cannot be
> > re-allocated. This will bring an issue, which is that there's
> > risk that memory space will be used out. To address it, the memory
> > service add logic to put part (at most 64 pages a time) of freed pages
> > back into page pool, so that the memory service can still have memory
> > to allocate, when all memory space have been allocated once. This is
> > called memory promotion. The promoted pages are always from the eldest
> > pages which haven been freed.
> >
> > This feature brings another problem is that memory map descriptors will
> > be increased enormously (200+ -> 2000+). One of change in this patch
> > is to update MergeMemoryMap() in file PropertiesTable.c to allow merge
> > freed pages back into the memory map. Now the number can stay at around
> > 510.
> >
> > Cc: Star Zeng
> > Cc: Michael D Kinney
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 409
> +-
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.h | 65 +++-
> > MdeModulePkg/Core/Dxe/Mem/Page.c | 41 ++-
> > MdeModulePkg/Core/Dxe/Mem/Pool.c | 23 +-
> > MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 2 +-
> > MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 18 +-
> > 6 files changed, 524 insertions(+), 34 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > index 663f969c0d..449a022658 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > @@ -44,6 +44,11 @@ GLOBAL_REMOVE_IF_UNREFERENCED UINTN
> mLevelShift[GUARDED_HEAP_MAP_TABLE_DEPTH]
> > GLOBAL_REMOVE_IF_UNREFERENCED UINTN
> mLevelMask[GUARDED_HEAP_MAP_TABLE_DEPTH]
> > = GUARDED_HEAP_MAP_TABLE_DEPTH_MASKS;
> >
> > +//
> > +// Used for promoting freed but not used pages.
> > +//
> > +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PHYSICAL_ADDRESS
> mLastPromotedPage = BASE_4GB;
> > +
> > /**
> > Set corresponding bits in bitmap table to 1 according to the address.
> >
> > @@ -379,7 +384,7 @@ ClearGuardedMemoryBits (
> >
> > @return An integer containing the guarded memory bitmap.
> > **/
> > -UINTN
> > +UINT64
> > GetGuardedMemoryBits (
> > IN EFI_PHYSICAL_ADDRESSAddress,
> > IN UINTN NumberOfPages
> > @@ -387,7 +392,7 @@ GetGuardedMemoryBits (
> > {
> > UINT64*BitMap;
> > UINTN Bits;
> > - UINTN Result;
> > + UINT64Result;
> > U
Re: [edk2] [PATCH v3 6/6] MdeModulePkg/Core: add freed-memory guard feature
Star,
Regards,
Jian
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, October 25, 2018 11:37 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> ; Yao, Jiewen ; Laszlo Ersek
> ; Zeng, Star
> Subject: Re: [edk2] [PATCH v3 6/6] MdeModulePkg/Core: add freed-memory
> guard feature
>
> On 2018/10/24 13:26, Jian J Wang wrote:
> >> v3 changes:
> >> a. Merge from #4 and #5 of v2 patch
> >> b. Coding style cleanup
> >
> > Freed-memory guard is used to detect UAF (Use-After-Free) memory issue
> > which is illegal access to memory which has been freed. The principle
> > behind is similar to heap guard feature, that is we'll turn all pool
>
> Since we also regard UAF part of heap guard feature, better to use
> "pool/page heap guard feature" instead of "heap guard feature" here.
>
You're right. I'll change it.
> I quoted a piece of code at below and have question that why it uses
> hard code Attribute parameter?
>
> + CoreAddRange (
> +EfiConventionalMemory,
> +StartAddress,
> +EndAddress,
> +EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT |
> EFI_MEMORY_WB
> +);
>
Because I don't know the actual attributes at that time so I think it'd be
safer to add all supported ones.
> Thanks,
> Star
>
> > memory allocation to page allocation and mark them to be not-present
> > once they are freed. The freed memory block will not be added back into
> > memory pool.
> >
> > This means that, once a page is allocated and freed, it cannot be
> > re-allocated. This will bring an issue, which is that there's
> > risk that memory space will be used out. To address it, the memory
> > service add logic to put part (at most 64 pages a time) of freed pages
> > back into page pool, so that the memory service can still have memory
> > to allocate, when all memory space have been allocated once. This is
> > called memory promotion. The promoted pages are always from the eldest
> > pages which haven been freed.
> >
> > This feature brings another problem is that memory map descriptors will
> > be increased enormously (200+ -> 2000+). One of change in this patch
> > is to update MergeMemoryMap() in file PropertiesTable.c to allow merge
> > freed pages back into the memory map. Now the number can stay at around
> > 510.
> >
> > Cc: Star Zeng
> > Cc: Michael D Kinney
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 409
> +-
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.h | 65 +++-
> > MdeModulePkg/Core/Dxe/Mem/Page.c | 41 ++-
> > MdeModulePkg/Core/Dxe/Mem/Pool.c | 23 +-
> > MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 2 +-
> > MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 18 +-
> > 6 files changed, 524 insertions(+), 34 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > index 663f969c0d..449a022658 100644
> > --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> > @@ -44,6 +44,11 @@ GLOBAL_REMOVE_IF_UNREFERENCED UINTN
> mLevelShift[GUARDED_HEAP_MAP_TABLE_DEPTH]
> > GLOBAL_REMOVE_IF_UNREFERENCED UINTN
> mLevelMask[GUARDED_HEAP_MAP_TABLE_DEPTH]
> > = GUARDED_HEAP_MAP_TABLE_DEPTH_MASKS;
> >
> > +//
> > +// Used for promoting freed but not used pages.
> > +//
> > +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PHYSICAL_ADDRESS
> mLastPromotedPage = BASE_4GB;
> > +
> > /**
> > Set corresponding bits in bitmap table to 1 according to the address.
> >
> > @@ -379,7 +384,7 @@ ClearGuardedMemoryBits (
> >
> > @return An integer containing the guarded memory bitmap.
> > **/
> > -UINTN
> > +UINT64
> > GetGuardedMemoryBits (
> > IN EFI_PHYSICAL_ADDRESSAddress,
> > IN UINTN NumberOfPages
> > @@ -387,7 +392,7 @@ GetGuardedMemoryBits (
> > {
> > UINT64*BitMap;
> > UINTN Bits;
> > - UINTN Result;
> > + UINT64Result;
> > UINTN Shift;
> > UINTN BitsToUnitEnd;
> >
> > @@ -660,15 +665,16 @@ IsPageTypeToGua
Re: [edk2] [PATCH v3 5/6] MdeModulePkg/Core: prevent re-acquire GCD memory lock
Sure. I'll change them. Thanks.
Regards,
Jian
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, October 25, 2018 11:23 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> ; Yao, Jiewen ; Laszlo Ersek
> ; Zeng, Star
> Subject: Re: [edk2] [PATCH v3 5/6] MdeModulePkg/Core: prevent re-acquire
> GCD memory lock
>
> Some minor comments are added below.
> With them addressed, Reviewed-by: Star Zeng .
>
> On 2018/10/24 13:26, Jian J Wang wrote:
> >> v3 changes:
> >> a. drop the changes to CoreGetIoSpaceMap() because it won't cause
> >> problem
> >> b. refine the logic in changes of CoreGetMemorySpaceMap()
> >> and add more comments
> >
> > This issue is hidden in current code but exposed by introduction
> > of freed-memory guard feature due to the fact that the feature
> > will turn all pool allocation to page allocation.
> >
> > The solution is move the memory allocation in CoreGetMemorySpaceMap()
>
> Use 'moving' instead of 'move'?
>
> > and CoreGetIoSpaceMap() to be out of the GCD memory map lock.
>
> Please remove CoreGetIoSpaceMap() as the code does not touch it at all.
>
> >
> > Although it's rare, a while-loop is added to make sure that the count
> > of descriptor of memory map is the same after memory allocation, because
> > it's executed outside the GCD memory lock.
> >
> > CoreDumpGcdMemorySpaceMap()
> > => CoreGetMemorySpaceMap()
> > => CoreAcquireGcdMemoryLock () *
> > AllocatePool()
> > => InternalAllocatePool()
> > => CoreAllocatePool()
> > => CoreAllocatePoolI()
> > => CoreAllocatePoolPagesI()
> > => CoreAllocatePoolPages()
> > => FindFreePages()
> > => PromoteMemoryResource()
> > => CoreAcquireGcdMemoryLock() **
> >
> > Cc: Star Zeng
> > Cc: Michael D Kinney
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 80 +++-
> -
> > 1 file changed, 54 insertions(+), 26 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > index d9c65a8045..bc02945721 100644
> > --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > @@ -1691,10 +1691,10 @@ CoreGetMemorySpaceMap (
> > OUT EFI_GCD_MEMORY_SPACE_DESCRIPTOR **MemorySpaceMap
> > )
> > {
> > - EFI_STATUS Status;
> > LIST_ENTRY *Link;
> > EFI_GCD_MAP_ENTRY*Entry;
> > EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Descriptor;
> > + UINTNDescriptorCount;
> >
> > //
> > // Make sure parameters are valid
> > @@ -1706,38 +1706,66 @@ CoreGetMemorySpaceMap (
> > return EFI_INVALID_PARAMETER;
> > }
> >
> > + *NumberOfDescriptors = 0;
> > + *MemorySpaceMap = NULL;
> > +
> > CoreAcquireGcdMemoryLock ();
>
> Better to add comment for it like below quoted from the example at
> https://lists.01.org/pipermail/edk2-devel/2018-October/031279.html given
> by Laszlo.
>
> //
> // Take the lock, for entering the loop with the lock held.
> //
>
> >
> > - //
> > - // Count the number of descriptors
> > - //
> > - *NumberOfDescriptors = CoreCountGcdMapEntry
> (&mGcdMemorySpaceMap);
> > + while (TRUE) {
> > +//
> > +// Count the number of descriptors. It might be done more than once
> because
>
> Use 'count' instead of 'number' to match the variable name?
>
> > +// there's code which has to be running outside the GCD lock.
>
> Use "AllocatePool() calling code below" instead of "there's code"?
>
> > +//
> > +DescriptorCount = CoreCountGcdMapEntry (&mGcdMemorySpaceMap);
> > +if (DescriptorCount == *NumberOfDescriptors) {
> > + //
> > + // Fill in the MemorySpaceMap if no memory space map change.
> > + //
> > + Descriptor = *MemorySpaceMap;
> > + Link = mGcdMemorySpaceMap.ForwardLink;
> > + while (Link != &mGcdMemorySpaceMap) {
> > +Entry = CR (Link, EFI_GCD_MAP_ENTRY, Link,
> EFI_GCD_MAP_SIGNATURE);
> > +BuildMemoryDescriptor (Descriptor, Entry);
> > +Descriptor
Re: [edk2] [PATCH v3 2/6] MdeModulePkg: introduce UEFI freed-memory guard bit in HeapGuard PCD
Star, Regards, Jian > -Original Message- > From: Zeng, Star > Sent: Thursday, October 25, 2018 11:02 AM > To: Wang, Jian J ; edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Ni, Ruiyu > ; Yao, Jiewen ; Laszlo Ersek > ; Zeng, Star > Subject: Re: [edk2] [PATCH v3 2/6] MdeModulePkg: introduce UEFI freed- > memory guard bit in HeapGuard PCD > > On 2018/10/24 13:26, Jian J Wang wrote: > >> v3 changes: > >> a. split from v2 #1 patch file. > >> b. refine the commit message and title. > > > > UAF (Use-After-Free) memory issue is kind of illegal access to memory > > which has been freed. It can be detected by a new freed-memory guard > > enforced onto freed memory. > > > > BIT4 of following PCD is used to enable the freed-memory guard feature. > > > >gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask > > > > Please note this feature is for debug purpose and should not be enabled > > Suggest also adding this information into the PCD description. > Pool/page heap guard also has same condition, right? > If yes, we can have a generic sentence for whole PCD. > > With this addressed, Reviewed-by: Star Zeng . > Sure. I'll update the dec/uni file with it. Thanks. > > Thanks, > Star > > > in product BIOS, and cannot be enabled with pool/page heap guard at the > > same time. It's disabled by default. > > > > Cc: Star Zeng > > Cc: Michael D Kinney > > Cc: Jiewen Yao > > Cc: Ruiyu Ni > > Cc: Laszlo Ersek > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Jian J Wang > > --- > > MdeModulePkg/MdeModulePkg.dec | 6 ++ > > MdeModulePkg/MdeModulePkg.uni | 4 +++- > > 2 files changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > > index 2009dbc5fd..255b92ea67 100644 > > --- a/MdeModulePkg/MdeModulePkg.dec > > +++ b/MdeModulePkg/MdeModulePkg.dec > > @@ -1011,14 +1011,20 @@ > > > gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType|0x0|UINT64|0x30 > 001053 > > > > ## This mask is to control Heap Guard behavior. > > + # > > # Note that due to the limit of pool memory implementation and the > alignment > > # requirement of UEFI spec, BIT7 is a try-best setting which cannot > guarantee > > # that the returned pool is exactly adjacent to head guard page or tail > > guard > > # page. > > + # > > + # Note that UEFI freed-memory guard and pool/page guard cannot be > enabled > > + # at the same time. > > + # > > # BIT0 - Enable UEFI page guard. > > # BIT1 - Enable UEFI pool guard. > > # BIT2 - Enable SMM page guard. > > # BIT3 - Enable SMM pool guard. > > + # BIT4 - Enable UEFI freed-memory guard (Use-After-Free memory > detection). > > # BIT6 - Enable non-stop mode. > > # BIT7 - The direction of Guard Page for Pool Guard. > > # 0 - The returned pool is near the tail guard page. > > diff --git a/MdeModulePkg/MdeModulePkg.uni > b/MdeModulePkg/MdeModulePkg.uni > > index 9d2e473fa9..e72b893509 100644 > > --- a/MdeModulePkg/MdeModulePkg.uni > > +++ b/MdeModulePkg/MdeModulePkg.uni > > @@ -1227,11 +1227,13 @@ > > > > "Note that due to the limit > of pool memory implementation and the alignment\n" > > > > "requirement of UEFI spec, > BIT7 is a try-best setting which cannot guarantee\n" > > > > "that the returned pool is > exactly adjacent to head guard page or tail guard\n" > > - > > "page.\n" > > + > > "page.\n\n" > > + > > "Note that UEFI freed- > memory guard and pool/page guard cannot be enabled at the same time.\n\n" > > > > " BIT0 - Enable UEFI page > guard.\n" > > > >
Re: [edk2] [PATCH v3 1/6] MdeModulePkg: cleanup Heap Guard pool/page type PCD documentation
Got it. Thanks. Regards, Jian > -Original Message- > From: Zeng, Star > Sent: Thursday, October 25, 2018 10:56 AM > To: Wang, Jian J ; edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Ni, Ruiyu > ; Yao, Jiewen ; Laszlo Ersek > ; Zeng, Star > Subject: Re: [edk2] [PATCH v3 1/6] MdeModulePkg: cleanup Heap Guard > pool/page type PCD documentation > > On 2018/10/24 13:26, Jian J Wang wrote: > >> v3 changes: > >> a. split from #1 patch of v2 > >> b. update title > > > > This cleanup is meant for avoiding misuse of newly introduced BIT4 > > (UAF detection) of PCD PcdHeapGuardPropertyMask, because it applies > > to all types of physical memory. In another words, > > PcdHeapGuardPoolType and PcdHeapGuardPageType don't have effect to > > the BIT4 of PcdHeapGuardPropertyMask. > > > > Cc: Star Zeng > > Cc: Michael D Kinney > > Cc: Jiewen Yao > > Cc: Ruiyu Ni > > Cc: Laszlo Ersek > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Jian J Wang > > Reviewed-by: Star Zeng > > You may can add Laszlo's RB and even Suggested-by according to Laszlo's > feedback to V2 patch series. > > > Thanks, > Star > > > --- > > MdeModulePkg/MdeModulePkg.dec | 4 > > MdeModulePkg/MdeModulePkg.uni | 2 ++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > > index 6037504fa7..2009dbc5fd 100644 > > --- a/MdeModulePkg/MdeModulePkg.dec > > +++ b/MdeModulePkg/MdeModulePkg.dec > > @@ -955,6 +955,8 @@ > > # free pages for all of them. The page allocation for the type related > > to > > # cleared bits keeps the same as ususal. > > # > > + # This PCD is only valid if BIT0 and/or BIT2 are set in > PcdHeapGuardPropertyMask. > > + # > > # Below is bit mask for this PCD: (Order is same as UEFI spec) > > # EfiReservedMemoryType 0x0001 > > # EfiLoaderCode 0x0002 > > @@ -984,6 +986,8 @@ > > # if there's enough free memory for all of them. The pool allocation > > for the > > # type related to cleared bits keeps the same as ususal. > > # > > + # This PCD is only valid if BIT1 and/or BIT3 are set in > PcdHeapGuardPropertyMask. > > + # > > # Below is bit mask for this PCD: (Order is same as UEFI spec) > > # EfiReservedMemoryType 0x0001 > > # EfiLoaderCode 0x0002 > > diff --git a/MdeModulePkg/MdeModulePkg.uni > b/MdeModulePkg/MdeModulePkg.uni > > index a6bcb627cf..9d2e473fa9 100644 > > --- a/MdeModulePkg/MdeModulePkg.uni > > +++ b/MdeModulePkg/MdeModulePkg.uni > > @@ -1171,6 +1171,7 @@ > > > > " before and after > corresponding type of pages allocated if there's enough\n" > > > > " free pages for all of them. > The page allocation for the type related to\n" > > > > " cleared bits keeps the same > as ususal.\n\n" > > + > > " This PCD is only valid if BIT0 > and/or BIT2 are set in PcdHeapGuardPropertyMask.\n\n" > > > > " Below is bit mask for this > PCD: (Order is same as UEFI spec)\n" > > > > " EfiReservedMemoryType > 0x0001\n" > > > > " EfiLoaderCode > 0x0002\n" > > @@ -1198,6 +1199,7 @@ > > > > " before and after > corresponding type of pages which the allocated pool occupies,\n" > > > > " if there's enough free > memory for all of them. The pool allocation for the\n" > > > > " type relate
Re: [edk2] [PATCH v2 1/5] MdeModulePkg/MdeModulePkg.dec: update PCD description for new feature
Laszlo, Thank you very much for the comments. I went through all of them in other patch emails and I think I have no objection. So to save all of us time I'm not going to respond them separately. I'll send out v3 patch soon. Thanks again. Regards, Jian > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, October 24, 2018 12:09 AM > To: Wang, Jian J ; edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Ni, Ruiyu > ; Yao, Jiewen ; Zeng, Star > > Subject: Re: [edk2] [PATCH v2 1/5] MdeModulePkg/MdeModulePkg.dec: update > PCD description for new feature > > On 10/23/18 16:53, Jian J Wang wrote: > >> v2 changes: > >> a. Drop PCD PcdUseAfterFreeDetectionPropertyMask. Use BIT4 of > >>PcdHeapGuardPropertyMask instead. Update related descriptions in both > >>dec and uni files. > > > > Freed-memory guard is used to detect UAF (Use-After-Free) memory issue > > which is illegal access to memory which has been freed. The principle > > behind is similar to heap guard feature, that is we'll turn all pool > > memory allocation to page allocation and mark them to be not-present > > once they are freed. > > > > This also implies that, once a page is allocated and freed, it cannot > > be re-allocated. This will bring another issue, which is that there's > > risk that memory space will be used out. To address it, this patch > > series add logic put part (at most 64 pages a time) of freed pages > > back into page pool, so that the memory service can still have memory > > to allocate, when all memory space have been allocated once. This is > > called memory promotion. The promoted pages are always from the eldest > > pages freed. > > > > BIT4 of following PCD is used to enable the freed-memory guard feature. > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask > > > > Please note this feature cannot be enabled with heap guard at the same > > time. > > > > Cc: Star Zeng > > Cc: Michael D Kinney > > Cc: Jiewen Yao > > Cc: Ruiyu Ni > > Cc: Laszlo Ersek > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Jian J Wang > > --- > > MdeModulePkg/MdeModulePkg.dec | 10 ++ > > MdeModulePkg/MdeModulePkg.uni | 6 +- > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > > index 6037504fa7..255b92ea67 100644 > > --- a/MdeModulePkg/MdeModulePkg.dec > > +++ b/MdeModulePkg/MdeModulePkg.dec > > @@ -955,6 +955,8 @@ > ># free pages for all of them. The page allocation for the type related to > ># cleared bits keeps the same as ususal. > ># > > + # This PCD is only valid if BIT0 and/or BIT2 are set in > PcdHeapGuardPropertyMask. > > + # > ># Below is bit mask for this PCD: (Order is same as UEFI spec) > ># EfiReservedMemoryType 0x0001 > ># EfiLoaderCode 0x0002 > > @@ -984,6 +986,8 @@ > ># if there's enough free memory for all of them. The pool allocation for > > the > ># type related to cleared bits keeps the same as ususal. > ># > > + # This PCD is only valid if BIT1 and/or BIT3 are set in > PcdHeapGuardPropertyMask. > > + # > ># Below is bit mask for this PCD: (Order is same as UEFI spec) > ># EfiReservedMemoryType 0x0001 > ># EfiLoaderCode 0x0002 > > @@ -1007,14 +1011,20 @@ > > > gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType|0x0|UINT64|0x30 > 001053 > > > >## This mask is to control Heap Guard behavior. > > + # > ># Note that due to the limit of pool memory implementation and the > alignment > ># requirement of UEFI spec, BIT7 is a try-best setting which cannot > guarantee > ># that the returned pool is exactly adjacent to head guard page or tail > > guard > ># page. > > (1) The above changes are not related to the use-after-free feature; > they should go into a separate cleanup patch. (Which is very welcome > otherwise.) The cleanup patch should be patch #1 in the series. > > The subject should be, for example: > > MdeModulePkg: clean up Heap Guard PageType / PoolType PCD > documentation > > (71 characters) > > > + # > > + # Note that UEFI freed-memory guard and pool/page guard cannot be > enabled > > + # at the same time. > > + # > ># BIT0 - Enable UEFI pa
Re: [edk2] [PATCH 3/3] MdeModulePkg/Core: add use-after-free memory detection
Star, Regards, Jian > -Original Message- > From: Zeng, Star > Sent: Monday, October 22, 2018 4:24 PM > To: Wang, Jian J ; edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Ni, Ruiyu > ; Yao, Jiewen ; Laszlo Ersek > ; Zeng, Star > Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg/Core: add use-after-free > memory detection > > On 2018/10/22 15:12, Wang, Jian J wrote: > > Star, > > > > Thanks for the comment. Please see my opinions below. > > > > Regards, > > Jian > > > > > >> -Original Message----- > >> From: Zeng, Star > >> Sent: Monday, October 22, 2018 10:53 AM > >> To: Wang, Jian J ; edk2-devel@lists.01.org > >> Cc: Kinney, Michael D ; Ni, Ruiyu > >> ; Yao, Jiewen ; Laszlo Ersek > >> ; Zeng, Star > >> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg/Core: add use-after-free > >> memory detection > >> > >> On 2018/10/19 9:50, Jian J Wang wrote: > >>> UAF (Use-After-Free) memory detection is new feature introduced to > >>> detect illegal access to memory which has been freed. The principle > >>> behind is similar to heap guard feature, that is the core turn all pool > >>> memory allocation to page allocation and mark them to be not-present > >>> once they are freed. > >>> > >>> This also implies that, once a page is allocated and freed, it cannot > >>> be re-allocated. This will bring another issue, which is that there's > >>> risk that memory space will be used out. To address it, the memory > >>> service add logic to put part (at most 64 pages a time) of freed pages > >>> back into page pool, so that the memory service can still have memory > >>> to allocate, when all memory space have been allocated once. This is > >>> called memory promotion. The promoted pages are always from the eldest > >>> pages which haven been freed. > >>> > >>> To use this feature, one can simply set following PCD to 1 > >>> > >> gEfiMdeModulePkgTokenSpaceGuid.PcdUseAfterFreeDetectionPropertyMask > >>> > >>> Please note this feature cannot be used with heap guard feature controlled > >>> by PCD gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask. > >>> > >>> Cc: Star Zeng > >>> Cc: Michael D Kinney > >>> Cc: Jiewen Yao > >>> Cc: Ruiyu Ni > >>> Cc: Laszlo Ersek > >>> Contributed-under: TianoCore Contribution Agreement 1.1 > >>> Signed-off-by: Jian J Wang > >> > >> I did not review the whole patch thoroughly. But I suggest that putting > >> the code for UAF in a separated file if it is feasible. I am aware that > >> UAF will be sharing much code with HeapGuard, so could we have Uaf.c, > >> HeapGuard.c and GuardPage.c (this file name is just for example)? > >> > > > > I think we can take the UAF as a special kind of heap guard: guarding the > > freed heap memory instead of guarding the allocated heap memory. So > > UAF is a complement of Heap Guard or part of Heap Guard. From this > > perspective, it's not necessary to put it in separate file. > > Very good point. From this perspective, I agree. > Then I would like to suggest not introducing a new PCD > PcdUseAfterFreeDetectionPropertyMask, but use one BIT of > PcdHeapGuardPropertyMask for it since we think it is part of Heap Guard. > The benefits are > 1. No confusion between Heap Guard and Use After Free. > 2. No need introduce new PCD. > 3. Can reuse BIT6 - Enable non-stop mode. > 4. No need update DxeIplPeim to enable IA32 PAE paging. > Good idea. I'll try it. Thanks. > > > >>> --- > >>>MdeModulePkg/Core/Dxe/DxeMain.h | 1 + > >>>MdeModulePkg/Core/Dxe/DxeMain.inf| 1 + > >>>MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 8 + > >>>MdeModulePkg/Core/Dxe/Mem/HeapGuard.c| 393 > >> ++- > >>>MdeModulePkg/Core/Dxe/Mem/HeapGuard.h| 66 + > >>>MdeModulePkg/Core/Dxe/Mem/Page.c | 39 ++- > >>>MdeModulePkg/Core/Dxe/Mem/Pool.c | 21 +- > >>>MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 16 +- > >>>8 files changed, 519 insertions(+), 26 deletions(-) > >>> > >>> diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h > >> b/MdeModulePkg/Core/Dxe/DxeMain.h > >>> index 2dec9da5e3..ae75
Re: [edk2] [PATCH 3/3] MdeModulePkg/Core: add use-after-free memory detection
Hi Laszlo,
Regards,
Jian
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, October 19, 2018 8:05 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Kinney, Michael D
> ; Yao, Jiewen ; Ni, Ruiyu
>
> Subject: Re: [PATCH 3/3] MdeModulePkg/Core: add use-after-free memory
> detection
>
> On 10/19/18 03:50, Jian J Wang wrote:
> > UAF (Use-After-Free) memory detection is new feature introduced to
> > detect illegal access to memory which has been freed. The principle
> > behind is similar to heap guard feature, that is the core turn all pool
> > memory allocation to page allocation and mark them to be not-present
> > once they are freed.
> >
> > This also implies that, once a page is allocated and freed, it cannot
> > be re-allocated. This will bring another issue, which is that there's
> > risk that memory space will be used out. To address it, the memory
> > service add logic to put part (at most 64 pages a time) of freed pages
> > back into page pool, so that the memory service can still have memory
> > to allocate, when all memory space have been allocated once. This is
> > called memory promotion. The promoted pages are always from the eldest
> > pages which haven been freed.
> >
> > To use this feature, one can simply set following PCD to 1
> > gEfiMdeModulePkgTokenSpaceGuid.PcdUseAfterFreeDetectionPropertyMask
> >
> > Please note this feature cannot be used with heap guard feature controlled
> > by PCD gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask.
> >
> > Cc: Star Zeng
> > Cc: Michael D Kinney
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > MdeModulePkg/Core/Dxe/DxeMain.h | 1 +
> > MdeModulePkg/Core/Dxe/DxeMain.inf| 1 +
> > MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 8 +
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.c| 393
> ++-
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.h| 66 +
> > MdeModulePkg/Core/Dxe/Mem/Page.c | 39 ++-
> > MdeModulePkg/Core/Dxe/Mem/Pool.c | 21 +-
> > MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 16 +-
> > 8 files changed, 519 insertions(+), 26 deletions(-)
>
> I don't think I can review this patch well (I'm not an MdeModulePkg
> reviewer). However I do think this patch is way too large. I suggest
> splitting out everything that counts as "preparation" to separate patches.
>
> For example:
Any comments are welcome.
>
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h
> b/MdeModulePkg/Core/Dxe/DxeMain.h
> > index 2dec9da5e3..ae75cc5b25 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
> > @@ -92,6 +92,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> > #include
> > #include
> > #include
> > +#include
> >
> >
> > //
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf
> b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > index 10375443c0..d91258c087 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain.inf
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > @@ -198,6 +198,7 @@
> >gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
> > ##
> CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
> ## CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard
> > ##
> CONSUMES
> > +
> gEfiMdeModulePkgTokenSpaceGuid.PcdUseAfterFreeDetectionPropertyMask
> ## CONSUMES
> >
> > # [Hob]
> > # RESOURCE_DESCRIPTOR ## CONSUMES
> > diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > index d9c65a8045..e43ec74010 100644
> > --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > @@ -160,6 +160,10 @@ CoreDumpGcdMemorySpaceMap (
> > EFI_GCD_MEMORY_SPACE_DESCRIPTOR *MemorySpaceMap;
> > UINTNIndex;
> >
> > +if ((GetDebugPrintErrorLevel () & DEBUG_GCD) == 0) {
> > + return;
> > +}
> > +
> > Status = CoreGetMemorySpaceMap (&NumberOfDescriptors,
> &MemorySpaceMap);
> > ASSERT (Status == EFI_SUCCESS && MemorySpaceMap != NULL);
> >
>
> this change doesn't belong to the UAF feature introduction. This change
> streamlines some de
Re: [edk2] [PATCH 2/3] UefiCpuPkg/CpuDxe: fix an infinite loop issue
Laszlo,
Thanks for the comments.
Regards,
Jian
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, October 19, 2018 7:46 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Kinney, Michael D
> ; Yao, Jiewen ; Ni, Ruiyu
>
> Subject: Re: [PATCH 2/3] UefiCpuPkg/CpuDxe: fix an infinite loop issue
>
> On 10/19/18 03:50, Jian J Wang wrote:
> > The UAF (Use-After-Free) memory detection feature will cause an
> > infinite calling of InitializePageTablePool(). This is due to a
> > fact that AllocateAlignedPages() is used to allocate page table
> > pool memory. This function will most likely call gBS->FreePages
> > to free unaligned pages and then cause another round of page
> > attributes change, like below
> >
> >FreePages() <===|
> > => SetMemoryAttributes() |
>
> This should likely be "SetMemorySpaceAttributes" (the DXE service), or else
> "CpuSetMemoryAttributes" (the underlying CpuDxe function name).
>
You're right. I'll change it.
> > => |
> > => InitializePageTablePool() |
> > => AllocateAlignedPages() |
> > => FreePages() |
> >
> > The solution is add a lock in page table pool allocation function
> > and fail any other requests if it has not been done.
>
> OK, but what is the end result? InitializePageTablePool() will return FALSE.
> How
> far back up is that error propagated? To what components will the error be
> visible?
>
> BTW, I've found the following comment in CpuSetMemoryAttributes():
>
> //
> // During memory attributes updating, new pages may be allocated to setup
> // smaller granularity of page table. Page allocation action might then
> cause
> // another calling of CpuSetMemoryAttributes() recursively, due to memory
> // protection policy configured (such as PcdDxeNxMemoryProtectionPolicy).
> // Since this driver will always protect memory used as page table by
> itself,
> // there's no need to apply protection policy requested from memory service.
> // So it's safe to just return EFI_SUCCESS if this time of calling is caused
> // by page table memory allocation.
> //
>
> Is the current argument similar? I think it should be documented somehow.
>
No, I don't think they're the similar. The issue I encountered here is that the
code
tries to set freed memory as not-present but trapped in dead loop. The only
consequence here is that the freed pages in AllocateAlignedPages() cannot be
set as not-present. But it's ok because they're just allocated and haven't been
used by any other code.
> >
> > Cc: Laszlo Ersek
> > Cc: Star Zeng
> > Cc: Michael D Kinney
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > UefiCpuPkg/CpuDxe/CpuPageTable.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > index 33e8ee2d2c..2145e623fa 100644
> > --- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > +++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
> > @@ -100,6 +100,7 @@ PAGE_ATTRIBUTE_TABLE mPageAttributeTable[] = {
> > };
> >
> > PAGE_TABLE_POOL *mPageTablePool = NULL;
> > +EFI_LOCK mPageTablePoolLock =
> EFI_INITIALIZE_LOCK_VARIABLE (TPL_NOTIFY);
>
> Why does this have to be an "EFI_LOCK"? Can't we just use a global variable?
> (I
> don't understand why messing with the TPL is necessary.)
>
> In fact, I totally don't understand the point of EfiAcquireLock(). If we have
> two
> independent resources, each protected with its own separate lock, then why do
> both locks share the system-wide TPL between each other?
>
Maybe you're right. Lock is a bit overkill. I'll try a global to find out if
it's ok.
>
> > PAGE_TABLE_LIB_PAGING_CONTEXT mPagingContext;
> > EFI_SMM_BASE2_PROTOCOL*mSmmBase2 = NULL;
> >
> > @@ -1045,6 +1046,12 @@ InitializePageTablePool (
> > {
> >VOID *Buffer;
> >BOOLEAN IsModified;
> > + EFI_STATUSStatus;
> > +
> > + Status = EfiAcquireLockOrFail (&mPageTablePoolLock);
> > + if (EFI_ERROR (Status)) {
> > +return FALSE;
> > + }
> >
> >//
> >// Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES, including one
> page for
> > @@ -1056,
Re: [edk2] [PATCH 3/3] MdeModulePkg/Core: add use-after-free memory detection
Star,
Thanks for the comment. Please see my opinions below.
Regards,
Jian
> -Original Message-
> From: Zeng, Star
> Sent: Monday, October 22, 2018 10:53 AM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> ; Yao, Jiewen ; Laszlo Ersek
> ; Zeng, Star
> Subject: Re: [edk2] [PATCH 3/3] MdeModulePkg/Core: add use-after-free
> memory detection
>
> On 2018/10/19 9:50, Jian J Wang wrote:
> > UAF (Use-After-Free) memory detection is new feature introduced to
> > detect illegal access to memory which has been freed. The principle
> > behind is similar to heap guard feature, that is the core turn all pool
> > memory allocation to page allocation and mark them to be not-present
> > once they are freed.
> >
> > This also implies that, once a page is allocated and freed, it cannot
> > be re-allocated. This will bring another issue, which is that there's
> > risk that memory space will be used out. To address it, the memory
> > service add logic to put part (at most 64 pages a time) of freed pages
> > back into page pool, so that the memory service can still have memory
> > to allocate, when all memory space have been allocated once. This is
> > called memory promotion. The promoted pages are always from the eldest
> > pages which haven been freed.
> >
> > To use this feature, one can simply set following PCD to 1
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdUseAfterFreeDetectionPropertyMask
> >
> > Please note this feature cannot be used with heap guard feature controlled
> > by PCD gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask.
> >
> > Cc: Star Zeng
> > Cc: Michael D Kinney
> > Cc: Jiewen Yao
> > Cc: Ruiyu Ni
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
>
> I did not review the whole patch thoroughly. But I suggest that putting
> the code for UAF in a separated file if it is feasible. I am aware that
> UAF will be sharing much code with HeapGuard, so could we have Uaf.c,
> HeapGuard.c and GuardPage.c (this file name is just for example)?
>
I think we can take the UAF as a special kind of heap guard: guarding the
freed heap memory instead of guarding the allocated heap memory. So
UAF is a complement of Heap Guard or part of Heap Guard. From this
perspective, it's not necessary to put it in separate file.
> > ---
> > MdeModulePkg/Core/Dxe/DxeMain.h | 1 +
> > MdeModulePkg/Core/Dxe/DxeMain.inf| 1 +
> > MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 8 +
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.c| 393
> ++-
> > MdeModulePkg/Core/Dxe/Mem/HeapGuard.h| 66 +
> > MdeModulePkg/Core/Dxe/Mem/Page.c | 39 ++-
> > MdeModulePkg/Core/Dxe/Mem/Pool.c | 21 +-
> > MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 16 +-
> > 8 files changed, 519 insertions(+), 26 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain.h
> b/MdeModulePkg/Core/Dxe/DxeMain.h
> > index 2dec9da5e3..ae75cc5b25 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain.h
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain.h
> > @@ -92,6 +92,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
> > #include
> > #include
> > #include
> > +#include
> >
> >
> > //
> > diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf
> b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > index 10375443c0..d91258c087 100644
> > --- a/MdeModulePkg/Core/Dxe/DxeMain.inf
> > +++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
> > @@ -198,6 +198,7 @@
> > gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
> > ##
> CONSUMES
> > gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
> ## CONSUMES
> > gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard
> > ##
> CONSUMES
> > +
> gEfiMdeModulePkgTokenSpaceGuid.PcdUseAfterFreeDetectionPropertyMask
> ## CONSUMES
> >
> > # [Hob]
> > # RESOURCE_DESCRIPTOR ## CONSUMES
> > diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > index d9c65a8045..e43ec74010 100644
> > --- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > +++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
> > @@ -160,6 +160,10 @@ CoreDumpGcdMemorySpaceMap (
> > EFI_GCD_MEMORY_SPACE_DESCRIPTOR *MemorySpaceMap;
> > UINTNIndex;
> >
> > +if ((GetDebugPrintErrorLevel () & DEBUG_GCD) == 0) {
> > +
Re: [edk2] [PATCH] MdePkg UefiLib: Check Table against NULL in ScanTableInSDT
Reviewed-by: Jian J Wang
> -Original Message-
> From: Zeng, Star
> Sent: Friday, October 19, 2018 4:07 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Gao, Liming ;
> Kinney, Michael D ; Wang, Jian J
>
> Subject: [PATCH] MdePkg UefiLib: Check Table against NULL in ScanTableInSDT
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1266
>
> af5e95215928e052445c473f1244412dadea8252 abstracted generic functions
> from different modules (IntelVTdDxe, S3SaveStateDxe, PcRtc,
> DpDynamicCommand and PiSmmCpuDxeSmm). Some of them (IntelVTdDxe and
> PcRtc) checked Table against NULL before accessing Table->Signature,
> some (S3SaveStateDxe, DpDynamicCommand and PiSmmCpuDxeSmm did not.
>
> The ScanTableInSDT() in Acpi.c of UefiLib was mainly from
> S3SaveStateDxe, so it does not check Table against NULL before
> accessing Table->Signature.
>
> This patch updates ScanTableInSDT() to check Table against NULL first
> before accessing Table->Signature.
>
> Cc: Liming Gao
> Cc: Michael D Kinney
> Cc: Jian J Wang
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdePkg/Library/UefiLib/Acpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdePkg/Library/UefiLib/Acpi.c b/MdePkg/Library/UefiLib/Acpi.c
> index 4df6731ff0a4..59a828835ca0 100644
> --- a/MdePkg/Library/UefiLib/Acpi.c
> +++ b/MdePkg/Library/UefiLib/Acpi.c
> @@ -67,7 +67,7 @@ ScanTableInSDT (
> EntryPtr = 0;
> CopyMem (&EntryPtr, (VOID *)(BasePtr + Index * TablePointerSize),
> TablePointerSize);
> Table = (EFI_ACPI_COMMON_HEADER *)((UINTN)(EntryPtr));
> -if (Table->Signature == Signature) {
> +if ((Table != NULL) && (Table->Signature == Signature)) {
>if (PreviousTable != NULL) {
> if (Table == PreviousTable) {
>*PreviousTableLocated = TRUE;
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/3] Add use-after-free memory detection
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1240 Tests: a. Access freed pages in shell to see if it triggers #PF b. Use debugger to verify page table attributes matching freed pages c. Exhaust memory space to see if the BIOS still works Regards, Jian > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] > Sent: Friday, October 19, 2018 9:50 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH 0/3] Add use-after-free memory detection > > UAF (Use-After-Free) memory detection is new feature introduced to > detect illegal access to memory which has been freed. > > Jian J Wang (3): > MdeModulePkg/MdeModulePkg.dec: add new PCD for UAF detection feature > UefiCpuPkg/CpuDxe: fix an infinite loop issue > MdeModulePkg/Core: add use-after-free memory detection > > MdeModulePkg/Core/Dxe/DxeMain.h | 1 + > MdeModulePkg/Core/Dxe/DxeMain.inf| 1 + > MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 8 + > MdeModulePkg/Core/Dxe/Mem/HeapGuard.c| 393 > ++- > MdeModulePkg/Core/Dxe/Mem/HeapGuard.h| 66 + > MdeModulePkg/Core/Dxe/Mem/Page.c | 39 ++- > MdeModulePkg/Core/Dxe/Mem/Pool.c | 21 +- > MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c | 16 +- > MdeModulePkg/MdeModulePkg.dec| 6 + > UefiCpuPkg/CpuDxe/CpuPageTable.c | 12 + > 10 files changed, 537 insertions(+), 26 deletions(-) > > -- > 2.16.2.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support
Mike, The code originate from Jiewen's work done years before. I think he validated related implementation. In addition, I also used following ways to verify those APIs: a. Use debugger to verify the parameters passed in is as expected. b. Disassemble the efi image to see if the calling convention is correct c. Update existing drivers (one for PEI and one for DXE) to overwrite local variable to see if it can catch the stack corruption. d. Write a driver which has local buffer overflow issue (write array variable cross boundary) and load it in shell I validated above with /GS, /RTCs and /GS + /RTCs separately. I think as long as we make sure the parameters are correct, we can decide how to implement them. Those APIs in VC's lib are meant for OS. We can't follow them with no changes for UEFI environment, right? Regards, Jian > -Original Message- > From: Kinney, Michael D > Sent: Friday, October 19, 2018 7:17 AM > To: Wang, Jian J ; Gao, Liming ; > edk2-devel@lists.01.org; Kinney, Michael D > Cc: Yao, Jiewen ; Andrew Fish > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain > support > > Jian, > > I do not see a description of the parameters, return > values or required behavior for those APIs in the header > files. How do you know if they are implemented correctly? > > How would we write tests for these APIs? > > Mike > > > -Original Message- > > From: Wang, Jian J > > Sent: Wednesday, October 17, 2018 7:16 PM > > To: Kinney, Michael D ; Gao, > > Liming ; edk2-devel > boun...@lists.01.org>; edk2-devel@lists.01.org > > Cc: Yao, Jiewen ; Andrew Fish > > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add > > MSFT toolchain support > > > > Mike, > > > > All those functions are declared in source files in > > Visual Studio except to > > __GSHandlerCheck(). But I can't find there's online link > > or document to those files > > and APIs. Is it ok to just list the file names? > > > > VC\INCLUDE\vcruntime.h: > > __security_check_cookie > > __report_gsfailure > > > > VC\INCLUDE\rtcapi.h: > > _RTC_CheckEsp > > _RTC_CheckStackVars > > _RTC_Shutdown > > _RTC_InitBase > > > > VC\crt\src\vcruntime\gs_report.c > > __report_rangecheckfailure > > > > I built the lib with all supported VS toolchains and all > > passed, but only tested > > with VS2015. I think I need to do more tests. Thanks for > > pointing it out. > > > > Regards, > > Jian > > > > > > > -Original Message- > > > From: Kinney, Michael D > > > Sent: Thursday, October 18, 2018 9:36 AM > > > To: Gao, Liming ; Wang, Jian J > > ; > > > edk2-devel ; edk2- > > de...@lists.01.org; > > > Kinney, Michael D > > > Cc: Yao, Jiewen ; Andrew Fish > > > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add MSFT toolchain > > > support > > > > > > Jian, > > > > > > Is there a link to the documentation for these new > > > functions? We should put the link in the file > > > headers. > > > > > > The link to docs should also be added to the BZ. > > > > > > Also, which VS compilers was this tested with? Are > > > different implementations required for different VS > > > compilers? > > > > > > Mike > > > > > > > -Original Message- > > > > From: Gao, Liming > > > > Sent: Wednesday, October 17, 2018 6:22 PM > > > > To: Wang, Jian J ; edk2-devel > > > > ; edk2- > > > > de...@lists.01.org > > > > Cc: Kinney, Michael D ; > > Yao, > > > > Jiewen ; Andrew Fish > > > > > > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add > > > > MSFT toolchain support > > > > > > > > Jian: > > > > The patch is good to me. Reviewed-by: Liming Gao > > > > > > > > > > > > Thanks > > > > Liming > > > > >-Original Message- > > > > >From: Wang, Jian J > > > > >Sent: Thursday, October 18, 2018 9:19 AM > > > > >To: edk2-devel ; > > edk2- > > > > de...@lists.01.org > > > > >Cc: Kinney, Michael D ; > > Yao, > > > > Jiewen > > > > >; Andrew Fish > > ; > > > > Gao, Liming > > > > > > > > > >S
Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support
Mike, I tested the lib with all supported MSFT toolchains. No difference found so far. Regards, Jian > -Original Message- > From: Kinney, Michael D > Sent: Thursday, October 18, 2018 9:36 AM > To: Gao, Liming ; Wang, Jian J ; > edk2-devel ; edk2-devel@lists.01.org; > Kinney, Michael D > Cc: Yao, Jiewen ; Andrew Fish > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain > support > > Jian, > > Is there a link to the documentation for these new > functions? We should put the link in the file > headers. > > The link to docs should also be added to the BZ. > > Also, which VS compilers was this tested with? Are > different implementations required for different VS > compilers? > > Mike > > > -Original Message- > > From: Gao, Liming > > Sent: Wednesday, October 17, 2018 6:22 PM > > To: Wang, Jian J ; edk2-devel > > ; edk2- > > de...@lists.01.org > > Cc: Kinney, Michael D ; Yao, > > Jiewen ; Andrew Fish > > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add > > MSFT toolchain support > > > > Jian: > > The patch is good to me. Reviewed-by: Liming Gao > > > > > > Thanks > > Liming > > >-Original Message- > > >From: Wang, Jian J > > >Sent: Thursday, October 18, 2018 9:19 AM > > >To: edk2-devel ; edk2- > > de...@lists.01.org > > >Cc: Kinney, Michael D ; Yao, > > Jiewen > > >; Andrew Fish ; > > Gao, Liming > > > > > >Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add MSFT toolchain > > >support > > > > > >Ping ... :) > > > > > >Regards, > > >Jian > > > > > > > > >> -Original Message- > > >> From: edk2-devel [mailto:edk2-devel- > > boun...@lists.01.org] > > >> Sent: Tuesday, October 16, 2018 8:59 AM > > >> To: edk2-devel ; > > edk2- > > >de...@lists.01.org > > >> Cc: Kinney, Michael D ; > > Yao, Jiewen > > >> ; Andrew Fish ; > > Gao, Liming > > >> > > >> Subject: Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add MSFT > > >toolchain > > >> support > > >> > > >> REF: > > https://bugzilla.tianocore.org/show_bug.cgi?id=1239 > > >> > > >> Regards, > > >> Jian > > >> > > >> > > >> > -Original Message- > > >> > From: edk2-devel [mailto:edk2-devel- > > boun...@lists.01.org] > > >> > Sent: Tuesday, October 16, 2018 8:55 AM > > >> > To: edk2-devel@lists.01.org > > >> > Cc: Kinney, Michael D ; > > Yao, Jiewen > > >> > ; Andrew Fish > > ; Gao, Liming > > >> > > > >> > Subject: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add MSFT toolchain > > >> > support > > >> > > > >> > This patch adds stack check support for MSFT > > toolchain, with > > >> > compiler option /GS and /RTCs. This functionality is > > similar > > >> > to the original ones supported by GCC toolchain. > > >> > > > >> > Usage example: > > >> > This is a NULL library instance. Add it under a > > [LibraryClasses] > > >> > section in dsc file to let it be built into all > > modules employed > > >> > in a platform. > > >> > > > >> > [LibraryClasses] > > >> > > > NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.i > > nf > > >> > > > >> > Please note all not modules can be built against > > this library. Most > > >> > of them are SEC type of modules, such as > > >> > > > >> > OvmfPkg/ResetVector/ResetVector.inf > > >> > > > >> > In this case, this library should not be added to a > > common > > >> > [LibraryClasses] section but to specific ones, like > > >> > [LibraryClasses.common.PEI_CORE/PEIM/...]. > > >> > > > >> > In addition, /GS and/or /RTCs should be added to > > compiler command line. > > >> > This can be done by adding something like below > > under [BuildOptions] > > >> > section in dsc file. > > >> > > > >> > [BuildOptions] > > >> > MSFT:DEBUG_*_*_CC_FLAGS = /GS /GL- > > >> > MSFT:DEBUG_*_*_CC_
Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support
Mike, All those functions are declared in source files in Visual Studio except to __GSHandlerCheck(). But I can't find there's online link or document to those files and APIs. Is it ok to just list the file names? VC\INCLUDE\vcruntime.h: __security_check_cookie __report_gsfailure VC\INCLUDE\rtcapi.h: _RTC_CheckEsp _RTC_CheckStackVars _RTC_Shutdown _RTC_InitBase VC\crt\src\vcruntime\gs_report.c __report_rangecheckfailure I built the lib with all supported VS toolchains and all passed, but only tested with VS2015. I think I need to do more tests. Thanks for pointing it out. Regards, Jian > -Original Message- > From: Kinney, Michael D > Sent: Thursday, October 18, 2018 9:36 AM > To: Gao, Liming ; Wang, Jian J ; > edk2-devel ; edk2-devel@lists.01.org; > Kinney, Michael D > Cc: Yao, Jiewen ; Andrew Fish > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain > support > > Jian, > > Is there a link to the documentation for these new > functions? We should put the link in the file > headers. > > The link to docs should also be added to the BZ. > > Also, which VS compilers was this tested with? Are > different implementations required for different VS > compilers? > > Mike > > > -Original Message- > > From: Gao, Liming > > Sent: Wednesday, October 17, 2018 6:22 PM > > To: Wang, Jian J ; edk2-devel > > ; edk2- > > de...@lists.01.org > > Cc: Kinney, Michael D ; Yao, > > Jiewen ; Andrew Fish > > > > Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add > > MSFT toolchain support > > > > Jian: > > The patch is good to me. Reviewed-by: Liming Gao > > > > > > Thanks > > Liming > > >-Original Message- > > >From: Wang, Jian J > > >Sent: Thursday, October 18, 2018 9:19 AM > > >To: edk2-devel ; edk2- > > de...@lists.01.org > > >Cc: Kinney, Michael D ; Yao, > > Jiewen > > >; Andrew Fish ; > > Gao, Liming > > > > > >Subject: RE: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add MSFT toolchain > > >support > > > > > >Ping ... :) > > > > > >Regards, > > >Jian > > > > > > > > >> -Original Message- > > >> From: edk2-devel [mailto:edk2-devel- > > boun...@lists.01.org] > > >> Sent: Tuesday, October 16, 2018 8:59 AM > > >> To: edk2-devel ; > > edk2- > > >de...@lists.01.org > > >> Cc: Kinney, Michael D ; > > Yao, Jiewen > > >> ; Andrew Fish ; > > Gao, Liming > > >> > > >> Subject: Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add MSFT > > >toolchain > > >> support > > >> > > >> REF: > > https://bugzilla.tianocore.org/show_bug.cgi?id=1239 > > >> > > >> Regards, > > >> Jian > > >> > > >> > > >> > -Original Message- > > >> > From: edk2-devel [mailto:edk2-devel- > > boun...@lists.01.org] > > >> > Sent: Tuesday, October 16, 2018 8:55 AM > > >> > To: edk2-devel@lists.01.org > > >> > Cc: Kinney, Michael D ; > > Yao, Jiewen > > >> > ; Andrew Fish > > ; Gao, Liming > > >> > > > >> > Subject: [edk2] [PATCH] MdePkg/BaseStackCheckLib: > > add MSFT toolchain > > >> > support > > >> > > > >> > This patch adds stack check support for MSFT > > toolchain, with > > >> > compiler option /GS and /RTCs. This functionality is > > similar > > >> > to the original ones supported by GCC toolchain. > > >> > > > >> > Usage example: > > >> > This is a NULL library instance. Add it under a > > [LibraryClasses] > > >> > section in dsc file to let it be built into all > > modules employed > > >> > in a platform. > > >> > > > >> > [LibraryClasses] > > >> > > > NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.i > > nf > > >> > > > >> > Please note all not modules can be built against > > this library. Most > > >> > of them are SEC type of modules, such as > > >> > > > >> > OvmfPkg/ResetVector/ResetVector.inf > > >> > > > >> > In this case, this library should not be added to a > > common > > >> > [LibraryClasses] section but to specific one
Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain support
Ping ... :) Regards, Jian > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] > Sent: Tuesday, October 16, 2018 8:59 AM > To: edk2-devel ; edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Yao, Jiewen > ; Andrew Fish ; Gao, Liming > > Subject: Re: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain > support > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1239 > > Regards, > Jian > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] > > Sent: Tuesday, October 16, 2018 8:55 AM > > To: edk2-devel@lists.01.org > > Cc: Kinney, Michael D ; Yao, Jiewen > > ; Andrew Fish ; Gao, Liming > > > > Subject: [edk2] [PATCH] MdePkg/BaseStackCheckLib: add MSFT toolchain > > support > > > > This patch adds stack check support for MSFT toolchain, with > > compiler option /GS and /RTCs. This functionality is similar > > to the original ones supported by GCC toolchain. > > > > Usage example: > > This is a NULL library instance. Add it under a [LibraryClasses] > > section in dsc file to let it be built into all modules employed > > in a platform. > > > > [LibraryClasses] > > NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf > > > > Please note all not modules can be built against this library. Most > > of them are SEC type of modules, such as > > > > OvmfPkg/ResetVector/ResetVector.inf > > > > In this case, this library should not be added to a common > > [LibraryClasses] section but to specific ones, like > > [LibraryClasses.common.PEI_CORE/PEIM/...]. > > > > In addition, /GS and/or /RTCs should be added to compiler command line. > > This can be done by adding something like below under [BuildOptions] > > section in dsc file. > > > > [BuildOptions] > > MSFT:DEBUG_*_*_CC_FLAGS = /GS /GL- > > MSFT:DEBUG_*_*_CC_FLAGS = /RTCs /Od > > > > Note: /GL- is required for /GS, and /Od is required for /RTCs. > > Note: The flash layout might be needed to update to accommodate larger > > image size due to /Od is enforced. > > > > Pass tests: > > a. Overwrite a local buffer variable (in a 32-bit and 64-bit driver)and > >check if it's caught by new code (on both real platform and virtual > >platform) > > b. Boot Windows 10 and Ubuntu 18.04 on real platform with this > >lib built-in > > > > Cc: Michael D Kinney > > Cc: Liming Gao > > Cc: Jiewen Yao > > Cc: Andrew Fish > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Jian J Wang > > --- > > .../BaseStackCheckLib/BaseStackCheckLib.inf| 11 +- > > .../Library/BaseStackCheckLib/BaseStackCheckMsft.c | 221 > > + > > .../Library/BaseStackCheckLib/BaseStackCheckNull.c | 15 -- > > .../BaseStackCheckLib/Ia32/StackCheckStubAsm.nasm | 76 +++ > > .../BaseStackCheckLib/X64/StackCheckStubAsm.nasm | 54 + > > 5 files changed, 360 insertions(+), 17 deletions(-) > > create mode 100644 > > MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c > > delete mode 100644 > MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c > > create mode 100644 > > MdePkg/Library/BaseStackCheckLib/Ia32/StackCheckStubAsm.nasm > > create mode 100644 > > MdePkg/Library/BaseStackCheckLib/X64/StackCheckStubAsm.nasm > > > > diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf > > b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf > > index e280651b11..1c9e6710c6 100644 > > --- a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf > > +++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf > > @@ -4,6 +4,7 @@ > > # Stack Check Library > > # > > # Copyright (c) 2014, ARM Ltd. All rights reserved. > > +# Copyright (c) 2018, Intel Corporation. All rights reserved. > > # > > # This program and the accompanying materials > > # are licensed and made available under the terms and conditions of the > > BSD > > License > > @@ -26,13 +27,19 @@ > > > > > > # > > -# VALID_ARCHITECTURES = ARM AARCH64 > > +# VALID_ARCHITECTURES = ARM AARCH64 IA32 X64 > > # > > > > [Sources] > >BaseStackCheckGcc.c | GCC > >BaseStackCheckGcc.c | RVCT > > - BaseStackCheckNull.c | MSFT > > + BaseStackCheckMsft.c | MSFT > > + > > +[Sources.IA32] > > + Ia32/StackCheckStubAsm.nasm | MSFT > > + > > +[Sources.X64] > > + X64/StackCheckStubAsm.nasm | MSFT > > > > [Packages] > >MdePkg/MdePkg.dec > > diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c > > b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c > > new file mode 100644 > > index 00..951154f0cd > > --- /dev/null > > +++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckMsft.c > > @@ -0,0 +1,221 @@ > > +/** @file > > + Base Stack Check library for MSFT toolchains compiler options: /GS, RTCs. > > + > > +Copyright (c) 2018, Intel Corporation. All rights reserved. > > +This program and the accompanying materials are licensed and made > available > > under > > +the terms a
