Re: [edk2-devel] [PATCH] SecurityPkg: Debug code to audit BIOS TPM extend operations.

[Yao, Jiewen]

I am OK to add API to the library.

I am OK to add one function call to dump PCR[0] in TcgPei to show if there is 
any measurement before BIOS. That is good use case for BootGuard.

But I don't think we need dump the PCR every time in PCR_Extend - assuming TPM 
hardware is good, then it should always be correct.

Thank you
Yao Jiewen

From: Gonzalez Del Cueto, Rodrigo 
Sent: Tuesday, August 10, 2021 2:41 PM
To: Yao, Jiewen ; devel@edk2.groups.io
Cc: Wang, Jian J 
Subject: Re: [PATCH] SecurityPkg: Debug code to audit BIOS TPM extend 
operations.

Hi Jiewen,

The intention of such API would be to ease debugging and auditing PCR 
attestation along the boot; it has been a common task while debugging several 
issues and TPM configurations.

a) Configurations in which BIOS is not the S-CRTM and we need to attest what 
has been measured to the TPM prior to any measurements performed by BIOS.
b) Verifying the values in all the active and supported PCR banks: attestation 
or capping of the PCRs. (See BZ: 
3515)

Such API together with the TCG event log print out it allows us to audit and 
debug the measured boot sequence.

Regards,
-Rodrigo

From: Yao, Jiewen mailto:jiewen@intel.com>>
Sent: Sunday, August 8, 2021 6:24 PM
To: Gonzalez Del Cueto, Rodrigo 
mailto:rodrigo.gonzalez.del.cu...@intel.com>>;
 devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: Wang, Jian J mailto:jian.j.w...@intel.com>>
Subject: RE: [PATCH] SecurityPkg: Debug code to audit BIOS TPM extend 
operations.

Some feedback:

1) I think it is OK to add Tpm2PcrReadForActiveBank() API.
But I feel we will add too many noise to dump Tpm2PcrReadForActiveBank() in the 
code everytime.
I am not sure why it is needed.
What is the problem statement?

2) Below definition does not follow EDKII coding style. Please use 2 "space" as 
indent.
EFI_STATUS
EFIAPI
Tpm2PcrReadForActiveBank (
 IN  TPMI_DH_PCRPcrHandle,
 OUT TPML_DIGEST*HashList
)



> -Original Message-
> From: Gonzalez Del Cueto, Rodrigo 
> mailto:rodrigo.gonzalez.del.cu...@intel.com>>
> Sent: Friday, July 30, 2021 6:43 AM
> To: devel@edk2.groups.io
> Cc: Gonzalez Del Cueto, Rodrigo 
> mailto:rodrigo.gonzalez.del.cu...@intel.com>>;
>  Yao,
> Jiewen mailto:jiewen@intel.com>>; Wang, Jian J 
> mailto:jian.j.w...@intel.com>>
> Subject: [PATCH] SecurityPkg: Debug code to audit BIOS TPM extend operations.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2858
>
> Add debug functionality to examine TPM extend operations
> performed by BIOS and inspect the PCR 00 value prior to
> any BIOS measurements.
>
> Replaced usage of EFI_D_* for DEBUG_* definitions in debug
> messages.
>
> Signed-off-by: Rodrigo Gonzalez del Cueto
> mailto:rodrigo.gonzalez.del.cu...@intel.com>>
> Cc: Jiewen Yao mailto:jiewen@intel.com>>
> Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
> ---
>  SecurityPkg/Include/Library/Tpm2CommandLib.h   |  28
> ++--
>  SecurityPkg/Library/Tpm2CommandLib/Tpm2Integrity.c | 226
> +
> +
> +
> ---
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c  |  34 
> --
> 
>  3 files changed, 245 insertions(+), 43 deletions(-)
>
> diff --git a/SecurityPkg/Include/Library/Tpm2CommandLib.h
> b/SecurityPkg/Include/Library/Tpm2CommandLib.h
> index ee8eb62295..5e5c340893 100644
> --- a/SecurityPkg/Include/Library/Tpm2CommandLib.h
> +++ b/SecurityPkg/Include/Library/Tpm2CommandLib.h
> @@ -1,7 +1,7 @@
>  /** @file
>This library is used by other modules to send TPM2 command.
>
> -Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved. 
> +Copyright (c) 2013 - 2021, Intel Corporation. All rights reserved. 
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>
>  **/
> @@ -505,7 +505,7 @@ EFIAPI
>  Tpm2PcrEvent (
>IN  TPMI_DH_PCR   PcrHandle,
>IN  TPM2B_EVENT   *EventData,
> - OUT  TPML_DIGEST_VALUES*Digests
> +  OUT TPML_DIGEST_VALUES*Digests
>);
>
>  /**
> @@ -522,10 +522,10 @@ Tpm2PcrEvent (
>  EFI_STATUS
>  EFIAPI
>  Tpm2PcrRead (
> -  IN  TPML_PCR_SELECTION*PcrSelectionIn,
> - OUT  UINT32*PcrUpdateCounter,
> - OUT  TPML_PCR_SELECTION*PcrSelectionOut,
> - OUT  TPML_DIGEST   *PcrValues
> +  IN   TPML_PCR_SELECTION*PcrSelectionIn,
> +  OUT  UINT32*PcrUpdateCounter,
> +  OUT  TPML_PCR_SELECTION*PcrSelectionOut,
> +  OUT  TPML_DIGEST   *PcrValues
>);
>
>  /**
> @@ -1113,4 +1113,20 @@ GetDigestFromDigestList(
>OUT VOID  *Digest
>  

Re: [edk2-devel] [PATCH] Reallocate TPM Active PCRs based on platform support.

[Yao, Jiewen]

OK, Would you please to share the PCD configuration works before and PCD 
configuration fails now? As well as your DSC file on how to configure the 
library.

I would like to understand the problem statement from real use case, because 
the issue description cannot provide useful information to me.

From: Gonzalez Del Cueto, Rodrigo 
Sent: Tuesday, August 10, 2021 2:27 PM
To: Yao, Jiewen ; devel@edk2.groups.io
Cc: Wang, Jian J 
Subject: Re: [PATCH] Reallocate TPM Active PCRs based on platform support.

Hi Jiewen,

Indeed, this bug has existed for a long time in this code. What recently 
changed are the TPM configurations we are testing and exposed the issue; this 
can be reproduced when the BIOS supported algorithms are a strict subset of the 
PCRs currently active in the TPM.

Now that we are using TPM configurations with support for additional PCR banks 
(ex. SHA384 and SM3) the bug has been exposed when compiling a BIOS without 
support for these PCR banks which are active by default in the some of the TPMs.

Regards,
-Rodrigo


From: Yao, Jiewen mailto:jiewen@intel.com>>
Sent: Sunday, August 8, 2021 6:13 PM
To: Gonzalez Del Cueto, Rodrigo 
mailto:rodrigo.gonzalez.del.cu...@intel.com>>;
 devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: Wang, Jian J mailto:jian.j.w...@intel.com>>
Subject: RE: [PATCH] Reallocate TPM Active PCRs based on platform support.

Hi Rodrigo
I don't understand the problem statement.

This code has been there for long time. What is changed recently ?

Thank you
Yao Jiewen


> -Original Message-
> From: Gonzalez Del Cueto, Rodrigo 
> mailto:rodrigo.gonzalez.del.cu...@intel.com>>
> Sent: Thursday, August 5, 2021 7:28 AM
> To: devel@edk2.groups.io
> Cc: Gonzalez Del Cueto, Rodrigo 
> mailto:rodrigo.gonzalez.del.cu...@intel.com>>;
> Wang, Jian J mailto:jian.j.w...@intel.com>>; Yao, 
> Jiewen mailto:jiewen@intel.com>>
> Subject: [PATCH] Reallocate TPM Active PCRs based on platform support.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3515
>
> In V2: Add case to RegisterHashInterfaceLib logic
>
> RegisterHashInterfaceLib needs to correctly handle registering the HashLib
> instance supported algorithm bitmap when PcdTpm2HashMask is set to zero.
>
> The current implementation of SyncPcrAllocationsAndPcrMask() triggers
> PCR bank reallocation only based on the intersection between
> TpmActivePcrBanks and PcdTpm2HashMask.
>
> When the software HashLibBaseCryptoRouter solution is used, no PCR bank
> reallocation is occurring based on the supported hashing algorithms
> registered by the HashLib instances.
>
> Need to have an additional check for the intersection between the
> TpmActivePcrBanks and the PcdTcg2HashAlgorithmBitmap populated by the
> HashLib instances present on the platform's BIOS.
>
> Signed-off-by: Rodrigo Gonzalez del Cueto
> mailto:rodrigo.gonzalez.del.cu...@intel.com>>
>
> Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
> Cc: Jiewen Yao mailto:jiewen@intel.com>>
> ---
>  SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.c
> |  6 +-
>  SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c |
> 6 +-
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c| 18
> +-
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf  |  
> 1 +
>  4 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.
> c
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.
> c
> index 7a0f61efbb..0821159120 100644
> ---
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.
> c
> +++
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.
> c
> @@ -230,13 +230,17 @@ RegisterHashInterfaceLib (
>  {
>UINTN  Index;
>UINT32 HashMask;
> +  UINT32 Tpm2HashMask;
>EFI_STATUS Status;
>
>//
>// Check allow
>//
>HashMask = Tpm2GetHashMaskFromAlgo (>HashGuid);
> -  if ((HashMask & PcdGet32 (PcdTpm2HashMask)) == 0) {
> +  Tpm2HashMask = PcdGet32 (PcdTpm2HashMask);
> +
> +  if ((Tpm2HashMask != 0) &&
> +  ((HashMask & Tpm2HashMask) == 0)) {
>  return EFI_UNSUPPORTED;
>}
>
> diff --git
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> index 42cb562f67..6ae51dbce4 100644
> ---
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> +++
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> @@ -327,13 +327,17 @@ RegisterHashInterfaceLib (
>UINTN  Index;
>HASH_INTERFACE_HOB *HashInterfaceHob;
>UINT32 HashMask;
> +  UINT32 Tpm2HashMask;
>EFI_STATUS Status;
>
>   

Re: [edk2-devel] [PATCH V2] RedfishPkg/RefishCrtLib: Public RefishCrtLib

[Nickle Wang]

Reviewed-by: Nickle Wang 

Thanks,
Nickle

-Original Message-
From: Chang, Abner (HPS SW/FW Technologist)  
Sent: Wednesday, August 11, 2021 11:01 AM
To: devel@edk2.groups.io
Cc: Wang, Nickle (HPS SW) 
Subject: [PATCH V2] RedfishPkg/RefishCrtLib: Public RefishCrtLib

Public the header file, move RefishCrtLib.h from PrivateInclude/ to Include/.
RefishCrtLib.lib will be public later. (Moved out from PrivateLibrary/)

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Reviewed-by: Nickle Wang 
---
 RedfishPkg/{PrivateInclude => Include}/Library/RedfishCrtLib.h  | 2 +-
 .../RedfishLib/edk2libredfish/include/redfishPayload.h  | 2 +-
 .../RedfishLib/edk2libredfish/include/redfishService.h  | 2 +-
 .../PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h  | 2 +-
 RedfishPkg/RedfishPkg.ci.yaml   | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)  rename 
RedfishPkg/{PrivateInclude => Include}/Library/RedfishCrtLib.h (96%)

diff --git a/RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h 
b/RedfishPkg/Include/Library/RedfishCrtLib.h
similarity index 96%
rename from RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h
rename to RedfishPkg/Include/Library/RedfishCrtLib.h
index 28a493d782..5e15768938 100644
--- a/RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h
+++ b/RedfishPkg/Include/Library/RedfishCrtLib.h
@@ -2,7 +2,7 @@
   Redfish CRT wrapper functions.
 
   Copyright (c) 2019, Intel Corporation. All rights reserved.
-  (C) Copyright 2020 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
diff --git 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPayload.h 
b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPayload.h
index 03380d9394..43149f3c89 100644
--- 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPayload.h
+++ b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfis
+++ hPayload.h
@@ -17,7 +17,7 @@
 #ifndef LIBREDFISH_REDFISH_PAYLOAD_H_
 #define LIBREDFISH_REDFISH_PAYLOAD_H_
 
-#include 
+#include 
 
 #include 
 #include 
diff --git 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishService.h 
b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishService.h
index 5bcb381c05..0215caccfc 100644
--- 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishService.h
+++ b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfis
+++ hService.h
@@ -30,7 +30,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h 
b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h
index bdec6098e5..24413a648a 100644
--- a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h
+++ b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpat
+++ h.h
@@ -17,7 +17,7 @@
 #ifndef LIBREDFISH_REDPATH_H_
 #define LIBREDFISH_REDPATH_H_
 
-#include 
+#include 
 
 #include 
 
diff --git a/RedfishPkg/RedfishPkg.ci.yaml b/RedfishPkg/RedfishPkg.ci.yaml 
index 1fe9bdb8d1..96133f8c28 100644
--- a/RedfishPkg/RedfishPkg.ci.yaml
+++ b/RedfishPkg/RedfishPkg.ci.yaml
@@ -34,8 +34,8 @@
 "PrivateInclude/Crt/stdlib.h",
 "PrivateInclude/Crt/string.h",
 "PrivateInclude/Crt/time.h",
-"PrivateInclude/Library/RedfishCrtLib.h",
 "PrivateLibrary/RedfishCrtLib/RedfishCrtLib.c",
+"Include/Library/RedfishCrtLib.h",
 ##
 ## For jansson library open source
 ## load.c is overrided from open source.
--
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79084): https://edk2.groups.io/g/devel/message/79084
Mute This Topic: https://groups.io/mt/84809696/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] RedfishPkg/RefishCrtLib: Public RefishCrtLib

[Abner Chang]

Hi Nickle,
I sent the V2 patch to add the change on RedfishPkg.yaml file. Please review it 
again.

Thanks
Abner
> -Original Message-
> From: Wang, Nickle (HPS SW)
> Sent: Sunday, August 8, 2021 9:00 PM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> devel@edk2.groups.io
> Subject: RE: [PATCH] RedfishPkg/RefishCrtLib: Public RefishCrtLib
> 
> Reviewed-by: Nickle Wang 
> 
> Thanks,
> Nickle
> 
> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist) 
> Sent: Wednesday, July 28, 2021 1:04 PM
> To: devel@edk2.groups.io
> Cc: Wang, Nickle (HPS SW) 
> Subject: [PATCH] RedfishPkg/RefishCrtLib: Public RefishCrtLib
> 
> Move RefishCrtLib from PrivateInclude to Include.
> 
> Signed-off-by: Abner Chang 
> Cc: Nickle Wang 
> ---
>  RedfishPkg/{PrivateInclude => Include}/Library/RedfishCrtLib.h  | 2 +-
>  .../RedfishLib/edk2libredfish/include/redfishPayload.h  | 2 +-
>  .../RedfishLib/edk2libredfish/include/redfishService.h  | 2 +-
>  .../PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h  | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)  rename
> RedfishPkg/{PrivateInclude => Include}/Library/RedfishCrtLib.h (96%)
> 
> diff --git a/RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h
> b/RedfishPkg/Include/Library/RedfishCrtLib.h
> similarity index 96%
> rename from RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h
> rename to RedfishPkg/Include/Library/RedfishCrtLib.h
> index 28a493d782..5e15768938 100644
> --- a/RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h
> +++ b/RedfishPkg/Include/Library/RedfishCrtLib.h
> @@ -2,7 +2,7 @@
>Redfish CRT wrapper functions.
> 
>Copyright (c) 2019, Intel Corporation. All rights reserved.
> -  (C) Copyright 2020 Hewlett Packard Enterprise Development LP
> +  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
> 
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> diff --git
> a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPaylo
> ad.h
> b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPaylo
> ad.h
> index 03380d9394..43149f3c89 100644
> ---
> a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPaylo
> ad.h
> +++ b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfis
> +++ hPayload.h
> @@ -17,7 +17,7 @@
>  #ifndef LIBREDFISH_REDFISH_PAYLOAD_H_
>  #define LIBREDFISH_REDFISH_PAYLOAD_H_
> 
> -#include 
> +#include 
> 
>  #include 
>  #include 
> diff --git
> a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishServic
> e.h
> b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishServic
> e.h
> index 5bcb381c05..0215caccfc 100644
> ---
> a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishServic
> e.h
> +++ b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfis
> +++ hService.h
> @@ -30,7 +30,7 @@
>  #include 
>  #include 
> 
> -#include 
> +#include 
> 
>  #include 
>  #include 
> diff --git
> a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h
> b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h
> index bdec6098e5..24413a648a 100644
> --- a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h
> +++ b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpat
> +++ h.h
> @@ -17,7 +17,7 @@
>  #ifndef LIBREDFISH_REDPATH_H_
>  #define LIBREDFISH_REDPATH_H_
> 
> -#include 
> +#include 
> 
>  #include 
> 
> --
> 2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79083): https://edk2.groups.io/g/devel/message/79083
Mute This Topic: https://groups.io/mt/84499684/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V2] RedfishPkg/RefishCrtLib: Public RefishCrtLib

[Abner Chang]

Public the header file, move RefishCrtLib.h from PrivateInclude/
to Include/.
RefishCrtLib.lib will be public later. (Moved out from PrivateLibrary/)

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Reviewed-by: Nickle Wang 
---
 RedfishPkg/{PrivateInclude => Include}/Library/RedfishCrtLib.h  | 2 +-
 .../RedfishLib/edk2libredfish/include/redfishPayload.h  | 2 +-
 .../RedfishLib/edk2libredfish/include/redfishService.h  | 2 +-
 .../PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h  | 2 +-
 RedfishPkg/RedfishPkg.ci.yaml   | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)
 rename RedfishPkg/{PrivateInclude => Include}/Library/RedfishCrtLib.h (96%)

diff --git a/RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h 
b/RedfishPkg/Include/Library/RedfishCrtLib.h
similarity index 96%
rename from RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h
rename to RedfishPkg/Include/Library/RedfishCrtLib.h
index 28a493d782..5e15768938 100644
--- a/RedfishPkg/PrivateInclude/Library/RedfishCrtLib.h
+++ b/RedfishPkg/Include/Library/RedfishCrtLib.h
@@ -2,7 +2,7 @@
   Redfish CRT wrapper functions.
 
   Copyright (c) 2019, Intel Corporation. All rights reserved.
-  (C) Copyright 2020 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
diff --git 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPayload.h 
b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPayload.h
index 03380d9394..43149f3c89 100644
--- 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPayload.h
+++ 
b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishPayload.h
@@ -17,7 +17,7 @@
 #ifndef LIBREDFISH_REDFISH_PAYLOAD_H_
 #define LIBREDFISH_REDFISH_PAYLOAD_H_
 
-#include 
+#include 
 
 #include 
 #include 
diff --git 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishService.h 
b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishService.h
index 5bcb381c05..0215caccfc 100644
--- 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishService.h
+++ 
b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishService.h
@@ -30,7 +30,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
diff --git 
a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h 
b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h
index bdec6098e5..24413a648a 100644
--- a/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h
+++ b/RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redpath.h
@@ -17,7 +17,7 @@
 #ifndef LIBREDFISH_REDPATH_H_
 #define LIBREDFISH_REDPATH_H_
 
-#include 
+#include 
 
 #include 
 
diff --git a/RedfishPkg/RedfishPkg.ci.yaml b/RedfishPkg/RedfishPkg.ci.yaml
index 1fe9bdb8d1..96133f8c28 100644
--- a/RedfishPkg/RedfishPkg.ci.yaml
+++ b/RedfishPkg/RedfishPkg.ci.yaml
@@ -34,8 +34,8 @@
 "PrivateInclude/Crt/stdlib.h",
 "PrivateInclude/Crt/string.h",
 "PrivateInclude/Crt/time.h",
-"PrivateInclude/Library/RedfishCrtLib.h",
 "PrivateLibrary/RedfishCrtLib/RedfishCrtLib.c",
+"Include/Library/RedfishCrtLib.h",
 ##
 ## For jansson library open source
 ## load.c is overrided from open source.
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79082): https://edk2.groups.io/g/devel/message/79082
Mute This Topic: https://groups.io/mt/84809696/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms] [PATCH V2] KabylakeOpenBoardPkg: Add MMIO Base/Length to SA GNVS

[Chiu, Chasel]

Reviewed-by: Chasel Chiu 

> -Original Message-
> From: Desimone, Nathaniel L 
> Sent: Wednesday, August 11, 2021 11:46 AM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Michael Kubacki
> ; Benjamin Doron
> 
> Subject: [edk2-platforms] [PATCH V2] KabylakeOpenBoardPkg: Add MMIO
> Base/Length to SA GNVS
> 
> The SA GNVS Area contains fields for the MMIO region base address and
> length. This implements code to populate those fields. The MMIO
> Base/Length are used by ASL at runtime and must be populated for normal
> system operation.
> 
> Cc: Chasel Chiu 
> Cc: Michael Kubacki 
> Cc: Benjamin Doron 
> Signed-off-by: Nate DeSimone 
> ---
>  .../Acpi/BoardAcpiDxe/AcpiGnvsInit.c  | 58 ++-
>  .../Acpi/BoardAcpiDxe/BoardAcpiDxe.inf| 12 +++-
>  2 files changed, 64 insertions(+), 6 deletions(-)
> 
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.
> c
> index 0d9d217e38..5c32a6e04c 100644
> ---
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
> +++
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit
> +++ .c
> @@ -1,7 +1,7 @@
>  /** @file
>Acpi Gnvs Init Library.
> 
> -Copyright (c) 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -11,11 +11,52 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> #include   #include   #include
> 
> +#include 
>  #include 
> 
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +/**
> +  A protocol callback which updates MMIO Base and Length in SA GNVS
> +area
> +
> +  @param[in] Event- The triggered event.
> +  @param[in] Context  - Context for this event.
> +
> +**/
> +VOID
> +EFIAPI
> +UpdateSaGnvsForMmioResourceBaseLength (
> +  IN EFI_EVENT Event,
> +  IN VOID  *Context
> +  )
> +{
> +  EFI_STATUSStatus;
> +  SYSTEM_AGENT_GLOBAL_NVS_AREA_PROTOCOL
> *SaGlobalNvsAreaProtocol;
> +
> +  Status = gBS->LocateProtocol (, NULL,
> + (VOID **) );  if (Status != EFI_SUCCESS) {
> +return;
> +  }
> +  gBS->CloseEvent (Event);
> +
> +  //
> +  // Configure MMIO Base/Length. This logic is only valid for platforms that
> use PciHostBridgeLibSimple.
> +  //
> +  DEBUG ((DEBUG_INFO, "[BoardAcpiDxe] Update SA GNVS Area.\n"));
> +  SaGlobalNvsAreaProtocol->Area->Mmio32Base = PcdGet32
> +(PcdPciReservedMemBase);
> +  if (PcdGet32 (PcdPciReservedMemLimit) != 0) {
> +SaGlobalNvsAreaProtocol->Area->Mmio32Length = PcdGet32
> +(PcdPciReservedMemLimit) - PcdGet32 (PcdPciReservedMemBase) + 1;
> +  } else {
> +SaGlobalNvsAreaProtocol->Area->Mmio32Length = ((UINT32) PcdGet64
> +(PcdPciExpressBaseAddress)) - PcdGet32 (PcdPciReservedMemBase);
> +  }
> +  if (PcdGet64 (PcdPciReservedMemAbove4GBLimit) > PcdGet64
> (PcdPciReservedMemAbove4GBBase)) {
> +SaGlobalNvsAreaProtocol->Area->Mmio64Base   = PcdGet64
> (PcdPciReservedMemAbove4GBBase);
> +SaGlobalNvsAreaProtocol->Area->Mmio64Length = PcdGet64
> +(PcdPciReservedMemAbove4GBLimit) - PcdGet64
> +(PcdPciReservedMemAbove4GBBase) + 1;
> +  }
> +}
> 
>  /**
>  @brief
> @@ -39,6 +80,7 @@ AcpiGnvsInit (
>EFI_MP_SERVICES_PROTOCOL  *MpService;
>UINTN NumberOfCPUs;
>UINTN NumberOfEnabledCPUs;
> +  VOID  *SaGlobalNvsRegistration;
> 
>Pages = EFI_SIZE_TO_PAGES (sizeof (EFI_GLOBAL_NVS_AREA));
>Address = 0x; // allocate address below 4G.
> @@ -53,7 +95,7 @@ AcpiGnvsInit (
>if (EFI_ERROR(Status)) {
>  return Status;
>}
> -
> +
>//
>// Locate the MP services protocol
>// Find the MP Protocol. This is an MP platform, so MP protocol must be
> there.
> @@ -90,6 +132,16 @@ AcpiGnvsInit (
>GNVS->Area->PL1LimitCS = 0;
>GNVS->Area->PL1LimitCSValue = 4500;
> 
> +  //
> +  // Update SA GNVS with MMIO Base/Length  //
> + EfiCreateProtocolNotifyEvent (
> +,
> +TPL_CALLBACK,
> +UpdateSaGnvsForMmioResourceBaseLength,
> +NULL,
> +
> +);
> +
>return EFI_SUCCESS;
>  }
> -
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe
> .inf
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe
> .inf
> index 7d2e105e54..5d3d4c3a2b 100644
> ---
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe
> .inf
> +++
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe
> +++ .inf
> @@ -1,7 +1,7 @@
>  ### @file
>  #  Component information file for AcpiPlatform module  # -# Copyright (c)
> 2017 - 2019, Intel Corporation. All rights reserved.
> +# Copyright (c) 2017 - 2021, Intel Corporation. All rights
> +reserved.
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -38,6 +38,7 @@
>PcdLib
>UefiBootServicesTableLib
>UefiRuntimeServicesTableLib
> +  UefiLib
>

Re: [edk2-devel] [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Add MMIO Base/Length to SA GNVS

[Nate DeSimone]

Thank you for letting me know Chasel, please see PATCH V2 for the fix.

Thanks,
Nate

-Original Message-
From: Chiu, Chasel  
Sent: Tuesday, August 10, 2021 8:25 PM
To: devel@edk2.groups.io; Chiu, Chasel ; Desimone, 
Nathaniel L 
Cc: Michael Kubacki ; Benjamin Doron 

Subject: RE: [edk2-devel] [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Add 
MMIO Base/Length to SA GNVS


Hi Nate,

Internal test case failed, please see below inline for comments.

Thanks,
Chasel


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chiu, 
> Chasel
> Sent: Wednesday, August 11, 2021 9:56 AM
> To: Desimone, Nathaniel L ; 
> devel@edk2.groups.io
> Cc: Michael Kubacki ; Benjamin Doron 
> 
> Subject: Re: [edk2-devel] [edk2-platforms] [PATCH V1]
> KabylakeOpenBoardPkg: Add MMIO Base/Length to SA GNVS
> 
> 
> Reviewed-by: Chasel Chiu 
> 
> > -Original Message-
> > From: Desimone, Nathaniel L 
> > Sent: Wednesday, August 11, 2021 6:53 AM
> > To: devel@edk2.groups.io
> > Cc: Chiu, Chasel ; Michael Kubacki 
> > ; Benjamin Doron 
> > 
> > Subject: [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Add MMIO 
> > Base/Length to SA GNVS
> >
> > The SA GNVS Area contains fields for the MMIO region base address 
> > and length. This implements code to populate those fields. The MMIO 
> > Base/Length are used by ASL at runtime and must be populated for 
> > normal system operation.
> >
> > Cc: Chasel Chiu 
> > Cc: Michael Kubacki 
> > Cc: Benjamin Doron 
> > Signed-off-by: Nate DeSimone 
> > ---
> >  .../Acpi/BoardAcpiDxe/AcpiGnvsInit.c  | 57 ++-
> >  .../Acpi/BoardAcpiDxe/BoardAcpiDxe.inf| 12 +++-
> >  2 files changed, 63 insertions(+), 6 deletions(-)
> >
> > diff --git
> >
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
> >
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.
> > c
> > index 0d9d217e38..b09b92f2e6 100644
> > ---
> >
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
> > +++
> >
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit
> > +++ .c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >Acpi Gnvs Init Library.
> >
> > -Copyright (c) 2017, Intel Corporation. All rights reserved.
> > +Copyright (c) 2017 - 2021, Intel Corporation. All rights 
> > +reserved.
> >  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -11,11 +11,51 @@ SPDX-License-Identifier: BSD-2-Clause-Patent 
> > #include   #include   #include 
> > 
> > +#include 
> >  #include 
> >
> >  #include 
> >  #include   #include 
> > 
> > +#include 
> > +
> > +/**
> > +  A protocol callback which updates MMIO Base and Length in SA GNVS 
> > +area
> > +
> > +  @param[in] Event- The triggered event.
> > +  @param[in] Context  - Context for this event.
> > +
> > +**/
> > +VOID
> > +UpdateSaGnvsForMmioResourceBaseLength (
> > +  IN EFI_EVENT Event,
> > +  IN VOID  *Context
> > +  )



Should we add EFIAPI to this function?






> > +{
> > +  EFI_STATUSStatus;
> > +  SYSTEM_AGENT_GLOBAL_NVS_AREA_PROTOCOL
> > *SaGlobalNvsAreaProtocol;
> > +
> > +  Status = gBS->LocateProtocol (, 
> > + NULL, (VOID **) );  if (Status != EFI_SUCCESS) {
> > +return;
> > +  }
> > +  gBS->CloseEvent (Event);
> > +
> > +  //
> > +  // Configure MMIO Base/Length. This logic is only valid for 
> > + platforms that
> > use PciHostBridgeLibSimple.
> > +  //
> > +  DEBUG ((DEBUG_INFO, "[BoardAcpiDxe] Update SA GNVS Area.\n"));
> > +  SaGlobalNvsAreaProtocol->Area->Mmio32Base = PcdGet32 
> > +(PcdPciReservedMemBase);
> > +  if (PcdGet32 (PcdPciReservedMemLimit) != 0) {
> > +SaGlobalNvsAreaProtocol->Area->Mmio32Length = PcdGet32
> > +(PcdPciReservedMemLimit) - PcdGet32 (PcdPciReservedMemBase) + 1;
> > +  } else {
> > +SaGlobalNvsAreaProtocol->Area->Mmio32Length = ((UINT32) 
> > +PcdGet64
> > +(PcdPciExpressBaseAddress)) - PcdGet32 (PcdPciReservedMemBase);
> > +  }
> > +  if (PcdGet64 (PcdPciReservedMemAbove4GBLimit) > PcdGet64
> > (PcdPciReservedMemAbove4GBBase)) {
> > +SaGlobalNvsAreaProtocol->Area->Mmio64Base   = PcdGet64
> > (PcdPciReservedMemAbove4GBBase);
> > +SaGlobalNvsAreaProtocol->Area->Mmio64Length = PcdGet64
> > +(PcdPciReservedMemAbove4GBLimit) - PcdGet64
> > +(PcdPciReservedMemAbove4GBBase) + 1;
> > +  }
> > +}
> >
> >  /**
> >  @brief
> > @@ -39,6 +79,7 @@ AcpiGnvsInit (
> >EFI_MP_SERVICES_PROTOCOL  *MpService;
> >UINTN NumberOfCPUs;
> >UINTN NumberOfEnabledCPUs;
> > +  VOID  *SaGlobalNvsRegistration;
> >
> >Pages = EFI_SIZE_TO_PAGES (sizeof (EFI_GLOBAL_NVS_AREA));
> >Address = 0x; // allocate address below 4G.
> > @@ -53,7 +94,7 @@ AcpiGnvsInit (
> >if (EFI_ERROR(Status)) {
> >  return Status;
> >}
> > -
> > +
> >//
> >// Locate the MP services protocol
> >// Find the MP Protocol. This is an MP platform, so MP protocol 
> > must be there.
> > 

[edk2-devel] [edk2-platforms] [PATCH V2] KabylakeOpenBoardPkg: Add MMIO Base/Length to SA GNVS

[Nate DeSimone]

The SA GNVS Area contains fields for the MMIO region
base address and length. This implements code to
populate those fields. The MMIO Base/Length are used
by ASL at runtime and must be populated for normal
system operation.

Cc: Chasel Chiu 
Cc: Michael Kubacki 
Cc: Benjamin Doron 
Signed-off-by: Nate DeSimone 
---
 .../Acpi/BoardAcpiDxe/AcpiGnvsInit.c  | 58 ++-
 .../Acpi/BoardAcpiDxe/BoardAcpiDxe.inf| 12 +++-
 2 files changed, 64 insertions(+), 6 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c 
b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
index 0d9d217e38..5c32a6e04c 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
@@ -1,7 +1,7 @@
 /** @file
   Acpi Gnvs Init Library.
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -11,11 +11,52 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
+#include 
+
+/**
+  A protocol callback which updates MMIO Base and Length in SA GNVS area
+
+  @param[in] Event- The triggered event.
+  @param[in] Context  - Context for this event.
+
+**/
+VOID
+EFIAPI
+UpdateSaGnvsForMmioResourceBaseLength (
+  IN EFI_EVENT Event,
+  IN VOID  *Context
+  )
+{
+  EFI_STATUSStatus;
+  SYSTEM_AGENT_GLOBAL_NVS_AREA_PROTOCOL *SaGlobalNvsAreaProtocol;
+
+  Status = gBS->LocateProtocol (, NULL, (VOID **) 
);
+  if (Status != EFI_SUCCESS) {
+return;
+  }
+  gBS->CloseEvent (Event);
+
+  //
+  // Configure MMIO Base/Length. This logic is only valid for platforms that 
use PciHostBridgeLibSimple.
+  //
+  DEBUG ((DEBUG_INFO, "[BoardAcpiDxe] Update SA GNVS Area.\n"));
+  SaGlobalNvsAreaProtocol->Area->Mmio32Base = PcdGet32 (PcdPciReservedMemBase);
+  if (PcdGet32 (PcdPciReservedMemLimit) != 0) {
+SaGlobalNvsAreaProtocol->Area->Mmio32Length = PcdGet32 
(PcdPciReservedMemLimit) - PcdGet32 (PcdPciReservedMemBase) + 1;
+  } else {
+SaGlobalNvsAreaProtocol->Area->Mmio32Length = ((UINT32) PcdGet64 
(PcdPciExpressBaseAddress)) - PcdGet32 (PcdPciReservedMemBase);
+  }
+  if (PcdGet64 (PcdPciReservedMemAbove4GBLimit) > PcdGet64 
(PcdPciReservedMemAbove4GBBase)) {
+SaGlobalNvsAreaProtocol->Area->Mmio64Base   = PcdGet64 
(PcdPciReservedMemAbove4GBBase);
+SaGlobalNvsAreaProtocol->Area->Mmio64Length = PcdGet64 
(PcdPciReservedMemAbove4GBLimit) - PcdGet64 (PcdPciReservedMemAbove4GBBase) + 1;
+  }
+}
 
 /**
 @brief
@@ -39,6 +80,7 @@ AcpiGnvsInit (
   EFI_MP_SERVICES_PROTOCOL  *MpService;
   UINTN NumberOfCPUs;
   UINTN NumberOfEnabledCPUs;
+  VOID  *SaGlobalNvsRegistration;
 
   Pages = EFI_SIZE_TO_PAGES (sizeof (EFI_GLOBAL_NVS_AREA));
   Address = 0x; // allocate address below 4G.
@@ -53,7 +95,7 @@ AcpiGnvsInit (
   if (EFI_ERROR(Status)) {
 return Status;
   }
-  
+
   //
   // Locate the MP services protocol
   // Find the MP Protocol. This is an MP platform, so MP protocol must be 
there.
@@ -90,6 +132,16 @@ AcpiGnvsInit (
   GNVS->Area->PL1LimitCS = 0;
   GNVS->Area->PL1LimitCSValue = 4500;
 
+  //
+  // Update SA GNVS with MMIO Base/Length
+  //
+  EfiCreateProtocolNotifyEvent (
+,
+TPL_CALLBACK,
+UpdateSaGnvsForMmioResourceBaseLength,
+NULL,
+
+);
+
   return EFI_SUCCESS;
 }
-
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf 
b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf
index 7d2e105e54..5d3d4c3a2b 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf
@@ -1,7 +1,7 @@
 ### @file
 #  Component information file for AcpiPlatform module
 #
-# Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -38,6 +38,7 @@
   PcdLib
   UefiBootServicesTableLib
   UefiRuntimeServicesTableLib
+  UefiLib
   BaseMemoryLib
   HobLib
   AslUpdateLib
@@ -48,8 +49,15 @@
   gEfiFirmwareVolume2ProtocolGuid   ## CONSUMES
   gEfiMpServiceProtocolGuid ## CONSUMES
   gEfiGlobalNvsAreaProtocolGuid
+  gSaGlobalNvsAreaProtocolGuid  ## CONSUMES
 
 [Pcd]
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
+  gMinPlatformPkgTokenSpaceGuid.PcdPciReservedMemBase
+  gMinPlatformPkgTokenSpaceGuid.PcdPciReservedMemLimit
+  gMinPlatformPkgTokenSpaceGuid.PcdPciReservedMemAbove4GBBase
+  gMinPlatformPkgTokenSpaceGuid.PcdPciReservedMemAbove4GBLimit
+
   

Re: [edk2-devel] [staging/edk2-redfish-client RedfishFeatureCore PATCH 2/3] RedfishClientPkg/RedfishFeatureCoreDxe: Redfish Feature Core DXE driver

[Abner Chang]

Thanks
All issues were addressed before merged to edk2-staging edk2-redfish-clinet 
branch.
Abner

> -Original Message-
> From: Wang, Nickle (HPS SW)
> Sent: Sunday, August 8, 2021 8:55 PM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> devel@edk2.groups.io
> Cc: Liming Gao 
> Subject: RE: [staging/edk2-redfish-client RedfishFeatureCore PATCH 2/3]
> RedfishClientPkg/RedfishFeatureCoreDxe: Redfish Feature Core DXE driver
> 
> Minor issue as inline below.
> 
> Thanks,
> Nickle
> 
> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist) 
> Sent: Tuesday, July 27, 2021 10:55 PM
> To: devel@edk2.groups.io
> Cc: Wang, Nickle (HPS SW) ; Liming Gao
> 
> Subject: [staging/edk2-redfish-client RedfishFeatureCore PATCH 2/3]
> RedfishClientPkg/RedfishFeatureCoreDxe: Redfish Feature Core DXE driver
> 
> EDKII Redfish Feature Core DXE driver provides the protocol interface to
> the auto-generated Redfish feature driver to register itself for the
> Redfish resource URI it manages. Refer to the Readme.md for the details.
> 
> Signed-off-by: Abner Chang 
> Cc: Nickle Wang 
> Cc: Liming Gao 
> ---
>  RedfishClientPkg/RedfishClientPkg.dec |  13 +-
>  .../RedfishClientComponents.dsc.inc   |   2 +
>  RedfishClientPkg/RedfishClient.fdf.inc|   1 +
>  .../RedfishFeatureCoreDxe.inf |  49 +++
>  .../Include/Protocol/EdkIIRedfishFeature.h| 116 ++
>  .../RedfishFeatureCoreDxe.h   |  43 ++
>  .../RedfishFeatureCoreDxe.c   | 382 ++
>  RedfishClientPkg/Readme.md|  36 ++
>  8 files changed, 641 insertions(+), 1 deletion(-)
>  create mode 100644
> RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.inf
>  create mode 100644
> RedfishClientPkg/Include/Protocol/EdkIIRedfishFeature.h
>  create mode 100644
> RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.h
>  create mode 100644
> RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.c
> 
> diff --git a/RedfishClientPkg/RedfishClientPkg.dec
> b/RedfishClientPkg/RedfishClientPkg.dec
> index 4038a47bd5..6da0468e65 100644
> --- a/RedfishClientPkg/RedfishClientPkg.dec
> +++ b/RedfishClientPkg/RedfishClientPkg.dec
> @@ -15,10 +15,21 @@
>  [Includes]
>Include
> 
> -
>  [LibraryClasses]
> 
>  [Protocols]
> +  ## Include/Protocol/EdkIIRedfishFeature.h
> +  gEdkIIRedfishFeatureProtocolGuid = { 0x785CC694, 0x4930, 0xEFBF, { 0x2A,
> 0xCB, 0xA4, 0xB6, 0xA1, 0xCC, 0xAA, 0x34 } }
> 
>  [Guids]
>gEfiRedfishClientPkgTokenSpaceGuid= { 0x8c444dae, 0x728b, 0x48ee,
> { 0x9e, 0x19, 0x8f, 0x0a, 0x3d, 0x4e, 0x9c, 0xc8 } }
> +
> +[PcdsFixedAtBuild]
> +
> gEfiRedfishClientPkgTokenSpaceGuid.PcdMaxRedfishSchemaStringSize|32|
> UINT32|0x1001
> +
> gEfiRedfishClientPkgTokenSpaceGuid.PcdMaxRedfishSchemaVersionSize|8|
> UINT32|0x1002
> +  #
> +  # gEfiEventReadyToBootGuid is the default event to startup Redfish
> feature drivers.
> +  # { 0x7CE88FB3, 0x4BD7, 0x4679, { 0x87, 0xA8, 0xA8, 0xD8, 0xDE, 0xE5, 0x0D,
> 0x2B }}
> +  #
> +
> gEfiRedfishClientPkgTokenSpaceGuid.PcdEdkIIRedfishFeatureDriverStartupE
> ventGuid|{0xB3, 0x8F, 0xE8, 0x7C, 0xD7, 0x4B, 0x79, 0x46, 0x87, 0xA8, 0xA8,
> 0xD8, 0xDE, 0xE5, 0x0D, 0x2B}|VOID*|0x1003
> +
> diff --git a/RedfishClientPkg/RedfishClientComponents.dsc.inc
> b/RedfishClientPkg/RedfishClientComponents.dsc.inc
> index 0648fa9d54..e4e2619bfb 100644
> --- a/RedfishClientPkg/RedfishClientComponents.dsc.inc
> +++ b/RedfishClientPkg/RedfishClientComponents.dsc.inc
> @@ -13,4 +13,6 @@
>  ##
> 
>  !if $(REDFISH_CLIENT) == TRUE
> +  RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.inf
>  !endif
> +
> diff --git a/RedfishClientPkg/RedfishClient.fdf.inc
> b/RedfishClientPkg/RedfishClient.fdf.inc
> index 4f0714004e..d4c5874787 100644
> --- a/RedfishClientPkg/RedfishClient.fdf.inc
> +++ b/RedfishClientPkg/RedfishClient.fdf.inc
> @@ -11,4 +11,5 @@
>  #
>  ##
>  !if $(REDFISH_CLIENT) == TRUE
> +  INF RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.inf
>  !endif
> diff --git
> a/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.inf
> b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.inf
> new file mode 100644
> index 00..5a2cd7fecc
> --- /dev/null
> +++ b/RedfishClientPkg/RedfishFeatureCoreDxe/RedfishFeatureCoreDxe.inf
> @@ -0,0 +1,49 @@
> +## @file
> +#  RedfishFeatureCoreDxe is the DXE driver which provides
> +#  EdkIIRedfishFeatureCoreProtocol to EDK2 Redfish Feature
> +#  drivers for the registration.
> +#
> +#  (C) Copyright 2021 Hewlett Packard Enterprise Development LP
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x0001000b
> +  BASE_NAME  = RedfishFeatureCoreDxe
> +  FILE_GUID  = 1E01A624-4161-F1F1-25BC-D28E77420D8E
> +  MODULE_TYPE= DXE_DRIVER
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT

Re: [edk2-devel] [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Add MMIO Base/Length to SA GNVS

[Chiu, Chasel]

Hi Nate,

Internal test case failed, please see below inline for comments.

Thanks,
Chasel


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Chiu,
> Chasel
> Sent: Wednesday, August 11, 2021 9:56 AM
> To: Desimone, Nathaniel L ;
> devel@edk2.groups.io
> Cc: Michael Kubacki ; Benjamin Doron
> 
> Subject: Re: [edk2-devel] [edk2-platforms] [PATCH V1]
> KabylakeOpenBoardPkg: Add MMIO Base/Length to SA GNVS
> 
> 
> Reviewed-by: Chasel Chiu 
> 
> > -Original Message-
> > From: Desimone, Nathaniel L 
> > Sent: Wednesday, August 11, 2021 6:53 AM
> > To: devel@edk2.groups.io
> > Cc: Chiu, Chasel ; Michael Kubacki
> > ; Benjamin Doron
> > 
> > Subject: [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Add MMIO
> > Base/Length to SA GNVS
> >
> > The SA GNVS Area contains fields for the MMIO region base address and
> > length. This implements code to populate those fields. The MMIO
> > Base/Length are used by ASL at runtime and must be populated for
> > normal system operation.
> >
> > Cc: Chasel Chiu 
> > Cc: Michael Kubacki 
> > Cc: Benjamin Doron 
> > Signed-off-by: Nate DeSimone 
> > ---
> >  .../Acpi/BoardAcpiDxe/AcpiGnvsInit.c  | 57 ++-
> >  .../Acpi/BoardAcpiDxe/BoardAcpiDxe.inf| 12 +++-
> >  2 files changed, 63 insertions(+), 6 deletions(-)
> >
> > diff --git
> >
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
> >
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.
> > c
> > index 0d9d217e38..b09b92f2e6 100644
> > ---
> >
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
> > +++
> >
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit
> > +++ .c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >Acpi Gnvs Init Library.
> >
> > -Copyright (c) 2017, Intel Corporation. All rights reserved.
> > +Copyright (c) 2017 - 2021, Intel Corporation. All rights
> > +reserved.
> >  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -11,11 +11,51 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > #include   #include   #include
> > 
> > +#include 
> >  #include 
> >
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +
> > +/**
> > +  A protocol callback which updates MMIO Base and Length in SA GNVS
> > +area
> > +
> > +  @param[in] Event- The triggered event.
> > +  @param[in] Context  - Context for this event.
> > +
> > +**/
> > +VOID
> > +UpdateSaGnvsForMmioResourceBaseLength (
> > +  IN EFI_EVENT Event,
> > +  IN VOID  *Context
> > +  )



Should we add EFIAPI to this function?






> > +{
> > +  EFI_STATUSStatus;
> > +  SYSTEM_AGENT_GLOBAL_NVS_AREA_PROTOCOL
> > *SaGlobalNvsAreaProtocol;
> > +
> > +  Status = gBS->LocateProtocol (, NULL,
> > + (VOID **) );  if (Status != EFI_SUCCESS) {
> > +return;
> > +  }
> > +  gBS->CloseEvent (Event);
> > +
> > +  //
> > +  // Configure MMIO Base/Length. This logic is only valid for
> > + platforms that
> > use PciHostBridgeLibSimple.
> > +  //
> > +  DEBUG ((DEBUG_INFO, "[BoardAcpiDxe] Update SA GNVS Area.\n"));
> > +  SaGlobalNvsAreaProtocol->Area->Mmio32Base = PcdGet32
> > +(PcdPciReservedMemBase);
> > +  if (PcdGet32 (PcdPciReservedMemLimit) != 0) {
> > +SaGlobalNvsAreaProtocol->Area->Mmio32Length = PcdGet32
> > +(PcdPciReservedMemLimit) - PcdGet32 (PcdPciReservedMemBase) + 1;
> > +  } else {
> > +SaGlobalNvsAreaProtocol->Area->Mmio32Length = ((UINT32) PcdGet64
> > +(PcdPciExpressBaseAddress)) - PcdGet32 (PcdPciReservedMemBase);
> > +  }
> > +  if (PcdGet64 (PcdPciReservedMemAbove4GBLimit) > PcdGet64
> > (PcdPciReservedMemAbove4GBBase)) {
> > +SaGlobalNvsAreaProtocol->Area->Mmio64Base   = PcdGet64
> > (PcdPciReservedMemAbove4GBBase);
> > +SaGlobalNvsAreaProtocol->Area->Mmio64Length = PcdGet64
> > +(PcdPciReservedMemAbove4GBLimit) - PcdGet64
> > +(PcdPciReservedMemAbove4GBBase) + 1;
> > +  }
> > +}
> >
> >  /**
> >  @brief
> > @@ -39,6 +79,7 @@ AcpiGnvsInit (
> >EFI_MP_SERVICES_PROTOCOL  *MpService;
> >UINTN NumberOfCPUs;
> >UINTN NumberOfEnabledCPUs;
> > +  VOID  *SaGlobalNvsRegistration;
> >
> >Pages = EFI_SIZE_TO_PAGES (sizeof (EFI_GLOBAL_NVS_AREA));
> >Address = 0x; // allocate address below 4G.
> > @@ -53,7 +94,7 @@ AcpiGnvsInit (
> >if (EFI_ERROR(Status)) {
> >  return Status;
> >}
> > -
> > +
> >//
> >// Locate the MP services protocol
> >// Find the MP Protocol. This is an MP platform, so MP protocol
> > must be there.
> > @@ -90,6 +131,16 @@ AcpiGnvsInit (
> >GNVS->Area->PL1LimitCS = 0;
> >GNVS->Area->PL1LimitCSValue = 4500;
> >
> > +  //
> > +  // Update SA GNVS with MMIO Base/Length  //
> > + EfiCreateProtocolNotifyEvent (
> > +,
> > +TPL_CALLBACK,
> > +UpdateSaGnvsForMmioResourceBaseLength,
> > +NULL,
> > +
> > +);


The build failure is here, please help to fix it:

Re: [edk2-devel] [PATCH EDK2 v2 1/1] MdeModulePkg/UefiSortLib:Add UefiSortLib unit test

[wenyi,xie via groups.io]

Hi Wu Hao，

Thank you for your help. I will have a try and send a V3 patch later.

Best Regards,
Wenyi

On 2021/8/11 9:50, Wu, Hao A wrote:
> Seems no help is received so far.
> The approach I can think of is to add this to the ECC exception list defined 
> in file MdeModulePkg.ci.yaml.
> 
> Hello Wenyi,
> 
> Could you help to check if the code changes in 
> https://github.com/tianocore/edk2/pull/1883 works for you?
> If so, could you update a V3 version of the patch? Thanks in advance.
> 
> Best Regards,
> Hao Wu
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Wu, Hao
>> A
>> Sent: Tuesday, August 10, 2021 12:12 PM
>> To: Kinney, Michael D ; devel@edk2.groups.io;
>> xiewenyi (A) 
>> Cc: songdongku...@huawei.com; Wang, Jian J 
>> Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1]
>> MdeModulePkg/UefiSortLib:Add UefiSortLib unit test
>>
>> Sorry Mike,
>>
>> Do you have advice on how to deal with ECC reporting function naming issue
>> on the 'main' function for unit test cases?
>> So far, I think Wenyi has tried following the same pattern in file
>> MdeModulePkg\Universal\Variable\RuntimeDxe\RuntimeDxeUnitTest\Vari
>> ableLockRequestToLockUnitTest.c:
>>
>> ///
>> /// Avoid ECC error for function name that starts with lower case letter ///
>> #define Main main
>>
>> /**
>>   Standard POSIX C entry point for host based unit test execution.
>>
>>   @param[in] Argc  Number of arguments
>>   @param[in] Argv  Array of pointers to arguments
>>
>>   @retval 0  Success
>>   @retval other  Error
>> **/
>> INT32
>> Main (
>>   IN INT32  Argc,
>>   IN CHAR8  *Argv[]
>>   )
>>
>> But it looks like the ECC checker in the merge test is still complaining.
>>
>> Best Regards,
>> Hao Wu
>>
>>> -Original Message-
>>> From: devel@edk2.groups.io  On Behalf Of Wu,
>> Hao
>>> A
>>> Sent: Wednesday, August 4, 2021 4:24 PM
>>> To: xiewenyi (A) ; Kinney, Michael D
>>> ; devel@edk2.groups.io
>>> Cc: songdongku...@huawei.com; Wang, Jian J 
>>> Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1]
>>> MdeModulePkg/UefiSortLib:Add UefiSortLib unit test
>>>
 -Original Message-
 From: xiewenyi (A) 
 Sent: Wednesday, August 4, 2021 4:05 PM
 To: Wu, Hao A ; devel@edk2.groups.io
 Cc: songdongku...@huawei.com; Wang, Jian J 
 Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1]
 MdeModulePkg/UefiSortLib:Add UefiSortLib unit test



 On 2021/8/2 9:56, Wu, Hao A wrote:
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of
>> Wu, Hao A
>> Sent: Thursday, July 29, 2021 4:26 PM
>> To: Wenyi Xie ; devel@edk2.groups.io;
>> Wang,
>> Jian J 
>> Cc: songdongku...@huawei.com
>> Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1]
>> MdeModulePkg/UefiSortLib:Add UefiSortLib unit test
>>
>>> -Original Message-
>>> From: Wenyi Xie 
>>> Sent: Thursday, July 29, 2021 4:01 PM
>>> To: devel@edk2.groups.io; Wang, Jian J ;
>>> Wu, Hao A 
>>> Cc: songdongku...@huawei.com; xiewen...@huawei.com
>>> Subject: [PATCH EDK2 v2 1/1] MdeModulePkg/UefiSortLib:Add
>>> UefiSortLib unit test
>>>
>>> Adding two unit test case for UefiSortLib. One is a test on
>>> sorting an array of
>>> UINT32 by using PerformQuickSort, another is a test on comparing
>>> the same buffer by using StringCompare.
>>
>>
>> Thanks.
>> Reviewed-by: Hao A Wu 
>
>
> Sorry, I found that there are a couple of coding format style
> check failures
 when merging the patch.
> Could you help to resolve them and then create a test pull request
> on the
 GitHub for verification? Thanks in advance.
> (I think you can take the case under
>
>> MdeModulePkg/Universal/Variable/RuntimeDxe/RuntimeDxeUnitTest/
>>> for
> reference.)
>

 Hi, Wu Hao

 I try to deal with the coding format style check failures, and meet
 a failure which I am not sure how to solve.
 I take the case you told for reference, but still there's a failure
 said the define should be capital letters.
 but if change it to capital letters, there will be another error
 Function name does not follow the rules: 1. First character should
 be upper case 2. Must contain lower case characters 3. No white
 space characters

 #define Main main

 INT32
 Main (
   IN INT32  Argc,
   IN CHAR8  *Argv[]
   )
 {
   UnitTestingEntry ();
   return 0;
 }
>>>
>>>
>>> Hello Mike,
>>>
>>> I saw the below commit:
>>>   SHA-1: dcaa93936591883aa7826eb45ef00416ad82ef08
>>>   * MdeModulePkg/Variable/RuntimeDxe: Add Variable Lock Protocol Unit
>>> Tests has a similar case that should involve the naming of the 'main'
>>> function within the unit test codes.
>>>
>>> I am wondering how the open raised by Wenyi was handled back then.
>>> Do you have suggestions for this case? Thanks in advance.
>>>
>>> Best Regards,
>>> Hao Wu
>>>
>>>

 

Re: [edk2-devel] [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Add MMIO Base/Length to SA GNVS

[Chiu, Chasel]

Reviewed-by: Chasel Chiu 

> -Original Message-
> From: Desimone, Nathaniel L 
> Sent: Wednesday, August 11, 2021 6:53 AM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Michael Kubacki
> ; Benjamin Doron
> 
> Subject: [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Add MMIO
> Base/Length to SA GNVS
> 
> The SA GNVS Area contains fields for the MMIO region base address and
> length. This implements code to populate those fields. The MMIO
> Base/Length are used by ASL at runtime and must be populated for normal
> system operation.
> 
> Cc: Chasel Chiu 
> Cc: Michael Kubacki 
> Cc: Benjamin Doron 
> Signed-off-by: Nate DeSimone 
> ---
>  .../Acpi/BoardAcpiDxe/AcpiGnvsInit.c  | 57 ++-
>  .../Acpi/BoardAcpiDxe/BoardAcpiDxe.inf| 12 +++-
>  2 files changed, 63 insertions(+), 6 deletions(-)
> 
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.
> c
> index 0d9d217e38..b09b92f2e6 100644
> ---
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
> +++
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit
> +++ .c
> @@ -1,7 +1,7 @@
>  /** @file
>Acpi Gnvs Init Library.
> 
> -Copyright (c) 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -11,11 +11,51 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> #include   #include   #include
> 
> +#include 
>  #include 
> 
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +/**
> +  A protocol callback which updates MMIO Base and Length in SA GNVS
> +area
> +
> +  @param[in] Event- The triggered event.
> +  @param[in] Context  - Context for this event.
> +
> +**/
> +VOID
> +UpdateSaGnvsForMmioResourceBaseLength (
> +  IN EFI_EVENT Event,
> +  IN VOID  *Context
> +  )
> +{
> +  EFI_STATUSStatus;
> +  SYSTEM_AGENT_GLOBAL_NVS_AREA_PROTOCOL
> *SaGlobalNvsAreaProtocol;
> +
> +  Status = gBS->LocateProtocol (, NULL,
> + (VOID **) );  if (Status != EFI_SUCCESS) {
> +return;
> +  }
> +  gBS->CloseEvent (Event);
> +
> +  //
> +  // Configure MMIO Base/Length. This logic is only valid for platforms that
> use PciHostBridgeLibSimple.
> +  //
> +  DEBUG ((DEBUG_INFO, "[BoardAcpiDxe] Update SA GNVS Area.\n"));
> +  SaGlobalNvsAreaProtocol->Area->Mmio32Base = PcdGet32
> +(PcdPciReservedMemBase);
> +  if (PcdGet32 (PcdPciReservedMemLimit) != 0) {
> +SaGlobalNvsAreaProtocol->Area->Mmio32Length = PcdGet32
> +(PcdPciReservedMemLimit) - PcdGet32 (PcdPciReservedMemBase) + 1;
> +  } else {
> +SaGlobalNvsAreaProtocol->Area->Mmio32Length = ((UINT32) PcdGet64
> +(PcdPciExpressBaseAddress)) - PcdGet32 (PcdPciReservedMemBase);
> +  }
> +  if (PcdGet64 (PcdPciReservedMemAbove4GBLimit) > PcdGet64
> (PcdPciReservedMemAbove4GBBase)) {
> +SaGlobalNvsAreaProtocol->Area->Mmio64Base   = PcdGet64
> (PcdPciReservedMemAbove4GBBase);
> +SaGlobalNvsAreaProtocol->Area->Mmio64Length = PcdGet64
> +(PcdPciReservedMemAbove4GBLimit) - PcdGet64
> +(PcdPciReservedMemAbove4GBBase) + 1;
> +  }
> +}
> 
>  /**
>  @brief
> @@ -39,6 +79,7 @@ AcpiGnvsInit (
>EFI_MP_SERVICES_PROTOCOL  *MpService;
>UINTN NumberOfCPUs;
>UINTN NumberOfEnabledCPUs;
> +  VOID  *SaGlobalNvsRegistration;
> 
>Pages = EFI_SIZE_TO_PAGES (sizeof (EFI_GLOBAL_NVS_AREA));
>Address = 0x; // allocate address below 4G.
> @@ -53,7 +94,7 @@ AcpiGnvsInit (
>if (EFI_ERROR(Status)) {
>  return Status;
>}
> -
> +
>//
>// Locate the MP services protocol
>// Find the MP Protocol. This is an MP platform, so MP protocol must be
> there.
> @@ -90,6 +131,16 @@ AcpiGnvsInit (
>GNVS->Area->PL1LimitCS = 0;
>GNVS->Area->PL1LimitCSValue = 4500;
> 
> +  //
> +  // Update SA GNVS with MMIO Base/Length  //
> + EfiCreateProtocolNotifyEvent (
> +,
> +TPL_CALLBACK,
> +UpdateSaGnvsForMmioResourceBaseLength,
> +NULL,
> +
> +);
> +
>return EFI_SUCCESS;
>  }
> -
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe
> .inf
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe
> .inf
> index 7d2e105e54..5d3d4c3a2b 100644
> ---
> a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe
> .inf
> +++
> b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe
> +++ .inf
> @@ -1,7 +1,7 @@
>  ### @file
>  #  Component information file for AcpiPlatform module  # -# Copyright (c)
> 2017 - 2019, Intel Corporation. All rights reserved.
> +# Copyright (c) 2017 - 2021, Intel Corporation. All rights
> +reserved.
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -38,6 +38,7 @@
>PcdLib
>UefiBootServicesTableLib
>UefiRuntimeServicesTableLib
> +  UefiLib
>BaseMemoryLib
>

Re: [edk2-devel] [edk2-platforms] [PATCH V1] MinPlatformPkg: Cleanup PeiFspWrapperHobProcessLib dependencies

[Chiu, Chasel]

Reviewed-by: Chasel Chiu 


> -Original Message-
> From: Desimone, Nathaniel L 
> Sent: Tuesday, August 10, 2021 12:37 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Michael Kubacki
> ; Benjamin Doron
> 
> Subject: [edk2-platforms] [PATCH V1] MinPlatformPkg: Cleanup
> PeiFspWrapperHobProcessLib dependencies
> 
> PeiFspWrapperHobProcessLib is currently set to depens on
> FspWrapperPlatformLib, but it does not use any of the functions
> implemented by that LibraryClass. This change removes that unneeded
> dependency.
> 
> Cc: Chasel Chiu 
> Cc: Michael Kubacki 
> Cc: Benjamin Doron 
> Signed-off-by: Nate DeSimone 
> ---
>  .../PeiFspWrapperHobProcessLib/PeiFspWrapperHobProcessLib.inf  | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/PeiFspWrapperHobP
> rocessLib/PeiFspWrapperHobProcessLib.inf
> b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/PeiFspWrapperHobP
> rocessLib/PeiFspWrapperHobProcessLib.inf
> index 64f3302959..b846e7af1d 100644
> ---
> a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/PeiFspWrapperHobP
> rocessLib/PeiFspWrapperHobProcessLib.inf
> +++
> b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/PeiFspWrapperHobP
> +++ rocessLib/PeiFspWrapperHobProcessLib.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Provide FSP wrapper hob process related function.
>  #
> -# Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
> +# Copyright (c) 2017 - 2021, Intel Corporation. All rights
> +reserved.
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -55,7 +55,6 @@
>BaseMemoryLib
>HobLib
>DebugLib
> -  FspWrapperPlatformLib
>PeiServicesLib
>PeiServicesTablePointerLib
> 
> --
> 2.27.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79074): https://edk2.groups.io/g/devel/message/79074
Mute This Topic: https://groups.io/mt/84786793/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms] [PATCH V1] KabylakeSiliconPkg: Update SA_MISC_PEI_PREMEM_CONFIG

[Chiu, Chasel]

Reviewed-by: Chasel Chiu 

> -Original Message-
> From: Desimone, Nathaniel L 
> Sent: Tuesday, August 10, 2021 12:37 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Michael Kubacki
> ; Benjamin Doron
> 
> Subject: [edk2-platforms] [PATCH V1] KabylakeSiliconPkg: Update
> SA_MISC_PEI_PREMEM_CONFIG
> 
> Updates SA_MISC_PEI_PREMEM_CONFIG from revision 1 to revision 3. Add
> initialization of the policy values.
> 
> Cc: Chasel Chiu 
> Cc: Michael Kubacki 
> Cc: Benjamin Doron 
> Signed-off-by: Nate DeSimone 
> ---
>  .../KabylakeRvp3/OpenBoardPkg.dsc | 24 +++---
>  .../PeiSiliconPolicyUpdateLib.c   | 39 +-
>  .../PeiSiliconPolicyUpdateLib.inf |  9 ++-
>  .../ConfigBlock/SaMiscPeiPreMemConfig.h   | 77 ++-
>  .../Library/PeiSaPolicyLib/PeiSaPolicyLib.c   | 37 -
>  5 files changed, 169 insertions(+), 17 deletions(-)
> 
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
> b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
> index 8523ab3f4f..f64555e391 100644
> --- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
> +++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/OpenBoardPkg.dsc
> @@ -182,17 +182,6 @@
># Board-specific
>###
> 
> PlatformHookLib|$(PROJECT)/Library/BasePlatformHookLib/BasePlatformHook
> Lib.inf
> -!if gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection == 1
> -  #
> -  # FSP API mode
> -  #
> -
> SiliconPolicyUpdateLib|$(PROJECT)/FspWrapper/Library/PeiSiliconPolicyUpdate
> LibFsp/PeiSiliconPolicyUpdateLibFsp.inf
> -!else
> -  #
> -  # FSP Dispatch mode and non-FSP build (EDK2 build)
> -  #
> -
> SiliconPolicyUpdateLib|$(PROJECT)/Policy/Library/PeiSiliconPolicyUpdateLib/Pei
> SiliconPolicyUpdateLib.inf
> -!endif
> 
>  [LibraryClasses.IA32.SEC]
>###
> @@ -200,6 +189,7 @@
>###
> 
> TestPointCheckLib|$(PLATFORM_PACKAGE)/Test/Library/TestPointCheckLib/Sec
> TestPointCheckLib.inf
> 
> SecBoardInitLib|$(PLATFORM_PACKAGE)/PlatformInit/Library/SecBoardInitLibN
> ull/SecBoardInitLibNull.inf
> +
> + SiliconPolicyUpdateLib|MinPlatformPkg/PlatformInit/Library/SiliconPoli
> + cyUpdateLibNull/SiliconPolicyUpdateLibNull.inf
> 
>  [LibraryClasses.common.PEIM]
>###
> @@ -222,6 +212,18 @@
>###
># Board Package
>###
> +!if gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection == 1
> +  #
> +  # FSP API mode
> +  #
> +
> +SiliconPolicyUpdateLib|$(PROJECT)/FspWrapper/Library/PeiSiliconPolicyUp
> +dateLibFsp/PeiSiliconPolicyUpdateLibFsp.inf
> +!else
> +  #
> +  # FSP Dispatch mode and non-FSP build (EDK2 build)
> +  #
> +
> +SiliconPolicyUpdateLib|$(PROJECT)/Policy/Library/PeiSiliconPolicyUpdate
> +Lib/PeiSiliconPolicyUpdateLib.inf
> +!endif
> +
># Thunderbolt
>  !if gKabylakeOpenBoardPkgTokenSpaceGuid.PcdTbtEnable == TRUE
> 
> PeiDTbtInitLib|$(PLATFORM_BOARD_PACKAGE)/Features/Tbt/Library/Private/P
> eiDTbtInitLib/PeiDTbtInitLib.inf
> diff --git
> a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSilico
> nPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
> b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSilico
> nPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
> index 5cc7c03c61..2dce9be63c 100644
> ---
> a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/PeiSilico
> nPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
> +++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Policy/Library/Pe
> +++ iSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.c
> @@ -1,7 +1,7 @@
>  /** @file
>Provides silicon policy update library functions.
> 
> -Copyright (c) 2019, Intel Corporation. All rights reserved.
> +Copyright (c) 2019 - 2021, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -398,6 +398,8 @@ SiliconPolicyUpdatePreMem (
>SA_MISC_PEI_PREMEM_CONFIG *MiscPeiPreMemConfig;
>MEMORY_CONFIG_NO_CRC  *MemConfigNoCrc;
>VOID  *Buffer;
> +  UINTN VariableSize;
> +  VOID  *MemorySavedData;
>UINT8 SpdAddressTable[4];
> 
>DEBUG((DEBUG_INFO, "\nUpdating Policy in Pre-Mem\n")); @@ -417,6
> +419,41 @@ SiliconPolicyUpdatePreMem (
>// Pass board specific SpdAddressTable to policy
>//
>CopyMem ((VOID *) MiscPeiPreMemConfig->SpdAddressTable, (VOID *)
> SpdAddressTable, (sizeof (UINT8) * 4));
> +
> +  //
> +  // Set size of SMRAM
> +  //
> +  MiscPeiPreMemConfig->TsegSize = PcdGet32 (PcdTsegSize);
> +
> +  //
> +  // Initialize S3 Data variable (S3DataPtr). It may be used for warm 
> and fast
> boot paths.
> +  // Note: AmberLake FSP does not implement the 

[edk2-devel] 回复: [PATCH v5 2/5] ArmPkg: prepare 32bit ARM build of StandaloneMmPkg

[gaoliming]

Etienne:
  Thanks for your update. This version should pass CI. 

Sami:
  Can you help review the updated patch? So, it can still catch this stable
tag.

Thanks
Liming
> -邮件原件-
> 发件人: Etienne Carriere 
> 发送时间: 2021年8月9日 23:20
> 收件人: devel@edk2.groups.io
> 抄送: Achin Gupta ; Ard Biesheuvel
> ; Jiewen Yao ; Leif
> Lindholm ; Sami Mujawar ;
> Sughosh Ganu ; Liming Gao
> ; Etienne Carriere 
> 主题: [PATCH v5 2/5] ArmPkg: prepare 32bit ARM build of StandaloneMmPkg
> 
> Changes in ArmPkg to prepare building StandaloneMm firmware for
> 32bit Arm architectures.
> 
> Adds ArmmmuStandaloneMmLib library to the list of the standard
> components build for ArmPkg on when ARM architectures.
> 
> Changes path of source file AArch64/ArmMmuStandaloneMmLib.c
> and compile it for both 32bit and 64bit architectures.
> 
> Signed-off-by: Etienne Carriere 
> ---
> Changes since v4:
> - Remove changes related to MmCommunicationDxe and ArmMmuPeiLib
> since
>   they currently don't need to be built for ARM targets.
> - Remove review tags applied to patch v3.
> 
> Changes since v3:
> - Remove Cc tags and apply review tag.
> 
> No change since v2
> No change since v1
> ---
>  ArmPkg/ArmPkg.dec
> |  2 +-
>  ArmPkg/ArmPkg.dsc
> |  2 ++
>  ArmPkg/Library/StandaloneMmMmuLib/{AArch64
> => }/ArmMmuStandaloneMmLib.c | 15 ---
>  ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> |  6 +++---
>  4 files changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> index 214b2f5892..6ed51edd03 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -137,7 +137,7 @@
># hardware coherency (i.e., no virtualization or cache coherent DMA)
> 
> gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride|FALSE|BOO
> LEAN|0x0043
> 
> -[PcdsFeatureFlag.AARCH64]
> +[PcdsFeatureFlag.AARCH64, PcdsFeatureFlag.ARM]
>## Used to select method for requesting services from S-EL1.
>#   TRUE  - Selects FF-A calls for communication between S-EL0 and
> SPMC.
>#   FALSE - Selects SVC calls for communication between S-EL0 and
> SPMC.
> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> index 926986cf7f..8abe3713c8 100644
> --- a/ArmPkg/ArmPkg.dsc
> +++ b/ArmPkg/ArmPkg.dsc
> @@ -161,4 +161,6 @@
>  [Components.AARCH64]
>ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf
>ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf
> +
> +[Components.AARCH64, Components.ARM]
>ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.inf
> diff --git
> a/ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMm
> Lib.c b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.c
> similarity index 92%
> rename from
> ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMmLib
> .c
> rename to
> ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.c
> index dd014beec8..20f873e680 100644
> ---
> a/ArmPkg/Library/StandaloneMmMmuLib/AArch64/ArmMmuStandaloneMm
> Lib.c
> +++ b/ArmPkg/Library/StandaloneMmMmuLib/ArmMmuStandaloneMmLib.c
> @@ -2,6 +2,7 @@
>File managing the MMU for ARMv8 architecture in S-EL0
> 
>Copyright (c) 2017 - 2021, Arm Limited. All rights reserved.
> +  Copyright (c) 2021, Linaro Limited
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>@par Reference(s):
> @@ -62,7 +63,7 @@ SendMemoryPermissionRequest (
>  // for other Direct Request calls which are not atomic
>  // We therefore check only for Direct Response by the
>  // callee.
> -if (SvcArgs->Arg0 ==
> ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP_AARCH64) {
> +if (SvcArgs->Arg0 == ARM_SVC_ID_FFA_MSG_SEND_DIRECT_RESP) {
>// A Direct Response means FF-A success
>// Now check the payload for errors
>// The callee sends back the return value
> @@ -164,13 +165,13 @@ GetMemoryPermissions (
>ZeroMem (, sizeof (ARM_SVC_ARGS));
>if (FeaturePcdGet (PcdFfaEnable)) {
>  // See [2], Section 10.2 FFA_MSG_SEND_DIRECT_REQ.
> -SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64;
> +SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ;
>  SvcArgs.Arg1 = ARM_FFA_DESTINATION_ENDPOINT_ID;
>  SvcArgs.Arg2 = 0;
> -SvcArgs.Arg3 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64;
> +SvcArgs.Arg3 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES;
>  SvcArgs.Arg4 = BaseAddress;
>} else {
> -SvcArgs.Arg0 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES_AARCH64;
> +SvcArgs.Arg0 = ARM_SVC_ID_SP_GET_MEM_ATTRIBUTES;
>  SvcArgs.Arg1 = BaseAddress;
>  SvcArgs.Arg2 = 0;
>  SvcArgs.Arg3 = 0;
> @@ -219,15 +220,15 @@ RequestMemoryPermissionChange (
>ZeroMem (, sizeof (ARM_SVC_ARGS));
>if (FeaturePcdGet (PcdFfaEnable)) {
>  // See [2], Section 10.2 FFA_MSG_SEND_DIRECT_REQ.
> -SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64;
> +SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ;
>  SvcArgs.Arg1 = ARM_FFA_DESTINATION_ENDPOINT_ID;
>  SvcArgs.Arg2 = 0;
> -SvcArgs.Arg3 = ARM_SVC_ID_SP_SET_MEM_ATTRIBUTES_AARCH64;
> +SvcArgs.Arg3 = 

Re: [edk2-devel] [PATCH EDK2 v2 1/1] MdeModulePkg/UefiSortLib:Add UefiSortLib unit test

[Wu, Hao A]

Seems no help is received so far.
The approach I can think of is to add this to the ECC exception list defined in 
file MdeModulePkg.ci.yaml.

Hello Wenyi,

Could you help to check if the code changes in 
https://github.com/tianocore/edk2/pull/1883 works for you?
If so, could you update a V3 version of the patch? Thanks in advance.

Best Regards,
Hao Wu

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Wu, Hao
> A
> Sent: Tuesday, August 10, 2021 12:12 PM
> To: Kinney, Michael D ; devel@edk2.groups.io;
> xiewenyi (A) 
> Cc: songdongku...@huawei.com; Wang, Jian J 
> Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1]
> MdeModulePkg/UefiSortLib:Add UefiSortLib unit test
> 
> Sorry Mike,
> 
> Do you have advice on how to deal with ECC reporting function naming issue
> on the 'main' function for unit test cases?
> So far, I think Wenyi has tried following the same pattern in file
> MdeModulePkg\Universal\Variable\RuntimeDxe\RuntimeDxeUnitTest\Vari
> ableLockRequestToLockUnitTest.c:
> 
> ///
> /// Avoid ECC error for function name that starts with lower case letter ///
> #define Main main
> 
> /**
>   Standard POSIX C entry point for host based unit test execution.
> 
>   @param[in] Argc  Number of arguments
>   @param[in] Argv  Array of pointers to arguments
> 
>   @retval 0  Success
>   @retval other  Error
> **/
> INT32
> Main (
>   IN INT32  Argc,
>   IN CHAR8  *Argv[]
>   )
> 
> But it looks like the ECC checker in the merge test is still complaining.
> 
> Best Regards,
> Hao Wu
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Wu,
> Hao
> > A
> > Sent: Wednesday, August 4, 2021 4:24 PM
> > To: xiewenyi (A) ; Kinney, Michael D
> > ; devel@edk2.groups.io
> > Cc: songdongku...@huawei.com; Wang, Jian J 
> > Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1]
> > MdeModulePkg/UefiSortLib:Add UefiSortLib unit test
> >
> > > -Original Message-
> > > From: xiewenyi (A) 
> > > Sent: Wednesday, August 4, 2021 4:05 PM
> > > To: Wu, Hao A ; devel@edk2.groups.io
> > > Cc: songdongku...@huawei.com; Wang, Jian J 
> > > Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1]
> > > MdeModulePkg/UefiSortLib:Add UefiSortLib unit test
> > >
> > >
> > >
> > > On 2021/8/2 9:56, Wu, Hao A wrote:
> > > >> -Original Message-
> > > >> From: devel@edk2.groups.io  On Behalf Of
> > > >> Wu, Hao A
> > > >> Sent: Thursday, July 29, 2021 4:26 PM
> > > >> To: Wenyi Xie ; devel@edk2.groups.io;
> Wang,
> > > >> Jian J 
> > > >> Cc: songdongku...@huawei.com
> > > >> Subject: Re: [edk2-devel] [PATCH EDK2 v2 1/1]
> > > >> MdeModulePkg/UefiSortLib:Add UefiSortLib unit test
> > > >>
> > > >>> -Original Message-
> > > >>> From: Wenyi Xie 
> > > >>> Sent: Thursday, July 29, 2021 4:01 PM
> > > >>> To: devel@edk2.groups.io; Wang, Jian J ;
> > > >>> Wu, Hao A 
> > > >>> Cc: songdongku...@huawei.com; xiewen...@huawei.com
> > > >>> Subject: [PATCH EDK2 v2 1/1] MdeModulePkg/UefiSortLib:Add
> > > >>> UefiSortLib unit test
> > > >>>
> > > >>> Adding two unit test case for UefiSortLib. One is a test on
> > > >>> sorting an array of
> > > >>> UINT32 by using PerformQuickSort, another is a test on comparing
> > > >>> the same buffer by using StringCompare.
> > > >>
> > > >>
> > > >> Thanks.
> > > >> Reviewed-by: Hao A Wu 
> > > >
> > > >
> > > > Sorry, I found that there are a couple of coding format style
> > > > check failures
> > > when merging the patch.
> > > > Could you help to resolve them and then create a test pull request
> > > > on the
> > > GitHub for verification? Thanks in advance.
> > > > (I think you can take the case under
> > > >
> MdeModulePkg/Universal/Variable/RuntimeDxe/RuntimeDxeUnitTest/
> > for
> > > > reference.)
> > > >
> > >
> > > Hi, Wu Hao
> > >
> > > I try to deal with the coding format style check failures, and meet
> > > a failure which I am not sure how to solve.
> > > I take the case you told for reference, but still there's a failure
> > > said the define should be capital letters.
> > > but if change it to capital letters, there will be another error
> > > Function name does not follow the rules: 1. First character should
> > > be upper case 2. Must contain lower case characters 3. No white
> > > space characters
> > >
> > > #define Main main
> > >
> > > INT32
> > > Main (
> > >   IN INT32  Argc,
> > >   IN CHAR8  *Argv[]
> > >   )
> > > {
> > >   UnitTestingEntry ();
> > >   return 0;
> > > }
> >
> >
> > Hello Mike,
> >
> > I saw the below commit:
> >   SHA-1: dcaa93936591883aa7826eb45ef00416ad82ef08
> >   * MdeModulePkg/Variable/RuntimeDxe: Add Variable Lock Protocol Unit
> > Tests has a similar case that should involve the naming of the 'main'
> > function within the unit test codes.
> >
> > I am wondering how the open raised by Wenyi was handled back then.
> > Do you have suggestions for this case? Thanks in advance.
> >
> > Best Regards,
> > Hao Wu
> >
> >
> > >
> > > Thanks
> > > Wenyi
> > >
> > > > Error details:
> > > > 2021-08-02T01:09:28.5955820Z 

回复: [edk2-devel] [PATCH v2 00/13] Add ACPI 6.4 header file

[gaoliming]

Create PR https://github.com/tianocore/edk2/pull/1887 for this patch set. 

Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io  代表 Sami
> Mujawar
> 发送时间: 2021年8月6日 16:19
> 收件人: Christopher Jones ;
> devel@edk2.groups.io
> 抄送: Akanksha Jain ; Ben Adderson
> ; Michael Kinney ;
> gaolim...@byosoft.com.cn; zhiguang@intel.com; Leif Lindholm
> ; Matteo Carlini ; nd
> 
> 主题: Re: [edk2-devel] [PATCH v2 00/13] Add ACPI 6.4 header file
> 
> For this series.
> 
> Reviewed-by: Sami Mujawar 
> 
> Regards,
> 
> Sami Mujawar
> 
> On 05/08/2021, 17:25, "Chris Jones"  wrote:
> 
> Bugzilla: 3516 (https://bugzilla.tianocore.org/show_bug.cgi?id=3516)
> 
> This patch series introduces a header file for the latest version of the
> ACPI 6.4 specification, January 2021. This header contains all updates
> to the ACPI specification in addition to addressing a few small errors
> from the previous ACPI header files.
> 
> Changes since v1:
> 1. Patch 13/13
> - Remove EFI_ACPI_6_4_GIC_STRUCTURE field name changes.
> [Liming]
> - Add Acpi64.h to IgnoreFiles list in MdePkg.ci.yaml. [Liming]
> 
> The changes can be seen at:
> https://github.com/chris-jones-arm/edk2/tree/1661_add_acpi_64_header_v
> 2
> 
> Chris Jones (13):
>   MdePkg: Add ACPI 6.4 header file
>   MdePkg: Increment FADT version
>   MdePkg: Rename SBSA Generic Watchdog to Arm Generic Watchdog
>   MdePkg: Update PMTT to ACPI 6.4
>   MdePkg: Add SPA Location Cookie field to SPA Range structure
>   MdePkg: Remove DPPT table
>   MdePkg: Add flags and MinTransferSize to Generic Initiator
>   MdePkg: Add 'Type 5' PCC structure
>   MdePkg: Add Multiprocessor Wakeup structure
>   MdePkg: Add the Platform Health Assessment Table (PHAT)
>   MdePkg: Add Secure Access Components in the SDEV table
>   MdePkg: Add Cache ID to PPTT
>   MdePkg: Fix broken coding style in Acpi64.h
> 
>  MdePkg/Include/IndustryStandard/Acpi.h   |4 +-
>  MdePkg/Include/IndustryStandard/Acpi64.h | 3148
> 
>  MdePkg/MdePkg.ci.yaml|2 +
>  3 files changed, 3152 insertions(+), 2 deletions(-)
>  create mode 100644 MdePkg/Include/IndustryStandard/Acpi64.h
> 
> --
> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> 
> 
> 
> 
> 
> 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79070): https://edk2.groups.io/g/devel/message/79070
Mute This Topic: https://groups.io/mt/84807944/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] BaseTools/GenFds: Change FV Header to FileSystemGuid3.

[Yuwei Chen]

Following PI spec: when there has Ffs with EFI_FFS_FILE_HEADER2,
the Parent Fv of the Ffs need set to FileSystemGuid3; when all
the Ffs with EFI_FFS_FILE_HEADER, the Parent Fv of the Ffs need
set to FileSystemGuid2.
Currently, when changing the Ffs in Fv from EFI_FFS_FILE_HEADER
to EFI_FFS_FILE_HEADER2, the Fv FileSystemGuid does not changed
consistent with Ffs type.That caused build issue.

This patch fixes this issue.
As FileSystemGuid3 is compatible with FileSystemGuid2, change all
the Fv header to FileSystemGuid3.

Signed-off-by: Yuwei Chen 
Cc: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/C/GenFv/GenFv.c   | 2 +-
 BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/GenFv/GenFv.c b/BaseTools/Source/C/GenFv/GenFv.c
index 43cc5cd3fe82..af0c21db062a 100644
--- a/BaseTools/Source/C/GenFv/GenFv.c
+++ b/BaseTools/Source/C/GenFv/GenFv.c
@@ -225,7 +225,7 @@ Routine Description:
   //
   // Set the default FvGuid
   //
-  memcpy (, , sizeof 
(EFI_GUID));
+  memcpy (, , sizeof 
(EFI_GUID));
   mFvDataInfo.ForceRebase = -1;
 
   //
diff --git a/BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py 
b/BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py
index 25f9d54874d3..fa559793824d 100644
--- a/BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py
+++ b/BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py
@@ -599,6 +599,8 @@ class GenFdsGlobalVariable:
 if MapFile:
 Cmd += ("-m", MapFile)
 if FileSystemGuid:
+if FileSystemGuid == EFI_FIRMWARE_FILE_SYSTEM2_GUID:
+FileSystemGuid = EFI_FIRMWARE_FILE_SYSTEM3_GUID
 Cmd += ("-g", FileSystemGuid)
 Cmd += ("-o", Output)
 for I in Input:
-- 
2.27.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79069): https://edk2.groups.io/g/devel/message/79069
Mute This Topic: https://groups.io/mt/84807613/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

[Christoph Willing]

On 11/8/21 9:24 am, James Bottomley wrote:
> On Wed, 2021-08-11 at 09:04 +1000, Christoph Willing wrote:
>> On 11/8/21 12:26 am, James Bottomley wrote:
>> [...]
>>> In the working kernel dmesg Gerd requested, what does it mount as
>>> root? sda?  In which case what does the kernel say about where it
>>> got sda from?
>>>
>> Yes it mounts /dev/sda2 as root.
>>
>> The boot logs are are now attached at
>> https://bugzilla.tianocore.org/show_bug.cgi?id=3504 as well a diff
>> between good and bad boots (patched & unpatched code). There's
>> nothing obvious (to me) as to why the unpatched code can't find the
>> virtual disk.
>>
>> My simple minded guess is that PlatformBdsConnectSequence() performs
>> some preparatory work that enables the kernel to have access to the
>> vm (therefore to the virtual disk) by the time TryRunningQemuKernel()
>> is called. At the moment however, TryRunningQemuKernel() is called
>> before PlatformBdsConnectSequence() so that preparatory work hasn't
>> been done and the disk can't be found.
> 
> I suspect the problem is that it no longer creates default devices if
> you don't specify them.  If I look at my working version of a command
> line boot, it's this:
> 
> qemu-kvm \
> -drive 
> if=pflash,format=raw,unit=0,file=/home/jejb/git/edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd,readonly
>  \
> -debugcon file:debug.log -global isa-debugcon.iobase=0x402 \
> -kernel bzImage \
> -initrd initrd.img \
> -append "console=ttyS0 rd.driver.pre=virtio_scsi,9p,9pnet_virtio 
> root=/dev/sda1" \
> -m 2048 \
> -serial stdio \
> -drive if=none,id=sd00,file=debian.img,format=qcow2 \
> -fsdev local,security_model=passthrough,id=modules,path=/tmp/lib/modules \
> -fsdev local,security_model=passthrough,id=home,path=/home/jejb \
> -device virtio-scsi-pci,id=scsi \
> -device virtio-9p-pci,fsdev=modules,id=sd01,mount_tag=modules \
> -device virtio-9p-pci,fsdev=home,id=sd02,mount_tag=home \
> -device scsi-hd,bus=scsi.0,drive=sd00 \
> -device e1000,netdev=net0 \
> -netdev user,id=net0,hostfwd=tcp::-:22 \
> -display vnc=:5 \
> 
> 
> #-chardev socket,id=chrtpm,path=`pwd`/tpmdev/swtpm-sock \
> #-tpmdev emulator,id=tpm0,chardev=chrtpm \
> #-device tpm-tis,tpmdev=tpm0 \
> 
> You can ignore all the TPM stuff and my 9p pass throughs for home
> directory and /tmp modules directory (to make it easy to boot any
> kernel I build).  The relevant lines for you are:
> 
> -drive if=none,id=sd00,file=debian.img,format=qcow2 \
> -device virtio-scsi-pci,id=scsi \
> -device scsi-hd,bus=scsi.0,drive=sd00 \
> 
> Which is how I connect /dev/sda to the qcow2 debian image I use to
> boot.  You have the drive line but no device lines giving the driver
> ... if you add device lines can you then get it to boot?
> 
Thanks for the suggestion James,

I amended my script to have:

-drive if=none,id=sd00,file=disk.img,format=raw \
-device virtio-scsi-pci,id=scsi \
-device scsi-hd,bus=scsi.0,drive=sd00 \

but no joy unfortunately.

I also stripped out some other qemu options like -enable-kvm,-cpu,-cores
etc., in case they caused some weird impacts during boot but that also
had no effect.

chris


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79068): https://edk2.groups.io/g/devel/message/79068
Mute This Topic: https://groups.io/mt/84767423/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

[James Bottomley]

On Wed, 2021-08-11 at 09:04 +1000, Christoph Willing wrote:
> On 11/8/21 12:26 am, James Bottomley wrote:
> [...]
> > In the working kernel dmesg Gerd requested, what does it mount as
> > root? sda?  In which case what does the kernel say about where it
> > got sda from?
> > 
> Yes it mounts /dev/sda2 as root.
> 
> The boot logs are are now attached at
> https://bugzilla.tianocore.org/show_bug.cgi?id=3504 as well a diff
> between good and bad boots (patched & unpatched code). There's
> nothing obvious (to me) as to why the unpatched code can't find the
> virtual disk.
> 
> My simple minded guess is that PlatformBdsConnectSequence() performs
> some preparatory work that enables the kernel to have access to the
> vm (therefore to the virtual disk) by the time TryRunningQemuKernel()
> is called. At the moment however, TryRunningQemuKernel() is called
> before PlatformBdsConnectSequence() so that preparatory work hasn't
> been done and the disk can't be found.

I suspect the problem is that it no longer creates default devices if
you don't specify them.  If I look at my working version of a command
line boot, it's this:

qemu-kvm \
-drive 
if=pflash,format=raw,unit=0,file=/home/jejb/git/edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd,readonly
 \
-debugcon file:debug.log -global isa-debugcon.iobase=0x402 \
-kernel bzImage \
-initrd initrd.img \
-append "console=ttyS0 rd.driver.pre=virtio_scsi,9p,9pnet_virtio 
root=/dev/sda1" \
-m 2048 \
-serial stdio \
-drive if=none,id=sd00,file=debian.img,format=qcow2 \
-fsdev local,security_model=passthrough,id=modules,path=/tmp/lib/modules \
-fsdev local,security_model=passthrough,id=home,path=/home/jejb \
-device virtio-scsi-pci,id=scsi \
-device virtio-9p-pci,fsdev=modules,id=sd01,mount_tag=modules \
-device virtio-9p-pci,fsdev=home,id=sd02,mount_tag=home \
-device scsi-hd,bus=scsi.0,drive=sd00 \
-device e1000,netdev=net0 \
-netdev user,id=net0,hostfwd=tcp::-:22 \
-display vnc=:5 \


#-chardev socket,id=chrtpm,path=`pwd`/tpmdev/swtpm-sock \
#-tpmdev emulator,id=tpm0,chardev=chrtpm \
#-device tpm-tis,tpmdev=tpm0 \

You can ignore all the TPM stuff and my 9p pass throughs for home
directory and /tmp modules directory (to make it easy to boot any
kernel I build).  The relevant lines for you are:

-drive if=none,id=sd00,file=debian.img,format=qcow2 \
-device virtio-scsi-pci,id=scsi \
-device scsi-hd,bus=scsi.0,drive=sd00 \

Which is how I connect /dev/sda to the qcow2 debian image I use to
boot.  You have the drive line but no device lines giving the driver
... if you add device lines can you then get it to boot?

James




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79067): https://edk2.groups.io/g/devel/message/79067
Mute This Topic: https://groups.io/mt/84767423/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

[Christoph Willing]

On 11/8/21 12:26 am, James Bottomley wrote:
> On Tue, 2021-08-10 at 10:10 +1000, Christoph Willing wrote:
>> On 10/8/21 12:52 am, James Bottomley wrote:
>>> On Mon, 2021-08-09 at 22:53 +1000, Christoph Willing wrote:
 With soft feature freeze started, I wonder if this patch could be
 reviewed and pushed for edk2-stable202108 tag? I think it has
 languished because I didn't initially Cc appropriately - pls add
 others as necessary.

 This patch is a trivial (I think) change which fixes a long
 standing
 and annoying bug for those booting Qemu with UEFI using external
 kernel & initrd.
>>>
>>> I'm with Ard on this one: -kernel is working just fine for me and
>>> the
>>> team at IBM working on Kata containers.  It sounds like this might
>>> be a
>>> problem local to your environment, so we need to debug it to
>>> understand
>>> the issue rather than blindly reverse existing commits.
>>>
>> Thanks for responding James & Ard.
>>
>> Below is the script I'm using to create, then run, the VM. To verify
>> that it works normally with UEFI boot, it initially uses the internal
>> kernel & initrd.
>>
>> The OVMF_CODE & my_VARS lines contain git hash to identify the build
>> from which OVMF_CODE.fd & OVMF_VARS.fd were taken; 97fdcg is from a
>> build of yesterday's git master.
>>
>> After the OS has been installed, I can run the VM multiple times to
>> verify that it boots under UEFI OK (I see the TianoCore splash
>> screen)
>> with internal kernel.
>>
>>
>> #!/bin/bash
>>
>> /usr/bin/qemu-kvm \
>> -name "UEFI Testing" \
>> -enable-kvm \
>> -cpu kvm64 \
>> -smp cores=4 \
>> -boot once=c \
>> -m 8192 \
>> -device intel-hda \
>> -device hda-duplex \
>> -vga virtio \
>> -drive if=pflash,format=raw,file=OVMF_CODE_97fdcb.fd,readonly=on \
>> -drive if=pflash,format=raw,file=my_VARS_97fdcb.fd \
>> -drive file=disk.img,format=raw,cache=none,index=0,media=disk \
>> -cdrom
>> /storage/iso/slackware/slackware64-15.0/slackware64-15.0-20210807.iso 
>> \
>> -daemonize \
>> "$@"
> 
> There's no definition of a disk device in here.
> 
-drive file=disk.img,format=raw,cache=none,index=0,media=disk \


>> To now use external kernel, I add the lines:
>>
>> -kernel /var/cache/vmbuilder/boot/15.0/x86_64/vmlinuz \
>> -initrd /var/cache/vmbuilder/boot/15.0/x86_64/initrd \
>> -append "root=/dev/sda2 rootfstype=ext4 ro vga=0x386" \
>>
>> to the script just after "-boot once=c" (but I doubt the exact
>> positioning makes any difference).
>>
>> In this case, I see the kernel running and initrd unpacked and its
>> modules loaded but the root partition is unable to be mounted - the
>> disk
>> is not visible (running 'ls -l /dev/sd*' in recovery shell gives 'ls:
>> /dev/sd*: No such file or directory').
>>
>> The last lines of the Qemu screen are:
>>
>> /boot/initrd-5.13.8.gz: Loading kernel modules from initrd image:
>> insmod /lib/modules/5.13.8/kernel/fs/jbd2/jbd2.ko
>> insmod /lib/modules/5.13.8/kernel/fs/mbcache.ko
>> insmod /lib/modules/5.13.8/kernel/fs/ext4/ext4.ko
>> mount: mounting /dev/sda2 on /mnt failed: No such file or directory
> 
> Which looks like why this failed.
> 
Exactly. I should have mentioned that specifically in the patch comment,
although the bz report at
https://bugzilla.tianocore.org/show_bug.cgi?id=3504 already says:
"The kernel and initrd are loaded but have no access to the VM itself."


> Where's the vmm supposed to get /dev/sda from?  It sort of seems like
> the CD rom boot script thinks it was mounted as a USB device in this
> case.
> 
It should find /dev/sda in the virtual disk, just as it is correctly
found in the case of the patched code.


> In the working kernel dmesg Gerd requested, what does it mount as root?
> sda?  In which case what does the kernel say about where it got sda
> from?
> 
Yes it mounts /dev/sda2 as root.

The boot logs are are now attached at
https://bugzilla.tianocore.org/show_bug.cgi?id=3504 as well a diff
between good and bad boots (patched & unpatched code). There's nothing
obvious (to me) as to why the unpatched code can't find the virtual disk.

My simple minded guess is that PlatformBdsConnectSequence() performs
some preparatory work that enables the kernel to have access to the vm
(therefore to the virtual disk) by the time TryRunningQemuKernel() is
called. At the moment however, TryRunningQemuKernel() is called before
PlatformBdsConnectSequence() so that preparatory work hasn't been done
and the disk can't be found.

chris



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79066): https://edk2.groups.io/g/devel/message/79066
Mute This Topic: https://groups.io/mt/84767423/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Add MMIO Base/Length to SA GNVS

[Nate DeSimone]

The SA GNVS Area contains fields for the MMIO region
base address and length. This implements code to
populate those fields. The MMIO Base/Length are used
by ASL at runtime and must be populated for normal
system operation.

Cc: Chasel Chiu 
Cc: Michael Kubacki 
Cc: Benjamin Doron 
Signed-off-by: Nate DeSimone 
---
 .../Acpi/BoardAcpiDxe/AcpiGnvsInit.c  | 57 ++-
 .../Acpi/BoardAcpiDxe/BoardAcpiDxe.inf| 12 +++-
 2 files changed, 63 insertions(+), 6 deletions(-)

diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c 
b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
index 0d9d217e38..b09b92f2e6 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/AcpiGnvsInit.c
@@ -1,7 +1,7 @@
 /** @file
   Acpi Gnvs Init Library.
 
-Copyright (c) 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -11,11 +11,51 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
+#include 
+
+/**
+  A protocol callback which updates MMIO Base and Length in SA GNVS area
+
+  @param[in] Event- The triggered event.
+  @param[in] Context  - Context for this event.
+
+**/
+VOID
+UpdateSaGnvsForMmioResourceBaseLength (
+  IN EFI_EVENT Event,
+  IN VOID  *Context
+  )
+{
+  EFI_STATUSStatus;
+  SYSTEM_AGENT_GLOBAL_NVS_AREA_PROTOCOL *SaGlobalNvsAreaProtocol;
+
+  Status = gBS->LocateProtocol (, NULL, (VOID **) 
);
+  if (Status != EFI_SUCCESS) {
+return;
+  }
+  gBS->CloseEvent (Event);
+
+  //
+  // Configure MMIO Base/Length. This logic is only valid for platforms that 
use PciHostBridgeLibSimple.
+  //
+  DEBUG ((DEBUG_INFO, "[BoardAcpiDxe] Update SA GNVS Area.\n"));
+  SaGlobalNvsAreaProtocol->Area->Mmio32Base = PcdGet32 (PcdPciReservedMemBase);
+  if (PcdGet32 (PcdPciReservedMemLimit) != 0) {
+SaGlobalNvsAreaProtocol->Area->Mmio32Length = PcdGet32 
(PcdPciReservedMemLimit) - PcdGet32 (PcdPciReservedMemBase) + 1;
+  } else {
+SaGlobalNvsAreaProtocol->Area->Mmio32Length = ((UINT32) PcdGet64 
(PcdPciExpressBaseAddress)) - PcdGet32 (PcdPciReservedMemBase);
+  }
+  if (PcdGet64 (PcdPciReservedMemAbove4GBLimit) > PcdGet64 
(PcdPciReservedMemAbove4GBBase)) {
+SaGlobalNvsAreaProtocol->Area->Mmio64Base   = PcdGet64 
(PcdPciReservedMemAbove4GBBase);
+SaGlobalNvsAreaProtocol->Area->Mmio64Length = PcdGet64 
(PcdPciReservedMemAbove4GBLimit) - PcdGet64 (PcdPciReservedMemAbove4GBBase) + 1;
+  }
+}
 
 /**
 @brief
@@ -39,6 +79,7 @@ AcpiGnvsInit (
   EFI_MP_SERVICES_PROTOCOL  *MpService;
   UINTN NumberOfCPUs;
   UINTN NumberOfEnabledCPUs;
+  VOID  *SaGlobalNvsRegistration;
 
   Pages = EFI_SIZE_TO_PAGES (sizeof (EFI_GLOBAL_NVS_AREA));
   Address = 0x; // allocate address below 4G.
@@ -53,7 +94,7 @@ AcpiGnvsInit (
   if (EFI_ERROR(Status)) {
 return Status;
   }
-  
+
   //
   // Locate the MP services protocol
   // Find the MP Protocol. This is an MP platform, so MP protocol must be 
there.
@@ -90,6 +131,16 @@ AcpiGnvsInit (
   GNVS->Area->PL1LimitCS = 0;
   GNVS->Area->PL1LimitCSValue = 4500;
 
+  //
+  // Update SA GNVS with MMIO Base/Length
+  //
+  EfiCreateProtocolNotifyEvent (
+,
+TPL_CALLBACK,
+UpdateSaGnvsForMmioResourceBaseLength,
+NULL,
+
+);
+
   return EFI_SUCCESS;
 }
-
diff --git 
a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf 
b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf
index 7d2e105e54..5d3d4c3a2b 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/Acpi/BoardAcpiDxe/BoardAcpiDxe.inf
@@ -1,7 +1,7 @@
 ### @file
 #  Component information file for AcpiPlatform module
 #
-# Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
 #
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -38,6 +38,7 @@
   PcdLib
   UefiBootServicesTableLib
   UefiRuntimeServicesTableLib
+  UefiLib
   BaseMemoryLib
   HobLib
   AslUpdateLib
@@ -48,8 +49,15 @@
   gEfiFirmwareVolume2ProtocolGuid   ## CONSUMES
   gEfiMpServiceProtocolGuid ## CONSUMES
   gEfiGlobalNvsAreaProtocolGuid
+  gSaGlobalNvsAreaProtocolGuid  ## CONSUMES
 
 [Pcd]
+  gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
+  gMinPlatformPkgTokenSpaceGuid.PcdPciReservedMemBase
+  gMinPlatformPkgTokenSpaceGuid.PcdPciReservedMemLimit
+  gMinPlatformPkgTokenSpaceGuid.PcdPciReservedMemAbove4GBBase
+  gMinPlatformPkgTokenSpaceGuid.PcdPciReservedMemAbove4GBLimit
+
   gKabylakeOpenBoardPkgTokenSpaceGuid.PcdAcpiGnvsAddress
 
   

Re: [edk2-devel] [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx: Add missing _STA methods in ACPI tables

[Marcin Wojtas]

Hi,


wt., 10 sie 2021 o 16:41 Ard Biesheuvel  napisał(a):
>
> On Tue, 10 Aug 2021 at 16:36, Samer El-Haj-Mahmoud
>  wrote:
> >
> > Apologies for the tardiness in replying to this. Please see my comments 
> > below.
> >
> > > -Original Message-
> > > From: Marcin Wojtas 
> > > Sent: Friday, July 30, 2021 5:57 AM
> > > To: Ard Biesheuvel 
> > > Cc: Samer El-Haj-Mahmoud ; edk2-
> > > devel-groups-io ; Leif Lindholm
> > > ; Ard Biesheuvel ;
> > > Grzegorz Jaszczyk ; Grzegorz Bernacki
> > > ; upstr...@semihalf.com; Jon (j...@solid-run.com)
> > > 
> > > Subject: Re: [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx:
> > > Add missing _STA methods in ACPI tables
> > >
> > > Hi Ard,
> > >
> > > czw., 29 lip 2021 o 11:58 Ard Biesheuvel  napisał(a):
> > > >
> > > > On Thu, 29 Jul 2021 at 11:46, Marcin Wojtas  wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > pon., 19 lip 2021 o 17:06 Marcin Wojtas  
> > > > > napisał(a):
> > > > > >
> > > > > > Hi Ard,
> > > > > >
> > > > > > pon., 19 lip 2021 o 11:54 Ard Biesheuvel  
> > > > > > napisał(a):
> > > > > > >
> > > > > > > On Mon, 19 Jul 2021 at 11:31, Marcin Wojtas 
> > > wrote:
> > > > > > > >
> > > > > > > > BBR 1.0 spec says that _STA is required for each device in DSDT 
> > > > > > > > or
> > > SSDT.
> > > > > > > > Fix that for all platforms with the Marvell SoC's.
> > > > > > > >
> > > > > > >
> > > > > > > Can we fix the BBR instead? If ACPI itself does not require _STA, 
> > > > > > > BBR
> > > > > > > should not require it either.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I consulted with ARM on the matter. SBBR has requirements of things
> > > > > > that are otherwise optional in UEFI/ACPI/SMBIOS. Also some OS's may
> > > > > > require that and I can see those methods in most of the other ACPI
> > > > > > source files in the edk2-platfoms tree. I think the BBR requirements
> > > > > > discussions can follow, but it would be great if this change can be
> > > > > > applied, so that no to block other development.
> > > > > >
> > > > >
> > > > > Do you have any feedback to the patchset and the _STA methods
> > > concerns?
> > > > >
> > > >
> > > > Yes. I would like to understand why _STA methods are now mandated by
> > > BBR.
> > > >
> > >
> > > Understood. Providing an answer may not be immediate and may possibly
> > > require further discussion on the SystemArchAC level.
> > > How about we withdraw this single patch for now and process the
> > > remaining ones? We would come back to the _STA subject, as soon as
> > > there's more information available.
> > >
> > > Best regards,
> > > Marcin
> > >
> >
> > _STA has been required in SBBR since ver 1.0 (published 2016, with the 0.9 
> > draft since 2014)
> > https://developer.arm.com/documentation/den0044/b/?lang=en
> >
> > I do not have the history on why SBBR 1.0+ requires _STA, but it most 
> > likely has to do wit the Windows strong use case for it: 
> > https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-management-namespace-objects#device-status-changes
> >  . Windows is a key OS targeted by SBBR.
> >
>
> OK, I stand corrected again :-)
>
> Marcin,
>
> I won't object further to these additions -please respin the patch on
> top of current edk2-platform and I will apply it right away.

I resubmitted: 
https://edk2.groups.io/g/devel/topic/edk2_platforms_patch_v2/84804301?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,84804301
In a spare moment I'd appreciate taking a look at '[edk2-platforms
PATCH v2 0/4] SolidRun CEx7 Evaluation Board support' patchset :)

Thanks,
Marcin


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79064): https://edk2.groups.io/g/devel/message/79064
Mute This Topic: https://groups.io/mt/84304355/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH v2] Marvell: Armada7k8k/OcteonTx: Add missing _STA methods in ACPI tables

[Marcin Wojtas]

BBR 1.0 spec says that _STA is required for each device in DSDT or SSDT.
Fix that for all platforms with the Marvell SoC's.

Signed-off-by: Marcin Wojtas 
---
Changelog:
v1->v2:
* Rebase on top of tree

 Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl| 56 
+++
 Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0Db/Dsdt.asl| 76 

 Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0McBin/Dsdt.asl | 76 

 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl | 12 
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl | 60 

 5 files changed, 280 insertions(+)

diff --git a/Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl 
b/Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl
index 345c1e4dd6..88e38efeeb 100644
--- a/Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl
+++ b/Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl
@@ -20,21 +20,37 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "MVEBU ", 
"ARMADA7K", 3)
 {
 Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware 
ID
 Name (_UID, 0x000)  // _UID: Unique ID
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 }
 Device (CPU1)
 {
 Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware 
ID
 Name (_UID, 0x001)  // _UID: Unique ID
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 }
 Device (CPU2)
 {
 Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware 
ID
 Name (_UID, 0x100)  // _UID: Unique ID
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 }
 Device (CPU3)
 {
 Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware 
ID
 Name (_UID, 0x101)  // _UID: Unique ID
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 }
 
 Device (AHC0)
@@ -42,6 +58,10 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "MVEBU ", 
"ARMADA7K", 3)
 Name (_HID, "LNRO001E") // _HID: Hardware ID
 Name (_UID, 0x00)   // _UID: Unique ID
 Name (_CCA, 0x01)   // _CCA: Cache Coherency Attribute
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 Name (_CLS, Package (0x03)  // _CLS: Class Code
 {
 0x01,
@@ -67,6 +87,10 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "MVEBU ", 
"ARMADA7K", 3)
 Name (_HID, "MRVL0002") // _HID: Hardware ID
 Name (_UID, 0x00)   // _UID: Unique ID
 Name (_CCA, 0x01)   // _CCA: Cache Coherency Attribute
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
@@ -96,6 +120,10 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "MVEBU ", 
"ARMADA7K", 3)
 Name (_HID, "MRVL0004") // _HID: Hardware ID
 Name (_UID, 0x01)   // _UID: Unique ID
 Name (_CCA, 0x01)   // _CCA: Cache Coherency Attribute
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
@@ -123,6 +151,10 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "MVEBU ", 
"ARMADA7K", 3)
 Name (_HID, "PNP0D10")  // _HID: Hardware ID
 Name (_UID, 0x00)   // _UID: Unique ID
 Name (_CCA, 0x01)   // _CCA: Cache Coherency Attribute
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
@@ -142,6 +174,10 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "MVEBU ", 
"ARMADA7K", 3)
 Name (_HID, "PNP0D10")  // _HID: Hardware ID
 Name (_UID, 0x01)   // _UID: Unique ID
 Name (_CCA, 0x01)   // _CCA: Cache Coherency Attribute
+Method (_STA)   // _STA: Device status
+{
+Return (0xF)
+}
 
 Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
 {
@@ -160,6 +196,10 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "MVEBU ", 
"ARMADA7K", 3)
 {
 Name (_HID, "MRVL0001") // _HID: 
Hardware ID
 Name (_CID, "HISI0031")  

Re: [edk2-devel] [PATCH v2 1/2] BaseTools: Define the read-only data section name per toolchain

[Andrew Fish via groups.io]

> On Aug 10, 2021, at 2:30 PM, Marvin Häuser  wrote:
> 
> On 10/08/2021 21:35, Andrew Fish via groups.io wrote:
>> 
>> 
>>> On Aug 10, 2021, at 1:27 AM, Marvin Häuser >> > wrote:
>>> 
>>> On 10/08/2021 06:19, Andrew Fish via groups.io  wrote:
 
 
> On Aug 9, 2021, at 2:51 AM, Marvin Häuser    >> wrote:
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3318 
>  
>  >
> 
> Different toolchains of the EDK II build system may generate ELF or
> Mach-O files, which use the ".rodata" naming convention, or PE/COFF
> files, which use the ".rdata" naming convention. Section permissions
> are chosen based on this name per file format by NASM. To harden
> image permission security, and to save space by avoiding both
> ".rdata" and ".rodata" sections being emitted, expose the appropriate
> name as a preprocessor constant.
> 
> Cc: Bob Feng mailto:bob.c.f...@intel.com> 
> >>
> Cc: Liming Gao    >>
> Cc: Yuwei Chen mailto:yuwei.c...@intel.com> 
> >>
> Cc: Vitaly Cheptsov    >>
> Signed-off-by: Marvin Häuser    >>
> ---
> BaseTools/Conf/tools_def.template | 172 ++--
> 1 file changed, 86 insertions(+), 86 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 2e6b382ab623..84d464916c4d 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -463,9 +463,9 @@ NOOPT_VS2008_IA32_CC_FLAGS= /nologo /c /WX 
> /GS- /W4 /Gs32768 /D UNICODE
> RELEASE_VS2008_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd
> 
> NOOPT_VS2008_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
> 
> 
> 
> -  DEBUG_VS2008_IA32_NASM_FLAGS= -Ox -f win32 -g
> 
> -RELEASE_VS2008_IA32_NASM_FLAGS= -Ox -f win32
> 
> -NOOPT_VS2008_IA32_NASM_FLAGS  = -O0 -f win32 -g
> 
> +  DEBUG_VS2008_IA32_NASM_FLAGS= -Ox -f win32 -g 
> -DRODATA_SECTION_NAME=.rdata
> 
> +RELEASE_VS2008_IA32_NASM_FLAGS= -Ox -f win32 
> -DRODATA_SECTION_NAME=.rdata
> 
> +NOOPT_VS2008_IA32_NASM_FLAGS  = -O0 -f win32 -g 
> -DRODATA_SECTION_NAME=.rdata
> 
> 
> 
>   DEBUG_VS2008_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
> /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D 
> /MACHINE:X86 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
> /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /DEBUG
> 
> RELEASE_VS2008_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
> /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
> /SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
> /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER 
> /MERGE:.rdata=.data
> 
> @@ -495,9 +495,9 @@ NOOPT_VS2008_X64_CC_FLAGS   = /nologo /c /WX /GS- 
> /W4 /Gs32768 /D UNICODE /G
> RELEASE_VS2008_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
> 
> NOOPT_VS2008_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
> 
> 
> 
> -  DEBUG_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -g
> 
> -RELEASE_VS2008_X64_NASM_FLAGS   = -Ox -f win64
> 
> -NOOPT_VS2008_X64_NASM_FLAGS = -O0 -f win64 -g
> 
> +  DEBUG_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -g 
> -DRODATA_SECTION_NAME=.rdata
> 
> +RELEASE_VS2008_X64_NASM_FLAGS   = -Ox -f win64 
> -DRODATA_SECTION_NAME=.rdata
> 
> +NOOPT_VS2008_X64_NASM_FLAGS = -O0 -f win64 -g 
> -DRODATA_SECTION_NAME=.rdata
> 
> 
> 
>   DEBUG_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
> /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D 
> /Machine:X64 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
> /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /DEBUG
> 
> RELEASE_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
> /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
> /SECTION:.pdata,D /Machine:X64 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
> /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 

Re: [edk2-devel] [PATCH v2 1/2] BaseTools: Define the read-only data section name per toolchain

[Andrew Fish via groups.io]

> On Aug 10, 2021, at 2:24 PM, Marvin Häuser  wrote:
> 
> On 10/08/2021 21:49, Andrew Fish wrote:
>> I forgot I have an Ubuntu VM so we can take a look at an ELF to PE/COFF  
>> toolchain example ….
>> 
>> So it looks like nasm[1] “does the right thing”(tm) and places a .rodata 
>> section in the object file….
>> 
>> But it looks like GenFw[2] smashed the .rodata section into .data section 
>> when it translated to PE/COFF. This was the issue I was worried about….
>> 
>> Actually I should probably look at the ELF executable too[3]. Yikes no 
>> .rodata in the ELF. So it looks likely that the linker scripts are smashing 
>> .rodata into .data.
> 
> They smash it into .text, as linked in the other mail [1].

Sorry I get way to much email…..

> This is fine honestly, just I want some toggle that decides consistently for 
> all toolchains what to do (merge into .text or let it live as a separate 
> section). But that'd be a task for another patch.
> 

I’m still trying to wrap my head around the definition of the nasm 
RODATA_SECTION_NAME. Do we want it to track what ends up in the object file, 
the native executable, or the PE/COFF?

It seems like it is tracking the object file. If that is the case we can just 
fix the XCODE changes to use  `__TEXT,__const`and all the toolchains would be 
consistent. 

I’d like to see the commit message reworked to better define what is going on. 
RODATA_SECTION_NAME tracks what end up object file, and PE/COFF results are 
controlled by the linker script/GenFw or mtoc. 

Thanks,

Andrew Fish

> Best regards,
> Marvin
> 
> 
> [1] 
> https://github.com/tianocore/edk2/blob/d02dbb53cd78de799e6afaa237e98771fb5148db/BaseTools/Scripts/GccBase.lds#L25
> 
>> So there may be multiple issues with ELF toolchains that need to change to 
>> end up with a .rodata in the PE/COFF.
>> 
>> [1]$ objdump -fh  
>> Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj
>> 
>> Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj:
>>  file format elf64-x86-64
>> architecture: i386:x86-64, flags 0x0011:
>> HAS_RELOC, HAS_SYMS
>> start address 0x
>> 
>> Sections:
>> Idx Name  Size  VMA   LMA   File off  Algn
>>   0 .rodata   0006      0200  
>> 2**2
>>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>>   1 .text 001d      0210  
>> 2**4
>>   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>> 
>> 
>> 
>> [2]$ objdump -fh 
>> Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.efi
>> 
>> Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.efi: 
>> file format pei-x86-64
>> architecture: i386:x86-64, flags 0x010b:
>> HAS_RELOC, EXEC_P, HAS_DEBUG, D_PAGED
>> start address 0x8eb1
>> 
>> Sections:
>> Idx Name  Size  VMA LMA   File off  Algn
>>   0 .text ff80  0240  0240  0240  
>> 2**4
>>   CONTENTS, ALLOC, LOAD, READONLY, CODE
>>   1 .data 0540  000101c0  000101c0  000101c0  
>> 2**4
>>   CONTENTS, ALLOC, LOAD, DATA
>>   2 .reloc0080  00010700  00010700  00010700  
>> 2**2
>>   CONTENTS, ALLOC, LOAD, READONLY, DATA
>> 
>> [3] $ objdump -fh 
>> Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.dll
>> 
>> Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.dll: 
>> file format elf64-x86-64
>> architecture: i386:x86-64, flags 0x0013:
>> HAS_RELOC, EXEC_P, HAS_SYMS
>> start address 0x8eb1
>> 
>> Sections:
>> Idx Name  Size  VMA LMA   File off  Algn
>>   0 .text ff46  0240  0240  00c0  
>> 2**6
>>   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>>   1 .data 0490  000101c0  000101c0  00010040  
>> 2**6
>>   CONTENTS, ALLOC, LOAD, RELOC, DATA
>>   2 .rela 04f8  00010680  00010680  000104d0  
>> 2**3
>>   CONTENTS, READONLY
>>   3 .build-id 0024  00010b78  00010b78  000109c8  
>> 2**2
>>   CONTENTS, READONLY
>>   4 .gnu_debuglink 0014      000109ec  
>> 2**2
>>   CONTENTS, READONLY
>> 
>> 
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On Aug 10, 2021, at 12:35 PM, Andrew Fish via groups.io  
>>> mailto:afish=apple@groups.io>> wrote:
>>> 
>>> 
>>> 
 On Aug 10, 2021, at 1:27 AM, Marvin Häuser >>> > wrote:
 
 On 10/08/2021 06:19, Andrew Fish via groups.io  wrote:
> 
> 
>> On Aug 9, 2021, at 2:51 AM, Marvin Häuser > 

Re: [edk2-devel] [PATCH v2 1/2] BaseTools: Define the read-only data section name per toolchain

[Marvin Häuser]

On 10/08/2021 21:35, Andrew Fish via groups.io wrote:



On Aug 10, 2021, at 1:27 AM, Marvin Häuser > wrote:


On 10/08/2021 06:19, Andrew Fish via groups.io  wrote:



On Aug 9, 2021, at 2:51 AM, Marvin Häuser  >> wrote:


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


Different toolchains of the EDK II build system may generate ELF or
Mach-O files, which use the ".rodata" naming convention, or PE/COFF
files, which use the ".rdata" naming convention. Section permissions
are chosen based on this name per file format by NASM. To harden
image permission security, and to save space by avoiding both
".rdata" and ".rodata" sections being emitted, expose the appropriate
name as a preprocessor constant.

Cc: Bob Feng mailto:bob.c.f...@intel.com> 
>>
Cc: Liming Gao  >>
Cc: Yuwei Chen mailto:yuwei.c...@intel.com> 
>>
Cc: Vitaly Cheptsov  >>
Signed-off-by: Marvin Häuser  >>

---
BaseTools/Conf/tools_def.template | 172 ++--
1 file changed, 86 insertions(+), 86 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template

index 2e6b382ab623..84d464916c4d 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -463,9 +463,9 @@ NOOPT_VS2008_IA32_CC_FLAGS    = /nologo /c 
/WX /GS- /W4 /Gs32768 /D UNICODE

RELEASE_VS2008_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd

NOOPT_VS2008_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff 
/Zd /Zi




-  DEBUG_VS2008_IA32_NASM_FLAGS    = -Ox -f win32 -g

-RELEASE_VS2008_IA32_NASM_FLAGS    = -Ox -f win32

-NOOPT_VS2008_IA32_NASM_FLAGS  = -O0 -f win32 -g

+  DEBUG_VS2008_IA32_NASM_FLAGS    = -Ox -f win32 -g 
-DRODATA_SECTION_NAME=.rdata


+RELEASE_VS2008_IA32_NASM_FLAGS    = -Ox -f win32 
-DRODATA_SECTION_NAME=.rdata


+NOOPT_VS2008_IA32_NASM_FLAGS  = -O0 -f win32 -g 
-DRODATA_SECTION_NAME=.rdata




  DEBUG_VS2008_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
/SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 
/SAFESEH:NO /BASE:0 /DRIVER /DEBUG


RELEASE_VS2008_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 
/SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 
/SAFESEH:NO /BASE:0 /DRIVER /MERGE:.rdata=.data


@@ -495,9 +495,9 @@ NOOPT_VS2008_X64_CC_FLAGS   = /nologo /c 
/WX /GS- /W4 /Gs32768 /D UNICODE /G

RELEASE_VS2008_X64_ASM_FLAGS    = /nologo /c /WX /W3 /Cx /Zd

NOOPT_VS2008_X64_ASM_FLAGS    = /nologo /c /WX /W3 /Cx /Zd /Zi



-  DEBUG_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -g

-RELEASE_VS2008_X64_NASM_FLAGS   = -Ox -f win64

-NOOPT_VS2008_X64_NASM_FLAGS = -O0 -f win64 -g

+  DEBUG_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -g 
-DRODATA_SECTION_NAME=.rdata


+RELEASE_VS2008_X64_NASM_FLAGS   = -Ox -f win64 
-DRODATA_SECTION_NAME=.rdata


+NOOPT_VS2008_X64_NASM_FLAGS = -O0 -f win64 -g 
-DRODATA_SECTION_NAME=.rdata




  DEBUG_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
/SECTION:.pdata,D /Machine:X64 /LTCG /DLL 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 
/SAFESEH:NO /BASE:0 /DRIVER /DEBUG


RELEASE_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 
/SECTION:.xdata,D /SECTION:.pdata,D /Machine:X64 /LTCG /DLL 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 
/SAFESEH:NO /BASE:0 /DRIVER /MERGE:.rdata=.data


@@ -574,9 +574,9 @@ NOOPT_VS2008x86_IA32_CC_FLAGS  = /nologo /c 
/WX /GS- /W4 /Gs32768 /D UNICODE

RELEASE_VS2008x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd

NOOPT_VS2008x86_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff 
/Zd /Zi




-  DEBUG_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 -g

-RELEASE_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32

-NOOPT_VS2008x86_IA32_NASM_FLAGS    = -O0 -f win32 -g

+  DEBUG_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 -g 
-DRODATA_SECTION_NAME=.rdata


+RELEASE_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 
-DRODATA_SECTION_NAME=.rdata


+NOOPT_VS2008x86_IA32_NASM_FLAGS    = -O0 -f win32 -g 
-DRODATA_SECTION_NAME=.rdata




  

Re: [edk2-devel] [PATCH v2 1/2] BaseTools: Define the read-only data section name per toolchain

[Marvin Häuser]

On 10/08/2021 21:49, Andrew Fish wrote:
I forgot I have an Ubuntu VM so we can take a look at an ELF to 
PE/COFF  toolchain example ….


So it looks like nasm[1] “does the right thing”(tm) and places a 
.rodata section in the object file….


But it looks like GenFw[2] smashed the .rodata section into .data 
section when it translated to PE/COFF. This was the issue I was 
worried about….


Actually I should probably look at the ELF executable too[3]. Yikes no 
.rodata in the ELF. So it looks likely that the linker scripts are 
smashing .rodata into .data.


They smash it into .text, as linked in the other mail [1]. This is fine 
honestly, just I want some toggle that decides consistently for all 
toolchains what to do (merge into .text or let it live as a separate 
section). But that'd be a task for another patch.


Best regards,
Marvin


[1] 
https://github.com/tianocore/edk2/blob/d02dbb53cd78de799e6afaa237e98771fb5148db/BaseTools/Scripts/GccBase.lds#L25


So there may be multiple issues with ELF toolchains that need to 
change to end up with a .rodata in the PE/COFF.


[1]$ objdump -fh 
 Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj


Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj: 
    file format elf64-x86-64

architecture: i386:x86-64, flags 0x0011:
HAS_RELOC, HAS_SYMS
start address 0x

Sections:
Idx Name          Size      VMA               LMA       File off  Algn
  0 .rodata       0006     
 0200  2**2

                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         001d     
 0210  2**4

                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE



[2]$ objdump -fh 
Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.efi


Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.efi: 
    file format pei-x86-64

architecture: i386:x86-64, flags 0x010b:
HAS_RELOC, EXEC_P, HAS_DEBUG, D_PAGED
start address 0x8eb1

Sections:
Idx Name          Size      VMA LMA               File off  Algn
  0 .text         ff80  0240  0240 
 0240  2**4

                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         0540  000101c0  000101c0 
 000101c0  2**4

                  CONTENTS, ALLOC, LOAD, DATA
  2 .reloc        0080  00010700  00010700 
 00010700  2**2

                  CONTENTS, ALLOC, LOAD, READONLY, DATA

[3] $ objdump -fh 
Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.dll


Build/OvmfX64/DEBUG_GCC5/X64/UefiCpuPkg/CpuDxe/CpuDxe/DEBUG/CpuDxe.dll: 
    file format elf64-x86-64

architecture: i386:x86-64, flags 0x0013:
HAS_RELOC, EXEC_P, HAS_SYMS
start address 0x8eb1

Sections:
Idx Name          Size      VMA LMA               File off  Algn
  0 .text         ff46  0240  0240 
 00c0  2**6

                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         0490  000101c0  000101c0 
 00010040  2**6

                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .rela         04f8  00010680  00010680 
 000104d0  2**3

                  CONTENTS, READONLY
  3 .build-id     0024  00010b78  00010b78 
 000109c8  2**2

                  CONTENTS, READONLY
  4 .gnu_debuglink 0014     
 000109ec  2**2

                  CONTENTS, READONLY



Thanks,

Andrew Fish

On Aug 10, 2021, at 12:35 PM, Andrew Fish via groups.io 
 > wrote:




On Aug 10, 2021, at 1:27 AM, Marvin Häuser > wrote:


On 10/08/2021 06:19, Andrew Fish via groups.io  
wrote:



On Aug 9, 2021, at 2:51 AM, Marvin Häuser  >> wrote:


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


Different toolchains of the EDK II build system may generate ELF or
Mach-O files, which use the ".rodata" naming convention, or PE/COFF
files, which use the ".rdata" naming convention. Section permissions
are chosen based on this name per file format by NASM. To harden
image permission security, and to save space by avoiding both
".rdata" and ".rodata" sections being emitted, expose the appropriate
name as a preprocessor constant.

Cc: Bob Feng mailto:bob.c.f...@intel.com> 
>>
Cc: Liming Gao  >>
Cc: Yuwei Chen mailto:yuwei.c...@intel.com> 

Re: [edk2-devel] [PATCH v2 1/2] MdePkg/BaseLib: Fix unaligned API prototypes

[Marvin Häuser]

On 10/08/2021 19:36, Andrew Fish via groups.io wrote:



On Aug 10, 2021, at 1:53 AM, Marvin Häuser > wrote:


On 09/08/2021 23:32, Andrew Fish viagroups.io wrote:



On Aug 9, 2021, at 9:15 AM, Michael D Kinney 
>> wrote:


Hi Marvin,

Can you provide an example of which C compiler is flagging this as
an error and what error message is generated.

Please enter a BZ with this background information and add link to the
BZ in the commit message.

This is a change to the BaseLib class, so we need to make sure there
are no impacts to any existing code.  I looks like a safe change
because changing from a pointer to a fixed size type to VOID *
should be compatible.  Please add that analysis to the background
in the BZ as well.



MIke,

I want to say we had a discussion about this years ago? I don’t 
remember the outcome.


Dereferencing a misaligned pointer is UB (Undefined Behavior) in C 
[1], but historically x86 compilers have let it slide.


I think the situation we are in is the BaseLib functions don’t 
contain UB, but it is UB for the caller to use the returned pointer 
directly.


They do contain UB, inherently from the combination of their 
prototype and their usage.
Please refer to the new BZ added for 
V2:https://bugzilla.tianocore.org/show_bug.cgi?id=3542 





I think we are saying the same thing.


OK, sorry, misunderstood then.

My point is it is possible to use the library API correctly, but 
likely no one does. Changing the API to a VOID also does not fix every 
issue, actually it is a drop in to existing code so it does not really 
force any fixes...


Yes, but at least it does not *force* the caller to do UB casts.
I actually have fixed everything I found here: 
https://github.com/mhaeuser/edk2/commit/7266c31f04634bf3e1861e84f9be9983a6084f3c
Just I thought I could not possibly defend such a huge patch for an 
issue nobody encounters and likely never will either. If you want the 
patch, you totally can have it, just I did not want to increase the 
burden for no reason. I'm fine if future code does it right, but also to 
polish and submit above patch.





I could only speculate why UBsan does not check cast safety...
To be fair, I don't know a real-world platform that has issues with 
this UB, but the fix is simple enough in my opinion.




Cast is compile time UB, not runtime. UBSan is doing runtime checks. 
You can catch compile time UB with warnings. I've have had way too 
many talks with the clang folks about UB and firmware :).


Right, that would have been a guess. One could make a point though that 
it is RT UB, because UB is only invoked if the address is actually not 
aligned, the compiler not having a proof is not enough. Thanks for the 
insight!





Actually, enabling "-Wcast-align" some day would be great either way. :)



In my example this gets you past the -Wcast-align. We have the same 
type of casts for the size of pointers and casting through UINTN.

UINT16 *pointer = (UINT16 *)(void *)(buffer+1);


Yes, but this looks much more ominous than without the void cast. I 
sometimes experiment with code style a bit in my own private code, and 
omitting void pointers as far as possible (exceptions for cases as 
above) has been one of those experiments. I don't think one can nail C 
code style perfectly, it's always a game of trade-offs.




Actually I’m starting to remember why we chose not to fix this before. 
It does not really help…. Notice if we change the API to use `VOID *` 
vs. `UINT16 *` nothing really changed [1] ?  It is still up to the 
caller to do the right thing.


Yes-ish, this is not quite a functional fix, it's about guarantees. If 
the functions take UINT16 pointers, they request a guarantee from every 
caller, with no docs required, that the pointers must be aligned for 
this type. It's a guarantee for the functional implementation, but more 
importantly a guarantee for the compiler. If we change it to a VOID 
pointer, it will basically be no-op for the binary, as no compiler 
really makes such assumptions at cast-time (to my knowledge), but the 
guarantees were shifted. Now, if the function wants an alignment 
guarantee from the caller, it has to define it in the docs. No such 
exists, so the caller knows that the input pointer does not impose any 
alignment constraints, and the compiler knows it cannot assume any such.


The real issue is the functions are not really useful given strict UB 
in C….


A better solution is to just tell the compiler this pointer is not 
aligned, and at that point you DON'T need the lib functions….


This code passes -Wcast-align and -fsanitize=undefined runtime checks:
typedef UINT16 UUINT16 __attribute__ ((aligned (1)));

int main()
{
UINT8 *buffer = malloc(64);
UUINT16 *pointer = (UUINT16 *)(buffer+1);
*pointer = 42;
return 

Re: [edk2-devel] [PATCH v2 1/2] BaseTools: Define the read-only data section name per toolchain

[Andrew Fish via groups.io]

> On Aug 10, 2021, at 1:27 AM, Marvin Häuser  wrote:
> 
> On 10/08/2021 06:19, Andrew Fish via groups.io wrote:
>> 
>> 
>>> On Aug 9, 2021, at 2:51 AM, Marvin Häuser >> > wrote:
>>> 
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3318 
>>> 
>>> 
>>> Different toolchains of the EDK II build system may generate ELF or
>>> Mach-O files, which use the ".rodata" naming convention, or PE/COFF
>>> files, which use the ".rdata" naming convention. Section permissions
>>> are chosen based on this name per file format by NASM. To harden
>>> image permission security, and to save space by avoiding both
>>> ".rdata" and ".rodata" sections being emitted, expose the appropriate
>>> name as a preprocessor constant.
>>> 
>>> Cc: Bob Feng mailto:bob.c.f...@intel.com>>
>>> Cc: Liming Gao mailto:gaolim...@byosoft.com.cn>>
>>> Cc: Yuwei Chen mailto:yuwei.c...@intel.com>>
>>> Cc: Vitaly Cheptsov mailto:vit9...@protonmail.com>>
>>> Signed-off-by: Marvin Häuser >> >
>>> ---
>>> BaseTools/Conf/tools_def.template | 172 ++--
>>> 1 file changed, 86 insertions(+), 86 deletions(-)
>>> 
>>> diff --git a/BaseTools/Conf/tools_def.template 
>>> b/BaseTools/Conf/tools_def.template
>>> index 2e6b382ab623..84d464916c4d 100755
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -463,9 +463,9 @@ NOOPT_VS2008_IA32_CC_FLAGS= /nologo /c /WX /GS- 
>>> /W4 /Gs32768 /D UNICODE
>>> RELEASE_VS2008_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd
>>> 
>>> NOOPT_VS2008_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
>>> 
>>> 
>>> 
>>> -  DEBUG_VS2008_IA32_NASM_FLAGS= -Ox -f win32 -g
>>> 
>>> -RELEASE_VS2008_IA32_NASM_FLAGS= -Ox -f win32
>>> 
>>> -NOOPT_VS2008_IA32_NASM_FLAGS  = -O0 -f win32 -g
>>> 
>>> +  DEBUG_VS2008_IA32_NASM_FLAGS= -Ox -f win32 -g 
>>> -DRODATA_SECTION_NAME=.rdata
>>> 
>>> +RELEASE_VS2008_IA32_NASM_FLAGS= -Ox -f win32 
>>> -DRODATA_SECTION_NAME=.rdata
>>> 
>>> +NOOPT_VS2008_IA32_NASM_FLAGS  = -O0 -f win32 -g 
>>> -DRODATA_SECTION_NAME=.rdata
>>> 
>>> 
>>> 
>>>   DEBUG_VS2008_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
>>> /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D 
>>> /MACHINE:X86 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
>>> /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /DEBUG
>>> 
>>> RELEASE_VS2008_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
>>> /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
>>> /SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
>>> /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER 
>>> /MERGE:.rdata=.data
>>> 
>>> @@ -495,9 +495,9 @@ NOOPT_VS2008_X64_CC_FLAGS   = /nologo /c /WX /GS- 
>>> /W4 /Gs32768 /D UNICODE /G
>>> RELEASE_VS2008_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
>>> 
>>> NOOPT_VS2008_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
>>> 
>>> 
>>> 
>>> -  DEBUG_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -g
>>> 
>>> -RELEASE_VS2008_X64_NASM_FLAGS   = -Ox -f win64
>>> 
>>> -NOOPT_VS2008_X64_NASM_FLAGS = -O0 -f win64 -g
>>> 
>>> +  DEBUG_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -g 
>>> -DRODATA_SECTION_NAME=.rdata
>>> 
>>> +RELEASE_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -DRODATA_SECTION_NAME=.rdata
>>> 
>>> +NOOPT_VS2008_X64_NASM_FLAGS = -O0 -f win64 -g 
>>> -DRODATA_SECTION_NAME=.rdata
>>> 
>>> 
>>> 
>>>   DEBUG_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
>>> /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D /SECTION:.pdata,D 
>>> /Machine:X64 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
>>> /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /DEBUG
>>> 
>>> RELEASE_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
>>> /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
>>> /SECTION:.pdata,D /Machine:X64 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
>>> /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER 
>>> /MERGE:.rdata=.data
>>> 
>>> @@ -574,9 +574,9 @@ NOOPT_VS2008x86_IA32_CC_FLAGS  = /nologo /c /WX 
>>> /GS- /W4 /Gs32768 /D UNICODE
>>> RELEASE_VS2008x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd
>>> 
>>> NOOPT_VS2008x86_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
>>> 
>>> 
>>> 
>>> -  DEBUG_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 -g
>>> 
>>> -RELEASE_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32
>>> 
>>> -NOOPT_VS2008x86_IA32_NASM_FLAGS= -O0 -f win32 -g
>>> 
>>> +  DEBUG_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 -g 
>>> -DRODATA_SECTION_NAME=.rdata
>>> 
>>> +RELEASE_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 
>>> -DRODATA_SECTION_NAME=.rdata
>>> 
>>> +NOOPT_VS2008x86_IA32_NASM_FLAGS= -O0 -f win32 -g 
>>> -DRODATA_SECTION_NAME=.rdata
>>> 
>>> 
>>> 
>>>   DEBUG_VS2008x86_IA32_DLINK_FLAGS = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
>>> /OPT:REF /OPT:ICF=10 /MAP 

[edk2-devel] edk2-test Release Notice

[G Edhaya Chandran]

Hello All,

 This mail is to notify that the edk2-test repository shall be released by 
end of August 2021
with the tag edk2-test-stable202108.

The base-line commit shall be: 814b2af535d977b3967d65de77e42ab18a4f4db4

Please feel free to contact me or Barton for any clarifications.

With Warm Regards,
Edhay

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79055): https://edk2.groups.io/g/devel/message/79055
Mute This Topic: https://groups.io/mt/84801150/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Fix memory corruption

[Guo Dong]

Thanks to capture and fix this issue.

Reviewed-by: Guo Dong 

-Original Message-
From: Marvin Häuser  
Sent: Sunday, August 8, 2021 12:40 PM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Ni, Ray ; Ma, Maurice 
; You, Benjamin ; Vitaly Cheptsov 

Subject: [PATCH] UefiPayloadPkg/UefiPayloadEntry: Fix memory corruption

UefiPayloadEntry's AllocatePool() applies the "sizeof" operator to HOB index 
rather than the HOB header structure. This yields 4 Bytes compared to the 8 
Bytes the structure header requires. Fix the call to allocate the required 
space instead.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 
Cc: Vitaly Cheptsov 
Signed-off-by: Marvin Häuser 
---
 UefiPayloadPkg/UefiPayloadEntry/MemoryAllocation.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/UefiPayloadEntry/MemoryAllocation.c 
b/UefiPayloadPkg/UefiPayloadEntry/MemoryAllocation.c
index 1204573b3e09..f3494969e5ac 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/MemoryAllocation.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/MemoryAllocation.c
@@ -163,7 +163,7 @@ AllocatePool (
 return NULL;   } -  Hob = (EFI_HOB_MEMORY_POOL *)CreateHob 
(EFI_HOB_TYPE_MEMORY_POOL, (UINT16)(sizeof (EFI_HOB_TYPE_MEMORY_POOL) + 
AllocationSize));+  Hob = (EFI_HOB_MEMORY_POOL *)CreateHob 
(EFI_HOB_TYPE_MEMORY_POOL, (UINT16)(sizeof (EFI_HOB_MEMORY_POOL) + 
AllocationSize));   return (VOID *)(Hob + 1); } -- 
2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79054): https://edk2.groups.io/g/devel/message/79054
Mute This Topic: https://groups.io/mt/84754069/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiPayloadPkg: Fix the non-ascii character in UniversalPayloadEntry.c

[Guo Dong]

Reviewed-by: Guo Dong 

-Original Message-
From: Tan, Dun  
Sent: Sunday, August 8, 2021 11:08 PM
To: devel@edk2.groups.io
Cc: Dong, Guo ; Ni, Ray ; Ma, Maurice 
; You, Benjamin ; Tan, Dun 

Subject: [PATCH] UefiPayloadPkg: Fix the non-ascii character in 
UniversalPayloadEntry.c

Fix the non-ascii character in UniversalPayloadEntry.c

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Maurice Ma 
Cc: Benjamin You 

Signed-off-by: DunTan 
---
 UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.c 
b/UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.c
index 09dd1e8378..03ad9c457b 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/UniversalPayloadEntry.c
@@ -38,7 +38,7 @@ PrintHob (
 /**
   Some bootloader may pass a pcd database, and UPL also contain a PCD database.
   Dxe PCD driver has the assumption that the two PCD database can be catenated 
and
-  the local token number should be successive。
+  the local token number should be successive.
   This function will fix up the UPL PCD database to meet that assumption.
 
   @param[in]   DxeFv The FV where to find the Universal PCD database.
-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79053): https://edk2.groups.io/g/devel/message/79053
Mute This Topic: https://groups.io/mt/84762943/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/2] MdePkg/BaseLib: Fix unaligned API prototypes

[Andrew Fish via groups.io]

> On Aug 10, 2021, at 1:53 AM, Marvin Häuser  wrote:
> 
> On 09/08/2021 23:32, Andrew Fish via groups.io  wrote:
>> 
>> 
>>> On Aug 9, 2021, at 9:15 AM, Michael D Kinney >>  >> >> wrote:
>>> 
>>> Hi Marvin,
>>> 
>>> Can you provide an example of which C compiler is flagging this as
>>> an error and what error message is generated.
>>> 
>>> Please enter a BZ with this background information and add link to the
>>> BZ in the commit message.
>>> 
>>> This is a change to the BaseLib class, so we need to make sure there
>>> are no impacts to any existing code.  I looks like a safe change
>>> because changing from a pointer to a fixed size type to VOID *
>>> should be compatible.  Please add that analysis to the background
>>> in the BZ as well.
>>> 
>> 
>> MIke,
>> 
>> I want to say we had a discussion about this years ago? I don’t remember the 
>> outcome.
>> 
>> Dereferencing a misaligned pointer is UB (Undefined Behavior) in C [1], but 
>> historically x86 compilers have let it slide.
>> 
>> I think the situation we are in is the BaseLib functions don’t contain UB, 
>> but it is UB for the caller to use the returned pointer directly.
> 
> They do contain UB, inherently from the combination of their prototype and 
> their usage.
> Please refer to the new BZ added for V2: 
> https://bugzilla.tianocore.org/show_bug.cgi?id=3542 
> 
> 

I think we are saying the same thing. My point is it is possible to use the 
library API correctly, but likely no one does. Changing the API to a VOID also 
does not fix every issue, actually it is a drop in to existing code so it does 
not really force any fixes...

> I could only speculate why UBsan does not check cast safety...
> To be fair, I don't know a real-world platform that has issues with this UB, 
> but the fix is simple enough in my opinion.
> 

Cast is compile time UB, not runtime. UBSan is doing runtime checks. You can 
catch compile time UB with warnings. I've have had way too many talks with the 
clang folks about UB and firmware :).

> Actually, enabling "-Wcast-align" some day would be great either way. :)
> 

In my example this gets you past the -Wcast-align. We have the same type of 
casts for the size of pointers and casting through UINTN. 
UINT16 *pointer = (UINT16 *)(void *)(buffer+1);

Actually I’m starting to remember why we chose not to fix this before. It does 
not really help…. Notice if we change the API to use `VOID *` vs. `UINT16 *` 
nothing really changed [1] ?  It is still up to the caller to do the right 
thing. The real issue is the functions are not really useful given strict UB in 
C….

A better solution is to just tell the compiler this pointer is not aligned, and 
at that point you DON'T need the lib functions….

This code passes -Wcast-align and -fsanitize=undefined runtime checks:
 
typedef UINT16 UUINT16 __attribute__ ((aligned (1)));

int main()
{
UINT8 *buffer = malloc(64);
UUINT16 *pointer = (UUINT16 *)(buffer+1);

*pointer = 42;
return *pointer;
}

So a better solution maybe to defined unaligned basic types? I’m not sure if 
__declspec(align(1)) does the right thing for VC++, __attribute__ ((aligned 
(1))); does the right thing for GCC and clang. Assuming this works we could 
defined unaligned version of our basic types, and over time obsolete the 
current alignment lib functions. We could start with a warning comment to use 
the unaligned types vs. current library functions. 

I’m thinking for the types in ProcessorBind.h[2] and Base.h[3] we could have a 
byte aligned versions. For example given UINT16 we add UUINT16 to Base.h. I 
guess we could also  look into a #define abstraction for ` __attribute__ 
((aligned (1)))` so new could could use that in a portable way?

Just to be clear if we define UUINT16 then the compiler will do the the work of 
WriteUnaligned16() in the code generation, if it is needed by the CPU arch. 
Given that it is much harder for the coder to “mess it up”. 

Actually I changed my mind I think we will want to keep the Unaligned library 
functions, but update them to use the unaligned pointers. The reason we need 
the function is the compiler is generating code that follow the rules of the 
CPU, so we need the library functions to talk to hardware devices that have 
stricter alignment rules than the CPU. For example on x86 UUINT16 will end up 
being a word operation in assembler. This is the reason the current lib 
functions use volatile. Sorry figuring this out as I type. So looks like we 
need to add unaligned types and update the libs to use those types? For memory 
operations you can use the new unaligned types, and for hardware access use the 
lib functions. 

[1] ~/work/Compiler>cat ub.c
#include 

#define EFIAPI
#define IN
#define OUT
#define VOID void

typedef unsigned char   

[edk2-devel] [PATCH v3 6/6] ArmVirtPkg: Disable the TPM2 platform hierarchy

[Stefan Berger]

Use the newly added function to disable the TPM2 platform hierarchy.

Signed-off-by: Stefan Berger 
---
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c  | 6 ++
 .../PlatformBootManagerLib/PlatformBootManagerLib.inf   | 1 +
 2 files changed, 7 insertions(+)

diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 69448ff65b..a45824ab06 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -832,6 +833,11 @@ PlatformBootManagerAfterConsole (
 EfiBootManagerConnectAll ();
   }
 
+  //
+  // Disable the TPM 2 platform hierarchy
+  //
+  ConfigureTpmPlatformHierarchy ();
+
   //
   // Enumerate all possible boot options, then filter and reorder them based on
   // the QEMU configuration.
diff --git 
a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 11f52e019b..cead956bfc 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -51,6 +51,7 @@
   UefiBootServicesTableLib
   UefiLib
   UefiRuntimeServicesTableLib
+  TpmPlatformHierarchyLib
 
 [FixedPcd]
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
-- 
2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79051): https://edk2.groups.io/g/devel/message/79051
Mute This Topic: https://groups.io/mt/84798637/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 2/6] OvmfPkg/TPM: Add a NULL implementation of TpmPlatformHierarchyLib

[Stefan Berger]

Add a NULL implementation of the library class TpmPlatformHierarchyLib

Signed-off-by: Stefan Berger 
---
 .../PeiDxeTpmPlatformHierarchyLib.c   | 19 
 .../PeiDxeTpmPlatformHierarchyLib.inf | 31 +++
 2 files changed, 50 insertions(+)
 create mode 100644 
OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.c
 create mode 100644 
OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf

diff --git 
a/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.c
 
b/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.c
new file mode 100644
index 00..a4d38a1465
--- /dev/null
+++ 
b/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.c
@@ -0,0 +1,19 @@
+/** @file
+Null TPM Platform Hierarchy configuration library.
+
+This library provides stub functions for customizing the TPM's Platform 
Hierarchy.
+
+Copyright (c) 2021, IBM Corporation.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+VOID
+EFIAPI
+ConfigureTpmPlatformHierarchy (
+  )
+{
+  /* no nothing */
+}
diff --git 
a/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 
b/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
new file mode 100644
index 00..f0c474d57c
--- /dev/null
+++ 
b/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
@@ -0,0 +1,31 @@
+### @file
+#
+#   TPM Platform Hierarchy configuration library.
+#
+#   This library provides functions for customizing the TPM's Platform 
Hierarchy
+#   Authorization Value (platformAuth) and Platform Hierarchy Authorization
+#   Policy (platformPolicy) can be defined through this function.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+# Copyright (c) Microsoft Corporation.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+###
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = PeiDxeTpmPlatformHierarchyLibNull
+  FILE_GUID  = 7794F92C-4E8E-4E57-9E4A-49A0764C7D73
+  MODULE_TYPE= PEIM
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = TpmPlatformHierarchyLib|PEIM DXE_DRIVER
+
+[LibraryClasses]
+  BaseLib
+
+[Packages]
+  MdePkg/MdePkg.dec
+
+[Sources]
+  PeiDxeTpmPlatformHierarchyLib.c
-- 
2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79046): https://edk2.groups.io/g/devel/message/79046
Mute This Topic: https://groups.io/mt/84798632/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 1/6] OvmfPkg/TPM: Import PeiDxeTpmPlatformHierarchyLib.c from edk2-platforms

[Stefan Berger]

Import PeiDxeTpmPlatformHierarchyLib.c from edk2-platforms. Modify it so
that ConfigureTpmPlatformHierarchy() is the only public function provided
by this file.

Signed-off-by: Stefan Berger 
---
 .../Include/Library/TpmPlatformHierarchyLib.h |  27 +++
 .../PeiDxeTpmPlatformHierarchyLib.c   | 210 ++
 .../PeiDxeTpmPlatformHierarchyLib.inf |  40 
 3 files changed, 277 insertions(+)
 create mode 100644 OvmfPkg/Include/Library/TpmPlatformHierarchyLib.h
 create mode 100644 
OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c
 create mode 100644 
OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf

diff --git a/OvmfPkg/Include/Library/TpmPlatformHierarchyLib.h 
b/OvmfPkg/Include/Library/TpmPlatformHierarchyLib.h
new file mode 100644
index 00..a872fa09dc
--- /dev/null
+++ b/OvmfPkg/Include/Library/TpmPlatformHierarchyLib.h
@@ -0,0 +1,27 @@
+/** @file
+TPM Platform Hierarchy configuration library.
+
+This library provides functions for customizing the TPM's Platform 
Hierarchy
+Authorization Value (platformAuth) and Platform Hierarchy Authorization
+Policy (platformPolicy) can be defined through this function.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+Copyright (c) Microsoft Corporation.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _TPM_PLATFORM_HIERARCHY_LIB_H_
+#define _TPM_PLATFORM_HIERARCHY_LIB_H_
+
+/**
+   This service will perform the TPM Platform Hierarchy configuration at the 
SmmReadyToLock event.
+
+**/
+VOID
+EFIAPI
+ConfigureTpmPlatformHierarchy (
+  VOID
+  );
+
+#endif
diff --git 
a/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c 
b/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c
new file mode 100644
index 00..ba2d99bb53
--- /dev/null
+++ 
b/OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.c
@@ -0,0 +1,210 @@
+/** @file
+TPM Platform Hierarchy configuration library.
+
+This library provides functions for customizing the TPM's Platform 
Hierarchy
+Authorization Value (platformAuth) and Platform Hierarchy Authorization
+Policy (platformPolicy) can be defined through this function.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+Copyright (c) Microsoft Corporation.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+@par Specification Reference:
+
https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+//
+// The authorization value may be no larger than the digest produced by the 
hash
+//   algorithm used for context integrity.
+//
+#define  MAX_NEW_AUTHORIZATION_SIZE SHA512_DIGEST_SIZE
+
+UINT16   mAuthSize;
+
+/**
+  Generate high-quality entropy source through RDRAND.
+
+  @param[in]   LengthSize of the buffer, in bytes, to fill with.
+  @param[out]  Entropy   Pointer to the buffer to store the entropy data.
+
+  @retval EFI_SUCCESSEntropy generation succeeded.
+  @retval EFI_NOT_READY  Failed to request random data.
+
+**/
+EFI_STATUS
+EFIAPI
+RdRandGenerateEntropy (
+  IN UINTN Length,
+  OUT UINT8*Entropy
+  )
+{
+  EFI_STATUS  Status;
+  UINTN   BlockCount;
+  UINT64  Seed[2];
+  UINT8   *Ptr;
+
+  Status = EFI_NOT_READY;
+  BlockCount = Length / 64;
+  Ptr = (UINT8 *)Entropy;
+
+  //
+  // Generate high-quality seed for DRBG Entropy
+  //
+  while (BlockCount > 0) {
+Status = GetRandomNumber128 (Seed);
+if (EFI_ERROR (Status)) {
+  return Status;
+}
+CopyMem (Ptr, Seed, 64);
+
+BlockCount--;
+Ptr = Ptr + 64;
+  }
+
+  //
+  // Populate the remained data as request.
+  //
+  Status = GetRandomNumber128 (Seed);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+  CopyMem (Ptr, Seed, (Length % 64));
+
+  return Status;
+}
+
+/**
+  This function returns the maximum size of TPM2B_AUTH; this structure is used 
for an authorization value
+  and limits an authValue to being no larger than the largest digest produced 
by a TPM.
+
+  @param[out] AuthSize Tpm2 Auth size
+
+  @retval EFI_SUCCESS  Auth size returned.
+  @retval EFI_DEVICE_ERROR Can not return platform auth due to 
device error.
+
+**/
+EFI_STATUS
+EFIAPI
+GetAuthSize (
+  OUT UINT16*AuthSize
+  )
+{
+  EFI_STATUSStatus;
+  TPML_PCR_SELECTIONPcrs;
+  UINTN Index;
+  UINT16DigestSize;
+
+  Status = EFI_SUCCESS;
+
+  while (mAuthSize == 0) {
+
+mAuthSize = SHA1_DIGEST_SIZE;
+ZeroMem (, sizeof (TPML_PCR_SELECTION));
+Status = Tpm2GetCapabilityPcrs ();
+
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "Tpm2GetCapabilityPcrs fail!\n"));
+  break;
+}
+
+DEBUG ((DEBUG_ERROR, "Tpm2GetCapabilityPcrs - %08x\n", 

[edk2-devel] [PATCH v3 4/6] OvmfPkg: Disable the TPM2 platform hierarchy

[Stefan Berger]

Use the newly added function to disable the TPM2 platform hierarchy.

Signed-off-by: Stefan Berger 
---
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  | 6 ++
 OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c | 6 ++
 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c  | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index b0e9742937..5bf145ba25 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 
@@ -1516,6 +1517,11 @@ PlatformBootManagerAfterConsole (
   //
   Tcg2PhysicalPresenceLibProcessRequest (NULL);
 
+  //
+  // Disable the TPM 2 platform hierarchy
+  //
+  ConfigureTpmPlatformHierarchy ();
+
   //
   // Process QEMU's -kernel command line option
   //
diff --git a/OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c
index eaade4adea..09418dc4ff 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLibBhyve/BdsPlatform.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -1450,6 +1451,11 @@ PlatformBootManagerAfterConsole (
   //
   Tcg2PhysicalPresenceLibProcessRequest (NULL);
 
+  //
+  // Disable the TPM 2 platform hierarchy
+  //
+  ConfigureTpmPlatformHierarchy ();
+
   //
   // Perform some platform specific connect sequence
   //
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
index 7cceeea487..508e2b6403 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 //
@@ -1315,6 +1316,11 @@ PlatformBootManagerAfterConsole (
   //
   Tcg2PhysicalPresenceLibProcessRequest (NULL);
 
+  //
+  // Disable the TPM 2 platform hierachy
+  //
+  ConfigureTpmPlatformHierarchy ();
+
   //
   // Process QEMU's -kernel command line option
   //
-- 
2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79049): https://edk2.groups.io/g/devel/message/79049
Mute This Topic: https://groups.io/mt/84798635/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 5/6] ArmVirtPkg: Reference new TPM classes in the build system for compilation

[Stefan Berger]

Signed-off-by: Stefan Berger 
---
 ArmVirtPkg/ArmVirtCloudHv.dsc| 1 +
 ArmVirtPkg/ArmVirtQemu.dsc   | 3 +++
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
 ArmVirtPkg/ArmVirtXen.dsc| 1 +
 4 files changed, 6 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index f292ba6079..cb135d08d9 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -55,6 +55,7 @@
   
PciHostBridgeUtilityLib|ArmVirtPkg/Library/ArmVirtPciHostBridgeUtilityLib/ArmVirtPciHostBridgeUtilityLib.inf
 
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 
 !include MdePkg/MdeLibs.dsc.inc
 
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 97539edef7..10dfc382b5 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -86,8 +86,10 @@
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
 !else
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 !endif
 
 [LibraryClasses.common.PEIM]
@@ -523,6 +525,7 @@
 
   
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
   
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
   NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
   NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
   NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 28064199c8..d89da457e0 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -80,6 +80,7 @@
   
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
   
PciHostBridgeUtilityLib|OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 
 [LibraryClasses.common.DXE_DRIVER]
   
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 2b07a5ba19..e41259fa54 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -50,6 +50,7 @@
   
PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
-- 
2.31.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79050): https://edk2.groups.io/g/devel/message/79050
Mute This Topic: https://groups.io/mt/84798636/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 3/6] OvmfPkg: Reference new TPM classes in the build system for compilation

[Stefan Berger]

Compile the added TPM related code now.

Signed-off-by: Stefan Berger 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc   | 3 +++
 OvmfPkg/Bhyve/BhyveX64.dsc | 1 +
 .../Library/PlatformBootManagerLib/PlatformBootManagerLib.inf  | 1 +
 OvmfPkg/OvmfPkgIa32.dsc| 3 +++
 OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++
 OvmfPkg/OvmfPkgX64.dsc | 3 +++
 OvmfPkg/OvmfXen.dsc| 1 +
 7 files changed, 15 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index e6cd10b759..db1deffcc8 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -209,9 +209,11 @@
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
   
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
 !else
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 !endif
 
 [LibraryClasses.common]
@@ -836,6 +838,7 @@
   SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
 
   
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
   NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
   
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
   NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index d8fe607d1c..76904ae614 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -224,6 +224,7 @@
 
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index e470b9a6a3..e7d1917022 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -56,6 +56,7 @@
   PlatformBmPrintScLib
   Tcg2PhysicalPresenceLib
   XenPlatformLib
+  TpmPlatformHierarchyLib
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d1d92c97ba..7c2948c5e9 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -235,9 +235,11 @@
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
   
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
 !else
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 !endif
 
 [LibraryClasses.common]
@@ -711,6 +713,7 @@
   SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf {
 
   
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
+  
TpmPlatformHierarchyLib|OvmfPkg/Library/PeiDxeTpmPlatformHierarchyLib/PeiDxeTpmPlatformHierarchyLib.inf
   NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
   NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
   NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index a467ab7090..88a014510f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -239,9 +239,11 @@
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
   
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
   

Re: [edk2-devel] [edk2-platforms] [PATCH V1] MinPlatformPkg: Cleanup PeiFspWrapperHobProcessLib dependencies

[Michael Kubacki]

Acked-by: Michael Kubacki 

On 8/10/2021 12:37 AM, Nate DeSimone wrote:

PeiFspWrapperHobProcessLib is currently set to depens on
FspWrapperPlatformLib, but it does not use any of the
functions implemented by that LibraryClass. This change
removes that unneeded dependency.

Cc: Chasel Chiu 
Cc: Michael Kubacki 
Cc: Benjamin Doron 
Signed-off-by: Nate DeSimone 
---
  .../PeiFspWrapperHobProcessLib/PeiFspWrapperHobProcessLib.inf  | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/PeiFspWrapperHobProcessLib/PeiFspWrapperHobProcessLib.inf
 
b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/PeiFspWrapperHobProcessLib/PeiFspWrapperHobProcessLib.inf
index 64f3302959..b846e7af1d 100644
--- 
a/Platform/Intel/MinPlatformPkg/FspWrapper/Library/PeiFspWrapperHobProcessLib/PeiFspWrapperHobProcessLib.inf
+++ 
b/Platform/Intel/MinPlatformPkg/FspWrapper/Library/PeiFspWrapperHobProcessLib/PeiFspWrapperHobProcessLib.inf
@@ -1,7 +1,7 @@
  ## @file
  #  Provide FSP wrapper hob process related function.
  #
-# Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
  #
  # SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -55,7 +55,6 @@
BaseMemoryLib
HobLib
DebugLib
-  FspWrapperPlatformLib
PeiServicesLib
PeiServicesTablePointerLib
  




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79044): https://edk2.groups.io/g/devel/message/79044
Mute This Topic: https://groups.io/mt/84786793/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 6/6] Platform/StandaloneMm: build StandaloneMmRpmb for 32bit architectures

[Etienne Carriere]

Build PlatformStandaloneMmRpmb for ARM architecture (32bit arm machine).
The generated image targets an execution environment similar to AArch64
StMM secure partition in OP-TEE but in 32bit mode.

GCC flag -fno-stack-protector
added. The stack protection code bring
GOT dependencies we prefer avoid when StMM runs in OP-TEE.

Cc: Ard Biesheuvel 
Cc: Ilias Apalodimas 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Signed-off-by: Etienne Carriere 
---
No change since v2

Changes since v1:
- Remove useless duplication of ArmSvcLib loading.
- Move BaseStackCheckLib to generic library classes instead of ARM only.
- include MdePkg/MdeLibs.dsc.inc 
instead of loading
  RegisterFilterLibNull.inf for ARM architecture.
---
 Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc | 
12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git 
a/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc 
b/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
index cb3f1ddf52..33364deb1e 100644
--- a/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
+++ b/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
@@ -16,12 +16,14 @@
   PLATFORM_VERSION   = 1.0
   DSC_SPECIFICATION  = 0x0001001C
   OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
-  SUPPORTED_ARCHITECTURES= AARCH64
+  SUPPORTED_ARCHITECTURES= ARM|AARCH64
   BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
   SKUID_IDENTIFIER   = DEFAULT
   FLASH_DEFINITION   = 
Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.fdf
   DEFINE DEBUG_MESSAGE   = TRUE
 
+!include MdePkg/MdeLibs.dsc.inc
+
 

 #
 # Library Class section - list of all Library Classes needed by this Platform.
@@ -39,6 +41,7 @@
   FvLib|StandaloneMmPkg/Library/FvLib/FvLib.inf
   
HobLib|StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCoreHobLib.inf
   IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
   MemLib|StandaloneMmPkg/Library/StandaloneMmMemLib/StandaloneMmMemLib.inf
   
MemoryAllocationLib|StandaloneMmPkg/Library/StandaloneMmCoreMemoryAllocationLib/StandaloneMmCoreMemoryAllocationLib.inf
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
@@ -68,6 +71,9 @@
   #
   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
 
+[LibraryClasses.ARM]
+  ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
+
 [LibraryClasses.common.MM_STANDALONE]
   HobLib|StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
   
MmServicesTableLib|MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
@@ -160,3 +166,7 @@
 [BuildOptions.AARCH64]
 GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 -march=armv8-a+nofp
 GCC:*_*_*_CC_FLAGS = -mstrict-align
+
+[BuildOptions.ARM]
+GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000 -march=armv7-a
+GCC:*_*_*_CC_FLAGS = -fno-stack-protector
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79043): https://edk2.groups.io/g/devel/message/79043
Mute This Topic: https://groups.io/mt/84797252/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 5/6] Drivers/OpTee: address cast build warning issue in 32b mode

[Etienne Carriere]

Use (UINTN) cast to cast physical or virtual address values to the
pointer size before casting from/to a pointer value.

Cc: Ard Biesheuvel 
Cc: Ilias Apalodimas 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Signed-off-by: Etienne Carriere 
---
No change since v2
No change since v1
---
 Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c | 21 +---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c 
b/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
index 6eb19bed0e..83c2750368 100644
--- a/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
+++ b/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
@@ -305,7 +305,8 @@ OpTeeRpmbFvbRead (
 }
   }
 
-  Base = (VOID *)Instance->MemBaseAddress + (Lba * Instance->BlockSize) + 
Offset;
+  Base = (VOID *)(UINTN)Instance->MemBaseAddress + (Lba * Instance->BlockSize) 
+
+ Offset;
   // We could read the data from the RPMB instead of memory
   // The 2 copies should already be identical
   // Copy from memory image
@@ -387,7 +388,8 @@ OpTeeRpmbFvbWrite (
   return Status;
 }
   }
-  Base = (VOID *)Instance->MemBaseAddress + Lba * Instance->BlockSize + Offset;
+  Base = (VOID *)(UINTN)Instance->MemBaseAddress + (Lba * Instance->BlockSize) 
+
+ Offset;
   Status = ReadWriteRpmb (
  SP_SVC_RPMB_WRITE,
  (UINTN)Buffer,
@@ -477,7 +479,8 @@ OpTeeRpmbFvbErase (
   return EFI_INVALID_PARAMETER;
 }
 NumBytes = NumLba * Instance->BlockSize;
-Base = (VOID *)Instance->MemBaseAddress + Start * Instance->BlockSize;
+Base = (VOID *)(UINTN)Instance->MemBaseAddress +
+   (Start * Instance->BlockSize);
 Buf = AllocatePool (NumLba * Instance->BlockSize);
 if (Buf == NULL) {
   return EFI_DEVICE_ERROR;
@@ -689,7 +692,7 @@ InitializeFvAndVariableStoreHeaders (
 goto Exit;
   }
   // Install the combined header in memory
-  CopyMem ((VOID*)Instance->MemBaseAddress, Headers, HeadersLength);
+  CopyMem ((VOID*)(UINTN)Instance->MemBaseAddress, Headers, HeadersLength);
 
 Exit:
   FreePool (Headers);
@@ -747,14 +750,18 @@ FvbInitialize (
   // Read the file from disk and copy it to memory
   ReadEntireFlash (Instance);
 
-  FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *)Instance->MemBaseAddress;
+  FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)Instance->MemBaseAddress;
   Status = ValidateFvHeader (FwVolHeader);
   if (EFI_ERROR (Status)) {
 // There is no valid header, so time to install one.
 DEBUG ((DEBUG_INFO, "%a: The FVB Header is not valid.\n", __FUNCTION__));
 
 // Reset memory
-SetMem64 ((VOID *)Instance->MemBaseAddress, Instance->NBlocks * 
Instance->BlockSize, ~0UL);
+SetMem64 (
+  (VOID *)(UINTN)Instance->MemBaseAddress,
+  Instance->NBlocks * Instance->BlockSize,
+  ~0UL
+  );
 DEBUG ((DEBUG_INFO, "%a: Erasing Flash.\n", __FUNCTION__));
 Status = ReadWriteRpmb (
SP_SVC_RPMB_WRITE,
@@ -827,7 +834,7 @@ OpTeeRpmbFvbInit (
   mInstance.FvbProtocol.Write  = OpTeeRpmbFvbWrite;
   mInstance.FvbProtocol.Read   = OpTeeRpmbFvbRead;
 
-  mInstance.MemBaseAddress = (EFI_PHYSICAL_ADDRESS)Addr;
+  mInstance.MemBaseAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)Addr;
   mInstance.Signature  = FLASH_SIGNATURE;
   mInstance.Initialize = FvbInitialize;
   mInstance.BlockSize  = EFI_PAGE_SIZE;
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79042): https://edk2.groups.io/g/devel/message/79042
Mute This Topic: https://groups.io/mt/84797251/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 4/6] Drivers/OpTee: Add Aarch32 SVC IDs for 32bit Arm targets

[Etienne Carriere]

Add SMCCC function IDs for RPMB read/write service on 32bit architectures.
Define generic SP_SVC_RPMB_READ/SP_SVC_RPMB_WRITE IDs for native target
architecture (32b or 64b).

Changes OpTeeRpmbFvb.c to use architecture agnostic macro
ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ for 32b and 64b support.

Cc: Ard Biesheuvel 
Cc: Ilias Apalodimas 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Signed-off-by: Etienne Carriere 
---
No change since v2

Changes since v1:
- Use _AARCH64 (resp. _AARCH32) suffix instead of _64 (resp. _32) in
  the added macros.
---
 Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c |  2 +-
 Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.h | 16 ++--
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c 
b/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
index 5197c95abd..6eb19bed0e 100644
--- a/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
+++ b/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c
@@ -68,7 +68,7 @@ ReadWriteRpmb (
 
   ZeroMem (, sizeof (SvcArgs));
 
-  SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64;
+  SvcArgs.Arg0 = ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ;
   SvcArgs.Arg1 = mStorageId;
   SvcArgs.Arg2 = 0;
   SvcArgs.Arg3 = SvcAct;
diff --git a/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.h 
b/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.h
index c17fc287ef..9c2a4ea6a5 100644
--- a/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.h
+++ b/Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.h
@@ -13,8 +13,20 @@
  contract between OP-TEE and EDK2.
  For more details check core/arch/arm/include/kernel/stmm_sp.h in OP-TEE
 **/
-#define SP_SVC_RPMB_READ0xC466
-#define SP_SVC_RPMB_WRITE   0xC467
+#define SP_SVC_RPMB_READ_AARCH640xC466
+#define SP_SVC_RPMB_WRITE_AARCH64   0xC467
+
+#define SP_SVC_RPMB_READ_AARCH320x8466
+#define SP_SVC_RPMB_WRITE_AARCH32   0x8467
+
+#ifdef MDE_CPU_AARCH64
+#define SP_SVC_RPMB_READSP_SVC_RPMB_READ_AARCH64
+#define SP_SVC_RPMB_WRITE   SP_SVC_RPMB_WRITE_AARCH64
+#endif
+#ifdef MDE_CPU_ARM
+#define SP_SVC_RPMB_READSP_SVC_RPMB_READ_AARCH32
+#define SP_SVC_RPMB_WRITE   SP_SVC_RPMB_WRITE_AARCH32
+#endif
 
 #define FLASH_SIGNATURESIGNATURE_32 ('r', 'p', 'm', 'b')
 #define INSTANCE_FROM_FVB_THIS(a)  CR (a, MEM_INSTANCE, FvbProtocol, \
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79041): https://edk2.groups.io/g/devel/message/79041
Mute This Topic: https://groups.io/mt/84797250/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 2/6] Platform/Socionext/DeveloperBox: sync with edk2 StandaloneMmCpu path change

[Etienne Carriere]

Synchronize with edk2 package where StandaloneMmCpu component has moved
from StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
to StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf

Cc: Ard Biesheuvel 
Cc: Ilias Apalodimas 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Sughosh Ganu 
Cc: Thomas Abraham 
Signed-off-by: Etienne Carriere 
---
No change since v2

Changes since v1:
- split change in 3: this change relates to DeveloperBox only.
---
 Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc | 2 +-
 Platform/Socionext/DeveloperBox/DeveloperBoxMm.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
index e078de4bbb..b5524f87a6 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
@@ -80,7 +80,7 @@
   gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x2
   }
 
-  StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
+  StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf
   Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006StandaloneMm.inf
   
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf {
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.fdf 
b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.fdf
index 33de03c8e7..89453477c9 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBoxMm.fdf
+++ b/Platform/Socionext/DeveloperBox/DeveloperBoxMm.fdf
@@ -111,7 +111,7 @@ READ_LOCK_STATUS   = TRUE
   INF Silicon/Socionext/SynQuacer/Drivers/Fip006Dxe/Fip006StandaloneMm.inf
   INF 
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
   INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
-  INF StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
+  INF StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf
 
 

 #
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79039): https://edk2.groups.io/g/devel/message/79039
Mute This Topic: https://groups.io/mt/84797247/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 3/6] Platform/StandaloneMm: sync with edk2 StandaloneMmCpu path change

[Etienne Carriere]

Synchronize with edk2 package where StandaloneMmCpu component has moved
from StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
to StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf

Cc: Ard Biesheuvel 
Cc: Ilias Apalodimas 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Sughosh Ganu 
Cc: Thomas Abraham 
Signed-off-by: Etienne Carriere 
---
No change since v2

Changes since v1:
- split change in 3: this change relates to StandaloneMm package only.
---
 Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc | 2 
+-
 Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.fdf | 3 
++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc 
b/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
index f99a47ebf6..cb3f1ddf52 100644
--- a/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
+++ b/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
@@ -133,7 +133,7 @@
   #
   Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFv.inf
   StandaloneMmPkg/Core/StandaloneMmCore.inf
-  StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
+  StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf
   
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf 
{
 
   NULL|Drivers/OpTee/OpteeRpmbPkg/FixupPcd.inf
diff --git 
a/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.fdf 
b/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.fdf
index e175dc7b2d..c4295a3e63 100644
--- a/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.fdf
+++ b/Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.fdf
@@ -68,7 +68,8 @@ READ_LOCK_STATUS   = TRUE
   INF Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFv.inf
   INF 
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
   INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
-  INF StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
+  INF StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf
+
 

 #
 # Rules are use with the [FV] section's module INF type to define
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79040): https://edk2.groups.io/g/devel/message/79040
Mute This Topic: https://groups.io/mt/84797248/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 1/6] Platform/ARM/SgiPkg: sync with edk2 StandaloneMmCpu path change

[Etienne Carriere]

Synchronize with edk2 package where StandaloneMmCpu component has moved
from StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
to StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf

Cc: Ard Biesheuvel 
Cc: Ilias Apalodimas 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Sughosh Ganu 
Cc: Thomas Abraham 
Signed-off-by: Etienne Carriere 
---
Changes since v2:
- Fix StandaloneMmCpu.inf
path required when rebasing the patch.

Changes since v1:
- split change in 3: this change relates to Platform/ARM/SgiPkg only.
---
 Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf | 2 +-
 Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf 
b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
index 474c9c0ce7..c1c24b747f 100644
--- a/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
+++ b/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf
@@ -54,7 +54,7 @@ READ_LOCK_STATUS   = TRUE
   INF 
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
   INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
 !endif
-  INF StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
+  INF StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf
 
 

 #
diff --git a/Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc 
b/Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
index 2b461d5afb..5287e1f8e5 100644
--- a/Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
+++ b/Platform/ARM/SgiPkg/SgiPlatformMm.dsc.inc
@@ -119,7 +119,7 @@
   StandaloneMmPkg/Core/StandaloneMmCore.inf
 
 [Components.AARCH64]
-  StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.inf
+  StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf
 !if $(SECURE_STORAGE_ENABLE) == TRUE
   ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashStandaloneMm.inf
   
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79038): https://edk2.groups.io/g/devel/message/79038
Mute This Topic: https://groups.io/mt/84797246/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v3 0/6] Arm 32bit support in PlatformStandaloneMmRpmb

[Etienne Carriere]

This series brings support for building PlatformStandaloneMmRpmb for
32bit Arm architectures. This series is based on series tracked through
[1] in edk2 that allows to build StandaloneMm package for 32bit Arm.
This series starts by syncing with paths changes from [1] series,
then comes changes for Arm 32bit support in OpTee drivers and last
updates PlatformStandaloneMmRpmb.dsc for 32bit the ARM architure.
This series is tracked through ticket [2].

One can test the generated StMM image with OP-TEE release for
stm32mp157c-ev1 board which integrates an eMMC device with a
RPMB partition. Se below are the fetch/build directives.
Note that enabling EFI secure boot on stm32mp1 needs more than the
build instruction below. At least these show how U-Boot and OP-TEE
can leverage StMM with an RPMB device.

Step 1: fetch edk2, edk2-platforms, apply patches and Build StMM.
I build edk2 with the following command (one shall replace ${path_to_xxx}
with the appropriate paths.

  # export WORKSPACE=${path_to_edk2_build_dir}
  # export PYTHON3_ENABLE=TRUE
  # export PACKAGES_PATH=${path_to_edk2}:${path_to_edk2_platforms}
  # source ${path_to_edk2}/edksetup.sh
  # make -j$(nproc) -C ${path_to_edk2}/BaseTools
  # GCC5_ARM_PREFIX=${path_to_arm_tooclain}/bin/arm-linux-gnueabihf- \
  build -n $(nproc) -a ARM -t GCC5 -b RELEASE -D DO_X86EMU=TRUE \
   -p 
Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc \
   all

Step 2: clone and build OP-TEE release for stm32mp1 (see also [3]):

  # mkdir /tmp/optee-stm32mp1-stmm
  # cd /tmp/optee-stm32mp1-stmm
  # repo init -u https://github.com/OP-TEE/manifest.git -t 3.14.0 -m 
stm32mp1.xml
  # repo sync
  # cd build
  # make toolchains
  # make all 

Step 3: sync with U-Boot master branch, at least commit [4] which merges
a fix in MMC/RPMB driver OP-TEE [5]. Platform defconfig must be changed
to enable StMM and RPMB support.
The command below builds u-boot using OP-TEE build env (from build/ dir)

  # git -C ../u-boot checkout 99bb5f248ade371ee4713e0ef51401708ecbb13c
  # echo CONFIG_EFI_MM_COMM_TEE=y >> 
../u-boot/configs/stm32mp15_trusted_defconfig
  # echo CONFIG_SUPPORT_EMMC_RPMB=y >> 
../u-boot/configs/stm32mp15_trusted_defconfig
  # make u-boot

Step 4: rebuild optee_os (and SDcard image) with StMM image embedded in
OP-TEE core wand RPMB support for stm32mp15c-ev1 (the board has an eMMC
device with an RPMB partition).
The command below builds u-boot using OP-TEE build env.
  
  # make optee-os all \
 
CFG_STMM_PATH=${path_to_edk2_build_dir}/Build/MmStandaloneRpmb/RELEASE_GCC5/FV/BL32_AP_MM.fd
 \
 PLATFORM=stm32mp1-157C_ED1 \
 CFG_RPMB_FS=y CFG_CORE_HUK_SUBKEY_COMPAT=n CFG_RPMB_FS_DEV_ID=1

Once done, program SDcard (/dev/sdX relates to SDcard slot device file)
  # dd conf=fdatasync if=../out/bin/sdcard of=/dev/sdX # where /dev/sdX is

The target (stm32mp157c-ev1 board) can boot with the programmed
SDcard. One can interrupt the U-Boot console, possibly program
RPMB key (see note below) and read the EFI variable (read from the
RPMB though StMM executing in OP-TEE.

  $ printenv -e  # read EFI variables
  $ setenv -e # write an EFI variable

Note about the RPMB key:
  With the build instructions above, OP-TEE assumes the RPMB device key
  is generated from a known derivation of an all-zero root key. If the
  RPMB device key was not yet programmed, one can program it from the
  U-Boot console with command 'mmc rpmc key . The
  commands below can be used to program the platform default RPMB
  development key that is (hexadecimal notation, first byte first):
15 46 75 8c 61 8e d8 b8 a2 27 89 02 df 54 ef 63
11 de e2 96 49 99 5b d7 d9 12 f1 53 6d 8a 67 c7

  $ mw.l 0xc000 0x8c754615
  $ mw.l 0xc004 0xb8d88e61
  $ mw.l 0xc008 0x028927a2
  $ mw.l 0xc00c 0x63ef54df
  $ mw.l 0xc010 0x96e2de11
  $ mw.l 0xc014 0xd75b9949
  $ mw.l 0xc018 0x53f112d9
  $ mw.l 0xc01c 0xc7678a6d
  $ mmc rpmb key 0xc000

[1] https://bugzilla.tianocore.org/show_bug.cgi?id=3381
[2] https://bugzilla.tianocore.org/show_bug.cgi?id=3383
[3] 
https://optee.readthedocs.io/en/latest/building/devices/stm32mp1.html#build-instructions
[4] 
https://source.denx.de/u-boot/u-boot/-/commit/99bb5f248ade371ee4713e0ef51401708ecbb13c
[5] 
https://source.denx.de/u-boot/u-boot/-/commit/a9f7be509af90fa5f2c308867ad3b0bd48532c6e

Etienne Carriere (6):
  Platform/ARM/SgiPkg: sync with edk2 StandaloneMmCpu path change
  Platform/Socionext/DeveloperBox: sync with edk2 StandaloneMmCpu path
change
  Platform/StandaloneMm: sync with edk2 StandaloneMmCpu path change
  Drivers/OpTee: Add Aarch32 SVC IDs for 32bit Arm targets
  Drivers/OpTee: address cast build warning issue in 32b mode
  Platform/StandaloneMm: build StandaloneMmRpmb for 32bit architectures

 Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c | 23 ---
 Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.h | 16 +++--
 Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf  |  2 

Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] IntelSiliconPkg/PeiSmmAccessLib: Remove S3 requirement

[Michael Kubacki]

Installation is a platform decision. The buried dependency on boot mode 
in this particular function is just a roadblock platforms have to work 
around. The role of this API is to install the PPI.


Thanks,
Michael

On 8/9/2021 9:47 PM, Ni, Ray wrote:

Michael,
Allowing the gPeiSmmAccessPpiGuid PPI installation in normal boot will further 
allow gEfiPeiSmmCommunicationPpiGuid
installation in normal path, while without your change neither of the PPIs is 
installed in normal boot.

+ Jiewen for potential security concern.

Thanks,
Ray


-Original Message-
From: Chaganty, Rangasai V 
Sent: Tuesday, August 10, 2021 6:46 AM
To: mikub...@linux.microsoft.com; devel@edk2.groups.io
Cc: Ni, Ray 
Subject: RE: [edk2-platforms][PATCH v1 1/1] IntelSiliconPkg/PeiSmmAccessLib: 
Remove S3 requirement

Reviewed-by: Sai Chaganty 

-Original Message-
From: mikub...@linux.microsoft.com 
Sent: Monday, August 09, 2021 6:40 AM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Chaganty, Rangasai V 

Subject: [edk2-platforms][PATCH v1 1/1] IntelSiliconPkg/PeiSmmAccessLib: Remove 
S3 requirement

From: Michael Kubacki 

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

PeiInstallSmmAccessPpi() currently requires the boot mode be set to S3 to 
actually install gEfiPeiMmAccessPpiGuid.

This change removes this requirement in the function implementation for two 
reasons:

1. Practical use cases exist to require this PPI in cases other than
the boot mode being set to BOOT_ON_S3_RESUME.

2. It is poor API design to implicitly bury this requirement within
a function whose responsibility is to install the PPI. The caller
can easily place arbitrary constraints around whether to call
based on conditions such as the boot mode being
BOOT_ON_S3_RESUME.

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Signed-off-by: Michael Kubacki 
---
  
Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/PeiSmmAccessLib/PeiSmmAccessLib.c
 | 12 
  1 file changed, 12 deletions(-)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/PeiSmmAccessLib/PeiSmmAccessLib.c
b/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/PeiSmmAccessLib/PeiSmmAccessLib.c
index d9bf4fba983e..4df0d695fdaf 100644
--- 
a/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/PeiSmmAccessLib/PeiSmmAccessLib.c
+++ b/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/PeiSmmAcce
+++ ssLib/PeiSmmAccessLib.c
@@ -252,19 +252,7 @@ PeiInstallSmmAccessPpi (
EFI_SMRAM_HOB_DESCRIPTOR_BLOCK  *DescriptorBlock;
SMM_ACCESS_PRIVATE_DATA *SmmAccessPrivate;
VOID*HobList;
-  EFI_BOOT_MODE   BootMode;

-  Status = PeiServicesGetBootMode ();
-  if (EFI_ERROR (Status)) {
-//
-// If not in S3 boot path. do nothing
-//
-return EFI_SUCCESS;
-  }
-
-  if (BootMode != BOOT_ON_S3_RESUME) {
-return EFI_SUCCESS;
-  }
//
// Initialize private data
//
--
2.28.0.windows.1









-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79036): https://edk2.groups.io/g/devel/message/79036
Mute This Topic: https://groups.io/mt/84768258/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] IntelSiliconPkg: Add BaseSmmAccessLibNull

[Michael Kubacki]

There is not a SmmAccess PEIM in IntelSiliconPkg.

There is a SmmAccessDxe driver:
https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/SmmAccessDxe/SmmAccess.inf

And there is a PeiSmmAccessLib:
https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess

As long as this is a library class, the NULL library instance is 
necessary for the same reason many NULL instances are necessary.


Scenario #1:

If a user has a library that depends on SmmAccessLib and that library is 
linked to two different modules, the user may wish to actually call the 
install function from one module and not link the functionality (or 
inherit the non-NULL SmmAccessLib dependencies) in the other module.


Scenario #2:

Someone is trying to build common code. That common code has a PEIM. 
That PEIM links SmmAccessLib. A downstream package leveraging that PEIM 
does not use the functionality in the PEIM that invokes SmmAccessLib. 
Therefore, the package would like to reduce the overall PEIM 
dependencies by linking a NULL library instance.


---

This is the result of an invoke-once interface being exposed as a 
generic library class.


---

This patch is not trying to modify interfaces such as converting the 
library class to a driver or anything more involved/impactful. It is 
simply making the design already in place have an alternative, optional 
instance available for platform integration.


Thanks
Michael

On 8/9/2021 10:30 PM, Ni, Ray wrote:

Michael,
If your platform doesn't need SmmAccessPPI, you don't put the SmmAccess PEIM in 
the FDF.
Why do you need:
1. Put SmmAccess PEIM in FDF
2. Let SmmAccess PEIM link to a NULL dummy-do-nothing library

I feel the additional abstraction is not necessary.

Thanks,
Ray


-Original Message-
From: mikub...@linux.microsoft.com 
Sent: Monday, August 9, 2021 10:16 PM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Chaganty, Rangasai V 

Subject: [edk2-platforms][PATCH v1 1/1] IntelSiliconPkg: Add 
BaseSmmAccessLibNull

From: Michael Kubacki 

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

Adds a NULL instance of SmmAccessLib.

Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Signed-off-by: Michael Kubacki 
---
  
Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/BaseSmmAccessLibNull/BaseSmmAccessLibNull.c
   | 33

  
Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/BaseSmmAccessLibNull/BaseSmmAccessLibNull.inf
 | 26
+++
  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc 
|  1 +
  3 files changed, 60 insertions(+)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/BaseSmmAccessLibNull/BaseSmmAccessLibNull.c
b/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/BaseSmmAccessLibNull/BaseSmmAccessLibNull.c
new file mode 100644
index ..f5ad306b380b
--- /dev/null
+++ 
b/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/BaseSmmAccessLibNull/BaseSmmAccessLibNull.c
@@ -0,0 +1,33 @@
+/** @file
+  A NULL library instance of SmmAccessLib.
+
+  Copyright (c) 2019 - 2020, Intel Corporation. All rights reserved.
+  Copyright (c) Microsoft Corporation.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+
+/**
+  This function is to install an SMM Access PPI
+
+  @retval EFI_SUCCESS   - Ppi successfully started and installed.
+  @retval EFI_NOT_FOUND - Ppi can't be found.
+  @retval EFI_OUT_OF_RESOURCES  - Ppi does not have enough resources to 
initialize the driver.
+  @retval EFI_UNSUPPORTED   - The PPI was not installed and installation 
is unsupported in
+  this instance of function implementation.
+
+**/
+EFI_STATUS
+EFIAPI
+PeiInstallSmmAccessPpi (
+  VOID
+  )
+{
+  ASSERT (FALSE);
+  return EFI_UNSUPPORTED;
+}
diff --git 
a/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/BaseSmmAccessLibNull/BaseSmmAccessLibNull.inf
b/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/BaseSmmAccessLibNull/BaseSmmAccessLibNull.inf
new file mode 100644
index ..7fd3b0b89655
--- /dev/null
+++ 
b/Silicon/Intel/IntelSiliconPkg/Feature/SmmAccess/Library/BaseSmmAccessLibNull/BaseSmmAccessLibNull.inf
@@ -0,0 +1,26 @@
+## @file
+# A NULL library instance of SmmAccessLib.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+# Copyright (c) Microsoft Corporation.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+INF_VERSION = 0x00010017
+BASE_NAME   = BaseSmmAccessLibNull
+FILE_GUID   = C1A14AB6-B757-4046-9B92-9DCE1A2154C6
+VERSION_STRING  = 1.0
+MODULE_TYPE = BASE
+LIBRARY_CLASS   = SmmAccessLib
+
+[Packages]
+  MdePkg/MdePkg.dec
+  IntelSiliconPkg/IntelSiliconPkg.dec
+
+[LibraryClasses]
+  DebugLib
+
+[Sources]
+  BaseSmmAccessLibNull.c
diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc 

Re: [edk2-devel] [PATCH] ArmPkg: Enable boot discovery policy for ARM package.

[Sunny Wang]

Hi Ard,

Yeah, this is a good point. Greg and I offline discussed this as well.
If we don't miss anything, only applying this patch without platform changes 
should be fine. There should be no behavior change. I added some details below 
for your reference.
  - if the platform doesn’t add PcdBootDiscoveryPolicy to platform's dsc file 
and add BootDiscoveryPolicyUiLib to UiApp. BootDiscoveryPolicyHandler() would 
just get PcdBootDiscoveryPolicy default value and do nothing.
  - if the platform doesn't include BootManagerPolicyDxe driver or produce 
EfiBootManagerPolicyProtocol, BootDiscoveryPolicyHandler() would just return 
with only printing a message to remind users/developers that Boot Discovery 
Policy doesn't work (driver connect will be skipped).

Best Regards,
Sunny Wang

-Original Message-
From: Ard Biesheuvel 
Sent: Friday, August 6, 2021 9:45 PM
To: Grzegorz Bernacki 
Cc: edk2-devel-groups-io ; Leif Lindholm 
; Ard Biesheuvel ; Samer 
El-Haj-Mahmoud ; Sunny Wang ; 
Marcin Wojtas ; upstr...@semihalf.com
Subject: Re: [PATCH] ArmPkg: Enable boot discovery policy for ARM package.

On Fri, 6 Aug 2021 at 10:30, Grzegorz Bernacki  wrote:
>
> This commit adds code which check BootDiscoveryPolicy variable and
> calls Boot Policy Manager Protocol to connect device specified by
> the variable. To enable that mechanism for platform
> EfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy PCD must be
> added to DSC file and BootDiscoveryPolicyUiLib should be added to
> UiApp libraries.
>

... or the platform will be broken once we apply this patch, right? If
so, please propose patches for all platforms in edk2-platforms that
use this library - we can't just break them.

> Signed-off-by: Grzegorz Bernacki 
> ---
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  5 +
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 96 
> +++-
>  2 files changed, 100 insertions(+), 1 deletion(-)
>
> diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 353d7a967b..86751b45f8 100644
> --- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -65,11 +65,15 @@
>
>  [Pcd]
>gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy
>
>  [Guids]
> +  gBootDiscoveryPolicyMgrFormsetGuid
>gEdkiiNonDiscoverableEhciDeviceGuid
>gEdkiiNonDiscoverableUhciDeviceGuid
>gEdkiiNonDiscoverableXhciDeviceGuid
> +  gEfiBootManagerPolicyNetworkGuid
> +  gEfiBootManagerPolicyConnectAllGuid
>gEfiFileInfoGuid
>gEfiFileSystemInfoGuid
>gEfiFileSystemVolumeLabelInfoIdGuid
> @@ -79,6 +83,7 @@
>
>  [Protocols]
>gEdkiiNonDiscoverableDeviceProtocolGuid
> +  gEfiBootManagerPolicyProtocolGuid
>gEfiDevicePathProtocolGuid
>gEfiGraphicsOutputProtocolGuid
>gEfiLoadedImageProtocolGuid
> diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index 5ceb23d822..4332c45bb7 100644
> --- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -2,9 +2,10 @@
>Implementation for PlatformBootManagerLib library class interfaces.
>
>Copyright (C) 2015-2016, Red Hat, Inc.
> -  Copyright (c) 2014 - 2019, ARM Ltd. All rights reserved.
> +  Copyright (c) 2014 - 2021, ARM Ltd. All rights reserved.
>Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
>Copyright (c) 2016, Linaro Ltd. All rights reserved.
> +  Copyright (c) 2021, Semihalf All rights reserved.
>
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -19,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -27,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -703,6 +706,91 @@ HandleCapsules (
>
>  #define VERSION_STRING_PREFIXL"Tianocore/EDK2 firmware version "
>
> +/**
> +  This functions checks the value of BootDiscoverPolicy variable and
> +  connect devices of class specified by that variable. Then it refreshes
> +  Boot order for newly discovered boot device.
> +
> +  @retval  EFI_SUCCESS  Devices connected succesfully or connection
> +not required.
> +  @retval  others   Return values from GetVariable(), LocateProtocol()
> +and ConnectDeviceClass().
> +--*/
> +STATIC
> +EFI_STATUS
> +BootDiscoveryPolicyHandler (
> +  VOID
> +  )
> +{
> +  EFI_STATUS   Status;
> +  UINT32   DiscoveryPolicy;
> +  UINTNSize;
> +  EFI_BOOT_MANAGER_POLICY_PROTOCOL *BMPolicy;
> +  EFI_GUID *Class;
> +
> +  Size = sizeof (DiscoveryPolicy);
> +  Status = gRT->GetVariable (
> +

Re: [edk2-devel] [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx: Add missing _STA methods in ACPI tables

[Samer El-Haj-Mahmoud]

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel via groups.io
> Sent: Tuesday, August 10, 2021 10:41 AM
> To: edk2-devel-groups-io ; Samer El-Haj-Mahmoud
> 
> Cc: Marcin Wojtas ; Leif Lindholm ;
> Ard Biesheuvel ; Grzegorz Jaszczyk
> ; Grzegorz Bernacki ;
> upstr...@semihalf.com; Jon (j...@solid-run.com) 
> Subject: Re: [edk2-devel] [edk2-platforms PATCH 2/7] Marvell:
> Armada7k8k/OcteonTx: Add missing _STA methods in ACPI tables
>
> On Tue, 10 Aug 2021 at 16:36, Samer El-Haj-Mahmoud
>  wrote:
> >
> > Apologies for the tardiness in replying to this. Please see my comments
> below.
> >
> > > -Original Message-
> > > From: Marcin Wojtas 
> > > Sent: Friday, July 30, 2021 5:57 AM
> > > To: Ard Biesheuvel 
> > > Cc: Samer El-Haj-Mahmoud ; edk2-
> > > devel-groups-io ; Leif Lindholm
> > > ; Ard Biesheuvel ;
> > > Grzegorz Jaszczyk ; Grzegorz Bernacki
> > > ; upstr...@semihalf.com; Jon (jon@solid-
> run.com)
> > > 
> > > Subject: Re: [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx:
> > > Add missing _STA methods in ACPI tables
> > >
> > > Hi Ard,
> > >
> > > czw., 29 lip 2021 o 11:58 Ard Biesheuvel  napisał(a):
> > > >
> > > > On Thu, 29 Jul 2021 at 11:46, Marcin Wojtas 
> wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > pon., 19 lip 2021 o 17:06 Marcin Wojtas 
> napisał(a):
> > > > > >
> > > > > > Hi Ard,
> > > > > >
> > > > > > pon., 19 lip 2021 o 11:54 Ard Biesheuvel 
> napisał(a):
> > > > > > >
> > > > > > > On Mon, 19 Jul 2021 at 11:31, Marcin Wojtas 
> > > wrote:
> > > > > > > >
> > > > > > > > BBR 1.0 spec says that _STA is required for each device in DSDT
> or
> > > SSDT.
> > > > > > > > Fix that for all platforms with the Marvell SoC's.
> > > > > > > >
> > > > > > >
> > > > > > > Can we fix the BBR instead? If ACPI itself does not require _STA,
> BBR
> > > > > > > should not require it either.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I consulted with ARM on the matter. SBBR has requirements of
> things
> > > > > > that are otherwise optional in UEFI/ACPI/SMBIOS. Also some OS's
> may
> > > > > > require that and I can see those methods in most of the other ACPI
> > > > > > source files in the edk2-platfoms tree. I think the BBR requirements
> > > > > > discussions can follow, but it would be great if this change can be
> > > > > > applied, so that no to block other development.
> > > > > >
> > > > >
> > > > > Do you have any feedback to the patchset and the _STA methods
> > > concerns?
> > > > >
> > > >
> > > > Yes. I would like to understand why _STA methods are now mandated
> by
> > > BBR.
> > > >
> > >
> > > Understood. Providing an answer may not be immediate and may
> possibly
> > > require further discussion on the SystemArchAC level.
> > > How about we withdraw this single patch for now and process the
> > > remaining ones? We would come back to the _STA subject, as soon as
> > > there's more information available.
> > >
> > > Best regards,
> > > Marcin
> > >
> >
> > _STA has been required in SBBR since ver 1.0 (published 2016, with the 0.9
> draft since 2014)
> > https://developer.arm.com/documentation/den0044/b/?lang=en
> >
> > I do not have the history on why SBBR 1.0+ requires _STA, but it most likely
> has to do wit the Windows strong use case for it:
> https://docs.microsoft.com/en-us/windows-
> hardware/drivers/bringup/device-management-namespace-
> objects#device-status-changes . Windows is a key OS targeted by SBBR.
> >
>
> OK, I stand corrected again :-)
>
> Marcin,
>
> I won't object further to these additions -please respin the patch on
> top of current edk2-platform and I will apply it right away.
>

Thank you Ard! :-)

>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79033): https://edk2.groups.io/g/devel/message/79033
Mute This Topic: https://groups.io/mt/84304355/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx: Add missing _STA methods in ACPI tables

[Ard Biesheuvel]

On Tue, 10 Aug 2021 at 16:36, Samer El-Haj-Mahmoud
 wrote:
>
> Apologies for the tardiness in replying to this. Please see my comments below.
>
> > -Original Message-
> > From: Marcin Wojtas 
> > Sent: Friday, July 30, 2021 5:57 AM
> > To: Ard Biesheuvel 
> > Cc: Samer El-Haj-Mahmoud ; edk2-
> > devel-groups-io ; Leif Lindholm
> > ; Ard Biesheuvel ;
> > Grzegorz Jaszczyk ; Grzegorz Bernacki
> > ; upstr...@semihalf.com; Jon (j...@solid-run.com)
> > 
> > Subject: Re: [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx:
> > Add missing _STA methods in ACPI tables
> >
> > Hi Ard,
> >
> > czw., 29 lip 2021 o 11:58 Ard Biesheuvel  napisał(a):
> > >
> > > On Thu, 29 Jul 2021 at 11:46, Marcin Wojtas  wrote:
> > > >
> > > > Hi Ard,
> > > >
> > > > pon., 19 lip 2021 o 17:06 Marcin Wojtas  napisał(a):
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > pon., 19 lip 2021 o 11:54 Ard Biesheuvel  napisał(a):
> > > > > >
> > > > > > On Mon, 19 Jul 2021 at 11:31, Marcin Wojtas 
> > wrote:
> > > > > > >
> > > > > > > BBR 1.0 spec says that _STA is required for each device in DSDT or
> > SSDT.
> > > > > > > Fix that for all platforms with the Marvell SoC's.
> > > > > > >
> > > > > >
> > > > > > Can we fix the BBR instead? If ACPI itself does not require _STA, 
> > > > > > BBR
> > > > > > should not require it either.
> > > > > >
> > > > > >
> > > > >
> > > > > I consulted with ARM on the matter. SBBR has requirements of things
> > > > > that are otherwise optional in UEFI/ACPI/SMBIOS. Also some OS's may
> > > > > require that and I can see those methods in most of the other ACPI
> > > > > source files in the edk2-platfoms tree. I think the BBR requirements
> > > > > discussions can follow, but it would be great if this change can be
> > > > > applied, so that no to block other development.
> > > > >
> > > >
> > > > Do you have any feedback to the patchset and the _STA methods
> > concerns?
> > > >
> > >
> > > Yes. I would like to understand why _STA methods are now mandated by
> > BBR.
> > >
> >
> > Understood. Providing an answer may not be immediate and may possibly
> > require further discussion on the SystemArchAC level.
> > How about we withdraw this single patch for now and process the
> > remaining ones? We would come back to the _STA subject, as soon as
> > there's more information available.
> >
> > Best regards,
> > Marcin
> >
>
> _STA has been required in SBBR since ver 1.0 (published 2016, with the 0.9 
> draft since 2014)
> https://developer.arm.com/documentation/den0044/b/?lang=en
>
> I do not have the history on why SBBR 1.0+ requires _STA, but it most likely 
> has to do wit the Windows strong use case for it: 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-management-namespace-objects#device-status-changes
>  . Windows is a key OS targeted by SBBR.
>

OK, I stand corrected again :-)

Marcin,

I won't object further to these additions -please respin the patch on
top of current edk2-platform and I will apply it right away.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79032): https://edk2.groups.io/g/devel/message/79032
Mute This Topic: https://groups.io/mt/84304355/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

[James Bottomley]

On Tue, 2021-08-10 at 10:10 +1000, Christoph Willing wrote:
> On 10/8/21 12:52 am, James Bottomley wrote:
> > On Mon, 2021-08-09 at 22:53 +1000, Christoph Willing wrote:
> > > With soft feature freeze started, I wonder if this patch could be
> > > reviewed and pushed for edk2-stable202108 tag? I think it has
> > > languished because I didn't initially Cc appropriately - pls add
> > > others as necessary.
> > > 
> > > This patch is a trivial (I think) change which fixes a long
> > > standing
> > > and annoying bug for those booting Qemu with UEFI using external
> > > kernel & initrd.
> > 
> > I'm with Ard on this one: -kernel is working just fine for me and
> > the
> > team at IBM working on Kata containers.  It sounds like this might
> > be a
> > problem local to your environment, so we need to debug it to
> > understand
> > the issue rather than blindly reverse existing commits.
> > 
> Thanks for responding James & Ard.
> 
> Below is the script I'm using to create, then run, the VM. To verify
> that it works normally with UEFI boot, it initially uses the internal
> kernel & initrd.
> 
> The OVMF_CODE & my_VARS lines contain git hash to identify the build
> from which OVMF_CODE.fd & OVMF_VARS.fd were taken; 97fdcg is from a
> build of yesterday's git master.
> 
> After the OS has been installed, I can run the VM multiple times to
> verify that it boots under UEFI OK (I see the TianoCore splash
> screen)
> with internal kernel.
> 
> 
> #!/bin/bash
> 
> /usr/bin/qemu-kvm \
> -name "UEFI Testing" \
> -enable-kvm \
> -cpu kvm64 \
> -smp cores=4 \
> -boot once=c \
> -m 8192 \
> -device intel-hda \
> -device hda-duplex \
> -vga virtio \
> -drive if=pflash,format=raw,file=OVMF_CODE_97fdcb.fd,readonly=on \
> -drive if=pflash,format=raw,file=my_VARS_97fdcb.fd \
> -drive file=disk.img,format=raw,cache=none,index=0,media=disk \
> -cdrom
> /storage/iso/slackware/slackware64-15.0/slackware64-15.0-20210807.iso 
> \
> -daemonize \
> "$@"

There's no definition of a disk device in here.

> To now use external kernel, I add the lines:
> 
> -kernel /var/cache/vmbuilder/boot/15.0/x86_64/vmlinuz \
> -initrd /var/cache/vmbuilder/boot/15.0/x86_64/initrd \
> -append "root=/dev/sda2 rootfstype=ext4 ro vga=0x386" \
> 
> to the script just after "-boot once=c" (but I doubt the exact
> positioning makes any difference).
> 
> In this case, I see the kernel running and initrd unpacked and its
> modules loaded but the root partition is unable to be mounted - the
> disk
> is not visible (running 'ls -l /dev/sd*' in recovery shell gives 'ls:
> /dev/sd*: No such file or directory').
> 
> The last lines of the Qemu screen are:
> 
> /boot/initrd-5.13.8.gz: Loading kernel modules from initrd image:
> insmod /lib/modules/5.13.8/kernel/fs/jbd2/jbd2.ko
> insmod /lib/modules/5.13.8/kernel/fs/mbcache.ko
> insmod /lib/modules/5.13.8/kernel/fs/ext4/ext4.ko
> mount: mounting /dev/sda2 on /mnt failed: No such file or directory

Which looks like why this failed.

Where's the vmm supposed to get /dev/sda from?  It sort of seems like
the CD rom boot script thinks it was mounted as a USB device in this
case.

In the working kernel dmesg Gerd requested, what does it mount as root?
sda?  In which case what does the kernel say about where it got sda
from?

James




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79030): https://edk2.groups.io/g/devel/message/79030
Mute This Topic: https://groups.io/mt/84767423/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 6/6] OvmfPkg/AmdSevDxe: Add support for SEV live migration.

[Lendacky, Thomas via groups.io]

On 8/10/21 6:13 AM, Ashish Kalra wrote:
> Hello Tom,
> 
> On Mon, Aug 09, 2021 at 09:29:29AM -0500, Tom Lendacky wrote:
>> On 8/2/21 7:33 AM, Ashish Kalra wrote:
>>
>> Should there be an "ASSERT_EFI_ERROR (Status)" after the DEBUG call?
>>
> 
> I don't think we should do an assert here and abort booting, failure
> here will simply disable live migration support but i don't think that
> it is such a fatal error that we should abort booting because of that.
> 
> OTOH, if there is a failure when doing page encryption status hypercalls
> then aborting boot makes sense as guest page encryption status tracking
> may be critical for multiple guest operations and not only live
> migration.

Makes sense.

Thanks,
Tom

> 
> Thanks,
> Ashish
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79029): https://edk2.groups.io/g/devel/message/79029
Mute This Topic: https://groups.io/mt/84609858/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 1/6] OvmfPkg/BaseMemEncryptLib: Detect SEV live migration feature.

[Lendacky, Thomas via groups.io]

On 8/10/21 1:05 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>>> I still really don't understand the need for the CPUID loop. KVM only ever
>>> programs CPUID function 0x4000, right?
> 
> Nope.  When you enable hyper-v emulation features you'll go find the kvm
> cpuid @ 0x4000 and the hyper-v cpuid @ 0x4100 (or the other way
> around, not sure).

Ah, thanks. I just saw the comment above get_out_of_range_cpuid_entry() in
arch/x86/kvm/cpuid.c where HyperV would get the 0x4000-0x40ff
range and KVM would then get the 0x4100-0x41ff range (basically
each hypervisor class gets their own 0x100 range).

Thanks,
Tom

> 
> take care,
>   Gerd
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79028): https://edk2.groups.io/g/devel/message/79028
Mute This Topic: https://groups.io/mt/84609830/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

[Christoph Willing]

On 10/8/21 4:01 pm, Gerd Hoffmann wrote:
>   Hi,
> 
>> insmod /lib/modules/5.13.8/kernel/fs/jbd2/jbd2.ko
>> insmod /lib/modules/5.13.8/kernel/fs/mbcache.ko
>> insmod /lib/modules/5.13.8/kernel/fs/ext4/ext4.ko
>> mount: mounting /dev/sda2 on /mnt failed: No such file or directory
>> ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.
>>You can try to fix it. Type 'exit' when things are done.
>>
>> At that point I'm dropped into a recovery shell to try fixing something
>> but there's nothing that can be done since the disk containing the OS is
>> not visible.
> 
>> From the above, I think I've done everything possible to verify the
>> problem and a possible fix. Is there something fundamentally wrong in
>> the way I'm going about this?
> 
> Root cause is not clear.  Grab the kernel log ('dmesg') from a good and
> a bad boot and comparing them should give a clue.
> 
Thanks for your interest Gerd,

I added "-serial mon:stdio" to the qemu invocation and "console=ttyS0"
to the -append line to capture all boot output for both good and bad
cases and saved the results in files.

Rather than spam the list with those outputs, I've added them as
attachments to the bz report at
https://bugzilla.tianocore.org/show_bug.cgi?id=3504

When I first diff'd them, the slight difference in time stamps meant
every line showed up as different - real differences were hard to see.
Therefore I amended the files to replace the time stamps with "",
enabling diff to show actual differences more meaningfully.

I also attached there the output of a diff between the bad & good cases.
To be honest I can't see anything striking to explain the difference in
behaviour. To me, the main difference is that in the good case, an QEMU
HARDDISK & QEMU DVD-ROM are discovered and allows the system to boot but
no obvious indication why they are discovered in one case but not the
other. Apart from that, there are a few differences in some memory
locations being used but I have insufficient knowledge to judge whether
those differences are significant.

Is it possible for anyone to have a quick look through those files for
anything that may indicate what is causing the defective booting please?

Thanks,
chris


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79027): https://edk2.groups.io/g/devel/message/79027
Mute This Topic: https://groups.io/mt/84767423/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 6/6] OvmfPkg/AmdSevDxe: Add support for SEV live migration.

[Ashish Kalra via groups.io]

Hello Tom,

On Mon, Aug 09, 2021 at 09:29:29AM -0500, Tom Lendacky wrote:
> On 8/2/21 7:33 AM, Ashish Kalra wrote:
> > From: Ashish Kalra 
> > 
> > Check for SEV live migration feature support, if detected
> > setup a new UEFI enviroment variable to indicate OVMF
> > support for SEV live migration.
> > 
> > The new runtime UEFI environment variable is set via the
> > notification function registered for the
> > EFI_END_OF_DXE_EVENT_GROUP_GUID event in AmdSevDxe driver.
> > 
> > AmdSevDxe module is an apriori driver so it gets loaded between PEI
> > and DXE phases and the SetVariable call will fail at the driver's
> > entry point as the Variable DXE module is still not loaded yet.
> > So we need to wait for an event notification which is signaled
> > after the Variable DXE module is loaded, hence, using the
> > EndOfDxe event notification to make this call.
> > 
> > Signed-off-by: Ashish Kalra 
> > ---
> >  OvmfPkg/AmdSevDxe/AmdSevDxe.c  | 64 
> >  OvmfPkg/AmdSevDxe/AmdSevDxe.inf|  4 ++
> >  OvmfPkg/Include/Guid/AmdSevMemEncryptLib.h | 20 ++
> >  OvmfPkg/OvmfPkg.dec|  1 +
> >  4 files changed, 89 insertions(+)
> > 
> > diff --git a/OvmfPkg/AmdSevDxe/AmdSevDxe.c b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> > index c66c4e9b92..bfad71b9c6 100644
> > --- a/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> > +++ b/OvmfPkg/AmdSevDxe/AmdSevDxe.c
> > @@ -15,10 +15,47 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  
> > +STATIC
> > +VOID
> > +EFIAPI
> > +AmdSevDxeOnEndOfDxe (
> > +  IN EFI_EVENT Event,
> > +  IN VOID  *EventToSignal
> > +  )
> > +{
> > +  EFI_STATUS Status;
> > +  BOOLEAN SevLiveMigrationEnabled;
> > +
> > +  SevLiveMigrationEnabled = MemEncryptSevLiveMigrationIsEnabled();
> > +
> > +  if (SevLiveMigrationEnabled) {
> > +Status = gRT->SetVariable (
> > +   L"SevLiveMigrationEnabled",
> > +   ,
> > +   EFI_VARIABLE_NON_VOLATILE |
> > +   EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +   EFI_VARIABLE_RUNTIME_ACCESS,
> > +   sizeof SevLiveMigrationEnabled,
> > +   
> > +   );
> > +
> > +DEBUG ((
> > +  DEBUG_INFO,
> > +  "%a: Setting SevLiveMigrationEnabled variable, status = %lx\n",
> > +  __FUNCTION__,
> > +  Status
> > +  ));
> > +  }
> > +}
> > +
> >  EFI_STATUS
> >  EFIAPI
> >  AmdSevDxeEntryPoint (
> > @@ -30,6 +67,7 @@ AmdSevDxeEntryPoint (
> >EFI_GCD_MEMORY_SPACE_DESCRIPTOR  *AllDescMap;
> >UINTNNumEntries;
> >UINTNIndex;
> > +  EFI_EVENTEvent;
> >  
> >//
> >// Do nothing when SEV is not enabled
> > @@ -130,5 +168,31 @@ AmdSevDxeEntryPoint (
> >  }
> >}
> >  
> > +  //
> > +  // AmdSevDxe module is an apriori driver so it gets loaded between PEI
> > +  // and DXE phases and the SetVariable call will fail at the driver's
> > +  // entry point as the Variable DXE module is still not loaded yet.
> > +  // So we need to wait for an event notification which is signaled
> > +  // after the Variable DXE module is loaded, hence, using the
> > +  // EndOfDxe event notification to make this call.
> > +  //
> > +  // Register EFI_END_OF_DXE_EVENT_GROUP_GUID event.
> > +  // The notification function sets the runtime variable indicating OVMF
> > +  // support for SEV live migration.
> > +  //
> > +  Status = gBS->CreateEventEx (
> > +  EVT_NOTIFY_SIGNAL,
> > +  TPL_CALLBACK,
> > +  AmdSevDxeOnEndOfDxe,
> > +  NULL,
> > +  ,
> > +  
> > +  );
> > +
> > +  if (EFI_ERROR (Status)) {
> > +  DEBUG ((DEBUG_INFO, "%a: CreateEventEx(): %r\n",
> 
> DEBUG_ERROR?
> 
> > +__FUNCTION__, Status));
> 
> Should there be an "ASSERT_EFI_ERROR (Status)" after the DEBUG call?
> 

I don't think we should do an assert here and abort booting, failure
here will simply disable live migration support but i don't think that
it is such a fatal error that we should abort booting because of that.

OTOH, if there is a failure when doing page encryption status hypercalls
then aborting boot makes sense as guest page encryption status tracking
may be critical for multiple guest operations and not only live
migration.

Thanks,
Ashish


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79026): https://edk2.groups.io/g/devel/message/79026
Mute This Topic: https://groups.io/mt/84609858/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/2] MdePkg/BaseLib: Fix unaligned API prototypes

[Marvin Häuser]

On 09/08/2021 23:32, Andrew Fish via groups.io wrote:



On Aug 9, 2021, at 9:15 AM, Michael D Kinney 
mailto:michael.d.kin...@intel.com>> wrote:


Hi Marvin,

Can you provide an example of which C compiler is flagging this as
an error and what error message is generated.

Please enter a BZ with this background information and add link to the
BZ in the commit message.

This is a change to the BaseLib class, so we need to make sure there
are no impacts to any existing code.  I looks like a safe change
because changing from a pointer to a fixed size type to VOID *
should be compatible.  Please add that analysis to the background
in the BZ as well.



MIke,

I want to say we had a discussion about this years ago? I don’t 
remember the outcome.


Dereferencing a misaligned pointer is UB (Undefined Behavior) in C 
[1], but historically x86 compilers have let it slide.


I think the situation we are in is the BaseLib functions don’t contain 
UB, but it is UB for the caller to use the returned pointer directly.


They do contain UB, inherently from the combination of their prototype 
and their usage.
Please refer to the new BZ added for V2: 
https://bugzilla.tianocore.org/show_bug.cgi?id=3542


I could only speculate why UBsan does not check cast safety...
To be fair, I don't know a real-world platform that has issues with this 
UB, but the fix is simple enough in my opinion.


Actually, enabling "-Wcast-align" some day would be great either way. :)

Best regards,
Marvin



Here is a simple example with clang UndefinedBehaviorSanitizer (UBSan) .

~/work/Compiler>cat ub.c
#include 

#define EFIAPI
#define IN
#define OUT

typedef unsigned char UINT8;
typedef unsigned short UINT16;

UINT16
EFIAPI
WriteUnaligned16 (
  OUT UINT16                    *Buffer,
  IN  UINT16                    Value
  )
{
  // ASSERT (Buffer != NULL);

  ((volatile UINT8*)Buffer)[0] = (UINT8)Value;
  ((volatile UINT8*)Buffer)[1] = (UINT8)(Value >> 8);

  return Value;
}


int main()
{
UINT8 *buffer = malloc(64);
UINT16 *pointer = (UINT16 *)(buffer + 1);


WriteUnaligned16 (pointer, 42);


// *pointer = 42; // Error: misaligned integer pointer assignment
return *pointer;
}
~/work/Compiler>clang -fsanitize=undefined  ub.c
~/work/Compiler>./a.out
*ub.c:34:9:**runtime error: **load of misaligned address 
0x7feac6405aa1 for type 'UINT16' (aka 'unsigned short'), which 
requires 2 byte alignment*

*0x7feac6405aa1: note: *pointer points here
 00 00 00  64 2a 00 79 6d 28 52 54  4c 44 5f 44 45 46 41 55  4c 54 2c 
20 73 77 69 66  74 5f 64 65 6d

*              ^ *
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ub.c:34:9 in

FYI line 39 is `return *pointer`and 42 is 0x2A. So reading an writing 
to *pointer is UB.



As you can see in [1] the general advice is to take code that looks like:
int8_t *buffer = malloc(64);int32_t *pointer = (int32_t *)(buffer + 
1);*pointer = 42; // Error: misaligned integer pointer assignment

And replace it with;
int8_t *buffer = malloc(64);int32_t value = 42;memcpy(buffer + 1, 
, sizeof(int32_t)); // Correct


But in these cases the result is in a byte aligned buffer….

[1] https://developer.apple.com/documentation/xcode/misaligned-pointer 



Thanks,

Andrew Fish


Thanks,

Mike



-Original Message-
From: Marvin Häuser mailto:mhaeu...@posteo.de>>
Sent: Monday, August 9, 2021 2:51 AM
To:devel@edk2.groups.io 
Cc: Kinney, Michael D >; Liming Gao 
mailto:gaolim...@byosoft.com.cn>>; Liu, 
Zhiguang
mailto:zhiguang@intel.com>>; Vitaly 
Cheptsov mailto:vit9...@protonmail.com>>

Subject: [PATCH v2 1/2] MdePkg/BaseLib: Fix unaligned API prototypes

C prohibits not only dereferencing but also casting to unaligned
pointers. Thus, the current set of unaligned APIs cannot be called
safely. Update their prototypes to take VOID * pointers, which must
be able to represent any valid pointer.

Cc: Michael D Kinney >
Cc: Liming Gao >
Cc: Zhiguang Liu >
Cc: Vitaly Cheptsov >
Signed-off-by: Marvin Häuser >

---
MdePkg/Library/BaseLib/Arm/Unaligned.c | 14 -
MdePkg/Library/BaseLib/Unaligned.c | 32 ++--
MdePkg/Include/Library/BaseLib.h   | 16 +-
3 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/MdePkg/Library/BaseLib/Arm/Unaligned.c 
b/MdePkg/Library/BaseLib/Arm/Unaligned.c

index e9934e7003cb..57f19fc44e0b 100644
--- a/MdePkg/Library/BaseLib/Arm/Unaligned.c
+++ b/MdePkg/Library/BaseLib/Arm/Unaligned.c
@@ -59,7 +59,7 @@ ReadUnaligned16 (
UINT16

EFIAPI

WriteUnaligned16 (

-  OUT UINT16    *Buffer,

+  OUT VOID  *Buffer,

  IN  UINT16    Value

  )

{

@@ -87,7 +87,7 @@ WriteUnaligned16 (
UINT32

EFIAPI

ReadUnaligned24 (

-  IN 

Re: [edk2-devel] [PATCH v2 2/2] UefiCpuPkg/BaseUefiCpuLib: Use toolchain-specific rodata section name

[Marvin Häuser]

On 10/08/2021 06:40, Andrew Fish via groups.io wrote:



On Aug 9, 2021, at 7:43 PM, Ni, Ray > wrote:


Acked-by: Ray Ni mailto:ray...@intel.com>>

I will depend on tool owner to review the tool configuration change 
making sure that the correct section name is chosen for different C 
compilers.




Ray,

I made a detailed response about Mach-O with Xcode/clang and I don’t 
think patch works. Not sure if it breaks anything, but it puts things 
in the .data PE/COFF section.


The latter part is true only for Xcode-based toolchains, as far as I am 
aware now, and this is in fact the way it works right now.




I’m also worried it is broken for any toolchain that generates ELF and 
use GenFw. I don’t think the GenFw tool creates a PE/COFF .rodata 
section [1] so if things work they will end up in the .data section, 
or things might break? Some one who knows that tool better than me 
should take a detailed look.


You are correct, but the NASM section name semantically translates to an 
*ELF* .rodata section for usage during linking. The GNU linker scripts 
merge it into .text later [1], yielding no PE/COFF .rodata section as 
observed.




I’m guessing it likely does the correct thing for toolchains that 
generate PE/COFF directly?


Behaviour should be fixed for PE-based toolchains, preserved correct for 
ELF-based toolchains (but inconsistent with PE-based, as we merge 
.rodata into .text here), and as correct or broken for Xcode-based 
toolchains as it was before.




My vote is to not add this feature until we can prove it works 
properly on all the toolchains. For Xcode it may be easier to just 
dump this stuff in the .text section (see my other mail for more 
background).


If you can help with designing a solution, I'm more than happy to to 
submit a V2. Just I don't know Xcode, and I don't run macOS. :)


It looks like we might have to modify GenFw if we want to create a 
.rodata section?


For now, this patch un-breaks PE-based toolchains. They are broken in 
the way described in the BZ, but not in a security-critical fashion. 
Rather we have the worst of both worlds, the additional size of another 
aligned section, and the downgraded permission as we would observe with 
a merge into e.g. .text. I have no strong opinion on which route to 
pick, i.e. dedicated .r(o)data or merging into .text, but I would like 
it to be consistent in the end, especially across toolchains. Ideally, 
in my opinion, the platform maintainer can choose whether they want the 
extra protection (NX .rodata), or the extra space (.text merge).




It might be possible to cheat and use this concept to force code into 
the text section for ELF and Mach-O, but I’m not sure if that hits the 
correct security bar. But the last thing we want is to claim something 
is in a read only section when it is in a read write section.


I can check again later, but ELF should be fine, really.

Best regards,
Marvin


[1] 
https://github.com/tianocore/edk2/blob/d02dbb53cd78de799e6afaa237e98771fb5148db/BaseTools/Scripts/GccBase.lds#L25




[1] git grep CreateSectionHeader
BaseTools/Source/C/GenFw/Elf32Convert.c:602:*CreateSectionHeader*(".text", 
mTextOffset, mDataOffset - mTextOffset,
BaseTools/Source/C/GenFw/Elf32Convert.c:612:*CreateSectionHeader*(".data", 
mDataOffset, mHiiRsrcOffset - mDataOffset,
BaseTools/Source/C/GenFw/Elf32Convert.c:622:*CreateSectionHeader*(".rsrc", 
mHiiRsrcOffset, mRelocOffset - mHiiRsrcOffset,
BaseTools/Source/C/GenFw/Elf32Convert.c:1107:*CreateSectionHeader*(".reloc", 
mRelocOffset, mCoffOffset - mRelocOffset,
BaseTools/Source/C/GenFw/Elf64Convert.c:929:*CreateSectionHeader*(".text", 
mTextOffset, mDataOffset - mTextOffset,
BaseTools/Source/C/GenFw/Elf64Convert.c:939:*CreateSectionHeader*(".data", 
mDataOffset, mHiiRsrcOffset - mDataOffset,
BaseTools/Source/C/GenFw/Elf64Convert.c:949:*CreateSectionHeader*(".rsrc", 
mHiiRsrcOffset, mRelocOffset - mHiiRsrcOffset,
BaseTools/Source/C/GenFw/Elf64Convert.c:1641:*CreateSectionHeader*(".reloc", 
mRelocOffset, mCoffOffset - mRelocOffset,

BaseTools/Source/C/GenFw/ElfConvert.c:125:*CreateSectionHeader*(
BaseTools/Source/C/GenFw/ElfConvert.h:74:*CreateSectionHeader*(

Thanks,

Andrew Fish


Thanks,
Ray


-Original Message-
From: Marvin Häuser mailto:mhaeu...@posteo.de>>
Sent: Monday, August 9, 2021 5:51 PM
To:devel@edk2.groups.io 
Cc: Dong, Eric mailto:eric.d...@intel.com>>; 
Ni, Ray mailto:ray...@intel.com>>; Kumar, Rahul1 
mailto:rahul1.ku...@intel.com>>; Vitaly 
Cheptsov

mailto:vit9...@protonmail.com>>
Subject: [PATCH v2 2/2] UefiCpuPkg/BaseUefiCpuLib: Use 
toolchain-specific rodata section name


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



Correctly define the read-only data sections with the
toolchain-specific section name. This hardens image permission
security and may save image space.

Cc: Eric Dong mailto:eric.d...@intel.com>>
Cc: Ray 

Re: [edk2-devel] [PATCH v2 1/2] BaseTools: Define the read-only data section name per toolchain

[Marvin Häuser]

On 10/08/2021 06:19, Andrew Fish via groups.io wrote:



On Aug 9, 2021, at 2:51 AM, Marvin Häuser > wrote:


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



Different toolchains of the EDK II build system may generate ELF or
Mach-O files, which use the ".rodata" naming convention, or PE/COFF
files, which use the ".rdata" naming convention. Section permissions
are chosen based on this name per file format by NASM. To harden
image permission security, and to save space by avoiding both
".rdata" and ".rodata" sections being emitted, expose the appropriate
name as a preprocessor constant.

Cc: Bob Feng mailto:bob.c.f...@intel.com>>
Cc: Liming Gao >

Cc: Yuwei Chen mailto:yuwei.c...@intel.com>>
Cc: Vitaly Cheptsov >
Signed-off-by: Marvin Häuser >

---
BaseTools/Conf/tools_def.template | 172 ++--
1 file changed, 86 insertions(+), 86 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template

index 2e6b382ab623..84d464916c4d 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -463,9 +463,9 @@ NOOPT_VS2008_IA32_CC_FLAGS    = /nologo /c 
/WX /GS- /W4 /Gs32768 /D UNICODE

RELEASE_VS2008_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd

NOOPT_VS2008_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi



-  DEBUG_VS2008_IA32_NASM_FLAGS    = -Ox -f win32 -g

-RELEASE_VS2008_IA32_NASM_FLAGS    = -Ox -f win32

-NOOPT_VS2008_IA32_NASM_FLAGS  = -O0 -f win32 -g

+  DEBUG_VS2008_IA32_NASM_FLAGS    = -Ox -f win32 -g 
-DRODATA_SECTION_NAME=.rdata


+RELEASE_VS2008_IA32_NASM_FLAGS    = -Ox -f win32 
-DRODATA_SECTION_NAME=.rdata


+NOOPT_VS2008_IA32_NASM_FLAGS  = -O0 -f win32 -g 
-DRODATA_SECTION_NAME=.rdata




  DEBUG_VS2008_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
/SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
/SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /DEBUG


RELEASE_VS2008_IA32_DLINK_FLAGS   = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 
/SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 
/SAFESEH:NO /BASE:0 /DRIVER /MERGE:.rdata=.data


@@ -495,9 +495,9 @@ NOOPT_VS2008_X64_CC_FLAGS   = /nologo /c /WX 
/GS- /W4 /Gs32768 /D UNICODE /G

RELEASE_VS2008_X64_ASM_FLAGS    = /nologo /c /WX /W3 /Cx /Zd

NOOPT_VS2008_X64_ASM_FLAGS    = /nologo /c /WX /W3 /Cx /Zd /Zi



-  DEBUG_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -g

-RELEASE_VS2008_X64_NASM_FLAGS   = -Ox -f win64

-NOOPT_VS2008_X64_NASM_FLAGS = -O0 -f win64 -g

+  DEBUG_VS2008_X64_NASM_FLAGS   = -Ox -f win64 -g 
-DRODATA_SECTION_NAME=.rdata


+RELEASE_VS2008_X64_NASM_FLAGS   = -Ox -f win64 
-DRODATA_SECTION_NAME=.rdata


+NOOPT_VS2008_X64_NASM_FLAGS = -O0 -f win64 -g 
-DRODATA_SECTION_NAME=.rdata




  DEBUG_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
/OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
/SECTION:.pdata,D /Machine:X64 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
/SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /DEBUG


RELEASE_VS2008_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB /IGNORE:4001 
/IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
/SECTION:.pdata,D /Machine:X64 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
/SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER 
/MERGE:.rdata=.data


@@ -574,9 +574,9 @@ NOOPT_VS2008x86_IA32_CC_FLAGS  = /nologo /c 
/WX /GS- /W4 /Gs32768 /D UNICODE

RELEASE_VS2008x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd

NOOPT_VS2008x86_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd /Zi



-  DEBUG_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 -g

-RELEASE_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32

-NOOPT_VS2008x86_IA32_NASM_FLAGS    = -O0 -f win32 -g

+  DEBUG_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 -g 
-DRODATA_SECTION_NAME=.rdata


+RELEASE_VS2008x86_IA32_NASM_FLAGS  = -Ox -f win32 
-DRODATA_SECTION_NAME=.rdata


+NOOPT_VS2008x86_IA32_NASM_FLAGS    = -O0 -f win32 -g 
-DRODATA_SECTION_NAME=.rdata




  DEBUG_VS2008x86_IA32_DLINK_FLAGS = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D 
/SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) 
/SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO /BASE:0 /DRIVER /DEBUG


RELEASE_VS2008x86_IA32_DLINK_FLAGS = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 
/SECTION:.xdata,D /SECTION:.pdata,D /MACHINE:X86 /LTCG /DLL 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER 
/SAFESEH:NO /BASE:0 /DRIVER /MERGE:.rdata=.data


@@ -605,9 +605,9 @@ NOOPT_VS2008x86_X64_CC_FLAGS   = /nologo /c 
/WX 

Re: [edk2-devel] [PATCH 0/3] BaseTools: fix some python DeprecationWarnings

[Yuwei Chen]

Hi Robinson,

When we doing the internal test,  the issue is found that py27 is blocked by 
this patch. 
You can reproduce the error with below steps:

For Linux:
[Error Reproduce steps]
$ export PYTHON3_ENABLE=FALSE
$ export PYTHON_COMMAND=/usr/bin/python2.7
$ build -p OvmfPkg/OvmfPkgIa32X64.dsc -a IA32 -a X64 -t GCC5
Active Platform  = 
/home/jshi19/wksp_efi/edk2-3/OvmfPkg/OvmfPkgIa32X64.dsc
..
- Failed -
Build end time: 13:00:59, Aug.10 2021
Build total time: 00:00:07

[After Reverting the patch] 
$ git revert 0b1b0a9674e27c858f05436ed92250f4498245cf
$ build -p OvmfPkg/OvmfPkgIa32X64.dsc -a IA32 -a X64 -t GCC5 
Pass


For Windows:
[Error Reproduce steps]
set PYTHON3_ENABLE=FALSE
set PYTHON_COMMAND=C:\Python27\python.exe
build -p OvmfPkg\OvmfPkgIa32X64.dsc -a IA32 -a X64 -t VS2015x86
Active Platform  = 
c:\users\yuweiche\code\edk2\edk2\OvmfPkg\OvmfPkgIa32X64.dsc
..
- Failed -
Build end time: 15:40:35, Aug.10 2021
Build total time: 00:00:07

[After Reverting the patch] 
$ git revert 0b1b0a9674e27c858f05436ed92250f4498245cf
$ build -p OvmfPkg\OvmfPkgIa32X64.dsc -a IA32 -a X64 -t VS2015x86
- Done -
Build end time: 15:35:16, Aug.10 2021
Build total time: 00:01:58


Hope you can fix this bug.  @crobi...@redhat.com

Hi Liming @Liming Gao, what do you think about this issue? If we need fix it 
before this quarter release?

Thanks,
Yuwei (Christine)

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Cole
> Sent: Saturday, July 24, 2021 4:02 AM
> To: devel@edk2.groups.io
> Cc: Cole Robinson 
> Subject: [edk2-devel] [PATCH 0/3] BaseTools: fix some python
> DeprecationWarnings
> 
> This addresses some python DeprecationWarnings that are popping up with
> python 3.10
> 
> Cole Robinson (3):
>   build: Fix python3.10 threading DeprecationWarnings
>   python: Replace distutils.utils.split_quotes with shlex.split
>   BaseTools: Drop check for distutils.utils
> 
>  .../Source/Python/AutoGen/UniClassObject.py   |  4 +-
>  .../Python/UPT/Library/UniClassObject.py  |  4 +-
>  BaseTools/Source/Python/build/build.py| 48 +--
>  BaseTools/Tests/RunTests.py   |  7 ---
>  4 files changed, 28 insertions(+), 35 deletions(-)
> 
> --
> 2.31.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79022): https://edk2.groups.io/g/devel/message/79022
Mute This Topic: https://groups.io/mt/84409128/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms:PATCH V6] Platform/Intel: Correct CPU APIC IDs

[JackX Lin]

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

BIOS cannot find correct AcpiProcId in mApicIdMap because of
there is no suitable map, that causes ACPI_BIOS_ERROR.
Remove mApicIdMap for determing AcpiProcId, uses normal
countings instead.

Signed-off-by: JackX Lin 
Cc: Chasel Chiu 
Cc: Jenny Huang 
Cc: Jiewen Yao 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Donald Kuo 
Cc: Chandana C Kumar 
Cc: JackX Lin 
---
 Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c | 621 
++---
 1 file changed, 254 insertions(+), 367 deletions(-)

diff --git a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c 
b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
index 2b51c34ef2..174582c674 100644
--- a/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
+++ b/Platform/Intel/MinPlatformPkg/Acpi/AcpiTables/AcpiPlatform.c
@@ -1,23 +1,21 @@
 /** @file
   ACPI Platform Driver
 
-Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include "AcpiPlatform.h"
 
-#define MAX_CPU_NUM (FixedPcdGet32(PcdMaxCpuThreadCount) * 
FixedPcdGet32(PcdMaxCpuCoreCount) * FixedPcdGet32(PcdMaxCpuSocketCount))
-
 #pragma pack(1)
 
 typedef struct {
   UINT32   AcpiProcessorId;
   UINT32   ApicId;
   UINT32   Flags;
-  UINT32   SwProcApicId;
   UINT32   SocketNum;
+  UINT32   Thread;
 } EFI_CPU_ID_ORDER_MAP;
 
 //
@@ -50,7 +48,7 @@ VOID  *mLocalTable[] = {
   ,
 };
 
-EFI_ACPI_TABLE_PROTOCOL   *mAcpiTable;
+EFI_ACPI_TABLE_PROTOCOL *mAcpiTable;
 
 UINT32  mNumOfBitShift = 6;
 BOOLEAN mForceX2ApicId;
@@ -58,138 +56,19 @@ BOOLEAN mX2ApicEnabled;
 
 EFI_MP_SERVICES_PROTOCOL*mMpService;
 BOOLEAN mCpuOrderSorted;
-EFI_CPU_ID_ORDER_MAPmCpuApicIdOrderTable[MAX_CPU_NUM];
-UINTN   mNumberOfCPUs = 0;
+EFI_CPU_ID_ORDER_MAP*mCpuApicIdOrderTable = NULL;
+UINTN   mNumberOfCpus = 0;
 UINTN   mNumberOfEnabledCPUs = 0;
 
-// following are possible APICID Map for SKX
-static const UINT32 ApicIdMapA[] = {  //for SKUs have number of core > 16
-  //it is 14 + 14 + 14 + 14 format
-  0x, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 
0x0006, 0x0007,
-  0x0008, 0x0009, 0x000A, 0x000B, 0x000C, 0x000D, 
0x0010, 0x0011,
-  0x0012, 0x0013, 0x0014, 0x0015, 0x0016, 0x0017, 
0x0018, 0x0019,
-  0x001A, 0x001B, 0x001C, 0x001D, 0x0020, 0x0021, 
0x0022, 0x0023,
-  0x0024, 0x0025, 0x0026, 0x0027, 0x0028, 0x0029, 
0x002A, 0x002B,
-  0x002C, 0x002D, 0x0030, 0x0031, 0x0032, 0x0033, 
0x0034, 0x0035,
-  0x0036, 0x0037, 0x0038, 0x0039, 0x003A, 0x003B, 
0x003C, 0x003D
-};
-
-static const UINT32 ApicIdMapB[] = { //for SKUs have number of cores <= 16 use 
32 ID space
-  //it is 16+16 format
-  0x, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 
0x0006, 0x0007,
-  0x0008, 0x0009, 0x000A, 0x000B, 0x000C, 0x000D, 
0x000E, 0x000F,
-  0x0010, 0x0011, 0x0012, 0x0013, 0x0014, 0x0015, 
0x0016, 0x0017,
-  0x0018, 0x0019, 0x001A, 0x001B, 0x001C, 0x001D, 
0x001E, 0x001F,
-  0x, 0x, 0x, 0x, 0x, 0x, 
0x, 0x,
-  0x, 0x, 0x, 0x, 0x, 0x, 
0x, 0x,
-  0x, 0x, 0x, 0x, 0x, 0x, 
0x, 0x
-};
-
-
-static const UINT32 ApicIdMapC[] = { //for SKUs have number of cores <= 16 use 
64 ID space
-  //it is 16+0+16+0 format
-  0x, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 
0x0006, 0x0007,
-  0x0008, 0x0009, 0x000A, 0x000B, 0x000C, 0x000D, 
0x000E, 0x000F,
-  0x0020, 0x0021, 0x0022, 0x0023, 0x0024, 0x0025, 
0x0026, 0x0027,
-  0x0028, 0x0029, 0x002A, 0x002B, 0x002C, 0x002D, 
0x002E, 0x002F,
-  0x, 0x, 

Re: [edk2-devel] [PATCH] SecurityPkg: Debug code to audit BIOS TPM extend operations.

[Rodrigo Gonzalez del Cueto]

Hi Jiewen,

The intention of such API would be to ease debugging and auditing PCR 
attestation along the boot; it has been a common task while debugging several 
issues and TPM configurations.

a) Configurations in which BIOS is not the S-CRTM and we need to attest what 
has been measured to the TPM prior to any measurements performed by BIOS.
b) Verifying the values in all the active and supported PCR banks: attestation 
or capping of the PCRs. (See BZ: 
3515)

Such API together with the TCG event log print out it allows us to audit and 
debug the measured boot sequence.

Regards,
-Rodrigo

From: Yao, Jiewen 
Sent: Sunday, August 8, 2021 6:24 PM
To: Gonzalez Del Cueto, Rodrigo ; 
devel@edk2.groups.io 
Cc: Wang, Jian J 
Subject: RE: [PATCH] SecurityPkg: Debug code to audit BIOS TPM extend 
operations.

Some feedback:

1) I think it is OK to add Tpm2PcrReadForActiveBank() API.
But I feel we will add too many noise to dump Tpm2PcrReadForActiveBank() in the 
code everytime.
I am not sure why it is needed.
What is the problem statement?

2) Below definition does not follow EDKII coding style. Please use 2 "space" as 
indent.
EFI_STATUS
EFIAPI
Tpm2PcrReadForActiveBank (
 IN  TPMI_DH_PCRPcrHandle,
 OUT TPML_DIGEST*HashList
)



> -Original Message-
> From: Gonzalez Del Cueto, Rodrigo 
> Sent: Friday, July 30, 2021 6:43 AM
> To: devel@edk2.groups.io
> Cc: Gonzalez Del Cueto, Rodrigo ; Yao,
> Jiewen ; Wang, Jian J 
> Subject: [PATCH] SecurityPkg: Debug code to audit BIOS TPM extend operations.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2858
>
> Add debug functionality to examine TPM extend operations
> performed by BIOS and inspect the PCR 00 value prior to
> any BIOS measurements.
>
> Replaced usage of EFI_D_* for DEBUG_* definitions in debug
> messages.
>
> Signed-off-by: Rodrigo Gonzalez del Cueto
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> ---
>  SecurityPkg/Include/Library/Tpm2CommandLib.h   |  28
> ++--
>  SecurityPkg/Library/Tpm2CommandLib/Tpm2Integrity.c | 226
> +
> +
> +
> ---
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c  |  34 
> --
> 
>  3 files changed, 245 insertions(+), 43 deletions(-)
>
> diff --git a/SecurityPkg/Include/Library/Tpm2CommandLib.h
> b/SecurityPkg/Include/Library/Tpm2CommandLib.h
> index ee8eb62295..5e5c340893 100644
> --- a/SecurityPkg/Include/Library/Tpm2CommandLib.h
> +++ b/SecurityPkg/Include/Library/Tpm2CommandLib.h
> @@ -1,7 +1,7 @@
>  /** @file
>This library is used by other modules to send TPM2 command.
>
> -Copyright (c) 2013 - 2018, Intel Corporation. All rights reserved. 
> +Copyright (c) 2013 - 2021, Intel Corporation. All rights reserved. 
>  SPDX-License-Identifier: BSD-2-Clause-Patent
>
>  **/
> @@ -505,7 +505,7 @@ EFIAPI
>  Tpm2PcrEvent (
>IN  TPMI_DH_PCR   PcrHandle,
>IN  TPM2B_EVENT   *EventData,
> - OUT  TPML_DIGEST_VALUES*Digests
> +  OUT TPML_DIGEST_VALUES*Digests
>);
>
>  /**
> @@ -522,10 +522,10 @@ Tpm2PcrEvent (
>  EFI_STATUS
>  EFIAPI
>  Tpm2PcrRead (
> -  IN  TPML_PCR_SELECTION*PcrSelectionIn,
> - OUT  UINT32*PcrUpdateCounter,
> - OUT  TPML_PCR_SELECTION*PcrSelectionOut,
> - OUT  TPML_DIGEST   *PcrValues
> +  IN   TPML_PCR_SELECTION*PcrSelectionIn,
> +  OUT  UINT32*PcrUpdateCounter,
> +  OUT  TPML_PCR_SELECTION*PcrSelectionOut,
> +  OUT  TPML_DIGEST   *PcrValues
>);
>
>  /**
> @@ -1113,4 +1113,20 @@ GetDigestFromDigestList(
>OUT VOID  *Digest
>);
>
> +  /**
> +   This function will query the TPM to determine which hashing algorithms and
> +   get the digests of all active and supported PCR banks of a specific PCR
> register.
> +
> +   @param[in] PcrHandle The index of the PCR register to be read.
> +   @param[out]HashList  List of digests from PCR register being read.
> +
> +   @retval EFI_SUCCESS   The Pcr was read successfully.
> +   @retval EFI_DEVICE_ERROR  The command was unsuccessful.
> +**/
> +EFI_STATUS
> +EFIAPI
> +Tpm2PcrReadForActiveBank (
> +  IN  TPMI_DH_PCRPcrHandle,
> +  OUT TPML_DIGEST*HashList
> +  );
>  #endif
> diff --git a/SecurityPkg/Library/Tpm2CommandLib/Tpm2Integrity.c
> b/SecurityPkg/Library/Tpm2CommandLib/Tpm2Integrity.c
> index ddb15178fb..3b49192b93 100644
> --- a/SecurityPkg/Library/Tpm2CommandLib/Tpm2Integrity.c
> +++ b/SecurityPkg/Library/Tpm2CommandLib/Tpm2Integrity.c
> @@ -1,7 +1,7 @@
>  /** @file
>Implement TPM2 Integrity 

Re: [edk2-devel] [PATCH] Reallocate TPM Active PCRs based on platform support.

[Rodrigo Gonzalez del Cueto]

Hi Jiewen,

Indeed, this bug has existed for a long time in this code. What recently 
changed are the TPM configurations we are testing and exposed the issue; this 
can be reproduced when the BIOS supported algorithms are a strict subset of the 
PCRs currently active in the TPM.

Now that we are using TPM configurations with support for additional PCR banks 
(ex. SHA384 and SM3) the bug has been exposed when compiling a BIOS without 
support for these PCR banks which are active by default in the some of the TPMs.

Regards,
-Rodrigo


From: Yao, Jiewen 
Sent: Sunday, August 8, 2021 6:13 PM
To: Gonzalez Del Cueto, Rodrigo ; 
devel@edk2.groups.io 
Cc: Wang, Jian J 
Subject: RE: [PATCH] Reallocate TPM Active PCRs based on platform support.

Hi Rodrigo
I don’t understand the problem statement.

This code has been there for long time. What is changed recently ?

Thank you
Yao Jiewen


> -Original Message-
> From: Gonzalez Del Cueto, Rodrigo 
> Sent: Thursday, August 5, 2021 7:28 AM
> To: devel@edk2.groups.io
> Cc: Gonzalez Del Cueto, Rodrigo ;
> Wang, Jian J ; Yao, Jiewen 
> Subject: [PATCH] Reallocate TPM Active PCRs based on platform support.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3515
>
> In V2: Add case to RegisterHashInterfaceLib logic
>
> RegisterHashInterfaceLib needs to correctly handle registering the HashLib
> instance supported algorithm bitmap when PcdTpm2HashMask is set to zero.
>
> The current implementation of SyncPcrAllocationsAndPcrMask() triggers
> PCR bank reallocation only based on the intersection between
> TpmActivePcrBanks and PcdTpm2HashMask.
>
> When the software HashLibBaseCryptoRouter solution is used, no PCR bank
> reallocation is occurring based on the supported hashing algorithms
> registered by the HashLib instances.
>
> Need to have an additional check for the intersection between the
> TpmActivePcrBanks and the PcdTcg2HashAlgorithmBitmap populated by the
> HashLib instances present on the platform's BIOS.
>
> Signed-off-by: Rodrigo Gonzalez del Cueto
> 
>
> Cc: Jian J Wang 
> Cc: Jiewen Yao 
> ---
>  SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.c
> |  6 +-
>  SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c |
> 6 +-
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c| 18
> +-
>  SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf  |  
> 1 +
>  4 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.
> c
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.
> c
> index 7a0f61efbb..0821159120 100644
> ---
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.
> c
> +++
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.
> c
> @@ -230,13 +230,17 @@ RegisterHashInterfaceLib (
>  {
>UINTN  Index;
>UINT32 HashMask;
> +  UINT32 Tpm2HashMask;
>EFI_STATUS Status;
>
>//
>// Check allow
>//
>HashMask = Tpm2GetHashMaskFromAlgo (>HashGuid);
> -  if ((HashMask & PcdGet32 (PcdTpm2HashMask)) == 0) {
> +  Tpm2HashMask = PcdGet32 (PcdTpm2HashMask);
> +
> +  if ((Tpm2HashMask != 0) &&
> +  ((HashMask & Tpm2HashMask) == 0)) {
>  return EFI_UNSUPPORTED;
>}
>
> diff --git
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> index 42cb562f67..6ae51dbce4 100644
> ---
> a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> +++
> b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
> @@ -327,13 +327,17 @@ RegisterHashInterfaceLib (
>UINTN  Index;
>HASH_INTERFACE_HOB *HashInterfaceHob;
>UINT32 HashMask;
> +  UINT32 Tpm2HashMask;
>EFI_STATUS Status;
>
>//
>// Check allow
>//
>HashMask = Tpm2GetHashMaskFromAlgo (>HashGuid);
> -  if ((HashMask & PcdGet32 (PcdTpm2HashMask)) == 0) {
> +  Tpm2HashMask = PcdGet32 (PcdTpm2HashMask);
> +
> +  if ((Tpm2HashMask != 0) &&
> +  ((HashMask & Tpm2HashMask) == 0)) {
>  return EFI_UNSUPPORTED;
>}
>
> diff --git a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> index 93a8803ff6..5ad6a45cf3 100644
> --- a/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> +++ b/SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c
> @@ -262,6 +262,7 @@ SyncPcrAllocationsAndPcrMask (
>  {
>EFI_STATUSStatus;
>EFI_TCG2_EVENT_ALGORITHM_BITMAP   TpmHashAlgorithmBitmap;
> +  EFI_TCG2_EVENT_ALGORITHM_BITMAP   BiosHashAlgorithmBitmap;
>UINT32TpmActivePcrBanks;
>UINT32NewTpmActivePcrBanks;
>UINT32Tpm2PcrMask;
> @@ -273,16 +274,27 @@ 

Re: [edk2-devel] [PATCH v6 1/6] OvmfPkg/BaseMemEncryptLib: Detect SEV live migration feature.

[Gerd Hoffmann]

  Hi,

> > I still really don't understand the need for the CPUID loop. KVM only ever
> > programs CPUID function 0x4000, right?

Nope.  When you enable hyper-v emulation features you'll go find the kvm
cpuid @ 0x4000 and the hyper-v cpuid @ 0x4100 (or the other way
around, not sure).

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79018): https://edk2.groups.io/g/devel/message/79018
Mute This Topic: https://groups.io/mt/84609830/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()

[Gerd Hoffmann]

  Hi,

> insmod /lib/modules/5.13.8/kernel/fs/jbd2/jbd2.ko
> insmod /lib/modules/5.13.8/kernel/fs/mbcache.ko
> insmod /lib/modules/5.13.8/kernel/fs/ext4/ext4.ko
> mount: mounting /dev/sda2 on /mnt failed: No such file or directory
> ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.
>You can try to fix it. Type 'exit' when things are done.
> 
> At that point I'm dropped into a recovery shell to try fixing something
> but there's nothing that can be done since the disk containing the OS is
> not visible.

> From the above, I think I've done everything possible to verify the
> problem and a possible fix. Is there something fundamentally wrong in
> the way I'm going about this?

Root cause is not clear.  Grab the kernel log ('dmesg') from a good and
a bad boot and comparing them should give a clue.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79017): https://edk2.groups.io/g/devel/message/79017
Mute This Topic: https://groups.io/mt/84767423/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-