Date   

Re: [PATCH v1 2/3] MdeModulePkg/PciBusDxe: Fix possible uninitialized use

Wu, Hao A
 

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sergei
Dmitrouk
Sent: Tuesday, May 18, 2021 12:23 AM
To: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>
Subject: Re: [edk2-devel] [PATCH v1 2/3] MdeModulePkg/PciBusDxe: Fix
possible uninitialized use

If the function gets invalid value for the `ResizableBarOp` parameter and
asserts are disabled, `Bit` can be used uninitialized.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Ray Ni <ray.ni@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---

Notes:
v2:
- simplify if-statement to avoid unused branches

Hello,

Since the V1 is a patch series, I would suggest to send the whole series for V2 changes (even if other patches are unchanged).

With this handled:
Reviewed-by: Hao A Wu <hao.a.wu@...>

Best Regards,
Hao Wu


MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
index 6bba28367165..4caac56f1dcd 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
@@ -1778,10 +1778,9 @@ PciProgramResizableBar (

if (ResizableBarOp == PciResizableBarMax) {
Bit = HighBitSet64(Capabilities);
- } else if (ResizableBarOp == PciResizableBarMin) {
+ } else {
+ ASSERT (ResizableBarOp == PciResizableBarMin);
Bit = LowBitSet64(Capabilities);
- } else {
- ASSERT ((ResizableBarOp == PciResizableBarMax) || (ResizableBarOp ==
PciResizableBarMin));
}

ASSERT (Bit >= 0);
--
2.17.6





Re: [PATCH] UefiCpuPkg/PiSmmCpu: Remove hardcode 48 address size limitation

Ni, Ray
 

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Sunday, May 16, 2021 9:39 AM
To: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/PiSmmCpu: Remove hardcode 48 address size limitation

On 05/15/21 02:04, Ni, Ray wrote:
Laszlo,
Do you think that another API is also needed: GetPhysicalAddressWidth() that returns number 36/52?
No. The GetPhysicalAddressBits() function that I proposed already returns this information. It has three outputs: the number of
bits (that is, the width), as return value, and the two optional output parameters.

So if you only need the the bit count, call

GetPhysicalAddressBits (NULL, NULL);

These calculations are so cheap and small that keeping them in a single function makes a lot of sense in my opinion.
I wasn't aware of the return value of the API. with your API, there is no need for another API to retrieve the address size.

For a critical bugfix, I would prefer not mixing the actual fix with the introduction of the symbolic names. Your patch currently
fixes three things at the same time: (1) coding style (it replaces magic constants with macros / type names), (2) a bug in
calculation, (3) a missing CPUID "maximum function" check.

Maybe writing a separate patch for each of these is unjustified, but I was really unhappy to see that the commit message said
nothing about (1) and (3), and I had to hunt down (2) between the other changes.

The minimal fix -- that is, the fix for (2) -- would be just one line:

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index fd6583f9d172..4592b76fe595 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -1920,7 +1920,7 @@ InitializeMpServiceData (
//
AsmCpuid (0x80000008, (UINT32*)&Index, NULL, NULL, NULL);
gPhyMask = LShiftU64 (1, (UINT8)Index) - 1;
- gPhyMask &= (1ull << 48) - EFI_PAGE_SIZE;
+ gPhyMask &= 0xfffffffffffff000ULL;

//
// Create page tables


I don't like that the patch currently does three things but only documents one.
Thanks for explaining why you don't think it's a good patch. I thought anytime changing a code,
I should try to make it better, functional better, looks better.

I will follow your suggestion next time for bug fixes.


That said, if you are out of time, feel free to go ahead with Eric's R-b.
Indeed. thanks for the understanding.


Thanks
Laszlo









Re: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible uninitialized use

Wang, Jian J
 

Ard,

Patch 1&2 haven't got r-b. I'm not sure we can merge patch 3 separately.

Regards,
Jian

-----Original Message-----
From: Ard Biesheuvel <ardb@...>
Sent: Tuesday, May 18, 2021 3:27 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>; Liming Gao (Byosoft address)
<gaoliming@...>
Cc: sergei@...; Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: Re: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized use

Please merge this fix asap. Our CI is broken because of it, and we are
in the soft freeze so we need the CI up and running to catch potential
issues before the release.

Thanks,
Ard.

On Tue, 18 May 2021 at 02:59, gaoliming <gaoliming@...> wrote:

Sergei:
Yes. GCC49 is LTO disable GCC tool chain. GCC5 is LTO enable tool chain.
They both work on the different GCC version, such as gcc5, gcc6..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844 mentions
-ffat-lto-objects option that can trig the warning with LTO option. Do you
try it?

If this option works, we can update GCC5 tool chain definition in
tools_def.txt, then this issue can be detected in CI GCC5 build.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sergei
Dmitrouk
发送时间: 2021年5月15日 21:01
收件人: devel@edk2.groups.io; jiewen.yao@...
抄送: Wang, Jian J <jian.j.wang@...>; Lu, XiaoyuX
<xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>
主题: Re: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized use

Hello Jiewen,

I get the error only for GCC49 and not for GCC5 toolchain. CI uses GCC5.

So I compared build commands and this seems to depend on LTO. Adding
`-flto`
impedes compiler's ability to detect such simple issues.

I've found relevant bug report, there is even fix suggestion from last
month:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844

Regards,
Sergei

On Sat, May 15, 2021 at 12:30:44AM +0000, Yao, Jiewen wrote:
Hi Sergei
Thank you very much for the fix.
Reviewed-by: Jiewen Yao <Jiewen.yao@...>

I am a little surprised why it is not caught before. It is an obvious
logic issue.

Do you think we can do anything on CI, to catch it during pre-check-in
in the
future?
I just feel it is burden to make it post-check-in fix.


Thank you
Yao Jiewen

-----Original Message-----
From: Sergei Dmitrouk <sergei@...>
Sent: Friday, May 14, 2021 8:17 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>;
Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized
use

`Result` can be used uninitialized in both functions after following
either first or second `goto` statement.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyux.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c | 1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c | 1 +
2 files changed, 2 insertions(+)

diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
index 4009d37d5f91..0b2960f06c4c 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
@@ -82,6 +82,7 @@ RsaPssVerify (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
index b66b6f7296ad..ece765f9ae0a 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
@@ -97,6 +97,7 @@ RsaPssSign (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
--
2.17.6









Re: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible uninitialized use

Ard Biesheuvel
 

Please merge this fix asap. Our CI is broken because of it, and we are
in the soft freeze so we need the CI up and running to catch potential
issues before the release.

Thanks,
Ard.

On Tue, 18 May 2021 at 02:59, gaoliming <gaoliming@...> wrote:

Sergei:
Yes. GCC49 is LTO disable GCC tool chain. GCC5 is LTO enable tool chain.
They both work on the different GCC version, such as gcc5, gcc6..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844 mentions
-ffat-lto-objects option that can trig the warning with LTO option. Do you
try it?

If this option works, we can update GCC5 tool chain definition in
tools_def.txt, then this issue can be detected in CI GCC5 build.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sergei
Dmitrouk
发送时间: 2021年5月15日 21:01
收件人: devel@edk2.groups.io; jiewen.yao@...
抄送: Wang, Jian J <jian.j.wang@...>; Lu, XiaoyuX
<xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>
主题: Re: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized use

Hello Jiewen,

I get the error only for GCC49 and not for GCC5 toolchain. CI uses GCC5.

So I compared build commands and this seems to depend on LTO. Adding
`-flto`
impedes compiler's ability to detect such simple issues.

I've found relevant bug report, there is even fix suggestion from last
month:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844

Regards,
Sergei

On Sat, May 15, 2021 at 12:30:44AM +0000, Yao, Jiewen wrote:
Hi Sergei
Thank you very much for the fix.
Reviewed-by: Jiewen Yao <Jiewen.yao@...>

I am a little surprised why it is not caught before. It is an obvious
logic issue.

Do you think we can do anything on CI, to catch it during pre-check-in
in the
future?
I just feel it is burden to make it post-check-in fix.


Thank you
Yao Jiewen

-----Original Message-----
From: Sergei Dmitrouk <sergei@...>
Sent: Friday, May 14, 2021 8:17 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>;
Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized
use

`Result` can be used uninitialized in both functions after following
either first or second `goto` statement.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyux.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c | 1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c | 1 +
2 files changed, 2 insertions(+)

diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
index 4009d37d5f91..0b2960f06c4c 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
@@ -82,6 +82,7 @@ RsaPssVerify (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
index b66b6f7296ad..ece765f9ae0a 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
@@ -97,6 +97,7 @@ RsaPssSign (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
--
2.17.6









[PATCH EDK2 v1 1/1] MdeModulePkg/HiiDatabaseDxe: remove dead code

wenyi,xie
 

Outer condition is 'BlockData->Name==NULL' and inner
condition is 'BlockData->Name!=NULL', Opposite 'if'
condition leads to a dead code block.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Dandan Bi <dandan.bi@...>
Cc: Eric Dong <eric.dong@...>
Signed-off-by: Wenyi Xie <xiewenyi2@...>
---
MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 3 ---
1 file changed, 3 deletions(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
index d492b769d51c..17a914208c6d 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
@@ -2871,9 +2871,6 @@ ParseIfrData (
//
if ((BlockData->Name == NULL) && ((BlockData->Offset + BlockData->Width) > VarStorageData->Size)) {
Status = EFI_INVALID_PARAMETER;
- if (BlockData->Name != NULL) {
- FreePool (BlockData->Name);
- }
FreePool (BlockData);
goto Done;
}
--
2.20.1.windows.1


[PATCH EDK2 v1 0/1] MdeModulePkg/HiiDatabaseDxe: remove dead code

wenyi,xie
 

Main Changes :
Remove dead code.

Wenyi Xie (1):
MdeModulePkg/HiiDatabaseDxe: remove dead code

MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c | 3 ---
1 file changed, 3 deletions(-)

--
2.20.1.windows.1


Re: [PATCH v3] IntelFsp2Pkg: YAML script bug fix

Chiu, Chasel
 

Pushed: 1fbf5e30ae8eb725f4e10984f7b0a208f78abbd0

Thanks,
Chasel

-----Original Message-----
From: Loo, Tung Lun <tung.lun.loo@...>
Sent: Monday, May 17, 2021 12:04 PM
To: devel@edk2.groups.io
Cc: Loo, Tung Lun <tung.lun.loo@...>; Ma, Maurice
<maurice.ma@...>; Desimone, Nathaniel L
<nathaniel.l.desimone@...>; Zeng, Star <star.zeng@...>; Chiu,
Chasel <chasel.chiu@...>
Subject: [PATCH v3] IntelFsp2Pkg: YAML script bug fix

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

This patch fixes the issue observed during BSF file to YAML file conversion. It
also addresses the issue during multibyte array data conversion check, for
example the data representation of 0xFFFF instead of 0xFF, 0xFF would be
thrown exception "Array size is not proper" without this patch.

Cc: Maurice Ma <maurice.ma@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Star Zeng <star.zeng@...>
Cc: Chasel Chiu <chasel.chiu@...>
Signed-off-by: Loo Tung Lun <tung.lun.loo@...>
---
IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py | 11 +++++++++--
IntelFsp2Pkg/Tools/GenCfgOpt.py | 3 ++-
2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py
b/IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py
index cad9b60e73..d2ca7145ae 100644
--- a/IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py
+++ b/IntelFsp2Pkg/Tools/FspDscBsf2Yaml.py
@@ -46,6 +46,13 @@ def Bytes2Val(Bytes):
return reduce(lambda x, y: (x << 8) | y, Bytes[::-1]) +def Str2Bytes(Value,
Blen):+ Result = bytearray(Value[1:-1], 'utf-8') # Excluding quotes+ if
len(Result) < Blen:+ Result.extend(b'\x00' * (Blen - len(Result)))+ return
Result++ class CFspBsf2Dsc: def __init__(self, bsf_file):@@ -108,7 +115,8
@@ class CFspBsf2Dsc:
cfg_item['find'] = prefix cfg_item['cname'] = 'Signature'
cfg_item['length'] = len(finds[0][1])- cfg_item['value'] = '0x%X' %
Bytes2Val(finds[0][1].encode('UTF-8'))+ str2byte = Str2Bytes("'" +
finds[0][1] + "'", len(finds[0][1]))+ cfg_item['value'] = '0x%X' %
Bytes2Val(str2byte) cfg_list.append(dict(cfg_item)) cfg_item =
dict(cfg_temp) find_list.pop(0)@@ -291,7 +299,6 @@ class
CFspDsc2Yaml():
raise Exception('DSC variable creation error !') else: raise
Exception('Unsupported file "%s" !' % file_name)-
gen_cfg_data.UpdateDefaultValue() self.gen_cfg_data = gen_cfg_data
def print_dsc_line(self):diff --git a/IntelFsp2Pkg/Tools/GenCfgOpt.py
b/IntelFsp2Pkg/Tools/GenCfgOpt.py
index 660824b740..714b2d8b1a 100644
--- a/IntelFsp2Pkg/Tools/GenCfgOpt.py
+++ b/IntelFsp2Pkg/Tools/GenCfgOpt.py
@@ -708,7 +708,8 @@ EndList
for Page in PageList: Page = Page.strip()
Match = re.match("(\w+):\"(.+)\"", Page)-
self._CfgPageDict[Match.group(1)] = Match.group(2)+ if
Match != None:+ self._CfgPageDict[Match.group(1)] =
Match.group(2) Match =
re.match("(?:^|.+\s+)BLOCK:{NAME:\"(.+)\"\s*,\s*VER:\"(.+)\"\s*}", Remaining)
if Match:--
2.28.0.windows.1


Re: 回复: [edk2-devel] [PATCH v1 1/1] Add MemoryFence implementation for RiscV64

Daniel Schaefer
 

On 5/18/21 9:04 AM, gaoliming wrote:
Daniel:
Seemly, this API is missing in BaseLib for RiscV64 arch. How do you detect
this issue?
What do you mean it's missing?
Yes MemoryFence() for RiscV64 is missing currently, that's why I'm adding it here.

Maybe you mean that it's not currently used? That's also true.
I'm enabling the generic QEMU virt machine (like OVMF or ArmVirtPkg) for RISC-V.
At least QemuFwCfgLib and VirtioLib need it.
That's why I have the need to add this implementation now.

Does that clear it up?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Daniel
Schaefer
发送时间: 2021年5月16日 2:13
收件人: devel@edk2.groups.io
抄送: Abner Chang <abner.chang@...>; Michael D Kinney
<michael.d.kinney@...>; Liming Gao <gaoliming@...>;
Zhiguang Liu <zhiguang.liu@...>; Leif Lindholm <leif@...>
主题: [edk2-devel] [PATCH v1 1/1] Add MemoryFence implementation for
RiscV64

Cc: Abner Chang <abner.chang@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Leif Lindholm <leif@...>
Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
---
MdePkg/Library/BaseLib/BaseLib.inf | 1 +
MdePkg/Library/BaseLib/RiscV64/MemoryFence.S | 33
++++++++++++++++++++
2 files changed, 34 insertions(+)

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
b/MdePkg/Library/BaseLib/BaseLib.inf
index b76f3af380ea..b7ab5f632366 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -399,6 +399,7 @@
RiscV64/DisableInterrupts.c


RiscV64/EnableInterrupts.c


RiscV64/CpuPause.c


+ RiscV64/MemoryFence.S | GCC


RiscV64/RiscVSetJumpLongJump.S | GCC


RiscV64/RiscVCpuBreakpoint.S | GCC


RiscV64/RiscVCpuPause.S | GCC


diff --git a/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
b/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
new file mode 100644
index 000000000000..283df9356a9a
--- /dev/null
+++ b/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
@@ -0,0 +1,33 @@
+##-------------------------------------------------------------------------
-----


+#


+# MemoryFence() for RiscV64


+


+# Copyright (c) 2021, Hewlett Packard Enterprise Development. All rights
reserved.


+#


+# SPDX-License-Identifier: BSD-2-Clause-Patent


+#


+##-------------------------------------------------------------------------
-----


+


+.text


+.p2align 2


+


+ASM_GLOBAL ASM_PFX(MemoryFence)


+


+


+#/**


+# Used to serialize load and store operations.


+#


+# All loads and stores that proceed calls to this function are
guaranteed to
be


+# globally visible when this function returns.


+#


+#**/


+#VOID


+#EFIAPI


+#MemoryFence (


+# VOID


+# );


+#


+ASM_PFX(MemoryFence):


+ // Fence on all memory and I/O


+ fence


+ ret


--
2.30.1











Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, 18 May 2021 #cal-cancelled

devel@edk2.groups.io Calendar <noreply@...>
 

Cancelled: TianoCore Bug Triage - APAC / NAMO

This event has been cancelled.

When:
Tuesday, 18 May 2021
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

Organizer: Liming Gao gaoliming@...

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


Re: [edk2-platforms PATCH] Platform/ARM: Update Readme.md

Chris Jones
 

Hi Rebecca,

Thank you for your patch.

It functionally looks good however I noticed one small grammatical error to fix, noted below.

Reviewed-by: Chris Jones <christopher.jones@...>


Thanks,
Chris

The repo with the Visual Studio support no longer exists.
fiptool from the prebuilt_tools repo doesn't work due to a missing
dependency on libcrypto.so.1.0.0, so tell users to build it from the
trusted-firmware-a repo instead.
There's a newer version of fvp-uefi.zip that was released in 2020.

Signed-off-by: Rebecca Cran <rebecca@...>
---
Platform/ARM/Readme.md | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/Platform/ARM/Readme.md b/Platform/ARM/Readme.md
index e1a405b700..afc9ad3646 100644
--- a/Platform/ARM/Readme.md
+++ b/Platform/ARM/Readme.md
@@ -8,10 +8,8 @@ can be found here:
=0D
##Requirements=0D
- A 32-bit or 64-bit Linux host machine.=0D
-- Visual Studio is not officially supported, experimental support can be f=
ound here:=0D
-[https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=3Daarch64-vs]=
=0D
=0D
-# Build EDK2 Tianocore=0D
+# Build EDK2 TianoCore=0D
=0D
`build -a AARCH64 -p Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc =
-t GCC5`=0D
=0D
@@ -26,7 +24,7 @@ prebuilt edk2 image.
=0D
We will also rely on the "run_model" script that comes with the prebuilts,=
it=0D
is entirely possible to run the model without this but would require quite=
a bit=0D
[CHRIS] This does not make sense, instead I suggest:
"of knowledge regarding the arguments of the ARM fastmodel (documentation can be f=
ound here:=0D".
Note: while this was not introduced by you it would be nice to fix now.
-of knowledge regarding the areguments ARM fastmodel (documentation can be =
found here:=0D
+of knowledge regarding the arguments ARM fastmodel (documentation can be f=
ound here:=0D

[https://developer.arm.com/docs/100966/1101/programming-reference-for-base=
-fvps/base-platform-revc-features])=0D
however the manual set of the FVP is outside the scope of this document. I=
f you are interested=0D
please consult the documentation.=0D
@@ -40,16 +38,18 @@ the binaries in the same directory.
- Select Armv8-A Base Platform FVP based on Fast Models 11.4=0D
- It has a click through license but is free.=0D
=0D
-2. Download the 18.10 Linaro ARM Landing Team release for FVP booting UEFI=
=0D
-https://releases.linaro.org/members/arm/platforms/18.10/fvp-uefi.zip=0D
+2. Download the 20.01 Linaro ARM Landing Team release for FVP booting UEFI=
=0D
+https://releases.linaro.org/members/arm/platforms/20.01/fvp-uefi.zip=0D
=0D
-3. Download the prebuilt fiptool from https://git.linaro.org/landing-teams=
/working/arm/prebuilt_tools.git=0D
+3. Clone the trusted firmware repo from https://git.trustedfirmware.org/TF=
-A/trusted-firmware-a.git=0D
=0D
-4. Update the fip.bin image from fvp-uefi.zip by running the following com=
mand:=0D
+4. Build fiptool: `make -C trusted-firmware-a/tools/fiptool`=0D
=0D
- `fiptool update --nt-fw=3D[path to binary built above] fip.bin`=0D
+5. Update the fip.bin image from fvp-uefi.zip by running the following com=
mand:=0D
=0D
-5. Execute the FVP run_model.sh script from fvp-uefi.zip and provide a pat=
h to the FVP binaries=0D
+ `./trusted-firmware-a/tools/fiptool/fiptool update --nt-fw=3D[path to bin=
ary built above] fip.bin`=0D
+=0D
+6. Execute the FVP run_model.sh script from fvp-uefi.zip and provide a pat=
h to the FVP binaries=0D
downloaded in step 1):=0D
=0D
`MODEL=3D[path to FVP binary] ./run_model.sh`=0D
--=20
2.31.1


回复: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 05/18/2021 6:30pm-7:30pm #cal-reminder

gaoliming
 

Few new issue is submitted this week. Let’s cancel the meeting this week.

 

3394

EDK2

Code

unassigned@...

UNCO

Add APIs for CPU physical address mask calculation

Fri 20:02

ray.ni@...

3393

Tianocor

Code

unassigned@...

UNCO

Add firmware support for Cloud Hypervisor on arm64

Fri 05:07

jianyong.wu@...

3392

EDK2

Code

unassigned@...

UNCO

Null pointers referenced in SecureBoot LoadSignattureData() and LoadSignatureList()

Thu 21:54

Allen_Wynn@...

3388

EDK2

Code

unassigned@...

UNCO

About the efficiency of Shell command

Thu 08:57

ptabckimo@...

3367

EDK2

Document

unassigned@...

UNCO

URL links | HTTP redirected to HTTPS or non-secure TLS version

Wed 05:09

ricky.tigg@...

3390

EDK2 Tes

UEFI-SCT

xypron.glpk@...

UNCO

uefi-sct: Incorrect test of EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.SetState()

Wed 03:49

xypron.glpk@...

3362

EDK2

Code

unassigned@...

UNCO

Changes required for STR_SMBIOSVIEW_PRINTINFO_BITS_48_64 to be STR_SMBIOSVIEW_PRINTINFO_BITS_48_63 in smbiosviewstrings.uni

2021-05-12

saidurgab@...

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io>
发送时间: 2021518 9:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 05/18/2021 6:30pm-7:30pm #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 18 May 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

Where:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

View Event

Organizer: Liming Gao gaoliming@...

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


TianoCore Bug Triage - APAC / NAMO - Tue, 05/18/2021 6:30pm-7:30pm #cal-reminder

devel@edk2.groups.io Calendar <devel@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 18 May 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

Where:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%22b286b53a-1218-4db3-bfc9-3d4c5aa7669e%22%7d

View Event

Organizer: Liming Gao gaoliming@...

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

+1 916-245-6934,,77463821#   United States, Sacramento

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


回复: [edk2-devel] [PATCH v1 1/1] Add MemoryFence implementation for RiscV64

gaoliming
 

Daniel:
Seemly, this API is missing in BaseLib for RiscV64 arch. How do you detect
this issue?

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Daniel
Schaefer
发送时间: 2021年5月16日 2:13
收件人: devel@edk2.groups.io
抄送: Abner Chang <abner.chang@...>; Michael D Kinney
<michael.d.kinney@...>; Liming Gao <gaoliming@...>;
Zhiguang Liu <zhiguang.liu@...>; Leif Lindholm <leif@...>
主题: [edk2-devel] [PATCH v1 1/1] Add MemoryFence implementation for
RiscV64

Cc: Abner Chang <abner.chang@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Leif Lindholm <leif@...>
Signed-off-by: Daniel Schaefer <daniel.schaefer@...>
---
MdePkg/Library/BaseLib/BaseLib.inf | 1 +
MdePkg/Library/BaseLib/RiscV64/MemoryFence.S | 33
++++++++++++++++++++
2 files changed, 34 insertions(+)

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf
b/MdePkg/Library/BaseLib/BaseLib.inf
index b76f3af380ea..b7ab5f632366 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -399,6 +399,7 @@
RiscV64/DisableInterrupts.c


RiscV64/EnableInterrupts.c


RiscV64/CpuPause.c


+ RiscV64/MemoryFence.S | GCC


RiscV64/RiscVSetJumpLongJump.S | GCC


RiscV64/RiscVCpuBreakpoint.S | GCC


RiscV64/RiscVCpuPause.S | GCC


diff --git a/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
b/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
new file mode 100644
index 000000000000..283df9356a9a
--- /dev/null
+++ b/MdePkg/Library/BaseLib/RiscV64/MemoryFence.S
@@ -0,0 +1,33 @@
+##-------------------------------------------------------------------------
-----


+#


+# MemoryFence() for RiscV64


+


+# Copyright (c) 2021, Hewlett Packard Enterprise Development. All rights
reserved.


+#


+# SPDX-License-Identifier: BSD-2-Clause-Patent


+#


+##-------------------------------------------------------------------------
-----


+


+.text


+.p2align 2


+


+ASM_GLOBAL ASM_PFX(MemoryFence)


+


+


+#/**


+# Used to serialize load and store operations.


+#


+# All loads and stores that proceed calls to this function are
guaranteed to
be


+# globally visible when this function returns.


+#


+#**/


+#VOID


+#EFIAPI


+#MemoryFence (


+# VOID


+# );


+#


+ASM_PFX(MemoryFence):


+ // Fence on all memory and I/O


+ fence


+ ret


--
2.30.1





回复: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible uninitialized use

gaoliming
 

Sergei:
Yes. GCC49 is LTO disable GCC tool chain. GCC5 is LTO enable tool chain.
They both work on the different GCC version, such as gcc5, gcc6..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844 mentions
-ffat-lto-objects option that can trig the warning with LTO option. Do you
try it?

If this option works, we can update GCC5 tool chain definition in
tools_def.txt, then this issue can be detected in CI GCC5 build.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Sergei
Dmitrouk
发送时间: 2021年5月15日 21:01
收件人: devel@edk2.groups.io; jiewen.yao@...
抄送: Wang, Jian J <jian.j.wang@...>; Lu, XiaoyuX
<xiaoyux.lu@...>; Jiang, Guomin <guomin.jiang@...>
主题: Re: [edk2-devel] [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized use

Hello Jiewen,

I get the error only for GCC49 and not for GCC5 toolchain. CI uses GCC5.

So I compared build commands and this seems to depend on LTO. Adding
`-flto`
impedes compiler's ability to detect such simple issues.

I've found relevant bug report, there is even fix suggestion from last
month:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844

Regards,
Sergei

On Sat, May 15, 2021 at 12:30:44AM +0000, Yao, Jiewen wrote:
Hi Sergei
Thank you very much for the fix.
Reviewed-by: Jiewen Yao <Jiewen.yao@...>

I am a little surprised why it is not caught before. It is an obvious
logic issue.

Do you think we can do anything on CI, to catch it during pre-check-in
in the
future?
I just feel it is burden to make it post-check-in fix.


Thank you
Yao Jiewen

-----Original Message-----
From: Sergei Dmitrouk <sergei@...>
Sent: Friday, May 14, 2021 8:17 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>;
Lu, XiaoyuX <xiaoyux.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: [PATCH v1 3/3] CryptoPkg/BaseCryptLib: Fix possible
uninitialized
use

`Result` can be used uninitialized in both functions after following
either first or second `goto` statement.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyux.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c | 1 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c | 1 +
2 files changed, 2 insertions(+)

diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
index 4009d37d5f91..0b2960f06c4c 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPss.c
@@ -82,6 +82,7 @@ RsaPssVerify (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
index b66b6f7296ad..ece765f9ae0a 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptRsaPssSign.c
@@ -97,6 +97,7 @@ RsaPssSign (
EVP_PKEY_CTX *KeyCtx;
CONST EVP_MD *HashAlg;

+ Result = FALSE;
EvpRsaKey = NULL;
EvpVerifyCtx = NULL;
KeyCtx = NULL;
--
2.17.6



回复: [edk2-devel] [PATCH] EmulatorPkg: Update lldbefi.py to work with current lldb which uses python3

gaoliming
 

Rebecca:
This change supports python2 & python3 both. So, I think this is a good fix. Reviewed-by: Liming Gao <gaoliming@...>

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Rebecca Cran
发送时间: 2021年5月17日 21:29
收件人: devel@edk2.groups.io; Andrew Fish <afish@...>; Ray Ni
<ray.ni@...>
主题: Re: [edk2-devel] [PATCH] EmulatorPkg: Update lldbefi.py to work with
current lldb which uses python3

Could someone review this please?

Thanks.
Rebecca Cran

On 5/9/21 1:26 PM, Rebecca Cran wrote:
The version of lldb shipping with macOS Big Sur is lldb-1205.0.27.3, and
it uses python3. Update lldbefi.py to work with it, including removing
the unused 'commands' import and fixing the print statements.

Signed-off-by: Rebecca Cran <rebecca@...>
---
EmulatorPkg/Unix/lldbefi.py | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/EmulatorPkg/Unix/lldbefi.py b/EmulatorPkg/Unix/lldbefi.py
index c3fb2675cb..952f8bf982 100755
--- a/EmulatorPkg/Unix/lldbefi.py
+++ b/EmulatorPkg/Unix/lldbefi.py
@@ -10,7 +10,6 @@ import lldb
import os
import uuid
import string
-import commands
import optparse
import shlex

@@ -389,7 +388,7 @@ def LoadEmulatorEfiSymbols(frame, bp_loc ,
internal_dict):

FileName = frame.thread.process.ReadCStringFromMemory
(FileNamePtr, FileNameLen, Error)
if not Error.Success():
- print "!ReadCStringFromMemory() did not find a %d byte C string
at %x" % (FileNameLen, FileNamePtr)
+ print("!ReadCStringFromMemory() did not find a %d byte C string
at %x" % (FileNameLen, FileNamePtr))
# make breakpoint command continue
return False

@@ -398,7 +397,7 @@ def LoadEmulatorEfiSymbols(frame, bp_loc ,
internal_dict):
LoadAddress = frame.FindVariable
("LoadAddress").GetValueAsUnsigned() - 0x240

debugger.HandleCommand ("target modules add %s" %
FileName)
- print "target modules load --slid 0x%x %s" % (LoadAddress,
FileName)
+ print("target modules load --slid 0x%x %s" % (LoadAddress,
FileName))
debugger.HandleCommand ("target modules load --slide 0x%x
--file %s" % (LoadAddress, FileName))
else:
target = debugger.GetSelectedTarget()
@@ -408,7 +407,7 @@ def LoadEmulatorEfiSymbols(frame, bp_loc ,
internal_dict):
if FileName == ModuleName or FileName ==
SBModule.GetFileSpec().GetFilename():
target.ClearModuleLoadAddress (SBModule)
if not target.RemoveModule (SBModule):
- print "!lldb.target.RemoveModule (%s) FAILED" %
SBModule
+ print("!lldb.target.RemoveModule (%s) FAILED" %
SBModule)

# make breakpoint command continue
return False
@@ -490,15 +489,15 @@ def efi_guid_command(debugger, command,
result, dict):

if len(args) >= 1:
if GuidStr in guid_dict:
- print "%s = %s" % (guid_dict[GuidStr], GuidStr)
- print "%s = %s" % (guid_dict[GuidStr], GuidToCStructStr
(GuidStr))
+ print("%s = %s" % (guid_dict[GuidStr], GuidStr))
+ print("%s = %s" % (guid_dict[GuidStr], GuidToCStructStr
(GuidStr)))
else:
- print GuidStr
+ print(GuidStr)
else:
# dump entire dictionary
width = max(len(v) for k,v in guid_dict.iteritems())
for value in sorted(guid_dict, key=guid_dict.get):
- print '%-*s %s %s' % (width, guid_dict[value], value,
GuidToCStructStr(value))
+ print('%-*s %s %s' % (width, guid_dict[value], value,
GuidToCStructStr(value)))

return

@@ -538,4 +537,4 @@ def __lldb_init_module (debugger, internal_dict):
if Breakpoint.GetNumLocations() == 1:
# Set the emulator breakpoints, if we are in the emulator
debugger.HandleCommand("breakpoint command add -s
python -F lldbefi.LoadEmulatorEfiSymbols {id}".format(id=Breakpoint.GetID()))
- print 'Type r to run emulator. SecLldbScriptBreak armed. EFI
modules should now get source level debugging in the emulator.'
+ print('Type r to run emulator. SecLldbScriptBreak armed. EFI
modules should now get source level debugging in the emulator.')





Google Summer of Code (GSoC) 2021 Projects Announced!

Nate DeSimone
 

Hi Everyone,

 

Google has announced this year’s Summer of Code students. TianoCore is mentoring 7 students this year, which is more than 3 times larger than our previous high of 2 students! The list of projects is available here: https://summerofcode.withgoogle.com/organizations/6376892141142016/

 

Big shout out to all our students and mentors! I’m looking forward to a very busy, and fun summer!

 

Thanks!

Nate


Re: [PATCH v2 05/13] MdePkg/Register/Amd: define GHCB macro for the Page State Change

Erdem Aktas
 

I verified that the values align with the GHCB spec publication:
#56421 Revision: 2.00

Reviewed-by: Erdem Aktas <erdemaktas@...>

On Wed, May 12, 2021 at 4:46 PM Brijesh Singh <brijesh.singh@...> wrote:

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

The Page State Change NAE exit will be used by the SEV-SNP guest to
request a page state change using the GHCB protocol. See the GHCB
spec section 4.1.6 and 2.3.1 for more detail on the structure
definitions.

Cc: James Bottomley <jejb@...>
Cc: Min Xu <min.m.xu@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Tom Lendacky <thomas.lendacky@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Erdem Aktas <erdemaktas@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Reviewed-by: Laszlo Ersek <lersek@...>
Reviewed-by: Liming Gao <gaoliming@...>
Signed-off-by: Brijesh Singh <brijesh.singh@...>
---
MdePkg/Include/Register/Amd/Fam17Msr.h | 15 ++++++++++++
MdePkg/Include/Register/Amd/Ghcb.h | 33 ++++++++++++++++++++++++++
2 files changed, 48 insertions(+)

diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h b/MdePkg/Include/Register/Amd/Fam17Msr.h
index 542e4cdf4782..62014854d9b7 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -58,6 +58,19 @@ typedef union {
UINT64 GuestFrameNumber:52;
} GhcbGpaRegister;

+ struct {
+ UINT64 Function:12;
+ UINT64 GuestFrameNumber:40;
+ UINT64 Operation:4;
+ UINT64 Reserved:8;
+ } SnpPageStateChangeRequest;
+
+ struct {
+ UINT32 Function:12;
+ UINT32 Reserved:20;
+ UINT32 ErrorCode;
+ } SnpPageStateChangeResponse;
+
VOID *Ghcb;

UINT64 GhcbPhysicalAddress;
@@ -69,6 +82,8 @@ typedef union {
#define GHCB_INFO_CPUID_RESPONSE 5
#define GHCB_INFO_GHCB_GPA_REGISTER_REQUEST 18
#define GHCB_INFO_GHCB_GPA_REGISTER_RESPONSE 19
+#define GHCB_INFO_SNP_PAGE_STATE_CHANGE_REQUEST 20
+#define GHCB_INFO_SNP_PAGE_STATE_CHANGE_RESPONSE 21
#define GHCB_HYPERVISOR_FEATURES_REQUEST 128
#define GHCB_HYPERVISOR_FEATURES_RESPONSE 129
#define GHCB_INFO_TERMINATE_REQUEST 256
diff --git a/MdePkg/Include/Register/Amd/Ghcb.h b/MdePkg/Include/Register/Amd/Ghcb.h
index ec232ebd3807..029904b1c63a 100644
--- a/MdePkg/Include/Register/Amd/Ghcb.h
+++ b/MdePkg/Include/Register/Amd/Ghcb.h
@@ -54,6 +54,7 @@
#define SVM_EXIT_NMI_COMPLETE 0x80000003ULL
#define SVM_EXIT_AP_RESET_HOLD 0x80000004ULL
#define SVM_EXIT_AP_JUMP_TABLE 0x80000005ULL
+#define SVM_EXIT_SNP_PAGE_STATE_CHANGE 0x80000010ULL
#define SVM_EXIT_HYPERVISOR_FEATURES 0x8000FFFDULL
#define SVM_EXIT_UNSUPPORTED 0x8000FFFFULL

@@ -162,4 +163,36 @@ typedef union {
#define GHCB_HV_FEATURES_SNP_AP_CREATE (GHCB_HV_FEATURES_SNP | BIT1)
#define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION (GHCB_HV_FEATURES_SNP_AP_CREATE | BIT2)
#define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION_TIMER (GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION | BIT3)
+
+//
+// SNP Page State Change.
+//
+// Note that the PSMASH and UNSMASH operations are not supported when using the MSR protocol.
+//
+#define SNP_PAGE_STATE_PRIVATE 1
+#define SNP_PAGE_STATE_SHARED 2
+#define SNP_PAGE_STATE_PSMASH 3
+#define SNP_PAGE_STATE_UNSMASH 4
+
+typedef struct {
+ UINT64 CurrentPage:12;
+ UINT64 GuestFrameNumber:40;
+ UINT64 Operation:4;
+ UINT64 PageSize:1;
+ UINT64 Reserved:7;
+} SNP_PAGE_STATE_ENTRY;
+
+typedef struct {
+ UINT16 CurrentEntry;
+ UINT16 EndEntry;
+ UINT32 Reserved;
+} SNP_PAGE_STATE_HEADER;
+
+#define SNP_PAGE_STATE_MAX_ENTRY 253
+
+typedef struct {
+ SNP_PAGE_STATE_HEADER Header;
+ SNP_PAGE_STATE_ENTRY Entry[SNP_PAGE_STATE_MAX_ENTRY];
+} SNP_PAGE_STATE_CHANGE_INFO;
+
#endif
--
2.17.1


Re: [PATCH v2 04/13] MdePkg/Register/Amd: define GHCB macro for Register GPA structure

Erdem Aktas
 

I verified that the values align with the GHCB spec publication:
#56421 Revision: 2.00

Just one question: is there any reason why GHCB_* defines are decimal
while the SVM_EXIT_* are all in hexadecimal? Does EDK2 have any
preference?

Reviewed-by: Erdem Aktas <erdemaktas@...>

-Erdem

On Wed, May 12, 2021 at 4:46 PM Brijesh Singh <brijesh.singh@...> wrote:

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

An SEV-SNP guest is required to perform the GHCB GPA registration. See
the GHCB specification for further details.

Cc: James Bottomley <jejb@...>
Cc: Min Xu <min.m.xu@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Tom Lendacky <thomas.lendacky@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Erdem Aktas <erdemaktas@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Reviewed-by: Laszlo Ersek <lersek@...>
Reviewed-by: Liming Gao <gaoliming@...>
Signed-off-by: Brijesh Singh <brijesh.singh@...>
---
MdePkg/Include/Register/Amd/Fam17Msr.h | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h b/MdePkg/Include/Register/Amd/Fam17Msr.h
index cdb8f588ccf8..542e4cdf4782 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -53,6 +53,11 @@ typedef union {
UINT64 Features:52;
} GhcbHypervisorFeatures;

+ struct {
+ UINT64 Function:12;
+ UINT64 GuestFrameNumber:52;
+ } GhcbGpaRegister;
+
VOID *Ghcb;

UINT64 GhcbPhysicalAddress;
@@ -62,6 +67,8 @@ typedef union {
#define GHCB_INFO_SEV_INFO_GET 2
#define GHCB_INFO_CPUID_REQUEST 4
#define GHCB_INFO_CPUID_RESPONSE 5
+#define GHCB_INFO_GHCB_GPA_REGISTER_REQUEST 18
+#define GHCB_INFO_GHCB_GPA_REGISTER_RESPONSE 19
#define GHCB_HYPERVISOR_FEATURES_REQUEST 128
#define GHCB_HYPERVISOR_FEATURES_RESPONSE 129
#define GHCB_INFO_TERMINATE_REQUEST 256
--
2.17.1


Re: [PATCH v2 03/13] MdePkg/Register/Amd: define GHCB macros for hypervisor feature detection

Erdem Aktas
 

I verified that the values align with the GHCB spec publication:
#56421 Revision: 2.00

Reviewed-by: Erdem Aktas <erdemaktas@...>

-Erdem

On Wed, May 12, 2021 at 4:46 PM Brijesh Singh <brijesh.singh@...> wrote:

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

Version 2 of GHCB introduces advertisement of features that are supported
by the hypervisor. See the GHCB spec section 2.2 for an additional details.

Cc: James Bottomley <jejb@...>
Cc: Min Xu <min.m.xu@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Tom Lendacky <thomas.lendacky@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Erdem Aktas <erdemaktas@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Reviewed-by: Laszlo Ersek <lersek@...>
Reviewed-by: Liming Gao <gaoliming@...>
Signed-off-by: Brijesh Singh <brijesh.singh@...>
---
MdePkg/Include/Register/Amd/Fam17Msr.h | 7 +++++++
MdePkg/Include/Register/Amd/Ghcb.h | 8 ++++++++
2 files changed, 15 insertions(+)

diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h b/MdePkg/Include/Register/Amd/Fam17Msr.h
index 7368ce7af02a..cdb8f588ccf8 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -48,6 +48,11 @@ typedef union {
UINT32 Reserved2:32;
} GhcbTerminate;

+ struct {
+ UINT64 Function:12;
+ UINT64 Features:52;
+ } GhcbHypervisorFeatures;
+
VOID *Ghcb;

UINT64 GhcbPhysicalAddress;
@@ -57,6 +62,8 @@ typedef union {
#define GHCB_INFO_SEV_INFO_GET 2
#define GHCB_INFO_CPUID_REQUEST 4
#define GHCB_INFO_CPUID_RESPONSE 5
+#define GHCB_HYPERVISOR_FEATURES_REQUEST 128
+#define GHCB_HYPERVISOR_FEATURES_RESPONSE 129
#define GHCB_INFO_TERMINATE_REQUEST 256

#define GHCB_TERMINATE_GHCB 0
diff --git a/MdePkg/Include/Register/Amd/Ghcb.h b/MdePkg/Include/Register/Amd/Ghcb.h
index 712dc8e769c0..ec232ebd3807 100644
--- a/MdePkg/Include/Register/Amd/Ghcb.h
+++ b/MdePkg/Include/Register/Amd/Ghcb.h
@@ -54,6 +54,7 @@
#define SVM_EXIT_NMI_COMPLETE 0x80000003ULL
#define SVM_EXIT_AP_RESET_HOLD 0x80000004ULL
#define SVM_EXIT_AP_JUMP_TABLE 0x80000005ULL
+#define SVM_EXIT_HYPERVISOR_FEATURES 0x8000FFFDULL
#define SVM_EXIT_UNSUPPORTED 0x8000FFFFULL

//
@@ -154,4 +155,11 @@ typedef union {
#define GHCB_EVENT_INJECTION_TYPE_EXCEPTION 3
#define GHCB_EVENT_INJECTION_TYPE_SOFT_INT 4

+//
+// Hypervisor features
+//
+#define GHCB_HV_FEATURES_SNP BIT0
+#define GHCB_HV_FEATURES_SNP_AP_CREATE (GHCB_HV_FEATURES_SNP | BIT1)
+#define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION (GHCB_HV_FEATURES_SNP_AP_CREATE | BIT2)
+#define GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION_TIMER (GHCB_HV_FEATURES_SNP_RESTRICTED_INJECTION | BIT3)
#endif
--
2.17.1


Re: [PATCH v1 2/3] MdeModulePkg/PciBusDxe: Fix possible uninitialized use

Sergei Dmitrouk <sergei@...>
 

If the function gets invalid value for the `ResizableBarOp` parameter
and asserts are disabled, `Bit` can be used uninitialized.

Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Ray Ni <ray.ni@...>
Signed-off-by: Sergei Dmitrouk <sergei@...>
---

Notes:
v2:
- simplify if-statement to avoid unused branches

MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
index 6bba28367165..4caac56f1dcd 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
@@ -1778,10 +1778,9 @@ PciProgramResizableBar (

if (ResizableBarOp == PciResizableBarMax) {
Bit = HighBitSet64(Capabilities);
- } else if (ResizableBarOp == PciResizableBarMin) {
+ } else {
+ ASSERT (ResizableBarOp == PciResizableBarMin);
Bit = LowBitSet64(Capabilities);
- } else {
- ASSERT ((ResizableBarOp == PciResizableBarMax) || (ResizableBarOp == PciResizableBarMin));
}

ASSERT (Bit >= 0);
--
2.17.6