Re: [edk2-devel] [PATCH v1 0/2] Fix backward incompatible CPU_MP_DATA struct change

2020-02-05 Thread Wu, Hao A
> -Original Message- > From: Wu, Hao A > Sent: Thursday, February 06, 2020 1:24 PM > To: devel@edk2.groups.io > Cc: Wu, Hao A; Kubacki, Michael A; Kinney, Michael D; Dong, Eric; Ni, Ray; > Laszlo Ersek > Subject: [PATCH v1 0/2] Fix backward incompatible CPU_MP_DATA struct > change > > The

[edk2-devel] [PATCH v1] Maintainers.txt: Change NetworkPkg maintainer role.

2020-02-05 Thread Wu, Jiaxin
Change Jiaxin Wu from Maintainer to Reviewer. Cc: Maciej Rabeda Cc: Siyuan Fu Signed-off-by: Jiaxin Wu --- Maintainers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Maintainers.txt b/Maintainers.txt index ca9da28925..00b46a4884 100644 --- a/Maintainers.txt +++

[edk2-devel] [PATCH v1 1/2] Revert UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATA

2020-02-05 Thread Wu, Hao A
This reverts commit 88bd06616617ef2569f093f7b51893c11ad78e26. REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2465 Commit 88bd0661661 relocates the 'MicrocodePatchAddress' and 'MicrocodePatchRegionSize' fields in structure CPU_MP_DATA to ensure that they can be properly passed between

[edk2-devel] [PATCH v1 2/2] UefiCpuPkg/MpInitLib: Not pass microcode info between archs in CPU_MP_DATA

2020-02-05 Thread Wu, Hao A
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2465 Commit 89164babec: UefiCpuPkg/MpInitLib: don't shadow the microcode patch twice. attempted to use 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' fields to avoid loading the microcode patches data into memory again in the DXE phase.

[edk2-devel] [PATCH v1 0/2] Fix backward incompatible CPU_MP_DATA struct change

2020-02-05 Thread Wu, Hao A
The series will resolve a backward compatibility issue with pre-built binaries (e.g. FSP) introduced by commit 88bd0661661. The relocation of 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' fields in structure CPU_MP_DATA may cause access issue for platforms that use pre-built FSP binary,

Re: [EXTERNAL] Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

2020-02-05 Thread Bret Barkelew via Groups.Io
Kevin, Agreed and we were sensitive to that in our codebase as well. Surface and other consumers had drivers expecting VarLock and we didn’t want to have to rewrite them all (at least not immediately). If you take a look at the MuVarPolicyFoundationDxe driver in the extras branch… It contains

[edk2-devel] [PATCH v1] MdeModulePkg/PiDxeS3BootScriptLib: Fix potential numeric truncation (CVE-2019-14563)

2020-02-05 Thread Wu, Hao A
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2001 For S3BootScriptLib APIs: S3BootScriptSaveIoWrite S3BootScriptSaveMemWrite S3BootScriptSavePciCfgWrite S3BootScriptSavePciCfg2Write S3BootScriptSaveSmbusExecute S3BootScriptSaveInformation S3BootScriptSaveInformationAsciiString

Re: [edk2-devel] [PATCH v1] UefiCpuPkg/MpInitLib: Always get CPUID & PlatformID in MicrocodeDetect()

2020-02-05 Thread Wu, Hao A
Thanks Siyuan and Eric, The patch has been pushed via commit a9e3458ba7. Best Regards, Hao Wu > -Original Message- > From: Dong, Eric > Sent: Tuesday, February 04, 2020 9:47 PM > To: devel@edk2.groups.io; Wu, Hao A > Cc: Ni, Ray; Laszlo Ersek; Fu, Siyuan; Kinney, Michael D > Subject:

Re: [edk2-devel] [PATCH 0/1] Use _MSC_VER to determine MSVC compiler

2020-02-05 Thread Vitaly Cheptsov via Groups.Io
4 февр. 2020 г., в 09:56, Gao, Liming написал(а):Vitaly:  Yes. I think we should have better solution in OpenSSL to support EDK2 usage. But, this is a long term solution. For now, I will try the solution to remove -fms-compatibility option in CLANGPDB tool

Re: [edk2-devel] [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash Calculation API

2020-02-05 Thread Laszlo Ersek
On 02/05/20 17:18, Kinney, Michael D wrote: > Jian, > > I agree. If the PCD type is anything but FixedAtBuild, > the compiler can not optimize away the unused BaseCryptLib > functions. > > I think the best solution is to limit this PCD to only > FixedAtBuild. I agree that that technically

Re: [edk2-devel] setting the push label at once, when opening a PR [was: SecurityPkg/DxeImageVerificationHandler: fix retval for "deny" policy]

2020-02-05 Thread Laszlo Ersek
On 02/05/20 17:16, Kinney, Michael D wrote: > Hi Laszlo, > > If I follow this link, I see the expected screen with the ability to set a > label: > > https://github.com/lersek/edk2/pull/new/smram_at_default_smbase_bz_1512_wave_1_v2_pull > > If I type in the following URL from your screen shot,

Re: [edk2-devel] [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash Calculation API

2020-02-05 Thread Michael D Kinney
Jian, I agree. If the PCD type is anything but FixedAtBuild, the compiler can not optimize away the unused BaseCryptLib functions. I think the best solution is to limit this PCD to only FixedAtBuild. Thank you for noticing this issue Laszlo! Mike > -Original Message- > From: Wang,

Re: [edk2-devel] setting the push label at once, when opening a PR [was: SecurityPkg/DxeImageVerificationHandler: fix retval for "deny" policy]

2020-02-05 Thread Michael D Kinney
Hi Laszlo, If I follow this link, I see the expected screen with the ability to set a label: https://github.com/lersek/edk2/pull/new/smram_at_default_smbase_bz_1512_wave_1_v2_pull If I type in the following URL from your screen shot, I also get the same screen with the ability to set a label:

[edk2-devel] [PATCH v4 1/1] BaseTools: Script for converting .aml to .hex

2020-02-05 Thread PierreGondois
From: Pierre Gondois The "-tc" option of the iasl compiler allows to generate a .hex file containing a C array storing AML bytecode. An online discussion suggested that this "-tc" option was specific to the iasl compiler and it shouldn't be relied on. This conversation is available at:

[edk2-devel] [edk2-platform] FitGen: Support FV with the extension header

2020-02-05 Thread Liming Gao
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2086 To find Microcode FILE in FV image, need to skip FV header and FV extension header, then find the first RAW FFS file. Cc: Bob Feng Signed-off-by: Liming Gao --- Silicon/Intel/Tools/FitGen/FitGen.c | 40

[edk2-devel] [edk2-platform][patch v3] FitGen: Fix the issue to run in X64 linux machine

2020-02-05 Thread Liming Gao
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2466 Memory allocation (malloc) may return the buffer address be above 4G. Current logic always converts the memory address to UINT32. It will cause memory read and free corrupt. This patch uses pointer to store the allocated memory address. Cc:

Re: [edk2-devel] [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash Calculation API

2020-02-05 Thread Wang, Jian J
Laszlo, According to RFC discussion, using PCD here is mainly for optimization purpose. So I think we should limit the PCD type to just FixedAtBuild. Then there's no problem for modules linking this library. Regards, Jian > -Original Message- > From: Laszlo Ersek > Sent: Wednesday,

Re: [edk2-devel] [PATCH 0/3] BaseTools/Scripts: .mailmap improvements

2020-02-05 Thread Bob Feng
This patch set looks good to me. Reviewed-by: Bob Feng -Original Message- From: Philippe Mathieu-Daude [mailto:phi...@redhat.com] Sent: Wednesday, February 5, 2020 6:49 AM To: devel@edk2.groups.io Cc: Philippe Mathieu-Daude ; Feng, Bob C ; Gao, Liming Subject: [PATCH 0/3]

Re: [edk2-devel] [PATCH] MdeModulePkg: Perform test only if not ignore memory test

2020-02-05 Thread Ni, Ray
Reviewed-by: Ray Ni > -Original Message- > From: devel@edk2.groups.io On Behalf Of Heng Luo > Sent: Tuesday, January 14, 2020 4:54 PM > To: devel@edk2.groups.io > Subject: [edk2-devel] [PATCH] MdeModulePkg: Perform test only if not ignore > memory test > > REF:

Re: [edk2-devel] [RFC] VariablePolicy - Protocol, Libraries, and Implementation for VariableLock Alternative

2020-02-05 Thread Yao, Jiewen
HI Bret Thanks for the work. The design doc is very good. Some feedback/questions below: 1. We have 2 variable related protocol - EDKII_VARIABLE_LOCK_PROTOCOL and EDKII_VAR_CHECK_PROTOCOL. Do you want to deprecate both? Or only deprecate EDKII_VARIABLE_LOCK_PROTOCOL? 2. The Function -

Re: [edk2-devel] [PATCH v2 1/1] BaseTools: Rationalise makefile generation

2020-02-05 Thread Bob Feng
Hi Pierre, I agree with this change. But for this patch, I found there are two bugs. 1. +# Get Makefile name. +def getMakefileName(self): +if not self._FileType: +return _DEFAULT_FILE_NAME_ Should be self. _DEFAULT_FILE_NAME_ +else: +return

Re: [edk2-devel] [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash Calculation API

2020-02-05 Thread Laszlo Ersek
Hi, sorry I'm late to this discussion. I'd only like to mention a potential future improvement: On 02/04/20 00:35, Michael D Kinney wrote: > +[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] > + ## This PCD indicates the HASH algorithm to calculate hash of data > + #

Re: [edk2-devel] [Patch] BaseTools tools_def.template: Add back -fno-pie option in GCC49 tool chain

2020-02-05 Thread Liming Gao
Mike: GCC IA32 arch requires -fno-pie option. You can check the commit c25d3905523ae4961bb039b1aba597983f7e3e4e "BaseTools/tools_def IA32: disable PIE code generation explicitly". GCC X64 arch requires -fpie option. You can check the commit f49513f666ed25d24bdf3a02a1fdb5d18ae081c0 "