Date   

[PATCH V2 0/3] CryptoPkg: Add EC key retrieving and signature interface.

Qi Zhang
 

This patch is used to retrieve EC key from PEM and X509 and
carry out the EC-DSA signature and verify it.

The interface was tested by:
1. DeviceSecurity on edk2-staging
https://github.com/tianocore/edk2-staging/tree/DeviceSecurity.
2. Unit test in CryptoPkg/Test

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4102
PR: https://github.com/tianocore/edk2/pull/3464

V2 change: change the protocol version.

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Signed-off-by: Qi Zhang <qi1.zhang@...>

Qi Zhang (3):
CryptoPkg: Add EC key retrieving and signature interface.
CryptoPkg: Add EC key interface to DXE and protocol
CryptoPkg: add unit test for EC key interface.

CryptoPkg/Driver/Crypto.c | 143 +++++++++-
CryptoPkg/Include/Library/BaseCryptLib.h | 129 +++++++++
.../Pcd/PcdCryptoServiceFamilyEnable.h | 4 +
CryptoPkg/Library/BaseCryptLib/Pem/CryptPem.c | 87 ++++++
.../Library/BaseCryptLib/Pem/CryptPemNull.c | 30 ++
CryptoPkg/Library/BaseCryptLib/Pk/CryptEc.c | 258 ++++++++++++++++++
.../Library/BaseCryptLib/Pk/CryptEcNull.c | 82 ++++++
CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c | 83 ++++++
.../Library/BaseCryptLib/Pk/CryptX509Null.c | 28 ++
.../BaseCryptLibNull/Pem/CryptPemNull.c | 30 ++
.../Library/BaseCryptLibNull/Pk/CryptEcNull.c | 82 ++++++
.../BaseCryptLibNull/Pk/CryptX509Null.c | 28 ++
.../BaseCryptLibOnProtocolPpi/CryptLib.c | 136 +++++++++
CryptoPkg/Private/Protocol/Crypto.h | 131 ++++++++-
.../UnitTest/Library/BaseCryptLib/EcTests.c | 156 +++++++++++
15 files changed, 1405 insertions(+), 2 deletions(-)

--
2.26.2.windows.1


Re: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Michael D Kinney
 

Hi Jiewen,

comments below.

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 7:07 PM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>; Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran <quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

OK. That means we need manual write a wrapper for all EC APIs in Openssl Lib for internal usage.
More precisely, a wrapper for the delta between OpensslLib and OpensslLibFull, right?
Yes. This these are implemented in:

https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_MergeOptimizedOpensslLibs/CryptoPkg/Library/OpensslLib/SslNull.c
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_MergeOptimizedOpensslLibs/CryptoPkg/Library/OpensslLib/EcSm2Null.c

New instances are easy to find because you will get a link failure in CI for missing symbols if
BaseCryptLib or TlsLib uses a new API that is only present in OpensslLibFull.inf. When that occurs
add the Null version of API that always returns a failure condition.

The current implementation before this PR is using OpensslLib class, but the OpensslLib instances
are inconsistent in the APIs produced by the lib instances. This is what caused the introduction
of #if for EC feature into the layers above OpensslLib. This means the EDK II rules for
lib class/lib instance were not followed, and the workaround was to use #if which are also not allowed.

The correct fix is to follow EDK II lib class/lib instance rules. All lib instances of the same
lib class always produce the same APIs, and then all components that use the lib class can depend
on all the services being present without link failures.


There will be size difference between those two solutions, because the code other than EC will be include in the function.
Yes,


Why not use NO_EC macro from openssl directly?
Because that hides all the EC related types required to implement the Null EC APIs
and the EC types required in the layer above OpensslLib that calls EC services.
They will not compile without the EC types being defined.


Thank you
Yao Jiewen


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:55 AM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Jiewen,

The BKM is to just call the EC services from the layers above OpensslLib.
The EC APIs will always be present. Either real EC service or Null EC service.
This way we can remove all the #ifdef on EC PCD.

Platform developers select the OpensslLib instance with EC
(OpensslLibFull.inf) or
without EC (OpensslLib.inf).

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:37 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Hi Mike
For PcdOpensslEcEnabled, I am seeing other usage. For example:
https://github.com/qizhangz/edk2/blob/EC_Upstream/CryptoPkg/Library/
BaseCryptLib/Pem/CryptPem.c#L156

I think we may need BKM on "how to disable EC".

Thank you
Yao, Jiewen


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:25 AM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca
Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

Hi Jiewen,

Comments below.

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:09 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

Thank you Mike.

1) I like the idea to combine multiple OpensslLibIA32/X64.inf into one
OpensslLibAccel.inf.
Also the cleanup looks good to me.

2) I also like the summary in readme in
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg
I notice some algorithms are listed Y(Deprecated) but N(Don't Use),
such
as Tdes, Arc4, Aes.Ecb*.
But I don’t see the use case for those algorithms and I suggest a
Y(Deprecated) have Y(Don't Use).

Good catch. I will fix.


3) About PcdOpensslEcEnabled
I notice it is used in existing code -
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Library/TlsLib/TlsConfig.c#L11
39
Is this right way?
This was added since I started this work and was added back in by
rebase. I
will fix.
We can just remove the check for the PCD. If the OpensslLib instance
does
not include
SSL services, then the Null SSL services are present and the call to
SSL_ctrl()
will
return 0 which will force TlsSetEcCurve() to return EFI_UNSUPPORTED.
It
will also
ASSERT() informing the developer that a call to a service that depends
on
SSL was made
without SSL services available.

long
SSL_ctrl (
SSL *ssl,
int cmd,
long larg,
void *parg
)
{
ASSERT (FALSE);
return 0;
}

Likewise, if the OpensslLib instance does not support EC services, then
the
Null
EC services will be included and the call to
EC_KEY_new_by_curve_name()
will
return NULL which will force TlsSetEcCurve() to return
EFI_UNSUPPORTED. It
will also
ASSERT() informing the developer that a call to a service that depends
on EC
was made
without EC services available.

EC_KEY *
EC_KEY_new_by_curve_name (
int nid
)
{
ASSERT (FALSE);
return NULL;
}


Thank you
Yao, Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 11, 2022 11:04 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang,
Guomin <guomin.jiang@...>; Zurcher, Christopher
<christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

The recent addition of the Ecliptic Curve (EC) feature and the
performance
optimization features increased the complexity for platforms to
integrate
and enable these features. This series simplifies the platform
configuration
as much as possible and improves the ability to manage the the size
impact
of cryptographic services in each FW phase. A Readme.md is also
added
that
provides an overview of the CryptoPkg design and features along
with
platform
integration recommendations.

This series also addresses private library class declarations missing
from
CryptoPkg.dec and library instances not producing all the APIs
defined
by the library classes. A review of the CryptoPkg EDK II meta data
files
identified
a number of additional cleanups. The CryptoPkg.dsc file was also
updated to
improve CI coverage for future CryptoPkg changes and identified
some
unit test bug fixes.

PR: https://github.com/tianocore/edk2/pull/3443
Branch:
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs
Readme:
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Readme.md

Change Summary
==============
* Document disabled/deprecated cryptographic services
* Add missing UNI files in BaseCryptLib
* Update BaseCryptLib internal functions to be STATIC and remove
EFIAPI
* Add GLOBAL_REMOVE_IF_UNREFERENCED to BaseCryptLib global
variables
* Fix BaseCryptLib unit tests
* Cleanup BaseCryptLib and TlsLib INF files and
* Move SysCall/inet_pton.c from BaseCryptLib to TlsLib that uses it.
* Merge 4 performance optimized INFs into OpensslLib*Accel.inf
* Remove use of PcdOpensslEcEnabled and use OpensslLibFull*.inf
instead
* Add OpensslLib and IntrinsicLib to CryptoPkg.dec as private library
classes
* Update all OpensslLib instances to always produce all APIs in
OpensslLib
class
* Move PrintLib dependency from OpensslLib INF files to
BaseCryptLib
INF
files
* Update CryptoPkg.dsc files to provide full CI test coverage across
all
the
supported combinations of OpensslLib, BaseCryptLib, and TlsLib
instances.
* Remove PACKAGE profile from CryptoPkg.dsc and add
TARGET_UNIT_TESTS
profile. Adding TARGET_UNIT_TESTS profile is required to prevent
a
few
unit
test artifacts being included in non unit test builds of components.
* Add CryptoPkg Readme.md with overview and platform
integration
details.
* Update host-based unit tests to always use OpensslLibFull.inf and
add
unit
test coverage for OpensslLibFullAccel.inf.
* Add Readme.md with CryptoPkg overview and platform
integration
documentation

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Cc: Christopher Zurcher <christopher.zurcher@...>
Cc: Rebecca Cran <quic_rcran@...>
Cc: Ard Biesheuvel <ardb@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>

Michael D Kinney (12):
CryptoPkg: Document and disable deprecated crypto services
CryptoPkg/Library/BaseCryptLib: Add missing UNI file and fix
format
CryptoPkg/Library/BaseCryptLib: Update internal
functions/variables
CryptoPkg/Test/UnitTest/Library/BaseCryptLib: Unit test fixes
CryptoPkg/Library: Cleanup BaseCryptLib and TlsLib
CryptoPkg/Library/OpensslLib: Combine all performance optimized
INFs
CryptoPkg/Library/OpensslLib: Produce consistent set of APIs
CryptoPkg/Library/OpensslLib: Remove PrintLib from INF files
CryptoPkg: Remove PcdOpensslEcEnabled from CryptoPkg.dec
CryptoPkg: Update DSC to improve CI test coverage
CryptoPkg: Fixed host-based unit tests
CryptoPkg: Add Readme.md

CryptoPkg/CryptoPkg.ci.yaml | 11 +-
CryptoPkg/CryptoPkg.dec | 42 +-
CryptoPkg/CryptoPkg.dsc | 460 +++++++++---
.../Pcd/PcdCryptoServiceFamilyEnable.h | 122 +--
.../Library/BaseCryptLib/BaseCryptLib.inf | 10 +-
.../Library/BaseCryptLib/BaseCryptLib.uni | 2 -
.../Library/BaseCryptLib/Hmac/CryptHmac.c | 7 +
.../Library/BaseCryptLib/Kdf/CryptHkdf.c | 5 +-
.../Library/BaseCryptLib/PeiCryptLib.inf | 8 +-
.../Library/BaseCryptLib/PeiCryptLib.uni | 2 -
.../BaseCryptLib/Pk/CryptAuthenticode.c | 2 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c | 3 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyEku.c | 3 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 44 +-
.../Library/BaseCryptLib/RuntimeCryptLib.inf | 9 +-
.../Library/BaseCryptLib/RuntimeCryptLib.uni | 2 -
.../Library/BaseCryptLib/SecCryptLib.inf | 13 +-
.../{SmmCryptLib.uni => SecCryptLib.uni} | 11 +-
.../Library/BaseCryptLib/SmmCryptLib.inf | 12 -
.../Library/BaseCryptLib/SmmCryptLib.uni | 2 -
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 22 +-
.../Library/Include/openssl/opensslconf.h | 328 +++++++-
.../Include/openssl/opensslconf_generated.h | 333 ---------
CryptoPkg/Library/OpensslLib/EcSm2Null.c | 291 ++++++++
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 133 ++--
CryptoPkg/Library/OpensslLib/OpensslLib.uni | 10 +-
...nsslLibIa32Gcc.inf => OpensslLibAccel.inf} | 189 +++--
.../Library/OpensslLib/OpensslLibAccel.uni | 14 +
.../OpensslLib/OpensslLibConstructor.c | 6 +-
.../Library/OpensslLib/OpensslLibCrypto.inf | 185 +++--
.../Library/OpensslLib/OpensslLibCrypto.uni | 11 +-
.../{OpensslLib.inf => OpensslLibFull.inf} | 143 ++--
.../{OpensslLib.uni => OpensslLibFull.uni} | 10 +-
...sslLibIa32.inf => OpensslLibFullAccel.inf} | 192 +++--
.../OpensslLib/OpensslLibFullAccel.uni | 14 +
.../Library/OpensslLib/OpensslLibX64.inf | 706 ------------------
.../Library/OpensslLib/OpensslLibX64Gcc.inf | 706 ------------------
CryptoPkg/Library/OpensslLib/SslNull.c | 405 ++++++++++
.../SysCall/inet_pton.c | 0
CryptoPkg/Library/TlsLib/TlsConfig.c | 2 +-
CryptoPkg/Library/TlsLib/TlsLib.inf | 12 +-
CryptoPkg/Private/Library/IntrinsicLib.h | 16 +
CryptoPkg/Private/Library/OpensslLib.h | 14 +
CryptoPkg/Readme.md | 498 ++++++++++++
CryptoPkg/Test/CryptoPkgHostUnitTest.dsc | 17 +-
.../UnitTest/Library/BaseCryptLib/HmacTests.c | 17 +-
.../UnitTest/Library/BaseCryptLib/TSTests.c | 2 +-
.../TestBaseCryptLibHostAccel.inf | 55 ++
48 files changed, 2667 insertions(+), 2434 deletions(-)
copy CryptoPkg/Library/BaseCryptLib/{SmmCryptLib.uni =>
SecCryptLib.uni} (74%)
delete mode 100644
CryptoPkg/Library/Include/openssl/opensslconf_generated.h
create mode 100644 CryptoPkg/Library/OpensslLib/EcSm2Null.c
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32Gcc.inf =>
OpensslLibAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibAccel.uni
copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf =>
OpensslLibFull.inf}
(80%)
copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni =>
OpensslLibFull.uni}
(56%)
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32.inf =>
OpensslLibFullAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.uni
delete mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibX64.inf
delete mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf
create mode 100644 CryptoPkg/Library/OpensslLib/SslNull.c
rename CryptoPkg/Library/{BaseCryptLib =>
TlsLib}/SysCall/inet_pton.c
(100%)
create mode 100644 CryptoPkg/Private/Library/IntrinsicLib.h
create mode 100644 CryptoPkg/Private/Library/OpensslLib.h
create mode 100644 CryptoPkg/Readme.md
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/TestBaseCryptLibHostAccel.i
nf

--
2.37.1.windows.1


Re: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Yao, Jiewen
 

I just remember we cannot use macro in BaseCryptoLib. Please ignore my comment on NO_EC macro.

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao,
Jiewen
Sent: Wednesday, October 12, 2022 10:07 AM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: Re: [edk2-devel] [Patch 00/12] CryptoPkg: Remove EC PCD and
merge perf opt OpensslLibs

OK. That means we need manual write a wrapper for all EC APIs in Openssl
Lib for internal usage.
More precisely, a wrapper for the delta between OpensslLib and
OpensslLibFull, right?

There will be size difference between those two solutions, because the code
other than EC will be include in the function.

Why not use NO_EC macro from openssl directly?

Thank you
Yao Jiewen


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:55 AM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca
Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Jiewen,

The BKM is to just call the EC services from the layers above OpensslLib.
The EC APIs will always be present. Either real EC service or Null EC
service.
This way we can remove all the #ifdef on EC PCD.

Platform developers select the OpensslLib instance with EC
(OpensslLibFull.inf) or
without EC (OpensslLib.inf).

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:37 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

Hi Mike
For PcdOpensslEcEnabled, I am seeing other usage. For example:
https://github.com/qizhangz/edk2/blob/EC_Upstream/CryptoPkg/Library/
BaseCryptLib/Pem/CryptPem.c#L156

I think we may need BKM on "how to disable EC".

Thank you
Yao, Jiewen


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:25 AM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io;
Kinney,
Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca
Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

Hi Jiewen,

Comments below.

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:09 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge
perf
opt
OpensslLibs

Thank you Mike.

1) I like the idea to combine multiple OpensslLibIA32/X64.inf into
one
OpensslLibAccel.inf.
Also the cleanup looks good to me.

2) I also like the summary in readme in
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg
I notice some algorithms are listed Y(Deprecated) but N(Don't Use),
such
as Tdes, Arc4, Aes.Ecb*.
But I don’t see the use case for those algorithms and I suggest a
Y(Deprecated) have Y(Don't Use).

Good catch. I will fix.


3) About PcdOpensslEcEnabled
I notice it is used in existing code -
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Library/TlsLib/TlsConfig.c#L11
39
Is this right way?
This was added since I started this work and was added back in by
rebase. I
will fix.
We can just remove the check for the PCD. If the OpensslLib instance
does
not include
SSL services, then the Null SSL services are present and the call to
SSL_ctrl()
will
return 0 which will force TlsSetEcCurve() to return EFI_UNSUPPORTED.
It
will also
ASSERT() informing the developer that a call to a service that depends
on
SSL was made
without SSL services available.

long
SSL_ctrl (
SSL *ssl,
int cmd,
long larg,
void *parg
)
{
ASSERT (FALSE);
return 0;
}

Likewise, if the OpensslLib instance does not support EC services, then
the
Null
EC services will be included and the call to
EC_KEY_new_by_curve_name()
will
return NULL which will force TlsSetEcCurve() to return
EFI_UNSUPPORTED. It
will also
ASSERT() informing the developer that a call to a service that depends
on EC
was made
without EC services available.

EC_KEY *
EC_KEY_new_by_curve_name (
int nid
)
{
ASSERT (FALSE);
return NULL;
}


Thank you
Yao, Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 11, 2022 11:04 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>;
Jiang,
Guomin <guomin.jiang@...>; Zurcher, Christopher
<christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

The recent addition of the Ecliptic Curve (EC) feature and the
performance
optimization features increased the complexity for platforms to
integrate
and enable these features. This series simplifies the platform
configuration
as much as possible and improves the ability to manage the the
size
impact
of cryptographic services in each FW phase. A Readme.md is also
added
that
provides an overview of the CryptoPkg design and features along
with
platform
integration recommendations.

This series also addresses private library class declarations missing
from
CryptoPkg.dec and library instances not producing all the APIs
defined
by the library classes. A review of the CryptoPkg EDK II meta data
files
identified
a number of additional cleanups. The CryptoPkg.dsc file was also
updated to
improve CI coverage for future CryptoPkg changes and identified
some
unit test bug fixes.

PR: https://github.com/tianocore/edk2/pull/3443
Branch:
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs
Readme:
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Readme.md

Change Summary
==============
* Document disabled/deprecated cryptographic services
* Add missing UNI files in BaseCryptLib
* Update BaseCryptLib internal functions to be STATIC and remove
EFIAPI
* Add GLOBAL_REMOVE_IF_UNREFERENCED to BaseCryptLib
global
variables
* Fix BaseCryptLib unit tests
* Cleanup BaseCryptLib and TlsLib INF files and
* Move SysCall/inet_pton.c from BaseCryptLib to TlsLib that uses
it.
* Merge 4 performance optimized INFs into OpensslLib*Accel.inf
* Remove use of PcdOpensslEcEnabled and use OpensslLibFull*.inf
instead
* Add OpensslLib and IntrinsicLib to CryptoPkg.dec as private
library
classes
* Update all OpensslLib instances to always produce all APIs in
OpensslLib
class
* Move PrintLib dependency from OpensslLib INF files to
BaseCryptLib
INF
files
* Update CryptoPkg.dsc files to provide full CI test coverage across
all
the
supported combinations of OpensslLib, BaseCryptLib, and TlsLib
instances.
* Remove PACKAGE profile from CryptoPkg.dsc and add
TARGET_UNIT_TESTS
profile. Adding TARGET_UNIT_TESTS profile is required to
prevent
a
few
unit
test artifacts being included in non unit test builds of
components.
* Add CryptoPkg Readme.md with overview and platform
integration
details.
* Update host-based unit tests to always use OpensslLibFull.inf
and
add
unit
test coverage for OpensslLibFullAccel.inf.
* Add Readme.md with CryptoPkg overview and platform
integration
documentation

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Cc: Christopher Zurcher <christopher.zurcher@...>
Cc: Rebecca Cran <quic_rcran@...>
Cc: Ard Biesheuvel <ardb@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>

Michael D Kinney (12):
CryptoPkg: Document and disable deprecated crypto services
CryptoPkg/Library/BaseCryptLib: Add missing UNI file and fix
format
CryptoPkg/Library/BaseCryptLib: Update internal
functions/variables
CryptoPkg/Test/UnitTest/Library/BaseCryptLib: Unit test fixes
CryptoPkg/Library: Cleanup BaseCryptLib and TlsLib
CryptoPkg/Library/OpensslLib: Combine all performance
optimized
INFs
CryptoPkg/Library/OpensslLib: Produce consistent set of APIs
CryptoPkg/Library/OpensslLib: Remove PrintLib from INF files
CryptoPkg: Remove PcdOpensslEcEnabled from CryptoPkg.dec
CryptoPkg: Update DSC to improve CI test coverage
CryptoPkg: Fixed host-based unit tests
CryptoPkg: Add Readme.md

CryptoPkg/CryptoPkg.ci.yaml | 11 +-
CryptoPkg/CryptoPkg.dec | 42 +-
CryptoPkg/CryptoPkg.dsc | 460 +++++++++---
.../Pcd/PcdCryptoServiceFamilyEnable.h | 122 +--
.../Library/BaseCryptLib/BaseCryptLib.inf | 10 +-
.../Library/BaseCryptLib/BaseCryptLib.uni | 2 -
.../Library/BaseCryptLib/Hmac/CryptHmac.c | 7 +
.../Library/BaseCryptLib/Kdf/CryptHkdf.c | 5 +-
.../Library/BaseCryptLib/PeiCryptLib.inf | 8 +-
.../Library/BaseCryptLib/PeiCryptLib.uni | 2 -
.../BaseCryptLib/Pk/CryptAuthenticode.c | 2 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c | 3 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyEku.c | 3 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 44 +-
.../Library/BaseCryptLib/RuntimeCryptLib.inf | 9 +-
.../Library/BaseCryptLib/RuntimeCryptLib.uni | 2 -
.../Library/BaseCryptLib/SecCryptLib.inf | 13 +-
.../{SmmCryptLib.uni => SecCryptLib.uni} | 11 +-
.../Library/BaseCryptLib/SmmCryptLib.inf | 12 -
.../Library/BaseCryptLib/SmmCryptLib.uni | 2 -
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 22 +-
.../Library/Include/openssl/opensslconf.h | 328 +++++++-
.../Include/openssl/opensslconf_generated.h | 333 ---------
CryptoPkg/Library/OpensslLib/EcSm2Null.c | 291 ++++++++
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 133 ++--
CryptoPkg/Library/OpensslLib/OpensslLib.uni | 10 +-
...nsslLibIa32Gcc.inf => OpensslLibAccel.inf} | 189 +++--
.../Library/OpensslLib/OpensslLibAccel.uni | 14 +
.../OpensslLib/OpensslLibConstructor.c | 6 +-
.../Library/OpensslLib/OpensslLibCrypto.inf | 185 +++--
.../Library/OpensslLib/OpensslLibCrypto.uni | 11 +-
.../{OpensslLib.inf => OpensslLibFull.inf} | 143 ++--
.../{OpensslLib.uni => OpensslLibFull.uni} | 10 +-
...sslLibIa32.inf => OpensslLibFullAccel.inf} | 192 +++--
.../OpensslLib/OpensslLibFullAccel.uni | 14 +
.../Library/OpensslLib/OpensslLibX64.inf | 706 ------------------
.../Library/OpensslLib/OpensslLibX64Gcc.inf | 706 ------------------
CryptoPkg/Library/OpensslLib/SslNull.c | 405 ++++++++++
.../SysCall/inet_pton.c | 0
CryptoPkg/Library/TlsLib/TlsConfig.c | 2 +-
CryptoPkg/Library/TlsLib/TlsLib.inf | 12 +-
CryptoPkg/Private/Library/IntrinsicLib.h | 16 +
CryptoPkg/Private/Library/OpensslLib.h | 14 +
CryptoPkg/Readme.md | 498 ++++++++++++
CryptoPkg/Test/CryptoPkgHostUnitTest.dsc | 17 +-
.../UnitTest/Library/BaseCryptLib/HmacTests.c | 17 +-
.../UnitTest/Library/BaseCryptLib/TSTests.c | 2 +-
.../TestBaseCryptLibHostAccel.inf | 55 ++
48 files changed, 2667 insertions(+), 2434 deletions(-)
copy CryptoPkg/Library/BaseCryptLib/{SmmCryptLib.uni =>
SecCryptLib.uni} (74%)
delete mode 100644
CryptoPkg/Library/Include/openssl/opensslconf_generated.h
create mode 100644 CryptoPkg/Library/OpensslLib/EcSm2Null.c
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32Gcc.inf =>
OpensslLibAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibAccel.uni
copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf =>
OpensslLibFull.inf}
(80%)
copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni =>
OpensslLibFull.uni}
(56%)
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32.inf =>
OpensslLibFullAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.uni
delete mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibX64.inf
delete mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf
create mode 100644 CryptoPkg/Library/OpensslLib/SslNull.c
rename CryptoPkg/Library/{BaseCryptLib =>
TlsLib}/SysCall/inet_pton.c
(100%)
create mode 100644 CryptoPkg/Private/Library/IntrinsicLib.h
create mode 100644 CryptoPkg/Private/Library/OpensslLib.h
create mode 100644 CryptoPkg/Readme.md
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/TestBaseCryptLibHostAccel.i
nf

--
2.37.1.windows.1




Re: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Yao, Jiewen
 

OK. That means we need manual write a wrapper for all EC APIs in Openssl Lib for internal usage.
More precisely, a wrapper for the delta between OpensslLib and OpensslLibFull, right?

There will be size difference between those two solutions, because the code other than EC will be include in the function.

Why not use NO_EC macro from openssl directly?

Thank you
Yao Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:55 AM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Jiewen,

The BKM is to just call the EC services from the layers above OpensslLib.
The EC APIs will always be present. Either real EC service or Null EC service.
This way we can remove all the #ifdef on EC PCD.

Platform developers select the OpensslLib instance with EC
(OpensslLibFull.inf) or
without EC (OpensslLib.inf).

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:37 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Hi Mike
For PcdOpensslEcEnabled, I am seeing other usage. For example:
https://github.com/qizhangz/edk2/blob/EC_Upstream/CryptoPkg/Library/
BaseCryptLib/Pem/CryptPem.c#L156

I think we may need BKM on "how to disable EC".

Thank you
Yao, Jiewen


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:25 AM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca
Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

Hi Jiewen,

Comments below.

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:09 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

Thank you Mike.

1) I like the idea to combine multiple OpensslLibIA32/X64.inf into one
OpensslLibAccel.inf.
Also the cleanup looks good to me.

2) I also like the summary in readme in
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg
I notice some algorithms are listed Y(Deprecated) but N(Don't Use),
such
as Tdes, Arc4, Aes.Ecb*.
But I don’t see the use case for those algorithms and I suggest a
Y(Deprecated) have Y(Don't Use).

Good catch. I will fix.


3) About PcdOpensslEcEnabled
I notice it is used in existing code -
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Library/TlsLib/TlsConfig.c#L11
39
Is this right way?
This was added since I started this work and was added back in by
rebase. I
will fix.
We can just remove the check for the PCD. If the OpensslLib instance
does
not include
SSL services, then the Null SSL services are present and the call to
SSL_ctrl()
will
return 0 which will force TlsSetEcCurve() to return EFI_UNSUPPORTED.
It
will also
ASSERT() informing the developer that a call to a service that depends
on
SSL was made
without SSL services available.

long
SSL_ctrl (
SSL *ssl,
int cmd,
long larg,
void *parg
)
{
ASSERT (FALSE);
return 0;
}

Likewise, if the OpensslLib instance does not support EC services, then
the
Null
EC services will be included and the call to
EC_KEY_new_by_curve_name()
will
return NULL which will force TlsSetEcCurve() to return
EFI_UNSUPPORTED. It
will also
ASSERT() informing the developer that a call to a service that depends
on EC
was made
without EC services available.

EC_KEY *
EC_KEY_new_by_curve_name (
int nid
)
{
ASSERT (FALSE);
return NULL;
}


Thank you
Yao, Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 11, 2022 11:04 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang,
Guomin <guomin.jiang@...>; Zurcher, Christopher
<christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf
opt
OpensslLibs

The recent addition of the Ecliptic Curve (EC) feature and the
performance
optimization features increased the complexity for platforms to
integrate
and enable these features. This series simplifies the platform
configuration
as much as possible and improves the ability to manage the the size
impact
of cryptographic services in each FW phase. A Readme.md is also
added
that
provides an overview of the CryptoPkg design and features along
with
platform
integration recommendations.

This series also addresses private library class declarations missing
from
CryptoPkg.dec and library instances not producing all the APIs
defined
by the library classes. A review of the CryptoPkg EDK II meta data
files
identified
a number of additional cleanups. The CryptoPkg.dsc file was also
updated to
improve CI coverage for future CryptoPkg changes and identified
some
unit test bug fixes.

PR: https://github.com/tianocore/edk2/pull/3443
Branch:
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs
Readme:
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Readme.md

Change Summary
==============
* Document disabled/deprecated cryptographic services
* Add missing UNI files in BaseCryptLib
* Update BaseCryptLib internal functions to be STATIC and remove
EFIAPI
* Add GLOBAL_REMOVE_IF_UNREFERENCED to BaseCryptLib global
variables
* Fix BaseCryptLib unit tests
* Cleanup BaseCryptLib and TlsLib INF files and
* Move SysCall/inet_pton.c from BaseCryptLib to TlsLib that uses it.
* Merge 4 performance optimized INFs into OpensslLib*Accel.inf
* Remove use of PcdOpensslEcEnabled and use OpensslLibFull*.inf
instead
* Add OpensslLib and IntrinsicLib to CryptoPkg.dec as private library
classes
* Update all OpensslLib instances to always produce all APIs in
OpensslLib
class
* Move PrintLib dependency from OpensslLib INF files to
BaseCryptLib
INF
files
* Update CryptoPkg.dsc files to provide full CI test coverage across
all
the
supported combinations of OpensslLib, BaseCryptLib, and TlsLib
instances.
* Remove PACKAGE profile from CryptoPkg.dsc and add
TARGET_UNIT_TESTS
profile. Adding TARGET_UNIT_TESTS profile is required to prevent
a
few
unit
test artifacts being included in non unit test builds of components.
* Add CryptoPkg Readme.md with overview and platform
integration
details.
* Update host-based unit tests to always use OpensslLibFull.inf and
add
unit
test coverage for OpensslLibFullAccel.inf.
* Add Readme.md with CryptoPkg overview and platform
integration
documentation

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Cc: Christopher Zurcher <christopher.zurcher@...>
Cc: Rebecca Cran <quic_rcran@...>
Cc: Ard Biesheuvel <ardb@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>

Michael D Kinney (12):
CryptoPkg: Document and disable deprecated crypto services
CryptoPkg/Library/BaseCryptLib: Add missing UNI file and fix
format
CryptoPkg/Library/BaseCryptLib: Update internal
functions/variables
CryptoPkg/Test/UnitTest/Library/BaseCryptLib: Unit test fixes
CryptoPkg/Library: Cleanup BaseCryptLib and TlsLib
CryptoPkg/Library/OpensslLib: Combine all performance optimized
INFs
CryptoPkg/Library/OpensslLib: Produce consistent set of APIs
CryptoPkg/Library/OpensslLib: Remove PrintLib from INF files
CryptoPkg: Remove PcdOpensslEcEnabled from CryptoPkg.dec
CryptoPkg: Update DSC to improve CI test coverage
CryptoPkg: Fixed host-based unit tests
CryptoPkg: Add Readme.md

CryptoPkg/CryptoPkg.ci.yaml | 11 +-
CryptoPkg/CryptoPkg.dec | 42 +-
CryptoPkg/CryptoPkg.dsc | 460 +++++++++---
.../Pcd/PcdCryptoServiceFamilyEnable.h | 122 +--
.../Library/BaseCryptLib/BaseCryptLib.inf | 10 +-
.../Library/BaseCryptLib/BaseCryptLib.uni | 2 -
.../Library/BaseCryptLib/Hmac/CryptHmac.c | 7 +
.../Library/BaseCryptLib/Kdf/CryptHkdf.c | 5 +-
.../Library/BaseCryptLib/PeiCryptLib.inf | 8 +-
.../Library/BaseCryptLib/PeiCryptLib.uni | 2 -
.../BaseCryptLib/Pk/CryptAuthenticode.c | 2 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c | 3 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyEku.c | 3 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 44 +-
.../Library/BaseCryptLib/RuntimeCryptLib.inf | 9 +-
.../Library/BaseCryptLib/RuntimeCryptLib.uni | 2 -
.../Library/BaseCryptLib/SecCryptLib.inf | 13 +-
.../{SmmCryptLib.uni => SecCryptLib.uni} | 11 +-
.../Library/BaseCryptLib/SmmCryptLib.inf | 12 -
.../Library/BaseCryptLib/SmmCryptLib.uni | 2 -
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 22 +-
.../Library/Include/openssl/opensslconf.h | 328 +++++++-
.../Include/openssl/opensslconf_generated.h | 333 ---------
CryptoPkg/Library/OpensslLib/EcSm2Null.c | 291 ++++++++
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 133 ++--
CryptoPkg/Library/OpensslLib/OpensslLib.uni | 10 +-
...nsslLibIa32Gcc.inf => OpensslLibAccel.inf} | 189 +++--
.../Library/OpensslLib/OpensslLibAccel.uni | 14 +
.../OpensslLib/OpensslLibConstructor.c | 6 +-
.../Library/OpensslLib/OpensslLibCrypto.inf | 185 +++--
.../Library/OpensslLib/OpensslLibCrypto.uni | 11 +-
.../{OpensslLib.inf => OpensslLibFull.inf} | 143 ++--
.../{OpensslLib.uni => OpensslLibFull.uni} | 10 +-
...sslLibIa32.inf => OpensslLibFullAccel.inf} | 192 +++--
.../OpensslLib/OpensslLibFullAccel.uni | 14 +
.../Library/OpensslLib/OpensslLibX64.inf | 706 ------------------
.../Library/OpensslLib/OpensslLibX64Gcc.inf | 706 ------------------
CryptoPkg/Library/OpensslLib/SslNull.c | 405 ++++++++++
.../SysCall/inet_pton.c | 0
CryptoPkg/Library/TlsLib/TlsConfig.c | 2 +-
CryptoPkg/Library/TlsLib/TlsLib.inf | 12 +-
CryptoPkg/Private/Library/IntrinsicLib.h | 16 +
CryptoPkg/Private/Library/OpensslLib.h | 14 +
CryptoPkg/Readme.md | 498 ++++++++++++
CryptoPkg/Test/CryptoPkgHostUnitTest.dsc | 17 +-
.../UnitTest/Library/BaseCryptLib/HmacTests.c | 17 +-
.../UnitTest/Library/BaseCryptLib/TSTests.c | 2 +-
.../TestBaseCryptLibHostAccel.inf | 55 ++
48 files changed, 2667 insertions(+), 2434 deletions(-)
copy CryptoPkg/Library/BaseCryptLib/{SmmCryptLib.uni =>
SecCryptLib.uni} (74%)
delete mode 100644
CryptoPkg/Library/Include/openssl/opensslconf_generated.h
create mode 100644 CryptoPkg/Library/OpensslLib/EcSm2Null.c
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32Gcc.inf =>
OpensslLibAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibAccel.uni
copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf =>
OpensslLibFull.inf}
(80%)
copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni =>
OpensslLibFull.uni}
(56%)
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32.inf =>
OpensslLibFullAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.uni
delete mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibX64.inf
delete mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf
create mode 100644 CryptoPkg/Library/OpensslLib/SslNull.c
rename CryptoPkg/Library/{BaseCryptLib =>
TlsLib}/SysCall/inet_pton.c
(100%)
create mode 100644 CryptoPkg/Private/Library/IntrinsicLib.h
create mode 100644 CryptoPkg/Private/Library/OpensslLib.h
create mode 100644 CryptoPkg/Readme.md
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/TestBaseCryptLibHostAccel.i
nf

--
2.37.1.windows.1


Re: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Michael D Kinney
 

Jiewen,

The BKM is to just call the EC services from the layers above OpensslLib.
The EC APIs will always be present. Either real EC service or Null EC service.
This way we can remove all the #ifdef on EC PCD.

Platform developers select the OpensslLib instance with EC (OpensslLibFull.inf) or
without EC (OpensslLib.inf).

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:37 PM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>; Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran <quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Hi Mike
For PcdOpensslEcEnabled, I am seeing other usage. For example:
https://github.com/qizhangz/edk2/blob/EC_Upstream/CryptoPkg/Library/BaseCryptLib/Pem/CryptPem.c#L156

I think we may need BKM on "how to disable EC".

Thank you
Yao, Jiewen


-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:25 AM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Hi Jiewen,

Comments below.

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:09 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Thank you Mike.

1) I like the idea to combine multiple OpensslLibIA32/X64.inf into one
OpensslLibAccel.inf.
Also the cleanup looks good to me.

2) I also like the summary in readme in
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg
I notice some algorithms are listed Y(Deprecated) but N(Don't Use), such
as Tdes, Arc4, Aes.Ecb*.
But I don’t see the use case for those algorithms and I suggest a
Y(Deprecated) have Y(Don't Use).

Good catch. I will fix.


3) About PcdOpensslEcEnabled
I notice it is used in existing code -
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Library/TlsLib/TlsConfig.c#L11
39
Is this right way?
This was added since I started this work and was added back in by rebase. I
will fix.
We can just remove the check for the PCD. If the OpensslLib instance does
not include
SSL services, then the Null SSL services are present and the call to SSL_ctrl()
will
return 0 which will force TlsSetEcCurve() to return EFI_UNSUPPORTED. It
will also
ASSERT() informing the developer that a call to a service that depends on
SSL was made
without SSL services available.

long
SSL_ctrl (
SSL *ssl,
int cmd,
long larg,
void *parg
)
{
ASSERT (FALSE);
return 0;
}

Likewise, if the OpensslLib instance does not support EC services, then the
Null
EC services will be included and the call to EC_KEY_new_by_curve_name()
will
return NULL which will force TlsSetEcCurve() to return EFI_UNSUPPORTED. It
will also
ASSERT() informing the developer that a call to a service that depends on EC
was made
without EC services available.

EC_KEY *
EC_KEY_new_by_curve_name (
int nid
)
{
ASSERT (FALSE);
return NULL;
}


Thank you
Yao, Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 11, 2022 11:04 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang,
Guomin <guomin.jiang@...>; Zurcher, Christopher
<christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

The recent addition of the Ecliptic Curve (EC) feature and the
performance
optimization features increased the complexity for platforms to
integrate
and enable these features. This series simplifies the platform
configuration
as much as possible and improves the ability to manage the the size
impact
of cryptographic services in each FW phase. A Readme.md is also added
that
provides an overview of the CryptoPkg design and features along with
platform
integration recommendations.

This series also addresses private library class declarations missing from
CryptoPkg.dec and library instances not producing all the APIs defined
by the library classes. A review of the CryptoPkg EDK II meta data files
identified
a number of additional cleanups. The CryptoPkg.dsc file was also
updated to
improve CI coverage for future CryptoPkg changes and identified some
unit test bug fixes.

PR: https://github.com/tianocore/edk2/pull/3443
Branch:
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs
Readme:
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Readme.md

Change Summary
==============
* Document disabled/deprecated cryptographic services
* Add missing UNI files in BaseCryptLib
* Update BaseCryptLib internal functions to be STATIC and remove
EFIAPI
* Add GLOBAL_REMOVE_IF_UNREFERENCED to BaseCryptLib global
variables
* Fix BaseCryptLib unit tests
* Cleanup BaseCryptLib and TlsLib INF files and
* Move SysCall/inet_pton.c from BaseCryptLib to TlsLib that uses it.
* Merge 4 performance optimized INFs into OpensslLib*Accel.inf
* Remove use of PcdOpensslEcEnabled and use OpensslLibFull*.inf
instead
* Add OpensslLib and IntrinsicLib to CryptoPkg.dec as private library
classes
* Update all OpensslLib instances to always produce all APIs in
OpensslLib
class
* Move PrintLib dependency from OpensslLib INF files to BaseCryptLib
INF
files
* Update CryptoPkg.dsc files to provide full CI test coverage across all
the
supported combinations of OpensslLib, BaseCryptLib, and TlsLib
instances.
* Remove PACKAGE profile from CryptoPkg.dsc and add
TARGET_UNIT_TESTS
profile. Adding TARGET_UNIT_TESTS profile is required to prevent a
few
unit
test artifacts being included in non unit test builds of components.
* Add CryptoPkg Readme.md with overview and platform integration
details.
* Update host-based unit tests to always use OpensslLibFull.inf and add
unit
test coverage for OpensslLibFullAccel.inf.
* Add Readme.md with CryptoPkg overview and platform integration
documentation

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Cc: Christopher Zurcher <christopher.zurcher@...>
Cc: Rebecca Cran <quic_rcran@...>
Cc: Ard Biesheuvel <ardb@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>

Michael D Kinney (12):
CryptoPkg: Document and disable deprecated crypto services
CryptoPkg/Library/BaseCryptLib: Add missing UNI file and fix format
CryptoPkg/Library/BaseCryptLib: Update internal functions/variables
CryptoPkg/Test/UnitTest/Library/BaseCryptLib: Unit test fixes
CryptoPkg/Library: Cleanup BaseCryptLib and TlsLib
CryptoPkg/Library/OpensslLib: Combine all performance optimized
INFs
CryptoPkg/Library/OpensslLib: Produce consistent set of APIs
CryptoPkg/Library/OpensslLib: Remove PrintLib from INF files
CryptoPkg: Remove PcdOpensslEcEnabled from CryptoPkg.dec
CryptoPkg: Update DSC to improve CI test coverage
CryptoPkg: Fixed host-based unit tests
CryptoPkg: Add Readme.md

CryptoPkg/CryptoPkg.ci.yaml | 11 +-
CryptoPkg/CryptoPkg.dec | 42 +-
CryptoPkg/CryptoPkg.dsc | 460 +++++++++---
.../Pcd/PcdCryptoServiceFamilyEnable.h | 122 +--
.../Library/BaseCryptLib/BaseCryptLib.inf | 10 +-
.../Library/BaseCryptLib/BaseCryptLib.uni | 2 -
.../Library/BaseCryptLib/Hmac/CryptHmac.c | 7 +
.../Library/BaseCryptLib/Kdf/CryptHkdf.c | 5 +-
.../Library/BaseCryptLib/PeiCryptLib.inf | 8 +-
.../Library/BaseCryptLib/PeiCryptLib.uni | 2 -
.../BaseCryptLib/Pk/CryptAuthenticode.c | 2 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c | 3 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyEku.c | 3 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 44 +-
.../Library/BaseCryptLib/RuntimeCryptLib.inf | 9 +-
.../Library/BaseCryptLib/RuntimeCryptLib.uni | 2 -
.../Library/BaseCryptLib/SecCryptLib.inf | 13 +-
.../{SmmCryptLib.uni => SecCryptLib.uni} | 11 +-
.../Library/BaseCryptLib/SmmCryptLib.inf | 12 -
.../Library/BaseCryptLib/SmmCryptLib.uni | 2 -
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 22 +-
.../Library/Include/openssl/opensslconf.h | 328 +++++++-
.../Include/openssl/opensslconf_generated.h | 333 ---------
CryptoPkg/Library/OpensslLib/EcSm2Null.c | 291 ++++++++
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 133 ++--
CryptoPkg/Library/OpensslLib/OpensslLib.uni | 10 +-
...nsslLibIa32Gcc.inf => OpensslLibAccel.inf} | 189 +++--
.../Library/OpensslLib/OpensslLibAccel.uni | 14 +
.../OpensslLib/OpensslLibConstructor.c | 6 +-
.../Library/OpensslLib/OpensslLibCrypto.inf | 185 +++--
.../Library/OpensslLib/OpensslLibCrypto.uni | 11 +-
.../{OpensslLib.inf => OpensslLibFull.inf} | 143 ++--
.../{OpensslLib.uni => OpensslLibFull.uni} | 10 +-
...sslLibIa32.inf => OpensslLibFullAccel.inf} | 192 +++--
.../OpensslLib/OpensslLibFullAccel.uni | 14 +
.../Library/OpensslLib/OpensslLibX64.inf | 706 ------------------
.../Library/OpensslLib/OpensslLibX64Gcc.inf | 706 ------------------
CryptoPkg/Library/OpensslLib/SslNull.c | 405 ++++++++++
.../SysCall/inet_pton.c | 0
CryptoPkg/Library/TlsLib/TlsConfig.c | 2 +-
CryptoPkg/Library/TlsLib/TlsLib.inf | 12 +-
CryptoPkg/Private/Library/IntrinsicLib.h | 16 +
CryptoPkg/Private/Library/OpensslLib.h | 14 +
CryptoPkg/Readme.md | 498 ++++++++++++
CryptoPkg/Test/CryptoPkgHostUnitTest.dsc | 17 +-
.../UnitTest/Library/BaseCryptLib/HmacTests.c | 17 +-
.../UnitTest/Library/BaseCryptLib/TSTests.c | 2 +-
.../TestBaseCryptLibHostAccel.inf | 55 ++
48 files changed, 2667 insertions(+), 2434 deletions(-)
copy CryptoPkg/Library/BaseCryptLib/{SmmCryptLib.uni =>
SecCryptLib.uni} (74%)
delete mode 100644
CryptoPkg/Library/Include/openssl/opensslconf_generated.h
create mode 100644 CryptoPkg/Library/OpensslLib/EcSm2Null.c
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32Gcc.inf =>
OpensslLibAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibAccel.uni
copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf =>
OpensslLibFull.inf}
(80%)
copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni =>
OpensslLibFull.uni}
(56%)
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32.inf =>
OpensslLibFullAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.uni
delete mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibX64.inf
delete mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf
create mode 100644 CryptoPkg/Library/OpensslLib/SslNull.c
rename CryptoPkg/Library/{BaseCryptLib => TlsLib}/SysCall/inet_pton.c
(100%)
create mode 100644 CryptoPkg/Private/Library/IntrinsicLib.h
create mode 100644 CryptoPkg/Private/Library/OpensslLib.h
create mode 100644 CryptoPkg/Readme.md
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/TestBaseCryptLibHostAccel.i
nf

--
2.37.1.windows.1


Re: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Yao, Jiewen
 

Hi Mike
For PcdOpensslEcEnabled, I am seeing other usage. For example:
https://github.com/qizhangz/edk2/blob/EC_Upstream/CryptoPkg/Library/BaseCryptLib/Pem/CryptPem.c#L156

I think we may need BKM on "how to disable EC".

Thank you
Yao, Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:25 AM
To: Yao, Jiewen <jiewen.yao@...>; devel@edk2.groups.io; Kinney,
Michael D <michael.d.kinney@...>
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher, Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Hi Jiewen,

Comments below.

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:09 PM
To: Kinney, Michael D <michael.d.kinney@...>;
devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>;
Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

Thank you Mike.

1) I like the idea to combine multiple OpensslLibIA32/X64.inf into one
OpensslLibAccel.inf.
Also the cleanup looks good to me.

2) I also like the summary in readme in
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg
I notice some algorithms are listed Y(Deprecated) but N(Don't Use), such
as Tdes, Arc4, Aes.Ecb*.
But I don’t see the use case for those algorithms and I suggest a
Y(Deprecated) have Y(Don't Use).

Good catch. I will fix.


3) About PcdOpensslEcEnabled
I notice it is used in existing code -
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Library/TlsLib/TlsConfig.c#L11
39
Is this right way?
This was added since I started this work and was added back in by rebase. I
will fix.
We can just remove the check for the PCD. If the OpensslLib instance does
not include
SSL services, then the Null SSL services are present and the call to SSL_ctrl()
will
return 0 which will force TlsSetEcCurve() to return EFI_UNSUPPORTED. It
will also
ASSERT() informing the developer that a call to a service that depends on
SSL was made
without SSL services available.

long
SSL_ctrl (
SSL *ssl,
int cmd,
long larg,
void *parg
)
{
ASSERT (FALSE);
return 0;
}

Likewise, if the OpensslLib instance does not support EC services, then the
Null
EC services will be included and the call to EC_KEY_new_by_curve_name()
will
return NULL which will force TlsSetEcCurve() to return EFI_UNSUPPORTED. It
will also
ASSERT() informing the developer that a call to a service that depends on EC
was made
without EC services available.

EC_KEY *
EC_KEY_new_by_curve_name (
int nid
)
{
ASSERT (FALSE);
return NULL;
}


Thank you
Yao, Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 11, 2022 11:04 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang,
Guomin <guomin.jiang@...>; Zurcher, Christopher
<christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

The recent addition of the Ecliptic Curve (EC) feature and the
performance
optimization features increased the complexity for platforms to
integrate
and enable these features. This series simplifies the platform
configuration
as much as possible and improves the ability to manage the the size
impact
of cryptographic services in each FW phase. A Readme.md is also added
that
provides an overview of the CryptoPkg design and features along with
platform
integration recommendations.

This series also addresses private library class declarations missing from
CryptoPkg.dec and library instances not producing all the APIs defined
by the library classes. A review of the CryptoPkg EDK II meta data files
identified
a number of additional cleanups. The CryptoPkg.dsc file was also
updated to
improve CI coverage for future CryptoPkg changes and identified some
unit test bug fixes.

PR: https://github.com/tianocore/edk2/pull/3443
Branch:
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs
Readme:
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Readme.md

Change Summary
==============
* Document disabled/deprecated cryptographic services
* Add missing UNI files in BaseCryptLib
* Update BaseCryptLib internal functions to be STATIC and remove
EFIAPI
* Add GLOBAL_REMOVE_IF_UNREFERENCED to BaseCryptLib global
variables
* Fix BaseCryptLib unit tests
* Cleanup BaseCryptLib and TlsLib INF files and
* Move SysCall/inet_pton.c from BaseCryptLib to TlsLib that uses it.
* Merge 4 performance optimized INFs into OpensslLib*Accel.inf
* Remove use of PcdOpensslEcEnabled and use OpensslLibFull*.inf
instead
* Add OpensslLib and IntrinsicLib to CryptoPkg.dec as private library
classes
* Update all OpensslLib instances to always produce all APIs in
OpensslLib
class
* Move PrintLib dependency from OpensslLib INF files to BaseCryptLib
INF
files
* Update CryptoPkg.dsc files to provide full CI test coverage across all
the
supported combinations of OpensslLib, BaseCryptLib, and TlsLib
instances.
* Remove PACKAGE profile from CryptoPkg.dsc and add
TARGET_UNIT_TESTS
profile. Adding TARGET_UNIT_TESTS profile is required to prevent a
few
unit
test artifacts being included in non unit test builds of components.
* Add CryptoPkg Readme.md with overview and platform integration
details.
* Update host-based unit tests to always use OpensslLibFull.inf and add
unit
test coverage for OpensslLibFullAccel.inf.
* Add Readme.md with CryptoPkg overview and platform integration
documentation

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Cc: Christopher Zurcher <christopher.zurcher@...>
Cc: Rebecca Cran <quic_rcran@...>
Cc: Ard Biesheuvel <ardb@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>

Michael D Kinney (12):
CryptoPkg: Document and disable deprecated crypto services
CryptoPkg/Library/BaseCryptLib: Add missing UNI file and fix format
CryptoPkg/Library/BaseCryptLib: Update internal functions/variables
CryptoPkg/Test/UnitTest/Library/BaseCryptLib: Unit test fixes
CryptoPkg/Library: Cleanup BaseCryptLib and TlsLib
CryptoPkg/Library/OpensslLib: Combine all performance optimized
INFs
CryptoPkg/Library/OpensslLib: Produce consistent set of APIs
CryptoPkg/Library/OpensslLib: Remove PrintLib from INF files
CryptoPkg: Remove PcdOpensslEcEnabled from CryptoPkg.dec
CryptoPkg: Update DSC to improve CI test coverage
CryptoPkg: Fixed host-based unit tests
CryptoPkg: Add Readme.md

CryptoPkg/CryptoPkg.ci.yaml | 11 +-
CryptoPkg/CryptoPkg.dec | 42 +-
CryptoPkg/CryptoPkg.dsc | 460 +++++++++---
.../Pcd/PcdCryptoServiceFamilyEnable.h | 122 +--
.../Library/BaseCryptLib/BaseCryptLib.inf | 10 +-
.../Library/BaseCryptLib/BaseCryptLib.uni | 2 -
.../Library/BaseCryptLib/Hmac/CryptHmac.c | 7 +
.../Library/BaseCryptLib/Kdf/CryptHkdf.c | 5 +-
.../Library/BaseCryptLib/PeiCryptLib.inf | 8 +-
.../Library/BaseCryptLib/PeiCryptLib.uni | 2 -
.../BaseCryptLib/Pk/CryptAuthenticode.c | 2 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c | 3 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyEku.c | 3 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 44 +-
.../Library/BaseCryptLib/RuntimeCryptLib.inf | 9 +-
.../Library/BaseCryptLib/RuntimeCryptLib.uni | 2 -
.../Library/BaseCryptLib/SecCryptLib.inf | 13 +-
.../{SmmCryptLib.uni => SecCryptLib.uni} | 11 +-
.../Library/BaseCryptLib/SmmCryptLib.inf | 12 -
.../Library/BaseCryptLib/SmmCryptLib.uni | 2 -
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 22 +-
.../Library/Include/openssl/opensslconf.h | 328 +++++++-
.../Include/openssl/opensslconf_generated.h | 333 ---------
CryptoPkg/Library/OpensslLib/EcSm2Null.c | 291 ++++++++
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 133 ++--
CryptoPkg/Library/OpensslLib/OpensslLib.uni | 10 +-
...nsslLibIa32Gcc.inf => OpensslLibAccel.inf} | 189 +++--
.../Library/OpensslLib/OpensslLibAccel.uni | 14 +
.../OpensslLib/OpensslLibConstructor.c | 6 +-
.../Library/OpensslLib/OpensslLibCrypto.inf | 185 +++--
.../Library/OpensslLib/OpensslLibCrypto.uni | 11 +-
.../{OpensslLib.inf => OpensslLibFull.inf} | 143 ++--
.../{OpensslLib.uni => OpensslLibFull.uni} | 10 +-
...sslLibIa32.inf => OpensslLibFullAccel.inf} | 192 +++--
.../OpensslLib/OpensslLibFullAccel.uni | 14 +
.../Library/OpensslLib/OpensslLibX64.inf | 706 ------------------
.../Library/OpensslLib/OpensslLibX64Gcc.inf | 706 ------------------
CryptoPkg/Library/OpensslLib/SslNull.c | 405 ++++++++++
.../SysCall/inet_pton.c | 0
CryptoPkg/Library/TlsLib/TlsConfig.c | 2 +-
CryptoPkg/Library/TlsLib/TlsLib.inf | 12 +-
CryptoPkg/Private/Library/IntrinsicLib.h | 16 +
CryptoPkg/Private/Library/OpensslLib.h | 14 +
CryptoPkg/Readme.md | 498 ++++++++++++
CryptoPkg/Test/CryptoPkgHostUnitTest.dsc | 17 +-
.../UnitTest/Library/BaseCryptLib/HmacTests.c | 17 +-
.../UnitTest/Library/BaseCryptLib/TSTests.c | 2 +-
.../TestBaseCryptLibHostAccel.inf | 55 ++
48 files changed, 2667 insertions(+), 2434 deletions(-)
copy CryptoPkg/Library/BaseCryptLib/{SmmCryptLib.uni =>
SecCryptLib.uni} (74%)
delete mode 100644
CryptoPkg/Library/Include/openssl/opensslconf_generated.h
create mode 100644 CryptoPkg/Library/OpensslLib/EcSm2Null.c
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32Gcc.inf =>
OpensslLibAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibAccel.uni
copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf =>
OpensslLibFull.inf}
(80%)
copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni =>
OpensslLibFull.uni}
(56%)
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32.inf =>
OpensslLibFullAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.uni
delete mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibX64.inf
delete mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf
create mode 100644 CryptoPkg/Library/OpensslLib/SslNull.c
rename CryptoPkg/Library/{BaseCryptLib => TlsLib}/SysCall/inet_pton.c
(100%)
create mode 100644 CryptoPkg/Private/Library/IntrinsicLib.h
create mode 100644 CryptoPkg/Private/Library/OpensslLib.h
create mode 100644 CryptoPkg/Readme.md
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/TestBaseCryptLibHostAccel.i
nf

--
2.37.1.windows.1


Re: [edk2-platforms][PATCH V1 0/2] Platforms/Intel: Build fixes

Isaac Oram
 

Pushed as 07d0c989089f94133e7b71e38c18d206134863e7

-----Original Message-----
From: Desimone, Nathaniel L <nathaniel.l.desimone@...>
Sent: Tuesday, October 11, 2022 4:40 PM
To: Oram, Isaac W <isaac.w.oram@...>; devel@edk2.groups.io
Cc: Chaganty, Rangasai V <rangasai.v.chaganty@...>; Gao, Liming <gaoliming@...>; Chiu, Chasel <chasel.chiu@...>; Dong, Eric <eric.dong@...>; Benjamin Doron <benjamin.doron00@...>
Subject: RE: [edk2-devel][edk2-platforms][PATCH V1 0/2] Platforms/Intel: Build fixes

For the series...

Reviewed-by: Nate DeSimone <nathaniel.l.desimone@...>

-----Original Message-----
From: Oram, Isaac W <isaac.w.oram@...>
Sent: Wednesday, September 14, 2022 11:40 AM
To: devel@edk2.groups.io
Cc: Oram, Isaac W <isaac.w.oram@...>; Chaganty, Rangasai V <rangasai.v.chaganty@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Gao, Liming <gaoliming@...>; Chiu, Chasel <chasel.chiu@...>; Dong, Eric <eric.dong@...>; Benjamin Doron <benjamin.doron00@...>
Subject: [edk2-devel][edk2-platforms][PATCH V1 0/2] Platforms/Intel: Build fixes

The S3FeaturePkg changes in
[edk2-platforms][PATCH v3 2/4] S3FeaturePkg: Implement working S3 resume

Introduces some build issues with standalone package build for S3FeaturePkg and AdvancedFeaturePkg. There are also some type cast related compiler warnings.

We do not currently have continuous integration testing.
We do not currently have documented build testing configuration requirements.
Therefore I am just fixing the minor issues and intend to merge both patch series together to maintain git bisect to the best of my ability.
I do plan to document required and recommended board port and feature pkg builds.

Note that the use of UINTN for intermediate data instead of EFI_PHYSICAL_ADDRESS is only to be consistent with other ACPI implementations of similar functionality.

Cc: Sai Chaganty <rangasai.v.chaganty@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Liming Gao <gaoliming@...>
Cc: Chasel Chiu <chasel.chiu@...>
Cc: Eric Dong <eric.dong@...>
Cc: Benjamin Doron <benjamin.doron00@...>
Signed-off-by: Isaac Oram <isaac.w.oram@...>

Isaac Oram (2):
S3FeaturePkg/Build: Add libraries needed by S3FeaturePkg
MinPlatformPkg/S3: Use EFI_PHYSICAL_ADDRESS for address

.../Intel/AdvancedFeaturePkg/AdvancedFeaturePkg.dsc | 3 +++
.../Intel/PowerManagement/S3FeaturePkg/S3Dxe/S3Dxe.c | 10 +++++-----
.../PowerManagement/S3FeaturePkg/S3FeaturePkg.dsc | 3 +++
.../Intel/PowerManagement/S3FeaturePkg/S3Pei/S3Pei.c | 2 +-
.../Intel/MinPlatformPkg/Include/AcpiS3MemoryNvData.h | 4 ++--
5 files changed, 14 insertions(+), 8 deletions(-)

--
2.36.1.windows.1


Re: [edk2-platforms][PATCH v3 0/4] Implement S3 resume

Isaac Oram
 

Pushed as ee8d078e39..4d99e03828

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Isaac Oram
Sent: Tuesday, October 11, 2022 6:31 PM
To: Benjamin Doron <benjamin.doron00@...>; devel@edk2.groups.io
Cc: Chaganty, Rangasai V <rangasai.v.chaganty@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Sinha, Ankit <ankit.sinha@...>; Chiu, Chasel <chasel.chiu@...>; Gao, Liming <gaoliming@...>; Dong, Eric <eric.dong@...>; Soller, Jeremy <jeremy@...>
Subject: Re: [edk2-devel] [edk2-platforms][PATCH v3 0/4] Implement S3 resume

Series Reviewed-by: Isaac Oram <Isaac.w.oram@...>

-----Original Message-----
From: Benjamin Doron <benjamin.doron00@...>
Sent: Monday, September 12, 2022 10:13 AM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V <rangasai.v.chaganty@...>; Oram, Isaac W <isaac.w.oram@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Sinha, Ankit <ankit.sinha@...>; Chiu, Chasel <chasel.chiu@...>; Gao, Liming <gaoliming@...>; Dong, Eric <eric.dong@...>; Soller, Jeremy <jeremy@...>
Subject: [edk2-platforms][PATCH v3 0/4] Implement S3 resume

MinPlatform is an open-source EDK2 firmware project that can boot some mainstream boards. However, it lacked working support for S3 resume, an important feature for mobile platforms, which means that its applicability as-is to mainstream use is limited. Therefore, I have now implemented working S3 resume support on MinPlatform. This patch series comprises a majority of one of my work products for GSoC 2022.

The BootScript-related modules are EDK2 open-source and fairly straightforward to include. However, the partial dependency PiSmmCommunicationPei (for signalling SMM) creates a dependency on both the SmmAccess and SmmControl PPIs, so these are implemented here as libraries, ported from the DXE drivers. As the register definitions are generic, one library shim is implemented for compatibility, so the library can be generic too. SmmAccess shall be required regardless of SMM signalling, for the LockBox.

Like all boots, S3 resume will require working DRAM. To my understanding, we do not need to parse the memory map HOBs again, so some memory is allocated in DXE phase (to reserve it), the address stashed in a variable and consumed on S3 resume flows. Some optimisation can be performed here, regarding how much is necessary.
Stashing in a variable is imperfect, but the details must be available without DRAM. As the FSP HOBs are published later, SmmAccess cannot be used to retrieve from the LockBox.

Per my suspicions, notes from my mentors, Nate and Ankit, and the coreboot code, the PAMs are opened for access to the AP wake vectors.
Presently, all are opened, more research can be performed here.

As noted, either FSP or PiSmmCpuDxeSmm can apply boot CPU structures (GDT, IDT, MTRRs, etc). Per my research and findings by my mentors, the closed-source module CpuInitDxe would be required, so this implementation includes CpuS3DataDxe and open-source code will perform this task instead.

Unfortunately, board-specific code has some tasks to perform too. I've implemented these for Kabylake, the platform I can test. This includes detecting the boot mode, policy (memory overwrite is contraindicated, do not pass a VBT so FSP does not initialise graphics again) and ensuring a special provision, if desired, for debugging BootScriptExecutorDxe.

One major bug that blocked progress was simply specific to debugging.
DebugLibReportStatusCode should not be used for that module, because RSC has uninstalled the serial port handler at end-of-BS. Furthermore, it's obvious that the boot services are now unavailable. So, DebugLibSerialPort should be used. As an aside, due to AutoGen ordering, gBS cannot be used in SerialPortInitialize(). What really makes this module a unique case is the fact that it's behaviour is very like runtime drivers. For the integrity of the platform's security, the module is copied to the LockBox at DxeSmmReadyToLock. This caused one major bug that was blocking progress: libraries cannot attempt to modify globals (the data section) with end-of-BS events; they will never reach the true copy. So, rather than using flags to control code flow, it must be coded this way instead. For instance, there is now a special variant of I2cHdmiDebugSerialPortLib that does not use gBS in SerialPortWrite().

Previous revisions of this patch-set tested on my Aspire VN7-572G (Skylake). It's my belief and intention that this implementation be ready for other platforms too (some Intel-specific assumptions made), with a minimum of porting effort, though readying for some debugging is recommended.

Some potential bugs include:
- Power failure is being set (PMC PWR_FLR), so BootMode == 0x0. This bit
is RW/1C, so mitigate it. Until finalised and I close the laptop
chassis, I don't know if this is a bug in Kabylake's PchPmcLib.
- Very early in testing I saw a memory init error, which means that
self-refresh failed. A BaseMemoryTest() predictably failed too,
inserted before the PEI core installs memory. Either this was fixed
in the code as I finished the implementation, or it's a bug. A major
difference in build options is SerialPortSpiFlash ->
I2cHdmiDebugSerialPortLib, but this seemed irrelevant. If it's simply
the finalised implementation, I think this isn't worth a diff against
the reflog.

Cc: Sai Chaganty <rangasai.v.chaganty@...>
Cc: Isaac Oram <isaac.w.oram@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Ankit Sinha <ankit.sinha@...>
Cc: Chasel Chiu <chasel.chiu@...>
Cc: Liming Gao <gaoliming@...>
Cc: Eric Dong <eric.dong@...>
Cc: Jeremy Soller <jeremy@...>
Signed-off-by: Benjamin Doron <benjamin.doron00@...>

Benjamin Doron (4):
MinPlatformPkg: Add SmmLockBox to build
S3FeaturePkg: Implement working S3 resume
MinPlatformPkg: Implement working S3 resume
KabylakeOpenBoardPkg: Example of board S3

.../S3FeaturePkg/Include/PostMemory.fdf | 12 ++
.../S3FeaturePkg/Include/PreMemory.fdf | 8 +-
.../S3FeaturePkg/Include/S3Feature.dsc | 36 +++-
.../S3FeaturePkg/S3Dxe/S3Dxe.c | 155 ++++++++++++++++++
.../S3FeaturePkg/S3Dxe/S3Dxe.inf | 49 ++++++
.../S3FeaturePkg/S3FeaturePkg.dsc | 3 +
.../S3FeaturePkg/S3Pei/S3Pei.c | 83 +++++++++-
.../S3FeaturePkg/S3Pei/S3Pei.inf | 8 +-
.../PeiFspMiscUpdUpdateLib.c | 12 +-
.../PeiSaPolicyUpdate.c | 12 +-
.../PeiAspireVn7Dash572GInitPreMemLib.c | 38 +++--
.../BoardInitLib/PeiBoardInitPreMemLib.inf | 3 +
.../AspireVn7Dash572G/OpenBoardPkg.dsc | 21 +++
.../AspireVn7Dash572G/OpenBoardPkgPcd.dsc | 16 +-
.../PeiSiliconPolicyUpdateLib.c | 11 +-
.../PeiSiliconPolicyUpdateLib.inf | 1 +
.../PeiFspMiscUpdUpdateLib.c | 11 +-
.../PeiSaPolicyUpdate.c | 12 +-
.../BoardInitLib/PeiBoardInitPreMemLib.inf | 1 +
.../BoardInitLib/PeiGalagoPro3InitPreMemLib.c | 27 ++-
.../PeiMultiBoardInitPreMemLib.inf | 1 +
.../GalagoPro3/OpenBoardPkg.dsc | 15 ++
.../GalagoPro3/OpenBoardPkgPcd.dsc | 2 +-
.../PeiFspMiscUpdUpdateLib.c | 12 +-
.../PeiSaPolicyUpdate.c | 12 +-
.../BoardInitLib/PeiBoardInitPreMemLib.inf | 1 +
.../PeiKabylakeRvp3InitPreMemLib.c | 27 ++-
.../PeiMultiBoardInitPreMemLib.inf | 1 +
.../KabylakeRvp3/OpenBoardPkg.dsc | 12 ++
.../KabylakeRvp3/OpenBoardPkgPcd.dsc | 2 +-
.../PeiSiliconPolicyUpdateLib.c | 11 +-
.../PeiSiliconPolicyUpdateLib.inf | 1 +
.../FspWrapperHobProcessLib.c | 69 +++++++-
.../PeiFspWrapperHobProcessLib.inf | 2 +
.../Include/AcpiS3MemoryNvData.h | 22 +++
.../Include/Dsc/CoreDxeInclude.dsc | 1 +
.../Include/Dsc/CorePeiInclude.dsc | 2 +
.../Include/Fdf/CoreOsBootInclude.fdf | 1 +
.../Include/Fdf/CorePostMemoryInclude.fdf | 4 +
39 files changed, 665 insertions(+), 52 deletions(-) create mode 100644 Features/Intel/PowerManagement/S3FeaturePkg/S3Dxe/S3Dxe.c
create mode 100644 Features/Intel/PowerManagement/S3FeaturePkg/S3Dxe/S3Dxe.inf
create mode 100644 Platform/Intel/MinPlatformPkg/Include/AcpiS3MemoryNvData.h

--
2.37.2


Re: [edk2-platforms][PATCH v3 0/4] Implement S3 resume

Isaac Oram
 

Series Reviewed-by: Isaac Oram <Isaac.w.oram@...>

-----Original Message-----
From: Benjamin Doron <benjamin.doron00@...>
Sent: Monday, September 12, 2022 10:13 AM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V <rangasai.v.chaganty@...>; Oram, Isaac W <isaac.w.oram@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Sinha, Ankit <ankit.sinha@...>; Chiu, Chasel <chasel.chiu@...>; Gao, Liming <gaoliming@...>; Dong, Eric <eric.dong@...>; Soller, Jeremy <jeremy@...>
Subject: [edk2-platforms][PATCH v3 0/4] Implement S3 resume

MinPlatform is an open-source EDK2 firmware project that can boot some mainstream boards. However, it lacked working support for S3 resume, an important feature for mobile platforms, which means that its applicability as-is to mainstream use is limited. Therefore, I have now implemented working S3 resume support on MinPlatform. This patch series comprises a majority of one of my work products for GSoC 2022.

The BootScript-related modules are EDK2 open-source and fairly straightforward to include. However, the partial dependency PiSmmCommunicationPei (for signalling SMM) creates a dependency on both the SmmAccess and SmmControl PPIs, so these are implemented here as libraries, ported from the DXE drivers. As the register definitions are generic, one library shim is implemented for compatibility, so the library can be generic too. SmmAccess shall be required regardless of SMM signalling, for the LockBox.

Like all boots, S3 resume will require working DRAM. To my understanding, we do not need to parse the memory map HOBs again, so some memory is allocated in DXE phase (to reserve it), the address stashed in a variable and consumed on S3 resume flows. Some optimisation can be performed here, regarding how much is necessary.
Stashing in a variable is imperfect, but the details must be available without DRAM. As the FSP HOBs are published later, SmmAccess cannot be used to retrieve from the LockBox.

Per my suspicions, notes from my mentors, Nate and Ankit, and the coreboot code, the PAMs are opened for access to the AP wake vectors.
Presently, all are opened, more research can be performed here.

As noted, either FSP or PiSmmCpuDxeSmm can apply boot CPU structures (GDT, IDT, MTRRs, etc). Per my research and findings by my mentors, the closed-source module CpuInitDxe would be required, so this implementation includes CpuS3DataDxe and open-source code will perform this task instead.

Unfortunately, board-specific code has some tasks to perform too. I've implemented these for Kabylake, the platform I can test. This includes detecting the boot mode, policy (memory overwrite is contraindicated, do not pass a VBT so FSP does not initialise graphics again) and ensuring a special provision, if desired, for debugging BootScriptExecutorDxe.

One major bug that blocked progress was simply specific to debugging.
DebugLibReportStatusCode should not be used for that module, because RSC has uninstalled the serial port handler at end-of-BS. Furthermore, it's obvious that the boot services are now unavailable. So, DebugLibSerialPort should be used. As an aside, due to AutoGen ordering, gBS cannot be used in SerialPortInitialize(). What really makes this module a unique case is the fact that it's behaviour is very like runtime drivers. For the integrity of the platform's security, the module is copied to the LockBox at DxeSmmReadyToLock. This caused one major bug that was blocking progress: libraries cannot attempt to modify globals (the data section) with end-of-BS events; they will never reach the true copy. So, rather than using flags to control code flow, it must be coded this way instead. For instance, there is now a special variant of I2cHdmiDebugSerialPortLib that does not use gBS in SerialPortWrite().

Previous revisions of this patch-set tested on my Aspire VN7-572G (Skylake). It's my belief and intention that this implementation be ready for other platforms too (some Intel-specific assumptions made), with a minimum of porting effort, though readying for some debugging is recommended.

Some potential bugs include:
- Power failure is being set (PMC PWR_FLR), so BootMode == 0x0. This bit
is RW/1C, so mitigate it. Until finalised and I close the laptop
chassis, I don't know if this is a bug in Kabylake's PchPmcLib.
- Very early in testing I saw a memory init error, which means that
self-refresh failed. A BaseMemoryTest() predictably failed too,
inserted before the PEI core installs memory. Either this was fixed
in the code as I finished the implementation, or it's a bug. A major
difference in build options is SerialPortSpiFlash ->
I2cHdmiDebugSerialPortLib, but this seemed irrelevant. If it's simply
the finalised implementation, I think this isn't worth a diff against
the reflog.

Cc: Sai Chaganty <rangasai.v.chaganty@...>
Cc: Isaac Oram <isaac.w.oram@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Ankit Sinha <ankit.sinha@...>
Cc: Chasel Chiu <chasel.chiu@...>
Cc: Liming Gao <gaoliming@...>
Cc: Eric Dong <eric.dong@...>
Cc: Jeremy Soller <jeremy@...>
Signed-off-by: Benjamin Doron <benjamin.doron00@...>

Benjamin Doron (4):
MinPlatformPkg: Add SmmLockBox to build
S3FeaturePkg: Implement working S3 resume
MinPlatformPkg: Implement working S3 resume
KabylakeOpenBoardPkg: Example of board S3

.../S3FeaturePkg/Include/PostMemory.fdf | 12 ++
.../S3FeaturePkg/Include/PreMemory.fdf | 8 +-
.../S3FeaturePkg/Include/S3Feature.dsc | 36 +++-
.../S3FeaturePkg/S3Dxe/S3Dxe.c | 155 ++++++++++++++++++
.../S3FeaturePkg/S3Dxe/S3Dxe.inf | 49 ++++++
.../S3FeaturePkg/S3FeaturePkg.dsc | 3 +
.../S3FeaturePkg/S3Pei/S3Pei.c | 83 +++++++++-
.../S3FeaturePkg/S3Pei/S3Pei.inf | 8 +-
.../PeiFspMiscUpdUpdateLib.c | 12 +-
.../PeiSaPolicyUpdate.c | 12 +-
.../PeiAspireVn7Dash572GInitPreMemLib.c | 38 +++--
.../BoardInitLib/PeiBoardInitPreMemLib.inf | 3 +
.../AspireVn7Dash572G/OpenBoardPkg.dsc | 21 +++
.../AspireVn7Dash572G/OpenBoardPkgPcd.dsc | 16 +-
.../PeiSiliconPolicyUpdateLib.c | 11 +-
.../PeiSiliconPolicyUpdateLib.inf | 1 +
.../PeiFspMiscUpdUpdateLib.c | 11 +-
.../PeiSaPolicyUpdate.c | 12 +-
.../BoardInitLib/PeiBoardInitPreMemLib.inf | 1 +
.../BoardInitLib/PeiGalagoPro3InitPreMemLib.c | 27 ++-
.../PeiMultiBoardInitPreMemLib.inf | 1 +
.../GalagoPro3/OpenBoardPkg.dsc | 15 ++
.../GalagoPro3/OpenBoardPkgPcd.dsc | 2 +-
.../PeiFspMiscUpdUpdateLib.c | 12 +-
.../PeiSaPolicyUpdate.c | 12 +-
.../BoardInitLib/PeiBoardInitPreMemLib.inf | 1 +
.../PeiKabylakeRvp3InitPreMemLib.c | 27 ++-
.../PeiMultiBoardInitPreMemLib.inf | 1 +
.../KabylakeRvp3/OpenBoardPkg.dsc | 12 ++
.../KabylakeRvp3/OpenBoardPkgPcd.dsc | 2 +-
.../PeiSiliconPolicyUpdateLib.c | 11 +-
.../PeiSiliconPolicyUpdateLib.inf | 1 +
.../FspWrapperHobProcessLib.c | 69 +++++++-
.../PeiFspWrapperHobProcessLib.inf | 2 +
.../Include/AcpiS3MemoryNvData.h | 22 +++
.../Include/Dsc/CoreDxeInclude.dsc | 1 +
.../Include/Dsc/CorePeiInclude.dsc | 2 +
.../Include/Fdf/CoreOsBootInclude.fdf | 1 +
.../Include/Fdf/CorePostMemoryInclude.fdf | 4 +
39 files changed, 665 insertions(+), 52 deletions(-) create mode 100644 Features/Intel/PowerManagement/S3FeaturePkg/S3Dxe/S3Dxe.c
create mode 100644 Features/Intel/PowerManagement/S3FeaturePkg/S3Dxe/S3Dxe.inf
create mode 100644 Platform/Intel/MinPlatformPkg/Include/AcpiS3MemoryNvData.h

--
2.37.2


Re: [PATCH 1/3] UefiCpuPkg: Add Unit tests for DxeCpuExceptionHandlerLib

duntan
 

Ok, I'll do this in V2 patch. Thanks for your comments.

Thanks,
Dun

-----Original Message-----
From: Ni, Ray <ray.ni@...>
Sent: Tuesday, October 11, 2022 5:38 PM
To: Tan, Dun <dun.tan@...>; devel@edk2.groups.io
Cc: Dong, Eric <eric.dong@...>; Kumar, Rahul R <rahul.r.kumar@...>
Subject: RE: [PATCH 1/3] UefiCpuPkg: Add Unit tests for DxeCpuExceptionHandlerLib

Can you provide more details in the commit message?
Especially explain what "consistent" means for #3 and what "CpuStackGuard in both BSP and AP" means in #4?

Thanks,
Ray

-----Original Message-----
From: Tan, Dun <dun.tan@...>
Sent: Tuesday, October 11, 2022 2:04 PM
To: devel@edk2.groups.io
Cc: Dong, Eric <eric.dong@...>; Ni, Ray <ray.ni@...>; Kumar,
Rahul R <rahul.r.kumar@...>
Subject: [PATCH 1/3] UefiCpuPkg: Add Unit tests for
DxeCpuExceptionHandlerLib

Add target based unit tests for the DxeCpuExceptionHandlerLib.
A DXE driver is created to test DxeCpuExceptionHandlerLib. Four
kinds of test cases are created in this module:
1.Test if exception handler can be registered/unregistered for
no error code exception. 2.Test if exception handler can be
registered/unregistered for GP and PF. 3.Test if Cpu Context
is consistent before and after exception. 4.Test if stack
overflow can be captured by CpuStackGuard in both Bsp and AP.

Signed-off-by: Dun Tan <dun.tan@...>
Cc: Eric Dong <eric.dong@...>
Cc: Ray Ni <ray.ni@...>
Cc: Rahul Kumar <rahul1.kumar@...>
---
UefiCpuPkg/CpuExceptionHandlerUnitTest/CpuExceptionHandlerTest.h
| 353
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++

UefiCpuPkg/CpuExceptionHandlerUnitTest/CpuExceptionHandlerTestComm
on.c | 856
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++

UefiCpuPkg/CpuExceptionHandlerUnitTest/DxeCpuExceptionHandlerLibUnit
Test.inf | 58
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

UefiCpuPkg/CpuExceptionHandlerUnitTest/DxeCpuExceptionHandlerUnitTe
st.c | 196
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++

UefiCpuPkg/CpuExceptionHandlerUnitTest/X64/ArchExceptionHandlerTest.c
| 167
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++

UefiCpuPkg/CpuExceptionHandlerUnitTest/X64/ArchExceptionHandlerTestA
sm.nasm | 260
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++
6 files changed, 1890 insertions(+)

diff --git
a/UefiCpuPkg/CpuExceptionHandlerUnitTest/CpuExceptionHandlerTest.h
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/CpuExceptionHandlerTest.h
new file mode 100644
index 0000000000..bfbc483075
--- /dev/null
+++
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/CpuExceptionHandlerTest.h
@@ -0,0 +1,353 @@
+/** @file
+
+ Copyright (c) 2022, Intel Corporation. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef CPU_EXCEPTION_HANDLER_TEST_H_
+#define CPU_EXCEPTION_HANDLER_TEST_H_
+
+#include <Uefi.h>
+#include <Library/BaseLib.h>
+#include <Library/BaseMemoryLib.h>
+#include <Library/DebugLib.h>
+#include <Library/UnitTestLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/UnitTestHostBaseLib.h>
+#include <Library/CpuExceptionHandlerLib.h>
+#include <Library/UefiLib.h>
+#include <Library/SerialPortLib.h>
+#include <Library/HobLib.h>
+#include <Library/CpuPageTableLib.h>
+#include <Guid/MemoryAllocationHob.h>
+#include <Protocol/MpService.h>
+#include <PiPei.h>
+#include <Ppi/MpServices2.h>
+
+#define UNIT_TEST_APP_NAME "Cpu Exception Handler Lib Unit Tests"
+#define UNIT_TEST_APP_VERSION "1.0"
+
+#define CPU_INTERRUPT_NUM 256
+#define SPEC_MAX_EXCEPTION_NUM 22
+#define CR4_RESERVED_BIT BIT15
+
+#pragma pack (1)
+
+typedef union {
+ struct {
+ UINT32 LimitLow : 16;
+ UINT32 BaseLow : 16;
+ UINT32 BaseMid : 8;
+ UINT32 Type : 4;
+ UINT32 System : 1;
+ UINT32 Dpl : 2;
+ UINT32 Present : 1;
+ UINT32 LimitHigh : 4;
+ UINT32 Software : 1;
+ UINT32 Reserved : 1;
+ UINT32 DefaultSize : 1;
+ UINT32 Granularity : 1;
+ UINT32 BaseHigh : 8;
+ } Bits;
+ UINT64 Uint64;
+} IA32_GDT;
+
+typedef struct {
+ UINT32 InitialApicId;
+ UINT32 ApicId;
+ UINT32 Health;
+ UINT64 ApTopOfStack;
+} CPU_INFO_IN_HOB;
+#pragma pack ()
+
+typedef struct {
+ IA32_DESCRIPTOR OriginalGdtr;
+ IA32_DESCRIPTOR OriginalIdtr;
+ UINT16 Tr;
+} CPU_REGISTER_BUFFER;
+
+typedef union {
+ EDKII_PEI_MP_SERVICES2_PPI *Ppi;
+ EFI_MP_SERVICES_PROTOCOL *Protocol;
+} MP_SERVICES;
+
+typedef struct {
+ VOID *Buffer;
+ UINTN BufferSize;
+ EFI_STATUS Status;
+} EXCEPTION_STACK_SWITCH_CONTEXT;
+
+typedef struct {
+ UINT64 Rdi;
+ UINT64 Rsi;
+ UINT64 Rbp;
+ UINT64 Rbx;
+ UINT64 Rdx;
+ UINT64 Rcx;
+ UINT64 Rax;
+ UINT64 R8Register;
+ UINT64 R9Register;
+ UINT64 R10Register;
+ UINT64 R11Register;
+ UINT64 R12Register;
+ UINT64 R13Register;
+ UINT64 R14Register;
+ UINT64 R15Register;
+} GENERAL_REGISTER;
+
+typedef struct {
+ UINT32 Edi;
+ UINT32 Esi;
+ UINT32 Ebp;
+ UINT32 Ebx;
+ UINT32 Edx;
+ UINT32 Ecx;
+ UINT32 Eax;
+} GENERAL_REGISTER_IA32;
+
+extern UINTN mFaultInstructionLength;
+extern EFI_EXCEPTION_TYPE mExceptionType;
+extern UINTN mRspAddress[];
+extern GENERAL_REGISTER mRegisterForCheck[];
+extern GENERAL_REGISTER mAdjustRegisterBeforeException;
+extern GENERAL_REGISTER_IA32 mIa32RegisterForCheck[];
+extern GENERAL_REGISTER_IA32 mAdjustIa32RegisterBeforeException;
+
+/**
+ Initialize Bsp Idt with a new Idt table and return the IA32_DESCRIPTOR
buffer.
+ In PEIM, store original PeiServicePointer before new Idt table.
+
+ @return Pointer to the allocated IA32_DESCRIPTOR buffer.
+**/
+VOID *
+InitializeBspIdt (
+ VOID
+ );
+
+/**
+ Trigger no error code exception by INT n instruction.
+
+ @param[in] ExceptionType No error code exception type.
+**/
+VOID
+EFIAPI
+TriggerINTnException (
+ IN EFI_EXCEPTION_TYPE ExceptionType
+ );
+
+/**
+ Trigger GP exception.
+
+ @param[in] Cr4ReservedBit Cr4 reserved bit.
+**/
+VOID
+EFIAPI
+TriggerGPException (
+ UINTN Cr4ReservedBit
+ );
+
+/**
+ Trigger PF exception by write to not present or ReadOnly address.
+
+ @param[in] PFAddress Not present or ReadOnly address in page table.
+**/
+VOID
+EFIAPI
+TriggerPFException (
+ UINTN PFAddress
+ );
+
+/**
+ Special handler for fault exception.
+ Rip/Eip in SystemContext will be modified to the instruction after the
exception instruction.
+
+ @param ExceptionType Exception type.
+ @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+**/
+VOID
+EFIAPI
+AdjustRipForFaultHandler (
+ IN EFI_EXCEPTION_TYPE ExceptionType,
+ IN EFI_SYSTEM_CONTEXT SystemContext
+ );
+
+/**
+ Test consistency of Cpu context. Four steps:
+ 1. Set Cpu register to mAdjustRegisterBeforeException before exception.
+ 2. Trigger exception specified by ExceptionType.
+ 3. Store SystemContext in mRegisterForCheck[0] and set SystemContext
to mAdjustRegisterInsideException in handler.
+ 4. Store the Cpu register in mRegisterForCheck[1]
+
+ Rcx/Ecx in mAdjustRegisterInsideException is decided by different
exception type runtime since Rcx/Ecx is needed in assembly code.
+ For GP and PF, Rcx/Ecx is set to FaultParameter. For other exception
triggered by INTn, Rcx/Ecx is set to ExceptionType.
+
+ @param[in] ExceptionType Exception type.
+ @param[in] FaultParameter Parameter for GP and PF. OPTIONAL
+**/
+VOID
+EFIAPI
+AsmTestConsistencyOfCpuContext (
+ IN EFI_EXCEPTION_TYPE ExceptionType,
+ IN UINTN FaultParameter OPTIONAL
+ );
+
+/**
+ Special handler for ConsistencyOfCpuContext test case. General register in
SystemContext
+ is modified in this handler.
+
+ @param ExceptionType Exception type.
+ @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+**/
+VOID
+EFIAPI
+AdjustCpuContextHandler (
+ IN EFI_EXCEPTION_TYPE ExceptionType,
+ IN EFI_SYSTEM_CONTEXT SystemContext
+ );
+
+/**
+ Compare cpu context in ConsistencyOfCpuContext test case.
+ 1.Compare mRegisterForCheck[0] with mAdjustRegisterBeforeException.
+ 2.Compare mRegisterForCheck[1] with mAdjustRegisterAfterException.
+
+ @retval UNIT_TEST_PASSED The Unit test has completed and it was
successful.
+ @retval UNIT_TEST_ERROR_TEST_FAILED A test case assertion has failed.
+**/
+UNIT_TEST_STATUS
+CompareCpuContext (
+ VOID
+ );
+
+/**
+ Get EFI_MP_SERVICES_PROTOCOL/EDKII_PEI_MP_SERVICES2_PPI pointer.
+
+ @param[out] MpServices Pointer to the MP_SERVICES buffer
+
+ @retval EFI_SUCCESS EFI_MP_SERVICES_PROTOCOL/PPI interface is
returned
+ @retval EFI_NOT_FOUND EFI_MP_SERVICES_PROTOCOL/PPI interface is
not found
+**/
+EFI_STATUS
+GetMpServices (
+ OUT MP_SERVICES *MpServices
+ );
+
+/**
+ Create CpuExceptionLibUnitTestSuite and add test case.
+
+ @param[in] FrameworkHandle Unit test framework.
+
+ @return EFI_SUCCESS The unit test suite was created.
+ @retval EFI_OUT_OF_RESOURCES There are not enough resources
available to
+ initialize the unit test suite.
+**/
+EFI_STATUS
+AddCommonTestCase (
+ IN UNIT_TEST_FRAMEWORK_HANDLE Framework
+ );
+
+/**
+ Execute a caller provided function on all enabled APs.
+
+ @param[in] MpServices MP_SERVICES structure.
+ @param[in] Procedure Pointer to the function to be run on enabled APs
of the system.
+ @param[in] SingleThread If TRUE, then all the enabled APs execute the
function specified by Procedure
+ one by one, in ascending order of processor handle number.
+ If FALSE, then all the enabled APs execute the function
specified by Procedure
+ simultaneously.
+ @param[in] TimeoutInMicroseconds Indicates the time limit in
microseconds for APs to return from Procedure,
+ for blocking mode only. Zero means infinity.
+ @param[in] ProcedureArgument The parameter passed into Procedure
for all APs.
+
+ @retval EFI_SUCCESS Execute a caller provided function on all enabled
APs successfully
+ @retval Others Execute a caller provided function on all enabled APs
unsuccessfully
+**/
+EFI_STATUS
+MpServicesUnitTestStartupAllAPs (
+ IN MP_SERVICES MpServices,
+ IN EFI_AP_PROCEDURE Procedure,
+ IN BOOLEAN SingleThread,
+ IN UINTN TimeoutInMicroSeconds,
+ IN VOID *ProcedureArgument
+ );
+
+/**
+ Caller gets one enabled AP to execute a caller-provided function.
+
+ @param[in] MpServices MP_SERVICES structure.
+ @param[in] Procedure Pointer to the function to be run on enabled APs
of the system.
+ @param[in] ProcessorNumber The handle number of the AP.
+ @param[in] TimeoutInMicroseconds Indicates the time limit in
microseconds for APs to return from Procedure,
+ for blocking mode only. Zero means infinity.
+ @param[in] ProcedureArgument The parameter passed into Procedure
for all APs.
+
+
+ @retval EFI_SUCCESS Caller gets one enabled AP to execute a caller-
provided function successfully
+ @retval Others Caller gets one enabled AP to execute a caller-
provided function unsuccessfully
+**/
+EFI_STATUS
+MpServicesUnitTestStartupThisAP (
+ IN MP_SERVICES MpServices,
+ IN EFI_AP_PROCEDURE Procedure,
+ IN UINTN ProcessorNumber,
+ IN UINTN TimeoutInMicroSeconds,
+ IN VOID *ProcedureArgument
+ );
+
+/**
+ Get the handle number for the calling processor.
+
+ @param[in] MpServices Pointer to MP_SERVICES structure.
+ @param[out] ProcessorNumber The handle number for the calling
processor.
+
+ @retval EFI_SUCCESS Get the handle number for the calling processor
successfully.
+ @retval Others Get the handle number for the calling processor
unsuccessfully.
+**/
+EFI_STATUS
+MpServicesUnitTestWhoAmI (
+ IN MP_SERVICES MpServices,
+ OUT UINTN *ProcessorNumber
+ );
+
+/**
+ Retrieve the number of logical processor in the platform and the number
of those logical processors that
+ are enabled on this boot.
+
+ @param[in] MpServices Pointer to MP_SERVICES structure.
+ @param[out] NumberOfProcessors Pointer to the total number of logical
processors in the system, including
+ the BSP and disabled APs.
+ @param[out] NumberOfEnabledProcessors Pointer to the number of
processors in the system that are enabled.
+
+ @retval EFI_SUCCESS Retrieve the number of logical processor
successfully
+ @retval Others Retrieve the number of logical processor
unsuccessfully
+**/
+EFI_STATUS
+MpServicesUnitTestGetNumberOfProcessors (
+ IN MP_SERVICES MpServices,
+ OUT UINTN *NumberOfProcessors,
+ OUT UINTN *NumberOfEnabledProcessors
+ );
+
+/**
+ Trigger stack overflow by CpuStackGuard.
+**/
+VOID
+EFIAPI
+TriggerStackOverflowbyCpuStackGuard (
+ VOID
+ );
+
+/**
+ Special handler for CpuStackGuard test case.
+
+ @param ExceptionType Exception type.
+ @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+**/
+VOID
+EFIAPI
+CpuStackGuardExceptionHandler (
+ IN EFI_EXCEPTION_TYPE ExceptionType,
+ IN EFI_SYSTEM_CONTEXT SystemContext
+ );
+
+#endif
diff --git
a/UefiCpuPkg/CpuExceptionHandlerUnitTest/CpuExceptionHandlerTestCom
mon.c
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/CpuExceptionHandlerTestCom
mon.c
new file mode 100644
index 0000000000..1c3d011c76
--- /dev/null
+++
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/CpuExceptionHandlerTestCom
mon.c
@@ -0,0 +1,856 @@
+/** @file
+ Unit tests of the CpuExceptionHandlerLib.
+
+ Copyright (c) 2022, Intel Corporation. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "CpuExceptionHandlerTest.h"
+
+//
+// Length of the assembly falut instruction.
+//
+UINTN mFaultInstructionLength = 0;
+EFI_EXCEPTION_TYPE mExceptionType = 256;
+UINTN mNumberOfProcessors = 1;
+UINTN mRspAddress[2] = { 0 };
+
+//
+// Error code flag indicating whether or not an error code will be
+// pushed on the stack if an exception occurs.
+//
+// 1 means an error code will be pushed, otherwise 0
+//
+CONST UINT32 mErrorCodeExceptionFlag = 0x20227d00;
+
+/**
+ Special handler for trap exception.
+
+ @param ExceptionType Exception type.
+ @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+**/
+VOID
+EFIAPI
+INTnExceptionHandler (
+ IN EFI_EXCEPTION_TYPE ExceptionType,
+ IN EFI_SYSTEM_CONTEXT SystemContext
+ )
+{
+ mExceptionType = ExceptionType;
+}
+
+/**
+ Restore all cpu original register before test case.
+
+ @param[in] Buffer Argument of the procedure.
+**/
+VOID
+EFIAPI
+RestoreRegistersPerCpu (
+ IN VOID *Buffer
+ )
+{
+ CPU_REGISTER_BUFFER *CpuOriginalRegisterBuffer;
+ UINT16 Tr;
+ IA32_TSS_DESCRIPTOR *Tss;
+
+ CpuOriginalRegisterBuffer = (CPU_REGISTER_BUFFER *)Buffer;
+
+ AsmWriteGdtr (&(CpuOriginalRegisterBuffer->OriginalGdtr));
+ AsmWriteIdtr (&(CpuOriginalRegisterBuffer->OriginalIdtr));
+ Tr = CpuOriginalRegisterBuffer->Tr;
+ if ((Tr != 0) && (Tr < CpuOriginalRegisterBuffer->OriginalGdtr.Limit)) {
+ Tss = (IA32_TSS_DESCRIPTOR *)(CpuOriginalRegisterBuffer-
OriginalGdtr.Base + Tr);
+ if (Tss->Bits.P == 1) {
+ //
+ // Clear busy bit of TSS before write Tr
+ //
+ Tss->Bits.Type &= 0xD;
+ AsmWriteTr (Tr);
+ }
+ }
+}
+
+/**
+ Restore all cpu original register before test case.
+
+ @param[in] MpServices MpServices.
+ @param[in] CpuOriginalRegisterBuffer Address of
CpuOriginalRegisterBuffer.
+ @param[in] BspProcessorNum Bsp processor number.
+**/
+VOID
+RestoreAllCpuRegisters (
+ MP_SERVICES *MpServices, OPTIONAL
+ CPU_REGISTER_BUFFER *CpuOriginalRegisterBuffer,
+ UINTN BspProcessorNum
+ )
+{
+ CPU_REGISTER_BUFFER *AllCpuOriginalRegisterBuffer;
+ UINTN Index;
+ EFI_STATUS Status;
+
+ for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+ AllCpuOriginalRegisterBuffer = CpuOriginalRegisterBuffer + Index;
+ if (Index == BspProcessorNum) {
+ RestoreRegistersPerCpu ((VOID *)AllCpuOriginalRegisterBuffer);
+ continue;
+ }
+
+ ASSERT (MpServices != NULL);
+ Status = MpServicesUnitTestStartupThisAP (
+ *MpServices,
+ (EFI_AP_PROCEDURE)RestoreRegistersPerCpu,
+ Index,
+ 0,
+ (VOID *)AllCpuOriginalRegisterBuffer
+ );
+ ASSERT_EFI_ERROR (Status);
+ }
+}
+
+/**
+ Store all cpu original register before test case.
+
+ @param[in] Buffer Argument of the procedure.
+**/
+VOID
+EFIAPI
+SaveRegisterPerCpu (
+ IN VOID *Buffer
+ )
+{
+ CPU_REGISTER_BUFFER *CpuOriginalRegisterBuffer;
+ IA32_DESCRIPTOR Gdtr;
+ IA32_DESCRIPTOR Idtr;
+
+ CpuOriginalRegisterBuffer = (CPU_REGISTER_BUFFER *)Buffer;
+
+ AsmReadGdtr (&Gdtr);
+ AsmReadIdtr (&Idtr);
+ CpuOriginalRegisterBuffer->OriginalGdtr.Base = Gdtr.Base;
+ CpuOriginalRegisterBuffer->OriginalGdtr.Limit = Gdtr.Limit;
+ CpuOriginalRegisterBuffer->OriginalIdtr.Base = Idtr.Base;
+ CpuOriginalRegisterBuffer->OriginalIdtr.Limit = Idtr.Limit;
+ CpuOriginalRegisterBuffer->Tr = AsmReadTr ();
+}
+
+/**
+ Store all cpu original register before test case.
+
+ @param[in] MpServices MpServices.
+ @param[in] BspProcessorNum Bsp processor number.
+
+ @return Pointer to the allocated CPU_REGISTER_BUFFER.
+**/
+CPU_REGISTER_BUFFER *
+SaveAllCpuRegisters (
+ MP_SERVICES *MpServices, OPTIONAL
+ UINTN BspProcessorNum
+ )
+{
+ CPU_REGISTER_BUFFER *CpuOriginalRegisterBuffer;
+ CPU_REGISTER_BUFFER *AllCpuOriginalRegisterBuffer;
+ EFI_STATUS Status;
+ UINTN Index;
+
+ CpuOriginalRegisterBuffer = AllocateZeroPool (mNumberOfProcessors *
sizeof (CPU_REGISTER_BUFFER));
+ ASSERT (CpuOriginalRegisterBuffer != NULL);
+
+ for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+ AllCpuOriginalRegisterBuffer = CpuOriginalRegisterBuffer + Index;
+ if (Index == BspProcessorNum) {
+ SaveRegisterPerCpu ((VOID *)AllCpuOriginalRegisterBuffer);
+ continue;
+ }
+
+ ASSERT (MpServices != NULL);
+ Status = MpServicesUnitTestStartupThisAP (
+ *MpServices,
+ (EFI_AP_PROCEDURE)SaveRegisterPerCpu,
+ Index,
+ 0,
+ (VOID *)AllCpuOriginalRegisterBuffer
+ );
+ ASSERT_EFI_ERROR (Status);
+ }
+
+ return CpuOriginalRegisterBuffer;
+}
+
+/**
+ Initialize Ap Idt Procedure.
+
+ @param[in] Buffer Argument of the procedure.
+**/
+VOID
+EFIAPI
+InitializeIdtPerAp (
+ IN VOID *Buffer
+ )
+{
+ AsmWriteIdtr (Buffer);
+}
+
+/**
+ Initialize all Ap Idt.
+
+ @param[in] MpServices MpServices.
+ @param[in] BspIdtr Pointer to IA32_DESCRIPTOR allocated by Bsp.
+**/
+VOID
+InitializeApIdt (
+ MP_SERVICES MpServices,
+ VOID *BspIdtr
+ )
+{
+ EFI_STATUS Status;
+
+ Status = MpServicesUnitTestStartupAllAPs (
+ MpServices,
+ (EFI_AP_PROCEDURE)InitializeIdtPerAp,
+ FALSE,
+ 0,
+ BspIdtr
+ );
+ ASSERT_EFI_ERROR (Status);
+}
+
+/**
+ Check if exception handler can registered/unregistered for no error code
exception.
+
+ @param[in] Context [Optional] An optional parameter that enables:
+ 1) test-case reuse with varied parameters and
+ 2) test-case re-entry for Target tests that need a
+ reboot. This parameter is a VOID* and it is the
+ responsibility of the test author to ensure that the
+ contents are well understood by all test cases that may
+ consume it.
+
+ @retval UNIT_TEST_PASSED The Unit test has completed and the
test
+ case was successful.
+ @retval UNIT_TEST_ERROR_TEST_FAILED A test case assertion has failed.
+**/
+UNIT_TEST_STATUS
+EFIAPI
+TestRegisterHandlerForNoErrorCodeException (
+ IN UNIT_TEST_CONTEXT Context
+ )
+{
+ EFI_STATUS Status;
+ UINTN Index;
+ CPU_REGISTER_BUFFER *CpuOriginalRegisterBuffer;
+ VOID *NewIdtr;
+
+ CpuOriginalRegisterBuffer = SaveAllCpuRegisters (NULL, 0);
+ NewIdtr = InitializeBspIdt ();
+ Status = InitializeCpuExceptionHandlers (NULL);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+
+ for (Index = 0; Index < SPEC_MAX_EXCEPTION_NUM; Index++) {
+ //
+ // Only test no error code exception by INT n instruction.
+ //
+ if ((mErrorCodeExceptionFlag & (1 << Index)) != 0) {
+ continue;
+ }
+
+ DEBUG ((DEBUG_INFO, "TestCase1: ExceptionType is %d\n", Index));
+ Status = RegisterCpuInterruptHandler (Index, INTnExceptionHandler);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+
+ TriggerINTnException (Index);
+ UT_ASSERT_EQUAL (mExceptionType, Index);
+ Status = RegisterCpuInterruptHandler (Index, NULL);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ }
+
+ RestoreAllCpuRegisters (NULL, CpuOriginalRegisterBuffer, 0);
+ FreePool (CpuOriginalRegisterBuffer);
+ FreePool (NewIdtr);
+ return UNIT_TEST_PASSED;
+}
+
+/**
+ Get Bsp stack base.
+
+ @param[out] StackBase Pointer to stack base of BSP.
+**/
+VOID
+GetBspStackBase (
+ OUT UINTN *StackBase
+ )
+{
+ EFI_PEI_HOB_POINTERS Hob;
+ EFI_HOB_MEMORY_ALLOCATION *MemoryHob;
+
+ //
+ // Get the base of stack from Hob.
+ //
+ ASSERT (StackBase != NULL);
+ Hob.Raw = GetHobList ();
+ while ((Hob.Raw = GetNextHob (EFI_HOB_TYPE_MEMORY_ALLOCATION,
Hob.Raw)) != NULL) {
+ MemoryHob = Hob.MemoryAllocation;
+ if (CompareGuid (&gEfiHobMemoryAllocStackGuid, &MemoryHob-
AllocDescriptor.Name)) {
+ DEBUG ((
+ DEBUG_INFO,
+ "%a: Bsp StackBase = 0x%016lx StackSize = 0x%016lx\n",
+ __FUNCTION__,
+ MemoryHob->AllocDescriptor.MemoryBaseAddress,
+ MemoryHob->AllocDescriptor.MemoryLength
+ ));
+
+ *StackBase = (UINTN)MemoryHob-
AllocDescriptor.MemoryBaseAddress;
+ //
+ // Ensure the base of the stack is page-size aligned.
+ //
+ ASSERT ((*StackBase & EFI_PAGE_MASK) == 0);
+ break;
+ }
+
+ Hob.Raw = GET_NEXT_HOB (Hob);
+ }
+
+ ASSERT (*StackBase != 0);
+}
+
+/**
+ Initialize Ap Idt Procedure.
+
+ @param[in] Buffer Argument of the procedure.
+**/
+VOID
+EFIAPI
+GetStackBasePerAp (
+ IN VOID *Buffer
+ )
+{
+ UINTN ApTopOfStack;
+
+ ApTopOfStack = ALIGN_VALUE ((UINTN)&ApTopOfStack,
(UINTN)PcdGet32 (PcdCpuApStackSize));
+ *(UINTN *)Buffer = ApTopOfStack - (UINTN)PcdGet32
(PcdCpuApStackSize);
+}
+
+/**
+ Get Ap stack Info.
+
+ @param[in] MpServices MpServices.
+ @param[in] BspProcessorNum Bsp processor number.
+
+ @return Pointer to the allocated CpuStackBaseBuffer.
+**/
+UINTN *
+GetAllCpuStackBase (
+ MP_SERVICES *MpServices,
+ UINTN BspProcessorNum
+ )
+{
+ UINTN *CpuStackBaseBuffer;
+ UINTN *AllCpuStackBaseBuffer;
+ EFI_STATUS Status;
+ UINTN Index;
+
+ CpuStackBaseBuffer = AllocateZeroPool (mNumberOfProcessors * sizeof
(UINTN));
+ ASSERT (CpuStackBaseBuffer != NULL);
+
+ for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+ AllCpuStackBaseBuffer = CpuStackBaseBuffer + Index;
+ if (Index == BspProcessorNum) {
+ GetBspStackBase (AllCpuStackBaseBuffer);
+ continue;
+ }
+
+ ASSERT (MpServices != NULL);
+ Status = MpServicesUnitTestStartupThisAP (
+ *MpServices,
+ (EFI_AP_PROCEDURE)GetStackBasePerAp,
+ Index,
+ 0,
+ (VOID *)AllCpuStackBaseBuffer
+ );
+ ASSERT_EFI_ERROR (Status);
+ DEBUG ((DEBUG_INFO, "AP[%d] StackBase = 0x%x\n", Index,
CpuStackBaseBuffer[Index]));
+ }
+
+ return CpuStackBaseBuffer;
+}
+
+/**
+ Return not present or ReadOnly address in page table.
+
+ @param[out] PFAddress Access to the address which is not permitted will
trigger PF exceptions.
+**/
+VOID
+PageFaultAddressInPageTable (
+ UINTN *PFAddress
+ )
+{
+ IA32_CR0 Cr0;
+ IA32_CR4 Cr4;
+ UINTN PageTable;
+ PAGING_MODE PagingMode;
+ BOOLEAN Enable5LevelPaging;
+ RETURN_STATUS Status;
+ IA32_MAP_ENTRY *Map;
+ UINTN MapCount;
+ UINTN Index;
+
+ ASSERT (PFAddress != NULL);
+ *PFAddress = 0;
+
+ Cr0.UintN = AsmReadCr0 ();
+ if (Cr0.Bits.PG == 0) {
+ return;
+ }
+
+ PageTable = AsmReadCr3 ();
+ Cr4.UintN = AsmReadCr4 ();
+ if (sizeof (UINTN) == sizeof (UINT32)) {
+ ASSERT (Cr4.Bits.PAE == 1);
+ PagingMode = PagingPae;
+ } else {
+ Enable5LevelPaging = (BOOLEAN)(Cr4.Bits.LA57 == 1);
+ PagingMode = Enable5LevelPaging ? Paging5Level : Paging4Level;
+ }
+
+ MapCount = 0;
+ Status = PageTableParse (PageTable, PagingMode, NULL, &MapCount);
+ ASSERT (Status == RETURN_BUFFER_TOO_SMALL);
+ Map = AllocatePages (EFI_SIZE_TO_PAGES (MapCount * sizeof
(IA32_MAP_ENTRY)));
+ Status = PageTableParse (PageTable, PagingMode, Map, &MapCount);
+ ASSERT (Status == RETURN_SUCCESS);
+
+ for (Index = 0; Index < MapCount; Index++) {
+ DEBUG ((
+ DEBUG_ERROR,
+ "%02d: %016lx - %016lx, %016lx\n",
+ Index,
+ Map[Index].LinearAddress,
+ Map[Index].LinearAddress + Map[Index].Length,
+ Map[Index].Attribute.Uint64
+ ));
+
+ //
+ // Not present address in page table.
+ //
+ if ((Index >= 1) && (Map[Index].LinearAddress > Map[Index -
1].LinearAddress + Map[Index - 1].Length)) {
+ *PFAddress = (UINTN)(Map[Index - 1].LinearAddress + Map[Index -
1].Length);
+ return;
+ }
+
+ //
+ // ReadOnly address in page table.
+ //
+ if ((Cr0.Bits.WP != 0) && (Map[Index].Attribute.Bits.ReadWrite == 0)) {
+ *PFAddress = (UINTN)Map[Index].LinearAddress;
+ return;
+ }
+ }
+}
+
+/**
+ Test if exception handler can registered/unregistered for GP and PF.
+
+ @param[in] Context [Optional] An optional parameter that enables:
+ 1) test-case reuse with varied parameters and
+ 2) test-case re-entry for Target tests that need a
+ reboot. This parameter is a VOID* and it is the
+ responsibility of the test author to ensure that the
+ contents are well understood by all test cases that may
+ consume it.
+
+ @retval UNIT_TEST_PASSED The Unit test has completed and the
test
+ case was successful.
+ @retval UNIT_TEST_ERROR_TEST_FAILED A test case assertion has failed.
+**/
+UNIT_TEST_STATUS
+EFIAPI
+TestRegisterHandlerForGPAndPF (
+ IN UNIT_TEST_CONTEXT Context
+ )
+{
+ EFI_STATUS Status;
+ CPU_REGISTER_BUFFER *CpuOriginalRegisterBuffer;
+ UINTN PFAddress;
+ VOID *NewIdtr;
+
+ PFAddress = 0;
+ CpuOriginalRegisterBuffer = SaveAllCpuRegisters (NULL, 0);
+ NewIdtr = InitializeBspIdt ();
+ Status = InitializeCpuExceptionHandlers (NULL);
+
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+
+ //
+ // GP exception.
+ //
+ DEBUG ((DEBUG_INFO, "TestCase2: ExceptionType is %d\n",
EXCEPT_IA32_GP_FAULT));
+ Status = RegisterCpuInterruptHandler (EXCEPT_IA32_GP_FAULT,
AdjustRipForFaultHandler);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+
+ TriggerGPException (CR4_RESERVED_BIT);
+ UT_ASSERT_EQUAL (mExceptionType, EXCEPT_IA32_GP_FAULT);
+ Status = RegisterCpuInterruptHandler (EXCEPT_IA32_GP_FAULT, NULL);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+
+ //
+ // PF exception.
+ //
+ PageFaultAddressInPageTable (&PFAddress);
+
+ if (PFAddress > 0) {
+ DEBUG ((DEBUG_INFO, "TestCase2: ExceptionType is %d\n",
EXCEPT_IA32_PAGE_FAULT));
+ Status = RegisterCpuInterruptHandler (EXCEPT_IA32_PAGE_FAULT,
AdjustRipForFaultHandler);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ TriggerPFException (PFAddress);
+
+ UT_ASSERT_EQUAL (mExceptionType, EXCEPT_IA32_PAGE_FAULT);
+ Status = RegisterCpuInterruptHandler (EXCEPT_IA32_PAGE_FAULT,
NULL);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ }
+
+ RestoreAllCpuRegisters (NULL, CpuOriginalRegisterBuffer, 0);
+ FreePool (CpuOriginalRegisterBuffer);
+ FreePool (NewIdtr);
+ return UNIT_TEST_PASSED;
+}
+
+/**
+ Test if Cpu Context is consistent before and after exception.
+
+ @param[in] Context [Optional] An optional parameter that enables:
+ 1) test-case reuse with varied parameters and
+ 2) test-case re-entry for Target tests that need a
+ reboot. This parameter is a VOID* and it is the
+ responsibility of the test author to ensure that the
+ contents are well understood by all test cases that may
+ consume it.
+
+ @retval UNIT_TEST_PASSED The Unit test has completed and the
test
+ case was successful.
+ @retval UNIT_TEST_ERROR_TEST_FAILED A test case assertion has failed.
+**/
+UNIT_TEST_STATUS
+EFIAPI
+TestCpuContextConsistency (
+ IN UNIT_TEST_CONTEXT Context
+ )
+{
+ EFI_STATUS Status;
+ UINTN Index;
+ CPU_REGISTER_BUFFER *CpuOriginalRegisterBuffer;
+ UINTN FaultParameter;
+ VOID *NewIdtr;
+
+ FaultParameter = 0;
+ CpuOriginalRegisterBuffer = SaveAllCpuRegisters (NULL, 0);
+ NewIdtr = InitializeBspIdt ();
+ Status = InitializeCpuExceptionHandlers (NULL);
+
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+
+ for (Index = 0; Index < 22; Index++) {
+ if (Index == EXCEPT_IA32_PAGE_FAULT) {
+ PageFaultAddressInPageTable (&FaultParameter);
+ if (FaultParameter == 0) {
+ continue;
+ }
+ } else if (Index == EXCEPT_IA32_GP_FAULT) {
+ FaultParameter = CR4_RESERVED_BIT;
+ } else {
+ if ((mErrorCodeExceptionFlag & (1 << Index)) != 0) {
+ continue;
+ }
+ }
+
+ DEBUG ((DEBUG_INFO, "TestCase3: ExceptionType is %d\n", Index));
+ Status = RegisterCpuInterruptHandler (Index, AdjustCpuContextHandler);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+
+ //
+ // Trigger different type exception and compare different stage cpu
context.
+ //
+ AsmTestConsistencyOfCpuContext (Index, FaultParameter);
+ CompareCpuContext ();
+ Status = RegisterCpuInterruptHandler (Index, NULL);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ }
+
+ RestoreAllCpuRegisters (NULL, CpuOriginalRegisterBuffer, 0);
+ FreePool (CpuOriginalRegisterBuffer);
+ FreePool (NewIdtr);
+ return UNIT_TEST_PASSED;
+}
+
+/**
+ Initializes CPU exceptions handlers for the sake of stack switch
requirement.
+
+ This function is a wrapper of InitializeSeparateExceptionStacks. It's mainly
+ for the sake of AP's init because of EFI_AP_PROCEDURE API requirement.
+
+ @param[in,out] Buffer The pointer to private data buffer.
+
+**/
+VOID
+EFIAPI
+InitializeExceptionStackSwitchHandlersPerAp (
+ IN OUT VOID *Buffer
+ )
+{
+ EXCEPTION_STACK_SWITCH_CONTEXT *CpuSwitchStackData;
+
+ CpuSwitchStackData = (EXCEPTION_STACK_SWITCH_CONTEXT *)Buffer;
+
+ //
+ // This may be called twice for each Cpu. Only run
InitializeSeparateExceptionStacks
+ // if this is the first call or the first call failed because of size too small.
+ //
+ if ((CpuSwitchStackData->Status == EFI_NOT_STARTED) ||
(CpuSwitchStackData->Status == EFI_BUFFER_TOO_SMALL)) {
+ CpuSwitchStackData->Status = InitializeSeparateExceptionStacks
(CpuSwitchStackData->Buffer, &CpuSwitchStackData->BufferSize);
+ }
+}
+
+/**
+ Initializes MP exceptions handlers for the sake of stack switch requirement.
+
+ This function will allocate required resources required to setup stack switch
+ and pass them through SwitchStackData to each logic processor.
+
+ @param[in, out] MpServices MpServices.
+ @param[in, out] BspProcessorNum Bsp processor number.
+
+ @return Pointer to the allocated SwitchStackData.
+**/
+EXCEPTION_STACK_SWITCH_CONTEXT *
+InitializeMpExceptionStackSwitchHandlers (
+ MP_SERVICES MpServices,
+ UINTN BspProcessorNum
+ )
+{
+ UINTN Index;
+ EXCEPTION_STACK_SWITCH_CONTEXT *SwitchStackData;
+ EXCEPTION_STACK_SWITCH_CONTEXT *CpuSwitchStackData;
+ UINTN BufferSize;
+ EFI_STATUS Status;
+ UINT8 *Buffer;
+
+ SwitchStackData = AllocateZeroPool (mNumberOfProcessors * sizeof
(EXCEPTION_STACK_SWITCH_CONTEXT));
+ ASSERT (SwitchStackData != NULL);
+ for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+ CpuSwitchStackData = SwitchStackData + Index;
+ //
+ // Because the procedure may runs multiple times, use the status
EFI_NOT_STARTED
+ // to indicate the procedure haven't been run yet.
+ //
+ SwitchStackData[Index].Status = EFI_NOT_STARTED;
+ if (Index == BspProcessorNum) {
+ InitializeExceptionStackSwitchHandlersPerAp ((VOID
*)CpuSwitchStackData);
+ continue;
+ }
+
+ Status = MpServicesUnitTestStartupThisAP (
+ MpServices,
+ InitializeExceptionStackSwitchHandlersPerAp,
+ Index,
+ 0,
+ (VOID *)CpuSwitchStackData
+ );
+ ASSERT_EFI_ERROR (Status);
+ }
+
+ BufferSize = 0;
+ for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+ if (SwitchStackData[Index].Status == EFI_BUFFER_TOO_SMALL) {
+ ASSERT (SwitchStackData[Index].BufferSize != 0);
+ BufferSize += SwitchStackData[Index].BufferSize;
+ } else {
+ ASSERT (SwitchStackData[Index].Status == EFI_SUCCESS);
+ ASSERT (SwitchStackData[Index].BufferSize == 0);
+ }
+ }
+
+ if (BufferSize != 0) {
+ Buffer = AllocateZeroPool (BufferSize);
+ ASSERT (Buffer != NULL);
+ BufferSize = 0;
+ for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+ if (SwitchStackData[Index].Status == EFI_BUFFER_TOO_SMALL) {
+ SwitchStackData[Index].Buffer = (VOID *)(&Buffer[BufferSize]);
+ BufferSize += SwitchStackData[Index].BufferSize;
+ DEBUG ((
+ DEBUG_INFO,
+ "Buffer[cpu%lu] for InitializeExceptionStackSwitchHandlersPerAp:
0x%lX with size 0x%lX\n",
+ (UINT64)(UINTN)Index,
+ (UINT64)(UINTN)SwitchStackData[Index].Buffer,
+ (UINT64)(UINTN)SwitchStackData[Index].BufferSize
+ ));
+ }
+ }
+
+ for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+ CpuSwitchStackData = SwitchStackData + Index;
+ if (Index == BspProcessorNum) {
+ InitializeExceptionStackSwitchHandlersPerAp ((VOID
*)CpuSwitchStackData);
+ continue;
+ }
+
+ Status = MpServicesUnitTestStartupThisAP (
+ MpServices,
+ InitializeExceptionStackSwitchHandlersPerAp,
+ Index,
+ 0,
+ (VOID *)CpuSwitchStackData
+ );
+ ASSERT_EFI_ERROR (Status);
+ }
+
+ for (Index = 0; Index < mNumberOfProcessors; ++Index) {
+ ASSERT (SwitchStackData[Index].Status == EFI_SUCCESS);
+ }
+ }
+
+ return SwitchStackData;
+}
+
+/**
+ Test if stack overflow is captured by CpuStackGuard in Bsp and AP.
+
+ @param[in] Context [Optional] An optional parameter that enables:
+ 1) test-case reuse with varied parameters and
+ 2) test-case re-entry for Target tests that need a
+ reboot. This parameter is a VOID* and it is the
+ responsibility of the test author to ensure that the
+ contents are well understood by all test cases that may
+ consume it.
+
+ @retval UNIT_TEST_PASSED The Unit test has completed and the
test
+ case was successful.
+ @retval UNIT_TEST_ERROR_TEST_FAILED A test case assertion has failed.
+**/
+UNIT_TEST_STATUS
+EFIAPI
+TestCpuStackGuardInBspAndAp (
+ IN UNIT_TEST_CONTEXT Context
+ )
+{
+ EFI_STATUS Status;
+ UINTN OriginalStackBase;
+ UINTN NewStackTop;
+ UINTN NewStackBase;
+ EXCEPTION_STACK_SWITCH_CONTEXT *SwitchStackData;
+ MP_SERVICES MpServices;
+ UINTN ProcessorNumber;
+ UINTN EnabledProcessorNum;
+ CPU_REGISTER_BUFFER *CpuOriginalRegisterBuffer;
+ UINTN Index;
+ UINTN BspProcessorNum;
+ VOID *NewIdtr;
+ UINTN *CpuStackBaseBuffer;
+
+ if (!PcdGetBool (PcdCpuStackGuard)) {
+ return UNIT_TEST_PASSED;
+ }
+
+ //
+ // Get MP Service Protocol
+ //
+ Status = GetMpServices (&MpServices);
+ Status = MpServicesUnitTestGetNumberOfProcessors (MpServices,
&ProcessorNumber, &EnabledProcessorNum);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ Status = MpServicesUnitTestWhoAmI (MpServices, &BspProcessorNum);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ mNumberOfProcessors = ProcessorNumber;
+
+ CpuOriginalRegisterBuffer = SaveAllCpuRegisters (&MpServices,
BspProcessorNum);
+
+ //
+ // Initialize Bsp and AP Idt.
+ // Idt buffer should not be empty or it will hang in MP API.
+ //
+ NewIdtr = InitializeBspIdt ();
+ Status = InitializeCpuExceptionHandlers (NULL);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ InitializeApIdt (MpServices, NewIdtr);
+
+ //
+ // Get BSP and AP original stack base.
+ //
+ CpuStackBaseBuffer = GetAllCpuStackBase (&MpServices,
BspProcessorNum);
+
+ //
+ // InitializeMpExceptionStackSwitchHandlers and register exception
handler.
+ //
+ SwitchStackData = InitializeMpExceptionStackSwitchHandlers (MpServices,
BspProcessorNum);
+ Status = RegisterCpuInterruptHandler (EXCEPT_IA32_PAGE_FAULT,
CpuStackGuardExceptionHandler);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ Status = RegisterCpuInterruptHandler (EXCEPT_IA32_DOUBLE_FAULT,
AdjustRipForFaultHandler);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+
+ for (Index = 0; Index < mNumberOfProcessors; Index++) {
+ OriginalStackBase = CpuStackBaseBuffer[Index];
+ NewStackTop = (UINTN)(SwitchStackData[Index].Buffer) +
SwitchStackData[Index].BufferSize;
+ NewStackBase = (UINTN)(SwitchStackData[Index].Buffer);
+ if (Index == BspProcessorNum) {
+ TriggerStackOverflowbyCpuStackGuard ();
+ } else {
+ MpServicesUnitTestStartupThisAP (
+ MpServices,
+ (EFI_AP_PROCEDURE)TriggerStackOverflowbyCpuStackGuard,
+ Index,
+ 0,
+ NULL
+ );
+ }
+
+ DEBUG ((DEBUG_INFO, "TestCase4: mRspAddress[0] is 0x%x,
mRspAddress[1] is 0x%x\n", mRspAddress[0], mRspAddress[1]));
+ UT_ASSERT_TRUE ((mRspAddress[0] >= OriginalStackBase) &&
(mRspAddress[0] <= (OriginalStackBase + SIZE_4KB)));
+ UT_ASSERT_TRUE ((mRspAddress[1] >= NewStackBase) &&
(mRspAddress[1] < NewStackTop));
+ }
+
+ Status = RegisterCpuInterruptHandler (EXCEPT_IA32_PAGE_FAULT, NULL);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ Status = RegisterCpuInterruptHandler (EXCEPT_IA32_DOUBLE_FAULT,
NULL);
+ UT_ASSERT_EQUAL (Status, EFI_SUCCESS);
+ RestoreAllCpuRegisters (&MpServices, CpuOriginalRegisterBuffer,
BspProcessorNum);
+ FreePool (SwitchStackData);
+ FreePool (CpuOriginalRegisterBuffer);
+ FreePool (NewIdtr);
+
+ return UNIT_TEST_PASSED;
+}
+
+/**
+ Create CpuExceptionLibUnitTestSuite and add test case.
+
+ @param[in] FrameworkHandle Unit test framework.
+
+ @return EFI_SUCCESS The unit test suite was created.
+ @retval EFI_OUT_OF_RESOURCES There are not enough resources
available to
+ initialize the unit test suite.
+**/
+EFI_STATUS
+AddCommonTestCase (
+ IN UNIT_TEST_FRAMEWORK_HANDLE Framework
+ )
+{
+ EFI_STATUS Status;
+ UNIT_TEST_SUITE_HANDLE CpuExceptionLibUnitTestSuite;
+
+ //
+ // Populate the Manual Test Cases.
+ //
+ Status = CreateUnitTestSuite (&CpuExceptionLibUnitTestSuite, Framework,
"Test CpuExceptionHandlerLib", "CpuExceptionHandlerLib.Manual", NULL,
NULL);
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_ERROR, "Failed in CreateUnitTestSuite for
CpuExceptionHandlerLib Test Cases\n"));
+ Status = EFI_OUT_OF_RESOURCES;
+ return Status;
+ }
+
+ AddTestCase (CpuExceptionLibUnitTestSuite, "Check if exception handler
can be registered/unregistered for no error code exception",
"TestRegisterHandlerForNoErrorCodeException",
TestRegisterHandlerForNoErrorCodeException, NULL, NULL, NULL);
+ AddTestCase (CpuExceptionLibUnitTestSuite, "Check if exception handler
can be registered/unregistered for GP and PF",
"TestRegisterHandlerForGPAndPF", TestRegisterHandlerForGPAndPF, NULL,
NULL, NULL);
+
+ AddTestCase (CpuExceptionLibUnitTestSuite, "Check if Cpu Context is
consistent before and after exception.", "TestCpuContextConsistency",
TestCpuContextConsistency, NULL, NULL, NULL);
+ AddTestCase (CpuExceptionLibUnitTestSuite, "Check if stack overflow is
captured by CpuStackGuard in Bsp and AP",
"TestCpuStackGuardInBspAndAp", TestCpuStackGuardInBspAndAp, NULL,
NULL, NULL);
+
+ return EFI_SUCCESS;
+}
diff --git
a/UefiCpuPkg/CpuExceptionHandlerUnitTest/DxeCpuExceptionHandlerLibU
nitTest.inf
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/DxeCpuExceptionHandlerLibU
nitTest.inf
new file mode 100644
index 0000000000..e3dbe7b9ab
--- /dev/null
+++
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/DxeCpuExceptionHandlerLibU
nitTest.inf
@@ -0,0 +1,58 @@
+## @file
+# Unit tests of the DxeCpuExceptionHandlerLib instance.
+#
+# Copyright (c) 2022, Intel Corporation. All rights reserved.<BR>
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+ INF_VERSION = 0x00010005
+ BASE_NAME = CpuExceptionHandlerDxeTest
+ FILE_GUID = D76BFD9C-0B6D-46BD-AD66-2BBB6FA7031A
+ MODULE_TYPE = DXE_DRIVER
+ VERSION_STRING = 1.0
+ ENTRY_POINT = CpuExceptionHandlerTestEntry
+
+#
+# The following information is for reference only and not required by the
build tools.
+#
+# VALID_ARCHITECTURES = X64
+#
+[Sources.X64]
+ X64/ArchExceptionHandlerTestAsm.nasm
+ X64/ArchExceptionHandlerTest.c
+
+[Sources.common]
+ CpuExceptionHandlerTest.h
+ CpuExceptionHandlerTestCommon.c
+ DxeCpuExceptionHandlerUnitTest.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ UefiCpuPkg/UefiCpuPkg.dec
+
+[LibraryClasses]
+ BaseLib
+ BaseMemoryLib
+ DebugLib
+ UnitTestLib
+ MemoryAllocationLib
+ CpuExceptionHandlerLib
+ UefiDriverEntryPoint
+ HobLib
+ UefiBootServicesTableLib
+ CpuPageTableLib
+
+[Guids]
+ gEfiHobMemoryAllocStackGuid
+
+[Pcd]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard ## CONSUMES
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize ## CONSUMES
+
+[Protocols]
+ gEfiMpServiceProtocolGuid
+
+[Depex]
+ gEfiMpServiceProtocolGuid
diff --git
a/UefiCpuPkg/CpuExceptionHandlerUnitTest/DxeCpuExceptionHandlerUnitT
est.c
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/DxeCpuExceptionHandlerUnit
Test.c
new file mode 100644
index 0000000000..917fc549bf
--- /dev/null
+++
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/DxeCpuExceptionHandlerUnit
Test.c
@@ -0,0 +1,196 @@
+/** @file
+ Unit tests of the CpuExceptionHandlerLib.
+
+ Copyright (c) 2022, Intel Corporation. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "CpuExceptionHandlerTest.h"
+#include <Library/UefiBootServicesTableLib.h>
+
+/**
+ Initialize Bsp Idt with a new Idt table and return the IA32_DESCRIPTOR
buffer.
+ In PEIM, store original PeiServicePointer before new Idt table.
+
+ @return Pointer to the allocated IA32_DESCRIPTOR buffer.
+**/
+VOID *
+InitializeBspIdt (
+ VOID
+ )
+{
+ UINTN *NewIdtTable;
+ IA32_DESCRIPTOR *Idtr;
+
+ Idtr = AllocateZeroPool (sizeof (IA32_DESCRIPTOR));
+ ASSERT (Idtr != NULL);
+ NewIdtTable = AllocateZeroPool (sizeof (IA32_IDT_GATE_DESCRIPTOR) *
CPU_INTERRUPT_NUM);
+ ASSERT (NewIdtTable != NULL);
+ Idtr->Base = (UINTN)NewIdtTable;
+ Idtr->Limit = (UINT16)(sizeof (IA32_IDT_GATE_DESCRIPTOR) *
CPU_INTERRUPT_NUM - 1);
+
+ AsmWriteIdtr (Idtr);
+ return Idtr;
+}
+
+/**
+ Retrieve the number of logical processor in the platform and the number
of those logical processors that
+ are enabled on this boot.
+
+ @param[in] MpServices MP_SERVICES structure.
+ @param[out] NumberOfProcessors Pointer to the total number of logical
processors in the system, including
+ the BSP and disabled APs.
+ @param[out] NumberOfEnabledProcessors Pointer to the number of
processors in the system that are enabled.
+
+ @retval EFI_SUCCESS Retrieve the number of logical processor
successfully
+ @retval Others Retrieve the number of logical processor
unsuccessfully
+**/
+EFI_STATUS
+MpServicesUnitTestGetNumberOfProcessors (
+ IN MP_SERVICES MpServices,
+ OUT UINTN *NumberOfProcessors,
+ OUT UINTN *NumberOfEnabledProcessors
+ )
+{
+ return MpServices.Protocol->GetNumberOfProcessors
(MpServices.Protocol, NumberOfProcessors, NumberOfEnabledProcessors);
+}
+
+/**
+ Get the handle number for the calling processor.
+
+ @param[in] MpServices MP_SERVICES structure.
+ @param[out] ProcessorNumber The handle number for the calling
processor.
+
+ @retval EFI_SUCCESS Get the handle number for the calling processor
successfully.
+ @retval Others Get the handle number for the calling processor
unsuccessfully.
+**/
+EFI_STATUS
+MpServicesUnitTestWhoAmI (
+ IN MP_SERVICES MpServices,
+ OUT UINTN *ProcessorNumber
+ )
+{
+ return MpServices.Protocol->WhoAmI (MpServices.Protocol,
ProcessorNumber);
+}
+
+/**
+ Caller gets one enabled AP to execute a caller-provided function.
+
+ @param[in] MpServices MP_SERVICES structure.
+ @param[in] Procedure Pointer to the function to be run on enabled APs
of the system.
+ @param[in] ProcessorNumber The handle number of the AP.
+ @param[in] TimeoutInMicroSeconds Indicates the time limit in
microseconds for APs to return from Procedure,
+ for blocking mode only. Zero means infinity.
+ @param[in] ProcedureArgument The parameter passed into Procedure
for all APs.
+
+
+ @retval EFI_SUCCESS Caller gets one enabled AP to execute a caller-
provided function successfully
+ @retval Others Caller gets one enabled AP to execute a caller-
provided function unsuccessfully
+**/
+EFI_STATUS
+MpServicesUnitTestStartupThisAP (
+ IN MP_SERVICES MpServices,
+ IN EFI_AP_PROCEDURE Procedure,
+ IN UINTN ProcessorNumber,
+ IN UINTN TimeoutInMicroSeconds,
+ IN VOID *ProcedureArgument
+ )
+{
+ return MpServices.Protocol->StartupThisAP (MpServices.Protocol,
Procedure, ProcessorNumber, NULL, TimeoutInMicroSeconds,
ProcedureArgument, NULL);
+}
+
+/**
+ Execute a caller provided function on all enabled APs.
+
+ @param[in] MpServices MP_SERVICES structure.
+ @param[in] Procedure Pointer to the function to be run on enabled APs
of the system.
+ @param[in] SingleThread If TRUE, then all the enabled APs execute the
function specified by Procedure
+ one by one, in ascending order of processor handle number.
+ If FALSE, then all the enabled APs execute the function
specified by Procedure
+ simultaneously.
+ @param[in] TimeoutInMicroSeconds Indicates the time limit in
microseconds for APs to return from Procedure,
+ for blocking mode only. Zero means infinity.
+ @param[in] ProcedureArgument The parameter passed into Procedure
for all APs.
+
+ @retval EFI_SUCCESS Execute a caller provided function on all enabled
APs successfully
+ @retval Others Execute a caller provided function on all enabled APs
unsuccessfully
+**/
+EFI_STATUS
+MpServicesUnitTestStartupAllAPs (
+ IN MP_SERVICES MpServices,
+ IN EFI_AP_PROCEDURE Procedure,
+ IN BOOLEAN SingleThread,
+ IN UINTN TimeoutInMicroSeconds,
+ IN VOID *ProcedureArgument
+ )
+{
+ return MpServices.Protocol->StartupAllAPs (MpServices.Protocol,
Procedure, SingleThread, NULL, TimeoutInMicroSeconds,
ProcedureArgument, NULL);
+}
+
+/**
+ Get EFI_MP_SERVICES_PROTOCOL pointer.
+
+ @param[out] MpServices Pointer to the buffer where
EFI_MP_SERVICES_PROTOCOL is stored
+
+ @retval EFI_SUCCESS EFI_MP_SERVICES_PROTOCOL interface is
returned
+ @retval EFI_NOT_FOUND EFI_MP_SERVICES_PROTOCOL interface is not
found
+**/
+EFI_STATUS
+GetMpServices (
+ OUT MP_SERVICES *MpServices
+ )
+{
+ return gBS->LocateProtocol (&gEfiMpServiceProtocolGuid, NULL, (VOID
**)&MpServices->Protocol);
+}
+
+/**
+ Entry for CpuExceptionHandlerDxeTest driver.
+
+ @param ImageHandle Image handle this driver.
+ @param SystemTable Pointer to the System Table.
+
+ @retval EFI_SUCCESS The driver executed normally.
+
+**/
+EFI_STATUS
+EFIAPI
+CpuExceptionHandlerTestEntry (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUS Status;
+ UNIT_TEST_FRAMEWORK_HANDLE Framework;
+
+ Framework = NULL;
+
+ DEBUG ((DEBUG_INFO, "%a v%a\n", UNIT_TEST_APP_NAME,
UNIT_TEST_APP_VERSION));
+
+ //
+ // Start setting up the test framework for running the tests.
+ //
+ Status = InitUnitTestFramework (&Framework, UNIT_TEST_APP_NAME,
gEfiCallerBaseName, UNIT_TEST_APP_VERSION);
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_ERROR, "Failed in InitUnitTestFramework. Status
= %r\n", Status));
+ goto EXIT;
+ }
+
+ Status = AddCommonTestCase (Framework);
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_ERROR, "Failed in AddCommonTestCase. Status = %r\n",
Status));
+ goto EXIT;
+ }
+
+ //
+ // Execute the tests.
+ //
+ Status = RunAllTestSuites (Framework);
+
+EXIT:
+ if (Framework) {
+ FreeUnitTestFramework (Framework);
+ }
+
+ return Status;
+}
diff --git
a/UefiCpuPkg/CpuExceptionHandlerUnitTest/X64/ArchExceptionHandlerTes
t.c
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/X64/ArchExceptionHandlerTes
t.c
new file mode 100644
index 0000000000..9b086622f2
--- /dev/null
+++
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/X64/ArchExceptionHandlerTes
t.c
@@ -0,0 +1,167 @@
+/** @file
+ Unit tests of the CpuExceptionHandlerLib.
+
+ Copyright (c) 2022, Intel Corporation. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "CpuExceptionHandlerTest.h"
+
+GENERAL_REGISTER mRegisterForCheck[2];
+
+//
+// In TestCpuContextConsistency, Cpu registers will be set to
mAdjustRegisterBeforeException.
+// Rcx in mAdjustRegisterInsideException is set runtime since Rcx is needed
in assembly code.
+// For GP and PF, Rcx is set to FaultParameter. For other exception
triggered by INTn, Rcx is set to ExceptionType.
+//
+GENERAL_REGISTER mAdjustRegisterBeforeException = { 1, 2, 3, 4, 5, 0, 7, 8,
9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf };
+GENERAL_REGISTER mAdjustRegisterInsideException = { 0x11, 0x12, 0x13,
0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f };
+
+/**
+ Special handler for fault exception.
+ Rip/Eip in SystemContext will be modified to the instruction after the
exception instruction.
+
+ @param ExceptionType Exception type.
+ @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+**/
+VOID
+EFIAPI
+AdjustRipForFaultHandler (
+ IN EFI_EXCEPTION_TYPE ExceptionType,
+ IN EFI_SYSTEM_CONTEXT SystemContext
+ )
+{
+ mExceptionType = ExceptionType;
+ SystemContext.SystemContextX64->Rip += mFaultInstructionLength;
+}
+
+/**
+ Special handler for ConsistencyOfCpuContext test case.
+
+ @param ExceptionType Exception type.
+ @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+**/
+VOID
+EFIAPI
+AdjustCpuContextHandler (
+ IN EFI_EXCEPTION_TYPE ExceptionType,
+ IN EFI_SYSTEM_CONTEXT SystemContext
+ )
+{
+ //
+ // Do not handle Esp and ebp. They will not be restored.
+ // Store SystemContext in mRegisterForCheck[0] modified before
exception.
+ //
+ mRegisterForCheck[0].Rdi = SystemContext.SystemContextX64->Rdi;
+ mRegisterForCheck[0].Rsi = SystemContext.SystemContextX64->Rsi;
+ mRegisterForCheck[0].Rbx = SystemContext.SystemContextX64->Rbx;
+ mRegisterForCheck[0].Rdx = SystemContext.SystemContextX64->Rdx;
+ mRegisterForCheck[0].Rcx = SystemContext.SystemContextX64->Rcx;
+ mRegisterForCheck[0].Rax = SystemContext.SystemContextX64->Rax;
+ mRegisterForCheck[0].R8Register = SystemContext.SystemContextX64-
R8;
+ mRegisterForCheck[0].R9Register = SystemContext.SystemContextX64-
R9;
+ mRegisterForCheck[0].R10Register = SystemContext.SystemContextX64-
R10;
+ mRegisterForCheck[0].R11Register = SystemContext.SystemContextX64-
R11;
+ mRegisterForCheck[0].R12Register = SystemContext.SystemContextX64-
R12;
+ mRegisterForCheck[0].R13Register = SystemContext.SystemContextX64-
R13;
+ mRegisterForCheck[0].R14Register = SystemContext.SystemContextX64-
R14;
+ mRegisterForCheck[0].R15Register = SystemContext.SystemContextX64-
R15;
+
+ //
+ // Modify cpu context which will be stored in mRegisterForCheck[1].
+ //
+ SystemContext.SystemContextX64->Rdi =
mAdjustRegisterInsideException.Rdi;
+ SystemContext.SystemContextX64->Rsi =
mAdjustRegisterInsideException.Rsi;
+ SystemContext.SystemContextX64->Rbx =
mAdjustRegisterInsideException.Rbx;
+ SystemContext.SystemContextX64->Rdx =
mAdjustRegisterInsideException.Rdx;
+ SystemContext.SystemContextX64->Rcx =
mAdjustRegisterInsideException.Rcx;
+ SystemContext.SystemContextX64->Rax =
mAdjustRegisterInsideException.Rax;
+ SystemContext.SystemContextX64->R8 =
mAdjustRegisterInsideException.R8Register;
+ SystemContext.SystemContextX64->R9 =
mAdjustRegisterInsideException.R9Register;
+ SystemContext.SystemContextX64->R10 =
mAdjustRegisterInsideException.R10Register;
+ SystemContext.SystemContextX64->R11 =
mAdjustRegisterInsideException.R11Register;
+ SystemContext.SystemContextX64->R12 =
mAdjustRegisterInsideException.R12Register;
+ SystemContext.SystemContextX64->R13 =
mAdjustRegisterInsideException.R13Register;
+ SystemContext.SystemContextX64->R14 =
mAdjustRegisterInsideException.R14Register;
+ SystemContext.SystemContextX64->R15 =
mAdjustRegisterInsideException.R15Register;
+
+ //
+ // When fault exception happens, eip/rip points to the faulting instruction.
+ // For now, olny GP and PF are tested in fault exception.
+ //
+ if ((ExceptionType == EXCEPT_IA32_PAGE_FAULT) || (ExceptionType ==
EXCEPT_IA32_GP_FAULT)) {
+ AdjustRipForFaultHandler (ExceptionType, SystemContext);
+ }
+}
+
+/**
+ Compare cpu context in ConsistencyOfCpuContext test case.
+ 1.Compare mRegisterForCheck[0] with mAdjustRegisterBeforeException.
+ 2.Compare mRegisterForCheck[1] with mAdjustRegisterAfterException.
+
+ @retval UNIT_TEST_PASSED The Unit test has completed and it was
successful.
+ @retval UNIT_TEST_ERROR_TEST_FAILED A test case assertion has failed.
+**/
+UNIT_TEST_STATUS
+CompareCpuContext (
+ VOID
+ )
+{
+ //
+ // Do not handle Esp and ebp. They will not be restored.
+ //
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].Rdi,
mAdjustRegisterBeforeException.Rdi);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].Rsi,
mAdjustRegisterBeforeException.Rsi);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].Rbx,
mAdjustRegisterBeforeException.Rbx);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].Rdx,
mAdjustRegisterBeforeException.Rdx);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].Rcx,
mAdjustRegisterBeforeException.Rcx);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].Rax,
mAdjustRegisterBeforeException.Rax);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].R8Register,
mAdjustRegisterBeforeException.R8Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].R9Register,
mAdjustRegisterBeforeException.R9Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].R10Register,
mAdjustRegisterBeforeException.R10Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].R11Register,
mAdjustRegisterBeforeException.R11Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].R12Register,
mAdjustRegisterBeforeException.R12Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].R13Register,
mAdjustRegisterBeforeException.R13Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].R14Register,
mAdjustRegisterBeforeException.R14Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[0].R15Register,
mAdjustRegisterBeforeException.R15Register);
+
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].Rdi,
mAdjustRegisterInsideException.Rdi);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].Rsi,
mAdjustRegisterInsideException.Rsi);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].Rbx,
mAdjustRegisterInsideException.Rbx);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].Rdx,
mAdjustRegisterInsideException.Rdx);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].Rcx,
mAdjustRegisterInsideException.Rcx);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].Rax,
mAdjustRegisterInsideException.Rax);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].R8Register,
mAdjustRegisterInsideException.R8Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].R9Register,
mAdjustRegisterInsideException.R9Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].R10Register,
mAdjustRegisterInsideException.R10Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].R11Register,
mAdjustRegisterInsideException.R11Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].R12Register,
mAdjustRegisterInsideException.R12Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].R13Register,
mAdjustRegisterInsideException.R13Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].R14Register,
mAdjustRegisterInsideException.R14Register);
+ UT_ASSERT_EQUAL (mRegisterForCheck[1].R15Register,
mAdjustRegisterInsideException.R15Register);
+ return UNIT_TEST_PASSED;
+}
+
+/**
+ Special handler for CpuStackGuard test case.
+
+ @param ExceptionType Exception type.
+ @param SystemContext Pointer to EFI_SYSTEM_CONTEXT.
+
+**/
+VOID
+EFIAPI
+CpuStackGuardExceptionHandler (
+ IN EFI_EXCEPTION_TYPE ExceptionType,
+ IN EFI_SYSTEM_CONTEXT SystemContext
+ )
+{
+ UINTN LocalVariable;
+
+ AdjustRipForFaultHandler (ExceptionType, SystemContext);
+ mRspAddress[0] = (UINTN)SystemContext.SystemContextX64->Rsp;
+ mRspAddress[1] = (UINTN)(&LocalVariable);
+
+ return;
+}
diff --git
a/UefiCpuPkg/CpuExceptionHandlerUnitTest/X64/ArchExceptionHandlerTes
tAsm.nasm
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/X64/ArchExceptionHandlerTes
tAsm.nasm
new file mode 100644
index 0000000000..4838a12a67
--- /dev/null
+++
b/UefiCpuPkg/CpuExceptionHandlerUnitTest/X64/ArchExceptionHandlerTes
tAsm.nasm
@@ -0,0 +1,260 @@
+;------------------------------------------------------------------------------
+;
+; Copyright (c) 2022, Intel Corporation. All rights reserved.<BR>
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+; ArchExceptionHandlerTestAsm.nasm
+;
+; Abstract:
+;
+; x64 CPU Exception Handler Lib Unit test
+;
+;------------------------------------------------------------------------------
+
+ DEFAULT REL
+ SECTION .text
+
+struc GENERAL_REGISTER
+ .Rdi: resq 1
+ .Rsi: resq 1
+ .Rbp: resq 1
+ .Rbx: resq 1
+ .Rdx: resq 1
+ .Rcx: resq 1
+ .Rax: resq 1
+ .R8: resq 1
+ .R9: resq 1
+ .R10: resq 1
+ .R11: resq 1
+ .R12: resq 1
+ .R13: resq 1
+ .R14: resq 1
+ .R15: resq 1
+
+endstruc
+
+extern ASM_PFX(mRegisterForCheck)
+extern ASM_PFX(mAdjustRegisterBeforeException)
+extern ASM_PFX(mFaultInstructionLength)
+
+;------------------------------------------------------------------------------
+; VOID
+; EFIAPI
+; TriggerGPException (
+; UINTN Cr4ReservedBit
+; );
+;------------------------------------------------------------------------------
+global ASM_PFX(TriggerGPException)
+ASM_PFX(TriggerGPException):
+ ;
+ ; Set reserved bit 15 of cr4 to 1
+ ;
+ push rcx
+ lea rcx, [ASM_PFX(mFaultInstructionLength)]
+ mov qword[rcx], TriggerGPExceptionAfter - TriggerGPExceptionBefore
+ pop rcx
+TriggerGPExceptionBefore:
+ mov cr4, rcx
+TriggerGPExceptionAfter:
+ ret
+
+;------------------------------------------------------------------------------
+; VOID
+; EFIAPI
+; TriggerPFException (
+; UINTN PFAddress
+; );
+;------------------------------------------------------------------------------
+global ASM_PFX(TriggerPFException)
+ASM_PFX(TriggerPFException):
+ push rcx
+ lea rcx, [ASM_PFX(mFaultInstructionLength)]
+ mov qword[rcx], TriggerPFExceptionAfter - TriggerPFExceptionBefore
+ pop rcx
+TriggerPFExceptionBefore:
+ mov qword[rcx], 0x1
+TriggerPFExceptionAfter:
+ ret
+
+global ASM_PFX(ModifyRcxInGlobalBeforeException)
+ASM_PFX(ModifyRcxInGlobalBeforeException):
+ push rax
+ lea rax, [ASM_PFX(mAdjustRegisterBeforeException)]
+ mov [rax + GENERAL_REGISTER.Rcx], rcx
+ pop rax
+ ret
+
+;------------------------------------------------------------------------------
+;VOID
+;EFIAPI
+;AsmTestConsistencyOfCpuContext (
+; IN EFI_EXCEPTION_TYPE ExceptionType
+; IN UINTN FaultParameter OPTIONAL
+; );
+;------------------------------------------------------------------------------
+global ASM_PFX(AsmTestConsistencyOfCpuContext)
+ASM_PFX(AsmTestConsistencyOfCpuContext):
+ ;
+ ; push original register
+ ;
+ push r15
+ push r14
+ push r13
+ push r12
+ push r11
+ push r10
+ push r9
+ push r8
+ push rax
+ push rcx
+ push rbx
+ push rsi
+ push rdi
+ push rdx
+
+ ;
+ ; Modify register to mAdjustRegisterBeforeException
+ ;
+ lea r15, [ASM_PFX(mAdjustRegisterBeforeException)]
+ mov rdi, [r15 + GENERAL_REGISTER.Rdi]
+ mov rsi, [r15 + GENERAL_REGISTER.Rsi]
+ mov rbx, [r15 + GENERAL_REGISTER.Rbx]
+ mov rdx, [r15 + GENERAL_REGISTER.Rdx]
+ mov rax, [r15 + GENERAL_REGISTER.Rax]
+ mov r8, [r15 + GENERAL_REGISTER.R8]
+ mov r9, [r15 + GENERAL_REGISTER.R9]
+ mov r10, [r15 + GENERAL_REGISTER.R10]
+ mov r11, [r15 + GENERAL_REGISTER.R11]
+ mov r12, [r15 + GENERAL_REGISTER.R12]
+ mov r13, [r15 + GENERAL_REGISTER.R13]
+ mov r14, [r15 + GENERAL_REGISTER.R14]
+ mov r15, [r15 + GENERAL_REGISTER.R15]
+
+ cmp rcx, 0xd
+ jz GPException
+ cmp rcx, 0xe
+ jz PFException
+ jmp INTnException
+
+PFException:
+ ;
+ ; Pop rdx(Pei StackBase) to rcx and restore stack.
+ ; Modify Rcx in mAdjustRegisterBeforeException.
+ ;
+ pop rcx
+ push rcx
+ call ASM_PFX(ModifyRcxInGlobalBeforeException)
+ call ASM_PFX(TriggerPFException)
+ jmp AfterException
+
+GPException:
+ ;
+ ; Prepare rcx value for GP.
+ ; Modify Rcx in mAdjustRegisterBeforeException.
+ ;
+ pop rcx
+ push rcx
+ call ASM_PFX(ModifyRcxInGlobalBeforeException)
+ call ASM_PFX(TriggerGPException)
+ jmp AfterException
+
+INTnException:
+ ;
+ ; Modify Rcx in mAdjustRegisterBeforeException.
+ ;
+ call ASM_PFX(ModifyRcxInGlobalBeforeException)
+ call ASM_PFX(TriggerINTnException)
+
+AfterException:
+ ;
+ ; Save register in mRegisterForCheck[1]
+ ;
+ push rax
+ lea rax, [ASM_PFX(mRegisterForCheck)]
+ add rax, GENERAL_REGISTER_size
+ mov [rax + GENERAL_REGISTER.Rdi], rdi
+ mov [rax + GENERAL_REGISTER.Rsi], rsi
+ mov [rax + GENERAL_REGISTER.Rbx], rbx
+ mov [rax + GENERAL_REGISTER.Rdx], rdx
+ mov [rax + GENERAL_REGISTER.Rcx], rcx
+ pop rcx
+ mov [rax + GENERAL_REGISTER.Rax], rcx
+ mov [rax + GENERAL_REGISTER.R8], r8
+ mov [rax + GENERAL_REGISTER.R9], r9
+ mov [rax + GENERAL_REGISTER.R10], r10
+ mov [rax + GENERAL_REGISTER.R11], r11
+ mov [rax + GENERAL_REGISTER.R12], r12
+ mov [rax + GENERAL_REGISTER.R13], r13
+ mov [rax + GENERAL_REGISTER.R14], r14
+ mov [rax + GENERAL_REGISTER.R15], r15
+
+ ;
+ ; restore original register
+ ;
+ pop rdx
+ pop rdi
+ pop rsi
+ pop rbx
+ pop rcx
+ pop rax
+ pop r8
+ pop r9
+ pop r10
+ pop r11
+ pop r12
+ pop r13
+ pop r14
+ pop r15
+
+ ret
+
+;------------------------------------------------------------------------------
+; VOID
+; EFIAPI
+; TriggerStackOverflowbyCpuStackGuard (
+; VOID
+; );
+;------------------------------------------------------------------------------
+global ASM_PFX(TriggerStackOverflowbyCpuStackGuard)
+ASM_PFX(TriggerStackOverflowbyCpuStackGuard):
+ push rcx
+ lea rcx, [ASM_PFX(mFaultInstructionLength)]
+ mov qword[rcx], TriggerCpuStackGuardAfter -
TriggerCpuStackGuardBefore
+ pop rcx
+TriggerCpuStackGuardBefore:
+ call TriggerCpuStackGuardBefore
+TriggerCpuStackGuardAfter:
+ ret
+
+;------------------------------------------------------------------------------
+; VOID
+; EFIAPI
+; TriggerINTnException (
+; IN EFI_EXCEPTION_TYPE ExceptionType
+; );
+;------------------------------------------------------------------------------
+global ASM_PFX(TriggerINTnException)
+ASM_PFX(TriggerINTnException):
+ push rax
+ push rdx
+ push rcx
+ lea rax, [AsmTriggerException1 - AsmTriggerException0]
+ mul rcx
+ mov rcx, AsmTriggerException0
+ add rax, rcx
+ pop rcx
+ pop rdx
+ jmp rax
+ ;
+ ; rax = AsmTriggerException0 + (AsmTriggerException1 -
AsmTriggerException0) * rcx
+ ;
+%assign Vector 0
+%rep 22
+AsmTriggerException %+ Vector:
+ pop rax
+ INT Vector
+ ret
+%assign Vector Vector+1
+%endrep
--
2.31.1.windows.1


Re: The principles of EDK2 module reconstruction for archs

Chang, Abner
 

[AMD Official Use Only - General]

 

Don’t remove it for sure if there is already some use cases. Hah RedfishPkg, I forget this. 😊

 

 

From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 9:09 AM
To: Chang, Abner <Abner.Chang@...>; Ni, Ray <ray.ni@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>; Kinney, Michael D <michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

 

There are many instances of both in edk2 repo.  I would not remove from spec.

 

NetworkPkg/SnpDxe/Get_status.c

NetworkPkg/SnpDxe/Mcast_ip_to_mac.c

NetworkPkg/SnpDxe/Receive_filters.c

NetworkPkg/SnpDxe/Station_address.c

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h

OvmfPkg/Include/IndustryStandard/Xen/event_channel.h

OvmfPkg/Include/IndustryStandard/Xen/grant_table.h

OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h

OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h

OvmfPkg/PlatformCI/iasl_ext_dep.yaml

RedfishPkg/Library/JsonLib/jansson_config.h

RedfishPkg/Library/JsonLib/jansson_private_config.h

 

Mike

 

From: Chang, Abner <Abner.Chang@...>
Sent: Tuesday, October 11, 2022 5:52 PM
To: Kinney, Michael D <michael.d.kinney@...>; Ni, Ray <ray.ni@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

I was thinking to remove ‘_’ from edkII coding standard if there is no use case or rare people like it appears in file/dir name.

 

Abner

 

From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 4:16 AM
To: Chang, Abner <Abner.Chang@...>; Ni, Ray <ray.ni@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>; Kinney, Michael D <michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

 

I do not have a strong opinion either way. 

 

Some searching indicates there is some debate between use of spaces, underscores, and dashes in filenames.

 

The filename/dirname requirements for EDK II allow ‘_’ and ‘-‘ as long as they are not the first or last character.  Spaces ‘ ‘ are not allowed.

 

[A-Za-z][_A-Za-z0-9-]*[A-Za-z0-9]+

 

Mike

 

From: Chang, Abner <Abner.Chang@...>
Sent: Monday, October 10, 2022 7:21 PM
To: Ni, Ray <ray.ni@...>; Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

Removing '_' seems make the folder hard to read, but not too bad to me though. I am fine with removing '_'. 

Leif and Mike, how do you think?

 

Ex:

Riscv64Ia32X64 compares Riscv64_Ia32_X64.

ArmAArch64 compares to Arm_AArch64.

 

Abner


From: Ni, Ray <ray.ni@...>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner <Abner.Chang@...>; Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io <devel@edk2.groups.io>; quic_llindhol@... <quic_llindhol@...>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.


Abner, Mike, Leif,
"Ia32_X64" is the first case in edk2 that underscore "_" is used as part of file path.
Shall we use "Ia32X64" (removing "_")?

I know that Sunil is following the guideline.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F94912%3Fp%3D%252C%252C%252C20%252C0%252C0%252C0%253A%253Arecentpostdate%252Fsticky%252C%252CUefiCpuPkg%252FCpuTimerLib%252C20%252C2%252C0%252C94233015&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3D&amp;reserved=0

Thanks,
Ray

> -----Original Message-----
> From: Chang, Abner <Abner.Chang@...>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io;
> quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> <sunilvl@...>
> Cc: lichao <lichao@...>; Kirkendall, Garrett
> <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He,
> Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> archs
>
> [AMD Official Use Only - General]
>
> Here is the update of the Wiki page for the consistency with edk2 C Coding
> Standard Spec.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=i5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCjfIU%3D&amp;reserved=0
> Reconstruct-EDK-II-Modules-for-Processor-Architectures-and-Vendors'-
> Implementation
>
> Thanks
> Abner
>
> > -----Original Message-----
> > From: Chang, Abner
> > Sent: Wednesday, October 5, 2022 1:39 PM
> > To: Kinney, Michael D <michael.d.kinney@...>;
> devel@edk2.groups.io;
> > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> > (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > <sunilvl@...>
> > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
> He,
> > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> > archs
> >
> > [AMD Official Use Only - General]
> >
> > PR updated
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore-docs%2Fedk2-&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=YDYXODgrQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3D&amp;reserved=0
> > CCodingStandardsSpecification/pull/2/commits. Please check it.
> >
> > Thanks
> > Abner
> >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@...>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <Abner.Chang@...>; devel@edk2.groups.io;
> > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > <sunilvl@...>; Kinney, Michael D
> > > <michael.d.kinney@...>
> > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
> > He,
> > > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > > for archs
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > I would not add link to Wiki from EDK II C Coding Standard Specification.
> > >
> > > We want documents published from tianocore-docs to support
> standalone
> > > formats such as PDF and if there is a link in one of those documents,
> > > we want to know that it is a permanent link.  I am concerned we may
> > > reorganize Wiki pages and links in PDF would become stale.
> > >
> > > Links from Wiki to specs makes sense.
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: Chang, Abner <Abner.Chang@...>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
> > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall@...>; Grimes, Paul
> <Paul.Grimes@...>;
> > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> <afish@...>
> > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > reconstruction for archs
> > > >
> > > > [AMD Official Use Only - General]
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@...>;
> > > > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > <sunilvl@...>; Kinney, Michael D
> > > > > <michael.d.kinney@...>
> > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > <Paul.Grimes@...>;
> > > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> > <afish@...>
> > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > reconstruction for archs
> > > > >
> > > > > Caution: This message originated from an External Source. Use
> > > > > proper caution when opening attachments, clicking links, or
> responding.
> > > > >
> > > > >
> > > > > Hi Abner,
> > > > >
> > > > > responses below.
> > > > >
> > > > > Mike
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > > > > > Chang, Abner via groups.io
> > > > > > Sent: Sunday, October 2, 2022 10:37 PM
> > > > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > <sunilvl@...>
> > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > <Paul.Grimes@...>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module
> > > > > > reconstruction for archs
> > > > > >
> > > > > > [AMD Official Use Only - General]
> > > > > >
> > > > > > Mike,
> > > > > > Agree. This can be mentioned on the Wiki page. Also, this would
> > > > > > require the discussion between maintainer and contributor. I
> > > > > > would say
> > > > > maintainer has the responsibility to make sure an arch folder is
> > > > > only created when necessary.
> > > > >
> > > > > Agreed
> > > > Ok, I will update Directory and file names section.
> > > > >
> > > > > >
> > > > > > Do you agree with the arch concatenate solution for arch folder?
> > > > > > That
> > > > > means IA32_X64 instead of X86 (I am fine with this)?
> > > > >
> > > > > Yes
> > > > >
> > > > > > However, there is one scenario. Assume there were two arch
> > > > > > folders
> > > > > > IA32_X64 and RISCV64. Then ARM shares the code with IA32_X64,
> we
> > > > > > may
> > > > > rename IA32_X64 to IA32_X64_ARM.
> > > > > > Although the directory naming is not real a problem to the
> > > > > > build, a separate ARM folder seems easier? Or we can just allow
> > > > > > this kind of folder
> > > > > naming structure, however we let maintainer to make the decision?
> > > > >
> > > > > I would let the maintainer make the decision.  For your example,
> > > > > another approach may be to move the IA32_X64 content up a level so
> > > > > it is common and is used by IA32, X64, ARM.  And leave RISCV64
> > > > > folder for an arch that has special requirements.  I think having
> > > > > some flexibility in the guidelines is very beneficial.  The main
> > > > > goal is for consistency when a specific guideline is followed.
> > > > I think we can have the naming rules in the edk2 C coding standard
> > > > spec and
> > > put these guidelines on the Wiki page.
> > > > Is that ok to have a link to Wiki page in the edk2 C coding standard spec?
> > > >
> > > > Abner
> > > >
> > > > >
> > > > > >
> > > > > > Abner
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > > To: Chang, Abner <Abner.Chang@...>;
> > devel@edk2.groups.io;
> > > > > > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil
> > > > > > > V L <sunilvl@...>; Kinney, Michael D
> > > > > > > <michael.d.kinney@...>
> > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > <Paul.Grimes@...>; He, Jiangang
> <Jiangang.He@...>;
> > > > > > > Andrew Fish <afish@...>
> > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > reconstruction for archs
> > > > > > >
> > > > > > > Caution: This message originated from an External Source. Use
> > > > > > > proper caution when opening attachments, clicking links, or
> > responding.
> > > > > > >
> > > > > > >
> > > > > > > Abner,
> > > > > > >
> > > > > > > I think another guideline is to minimize the number of
> > subdirectories.
> > > > > > >
> > > > > > > Only create them if it helps with the organization and long
> > > > > > > term maintenance of the component.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Chang, Abner <Abner.Chang@...>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > <sunilvl@...>
> > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > <Paul.Grimes@...>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@...>; Andrew Fish
> > > > > > > > <afish@...>
> > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > > reconstruction for archs
> > > > > > > >
> > > > > > > > [AMD Official Use Only - General]
> > > > > > > >
> > > > > > > > Hi Mike and Leif,
> > > > > > > > First of all, we don't use arch folder if the module is
> > > > > > > > mainly for a specific arch in obviously. So we will  have
> > > > > > > > both common and arch-specific
> > > > > > > files constructed under module/library root.
> > > > > > > >
> > > > > > >
> > > > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > ed
> > > > > > > k
> > > > > > > 2
> > > > > > >
> > > > >
> > >
> > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=05%7C01%7C
> A
> > > > > > > bner.Chan
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884
> > > > > > > e608e11a
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ
> > > > > > > sb3d8eyJWI
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> > > > > > > 000%7
> > > > > > > >
> > > > > > >
> > > > >
> >
> C%7C%7C&amp;sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> > > > > > > M%3D&amp;r
> > > > > > > > eserved=0
> > > > > > > > SmmCpuFeatureLib\Ia32
> > > > > > > > SmmCpuFeatureLib\X64
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLib.c
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c
> > > > > > > > SmmCpuFeatureLib\IntelSmmCPuFeaturesLib
> > > > > > > > SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib
> > > > > > > >
> > > > > > > >
> > > > > > > > > > Could we concatenate architectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> > > > > > > > Looks like below?
> > > > > > > >
> > > > > > > > CpuDxe\IA32_X64\IA32\abc.nasm
> > CpuDxe\IA32_X64\X64\abc.nasm
> > > > > > > > CpuDxe\IA32_X64\CpuDxe.c CpuDxe\IA32_X64\AmdCpuDxe.c
> > > > > > > > CpuDxe\IA32_X64\IntelCpuDxe.c CpuDxe\RiscV64\CpuDxe.c
> > > > > > > > CpuDxe\ARM\CpuDxe.c CpuDxe\
> > > > > > > >                CpuDxeCommon.c  // If required.
> > > > > > > >                 CpuDxe.inf               // Use INF section arch modifier for
> X86,
> > > > > RISC-V
> > > > > > > and ARM.
> > > > > > > >                 CpuDxeAmd.inf        // Separate INF for AMD.
> > > > > > > >
> > > > > > > > Seems ok, but is AARCH64_RISCV64 a real case?  Or it means
> > > > > > > > we can create a folder "AARCH64_RISCV64" when there are
> some
> > > > > > > > common
> > > > > files
> > > > > > > shared by AARCH64 and RISCV64?
> > > > > > > >
> > > > > > > > For the 32/64 bit support, it can still stay under module
> > > > > > > > root and don't need to assign a folder for them unless the
> > > > > > > > arch has the different
> > > > > > > implementation.
> > > > > > > > Regards,
> > > > > > > > Abner
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io; quic_llindhol@...;
> > > > > > > > > Chang, Abner <Abner.Chang@...>; Ni, Ray
> > > > > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > <sunilvl@...>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@...>
> > > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > <Paul.Grimes@...>; He, Jiangang
> > <Jiangang.He@...>;
> > > > > > > > > Andrew Fish <afish@...>
> > > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > > > reconstruction for archs
> > > > > > > > >
> > > > > > > > > Caution: This message originated from an External Source.
> > > > > > > > > Use proper caution when opening attachments, clicking
> > > > > > > > > links, or
> > > > > responding.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Leif,
> > > > > > > > >
> > > > > > > > > Concatenation is a good idea.  Makes it more obvious and
> > > > > > > > > can be easily adopted for new CPU archs.
> > > > > > > > >
> > > > > > > > > There is an additional case where an implementation does
> > > > > > > > > not have differences based on CPU Arch or Vendor, but it
> > > > > > > > > does have differences based on the bit- width of the CPU.
> > > > > > > > > Take BaseSafeIntLib as
> > > > > > > an example.
> > > > > > > > > It has source files for 32-bit CPUs, 64-bit CPUs, and CPU
> > > > > > > > > arch specific file for Ebc because Ebc adapts to 32-bit or
> > > > > > > > > 64-bit depending on the CPU type the EBC Interpreter is
> running.
> > > > > > > > >
> > > > > > > > > MdePkg/Library/BaseSafeIntLib/
> > > > > > > > >   BaseSafeIntLib.inf
> > > > > > > > >   SafeIntLib.c
> > > > > > > > >   SafeIntLib32.c
> > > > > > > > >   SafeIntLib64.c
> > > > > > > > >   SafeIntLibEbc.c
> > > > > > > > >
> > > > > > > > > Should we add "32" and "64" as supported suffices in file
> names?
> > > > > > > > >
> > > > > > > > > If we wanted to put type content into a subdirectory, what
> > > > > > > > > would be the suggested directory name for "32" and "64".
> > > > > > > > > Or do we want to require this type of difference to always
> > > > > > > > > be files in top level directory of
> > > > > > > the modules/library?
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@...>; Chang, Abner
> > > > > > > <Abner.Chang@...>;
> > > > > > > > > > Ni, Ray <ray.ni@...>; Attar, AbdulLateef (Abdul
> > > > > > > > > > Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > > <sunilvl@...>
> > > > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > <Paul.Grimes@...>;
> > > > > > > > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> > > > > > > <afish@...>
> > > > > > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module
> > > > > > > > > > reconstruction for archs
> > > > > > > > > >
> > > > > > > > > > I agree similar things will certainly happen for
> > > > > > > > > > ARM/AARCH64, which will probably be noticeable when I
> > > > > > > > > > start eradicating ArmPkg and putting the arch-standard
> > > > > > > > > > bits into
> > > (mostly) MdePkg.
> > > > > > > > > >
> > > > > > > > > > But I like the ability to see already at the filesystem
> > > > > > > > > > level which files belong to the architecture I'm
> > > > > > > > > > currently working on and
> > > > > > > which don't.
> > > > > > > > > >
> > > > > > > > > > Could we concatenate architectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> > > > > > > > > >
> > > > > > > > > > /
> > > > > > > > > >      Leif
> > > > > > > > > >
> > > > > > > > > > On 2022-09-30 08:28, Michael D Kinney wrote:
> > > > > > > > > > > Hi Abner,
> > > > > > > > > > >
> > > > > > > > > > > One comment is on adding a new CPU type dir name of
> 'X86'
> > > > > > > > > > > for content that is common for IA32/X64.
> > > > > > > > > > >
> > > > > > > > > > > I can imagine a similar case for ARM/AARCH64 and for
> > > > > > > > > > > the RISCV (32, 64, 128) cases.
> > > > > > > > > > >
> > > > > > > > > > > I think I would prefer to drop X86 and if there are
> > > > > > > > > > > files that are common to multiple CPU architectures
> > > > > > > > > > > then they are considered common and are in top
> > > > > > > > > > > directory of module and the file header and INF file
> > > > > > > > > > > can clearly document which CPU archs the file
> > > > > > > applies.
> > > > > > > > > > >
> > > > > > > > > > > Mike
> > > > > > > > > > >
> > > > > > > > > > >> -----Original Message-----
> > > > > > > > > > >> From: Chang, Abner <Abner.Chang@...>
> > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > > >> <sunilvl@...>; devel@edk2.groups.io;
> > > > > > > > > > >> Kinney, Michael D <michael.d.kinney@...>
> > > > > > > > > > >> Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >> <Paul.Grimes@...>; He, Jiangang
> > > > > <Jiangang.He@...>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >> <afish@...>
> > > > > > > > > > >> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >> module reconstruction for archs
> > > > > > > > > > >>
> > > > > > > > > > >> [AMD Official Use Only - General]
> > > > > > > > > > >>
> > > > > > > > > > >> Thanks Ray, here are my responses.
> > > > > > > > > > >> https://nam11.safelinks.protection.outlook.com/?url=h
> > > > > > > > > > >> tt
> > > > > > > > > > >> ps%3
> > > > > > > > > > >> A%2F
> > > > > > > > > > >> %2Fg
> > > > > > > > > > >> ithub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > CCodingStandardsSpecification
> > > > > > > > > > >> %2Fp
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2
> > > > > > > f4
> > > > > > > > > 86f
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> > > > > > > > > 3800
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > > > JQ
> > > > > > > > > IjoiV
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > > > > > =
> > > > > > > > > HAq
> > > > > > > > > > >>
> > > > > > >
> > > > >
> > ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&amp;reserved=0
> > > > > > > > > > >>
> > > > > > > > > > >> @Kinney, Michael D we may also need your
> > > > > > > > > > >> clarification on the
> > > > > > > comments.
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>> -----Original Message-----
> > > > > > > > > > >>> From: Ni, Ray <ray.ni@...>
> > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@...>; Chang, Abner
> > > > > > > > > > >>> <Abner.Chang@...>; Sunil V L
> > > > > > > > > > >>> <sunilvl@...>; devel@edk2.groups.io
> > > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@...>; He, Jiangang
> > > > > <Jiangang.He@...>;
> > > > > > > > > > >>> Leif Lindholm <quic_llindhol@...>; Andrew
> > > > > > > > > > >>> Fish <afish@...>
> > > > > > > > > > >>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>> module reconstruction for archs
> > > > > > > > > > >>>
> > > > > > > > > > >>> Caution: This message originated from an External
> Source.
> > > > > > > > > > >>> Use proper caution when opening attachments,
> > > > > > > > > > >>> clicking links, or
> > > > > > > responding.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Abner,
> > > > > > > > > > >>> Comments in
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>>
> CCodingStandardsSpecification%2Fpull%2F2%23pullreque
> > > > > > > > > > >>> st
> > > > > > > > > > >>> revi
> > > > > > > > > > >>> ew-
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1124763311&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> 7C%7C%7C&amp;sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> > > > > > > > > > >>> 8jo8%3D&amp;reserved=0
> > > > > > > > > > >>>
> > > > > > > > > > >>> We can discuss more in tomorrow's meeting.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>>> <AbdulLateef.Attar@...>
> > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chang, Abner <Abner.Chang@...>; Sunil V L
> > > > > > > > > > >>>> <sunilvl@...>; devel@edk2.groups.io;
> > > > > > > > > > >>>> Ni, Ray <ray.ni@...>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@...>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@...>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>> <afish@...>
> > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module reconstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Hi Abner,
> > > > > > > > > > >>>>      Looks good to me.
> > > > > > > > > > >>>> Reviewed-by:  Abdul Lateef Attar <abdattar@...>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> AbduL
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Chang, Abner <Abner.Chang@...>
> > > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > > >>>> To: Sunil V L <sunilvl@...>;
> > > > > > > > > > >>>> devel@edk2.groups.io; ray.ni@...
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@...>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@...>; Attar, AbdulLateef
> > > > > > > > > > >>>> (Abdul
> > > > > > > > > > >>>> Lateef) <AbdulLateef.Attar@...>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>> <afish@...>
> > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module reconstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> [AMD Official Use Only - General]
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> I just had created PR to update edkII C coding
> > > > > > > > > > >>>> standard spec for the file and directory naming. We
> > > > > > > > > > >>>> can review and confirm this update first and then
> > > > > > > > > > >>>> go back to the principles of EDK2 module
> > > > > > > > > reconstruction for archs.
> > > > > > > > > > >>>> Here is the PR:
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>> &amp;data=05%7C01%7CAbner.Chang%40amd.c
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> > > > > > > > > > >>> d994e18
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> > > > > > > > > > >>> WIjoiMC4wLj
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > > > > > > > > > >>> 7C%7C&a
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
> > > > > > > > > > >>> mp;reserv
> > > > > > > > > > >>>> ed=0
> > > > > > > > > > >>>> CCodingStandardsSpecification/pull/2
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> The naming rule is mainly for the new module or new
> file
> > IMO.
> > > > > > > > > > >>>> Some existing module may not meet the guidelines
> > > > > > > > > > >>>> mentioned in this
> > > > > > > > > spec.
> > > > > > > > > > >>>> Thus we need the principles of EDK2 module
> > > > > > > > > > >>>> reconstruction on the existing module to support
> > > > > > > > > > >>>> other processor archs and not impacting the
> > > > > > > > > > >>> existing platforms (e.g.
> > > > > > > > > > >>>> rename the INF file or directory to meet the
> guidelines).
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Sunil, seems RISC-V CpuDxe meet the guideline.
> > > > > > > > > > >>>> Please check
> > > > > it.
> > > > > > > > > > >>>> Just feel that having  CpuDxe.c to Riscv64 folder
> > > > > > > > > > >>>> is not quite a best solution. I think at least we
> > > > > > > > > > >>>> can abstract the protocol structure and protocol
> > > > > > > > > > >>>> installation under CpuDxe\ and have the arch
> > > > > > > > > > >>>> implementation under arch folder. We can discuss
> > > > > > > > > > >>>> this later after we confirming the
> > > > > > > > > > >>> guideline and principles.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> Abner
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>> -----Original Message-----
> > > > > > > > > > >>>>> From: Sunil V L <sunilvl@...>
> > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: devel@edk2.groups.io; ray.ni@...
> > > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang@...>; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D <michael.d.kinney@...>; lichao
> > > > > > > > > > >>>>> <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>>> <Paul.Grimes@...>; He, Jiangang
> > > > > > > > > > >>>>> <Jiangang.He@...>; Attar, AbdulLateef (Abdul
> > > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar@...>; Leif
> Lindholm
> > > > > > > > > > >>>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>>> <afish@...>
> > > > > > > > > > >>>>> Subject: Re: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>>> module reconstruction for archs
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Caution: This message originated from an External
> > Source.
> > > > > > > > > > >>>>> Use proper caution when opening attachments,
> > > > > > > > > > >>>>> clicking links, or
> > > > > > > responding.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray
> > wrote:
> > > > > > > > > > >>>>> Hi Ray,
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    1.  When a new arch's implementation is
> > > > > > > > > > >>>>>> introduced to the existing
> > > > > > > > > > >>>>> module which was developed for the specific arch:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    1.  The folder reconstruction:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    *   Create arch folder for the existing arch
> > implementation
> > > > > > > > > > >>>>>> [Ray] Do you move existing arch implementation to
> > > > > > > > > > >>>>>> that arch
> > > > > > > folder?
> > > > > > > > > > >>>>>> It will
> > > > > > > > > > >>>>> break existing platforms a lot.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    *   Create the arch folder for the new introduced
> > arch
> > > > > > > > > > >>>>>> [Ray] I agree. But if we don't create arch folder
> > > > > > > > > > >>>>>> for existing arch
> > > > > > > > > > >>>>> implementation, the pkg layout will be a mess.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> [Ray] Hard for me to understand all the principles
> here.
> > > > > > > > > > >>>>>> Maybe we review
> > > > > > > > > > >>>>> existing code including to-be-upstreamed code and
> > > > > > > > > > >>>>> decide how
> > > > > > > to go.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Could you please take a look below changes which
> > > > > > > > > > >>>>> is trying to add RISC-V support for CpuDxe?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749&amp;
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&amp;reserved=0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&amp;da
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&amp;reserv
> > > > > > > > > > >>>>> ed=0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> What do you suggest with above example?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 1) Common INF for all architectures - but modify
> > > > > > > > > > >>>>> INF alone, no
> > > > > > > > > > >>>>> X86 folder creation.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This is what I have done in the commit above. May
> > > > > > > > > > >>>>> be of least impact to existing code since it is only INF
> > change.
> > > > > > > > > > >>>>> But like you mentioned this is bit weird that X86
> > > > > > > > > > >>>>> files will remain in root folder directly along
> > > > > > > > > > >>>>> with some common
> > > > > files.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 2) Common INF (CpuDxe.inf) + create arch folders
> > > > > > > > > > >>>>> X86, X64, IA32,
> > > > > > > > > > >>>>> RiscV64 etc
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> IMO, this is probably the best approach. What
> > > > > > > > > > >>>>> would be the challenges with this?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 3) Separate INF for arch like CpuDxe.inf for x86,
> > > > > > > > > > >>>>> CpuDxeRiscV64.inf for
> > > > > > > > > > >>>> RISC-V.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This again probably is not a good idea.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 4) If the module/library is specific to one arch (ex:
> > > > > > > > > > >>>>> SMM(X86), SBI(RISC-V)), then create separate INF.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Thanks!
> > > > > > > > > > >>>>> Sunil
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >


Re: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Michael D Kinney
 

Hi Jiewen,

Comments below.

Mike

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@...>
Sent: Tuesday, October 11, 2022 6:09 PM
To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>; Zurcher,
Christopher <christopher.zurcher@...>; Rebecca Cran <quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: RE: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Thank you Mike.

1) I like the idea to combine multiple OpensslLibIA32/X64.inf into one OpensslLibAccel.inf.
Also the cleanup looks good to me.

2) I also like the summary in readme in
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_MergeOptimizedOpensslLibs/CryptoPkg
I notice some algorithms are listed Y(Deprecated) but N(Don't Use), such as Tdes, Arc4, Aes.Ecb*.
But I don’t see the use case for those algorithms and I suggest a Y(Deprecated) have Y(Don't Use).
Good catch. I will fix.


3) About PcdOpensslEcEnabled
I notice it is used in existing code -
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_MergeOptimizedOpensslLibs/CryptoPkg/Library/TlsLib/TlsConfig.c#L11
39
Is this right way?
This was added since I started this work and was added back in by rebase. I will fix.
We can just remove the check for the PCD. If the OpensslLib instance does not include
SSL services, then the Null SSL services are present and the call to SSL_ctrl() will
return 0 which will force TlsSetEcCurve() to return EFI_UNSUPPORTED. It will also
ASSERT() informing the developer that a call to a service that depends on SSL was made
without SSL services available.

long
SSL_ctrl (
SSL *ssl,
int cmd,
long larg,
void *parg
)
{
ASSERT (FALSE);
return 0;
}

Likewise, if the OpensslLib instance does not support EC services, then the Null
EC services will be included and the call to EC_KEY_new_by_curve_name() will
return NULL which will force TlsSetEcCurve() to return EFI_UNSUPPORTED. It will also
ASSERT() informing the developer that a call to a service that depends on EC was made
without EC services available.

EC_KEY *
EC_KEY_new_by_curve_name (
int nid
)
{
ASSERT (FALSE);
return NULL;
}


Thank you
Yao, Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 11, 2022 11:04 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang,
Guomin <guomin.jiang@...>; Zurcher, Christopher
<christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

The recent addition of the Ecliptic Curve (EC) feature and the performance
optimization features increased the complexity for platforms to integrate
and enable these features. This series simplifies the platform configuration
as much as possible and improves the ability to manage the the size impact
of cryptographic services in each FW phase. A Readme.md is also added
that
provides an overview of the CryptoPkg design and features along with
platform
integration recommendations.

This series also addresses private library class declarations missing from
CryptoPkg.dec and library instances not producing all the APIs defined
by the library classes. A review of the CryptoPkg EDK II meta data files
identified
a number of additional cleanups. The CryptoPkg.dsc file was also updated to
improve CI coverage for future CryptoPkg changes and identified some
unit test bug fixes.

PR: https://github.com/tianocore/edk2/pull/3443
Branch:
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs
Readme:
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Readme.md

Change Summary
==============
* Document disabled/deprecated cryptographic services
* Add missing UNI files in BaseCryptLib
* Update BaseCryptLib internal functions to be STATIC and remove EFIAPI
* Add GLOBAL_REMOVE_IF_UNREFERENCED to BaseCryptLib global
variables
* Fix BaseCryptLib unit tests
* Cleanup BaseCryptLib and TlsLib INF files and
* Move SysCall/inet_pton.c from BaseCryptLib to TlsLib that uses it.
* Merge 4 performance optimized INFs into OpensslLib*Accel.inf
* Remove use of PcdOpensslEcEnabled and use OpensslLibFull*.inf instead
* Add OpensslLib and IntrinsicLib to CryptoPkg.dec as private library classes
* Update all OpensslLib instances to always produce all APIs in OpensslLib
class
* Move PrintLib dependency from OpensslLib INF files to BaseCryptLib INF
files
* Update CryptoPkg.dsc files to provide full CI test coverage across all the
supported combinations of OpensslLib, BaseCryptLib, and TlsLib instances.
* Remove PACKAGE profile from CryptoPkg.dsc and add
TARGET_UNIT_TESTS
profile. Adding TARGET_UNIT_TESTS profile is required to prevent a few
unit
test artifacts being included in non unit test builds of components.
* Add CryptoPkg Readme.md with overview and platform integration
details.
* Update host-based unit tests to always use OpensslLibFull.inf and add
unit
test coverage for OpensslLibFullAccel.inf.
* Add Readme.md with CryptoPkg overview and platform integration
documentation

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Cc: Christopher Zurcher <christopher.zurcher@...>
Cc: Rebecca Cran <quic_rcran@...>
Cc: Ard Biesheuvel <ardb@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>

Michael D Kinney (12):
CryptoPkg: Document and disable deprecated crypto services
CryptoPkg/Library/BaseCryptLib: Add missing UNI file and fix format
CryptoPkg/Library/BaseCryptLib: Update internal functions/variables
CryptoPkg/Test/UnitTest/Library/BaseCryptLib: Unit test fixes
CryptoPkg/Library: Cleanup BaseCryptLib and TlsLib
CryptoPkg/Library/OpensslLib: Combine all performance optimized INFs
CryptoPkg/Library/OpensslLib: Produce consistent set of APIs
CryptoPkg/Library/OpensslLib: Remove PrintLib from INF files
CryptoPkg: Remove PcdOpensslEcEnabled from CryptoPkg.dec
CryptoPkg: Update DSC to improve CI test coverage
CryptoPkg: Fixed host-based unit tests
CryptoPkg: Add Readme.md

CryptoPkg/CryptoPkg.ci.yaml | 11 +-
CryptoPkg/CryptoPkg.dec | 42 +-
CryptoPkg/CryptoPkg.dsc | 460 +++++++++---
.../Pcd/PcdCryptoServiceFamilyEnable.h | 122 +--
.../Library/BaseCryptLib/BaseCryptLib.inf | 10 +-
.../Library/BaseCryptLib/BaseCryptLib.uni | 2 -
.../Library/BaseCryptLib/Hmac/CryptHmac.c | 7 +
.../Library/BaseCryptLib/Kdf/CryptHkdf.c | 5 +-
.../Library/BaseCryptLib/PeiCryptLib.inf | 8 +-
.../Library/BaseCryptLib/PeiCryptLib.uni | 2 -
.../BaseCryptLib/Pk/CryptAuthenticode.c | 2 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c | 3 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyEku.c | 3 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 44 +-
.../Library/BaseCryptLib/RuntimeCryptLib.inf | 9 +-
.../Library/BaseCryptLib/RuntimeCryptLib.uni | 2 -
.../Library/BaseCryptLib/SecCryptLib.inf | 13 +-
.../{SmmCryptLib.uni => SecCryptLib.uni} | 11 +-
.../Library/BaseCryptLib/SmmCryptLib.inf | 12 -
.../Library/BaseCryptLib/SmmCryptLib.uni | 2 -
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 22 +-
.../Library/Include/openssl/opensslconf.h | 328 +++++++-
.../Include/openssl/opensslconf_generated.h | 333 ---------
CryptoPkg/Library/OpensslLib/EcSm2Null.c | 291 ++++++++
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 133 ++--
CryptoPkg/Library/OpensslLib/OpensslLib.uni | 10 +-
...nsslLibIa32Gcc.inf => OpensslLibAccel.inf} | 189 +++--
.../Library/OpensslLib/OpensslLibAccel.uni | 14 +
.../OpensslLib/OpensslLibConstructor.c | 6 +-
.../Library/OpensslLib/OpensslLibCrypto.inf | 185 +++--
.../Library/OpensslLib/OpensslLibCrypto.uni | 11 +-
.../{OpensslLib.inf => OpensslLibFull.inf} | 143 ++--
.../{OpensslLib.uni => OpensslLibFull.uni} | 10 +-
...sslLibIa32.inf => OpensslLibFullAccel.inf} | 192 +++--
.../OpensslLib/OpensslLibFullAccel.uni | 14 +
.../Library/OpensslLib/OpensslLibX64.inf | 706 ------------------
.../Library/OpensslLib/OpensslLibX64Gcc.inf | 706 ------------------
CryptoPkg/Library/OpensslLib/SslNull.c | 405 ++++++++++
.../SysCall/inet_pton.c | 0
CryptoPkg/Library/TlsLib/TlsConfig.c | 2 +-
CryptoPkg/Library/TlsLib/TlsLib.inf | 12 +-
CryptoPkg/Private/Library/IntrinsicLib.h | 16 +
CryptoPkg/Private/Library/OpensslLib.h | 14 +
CryptoPkg/Readme.md | 498 ++++++++++++
CryptoPkg/Test/CryptoPkgHostUnitTest.dsc | 17 +-
.../UnitTest/Library/BaseCryptLib/HmacTests.c | 17 +-
.../UnitTest/Library/BaseCryptLib/TSTests.c | 2 +-
.../TestBaseCryptLibHostAccel.inf | 55 ++
48 files changed, 2667 insertions(+), 2434 deletions(-)
copy CryptoPkg/Library/BaseCryptLib/{SmmCryptLib.uni =>
SecCryptLib.uni} (74%)
delete mode 100644
CryptoPkg/Library/Include/openssl/opensslconf_generated.h
create mode 100644 CryptoPkg/Library/OpensslLib/EcSm2Null.c
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32Gcc.inf =>
OpensslLibAccel.inf} (79%)
create mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibAccel.uni
copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibFull.inf}
(80%)
copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibFull.uni}
(56%)
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32.inf =>
OpensslLibFullAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.uni
delete mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibX64.inf
delete mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf
create mode 100644 CryptoPkg/Library/OpensslLib/SslNull.c
rename CryptoPkg/Library/{BaseCryptLib => TlsLib}/SysCall/inet_pton.c
(100%)
create mode 100644 CryptoPkg/Private/Library/IntrinsicLib.h
create mode 100644 CryptoPkg/Private/Library/OpensslLib.h
create mode 100644 CryptoPkg/Readme.md
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/TestBaseCryptLibHostAccel.i
nf

--
2.37.1.windows.1


Event: TianoCore Bug Triage - APAC / NAMO - 10/11/2022 #cal-reminder

Group Notification <noreply@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When:
10/11/2022
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d

Organizer: Liming Gao gaoliming@...

View Event

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

________________________________________________________________________________

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Join with a video conferencing device

teams@...

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions

Or call in (audio only)

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

Phone Conference ID: 774 638 21#

Find a local number | Reset PIN

Learn More | Meeting options


Re: The principles of EDK2 module reconstruction for archs

Michael D Kinney
 

There are many instances of both in edk2 repo.  I would not remove from spec.

 

NetworkPkg/SnpDxe/Get_status.c

NetworkPkg/SnpDxe/Mcast_ip_to_mac.c

NetworkPkg/SnpDxe/Receive_filters.c

NetworkPkg/SnpDxe/Station_address.c

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_32.h

OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen-x86_64.h

OvmfPkg/Include/IndustryStandard/Xen/event_channel.h

OvmfPkg/Include/IndustryStandard/Xen/grant_table.h

OvmfPkg/Include/IndustryStandard/Xen/hvm/hvm_op.h

OvmfPkg/Include/IndustryStandard/Xen/io/xs_wire.h

OvmfPkg/PlatformCI/iasl_ext_dep.yaml

RedfishPkg/Library/JsonLib/jansson_config.h

RedfishPkg/Library/JsonLib/jansson_private_config.h

 

Mike

 

From: Chang, Abner <Abner.Chang@...>
Sent: Tuesday, October 11, 2022 5:52 PM
To: Kinney, Michael D <michael.d.kinney@...>; Ni, Ray <ray.ni@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

I was thinking to remove ‘_’ from edkII coding standard if there is no use case or rare people like it appears in file/dir name.

 

Abner

 

From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 4:16 AM
To: Chang, Abner <Abner.Chang@...>; Ni, Ray <ray.ni@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>; Kinney, Michael D <michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

 

I do not have a strong opinion either way. 

 

Some searching indicates there is some debate between use of spaces, underscores, and dashes in filenames.

 

The filename/dirname requirements for EDK II allow ‘_’ and ‘-‘ as long as they are not the first or last character.  Spaces ‘ ‘ are not allowed.

 

[A-Za-z][_A-Za-z0-9-]*[A-Za-z0-9]+

 

Mike

 

From: Chang, Abner <Abner.Chang@...>
Sent: Monday, October 10, 2022 7:21 PM
To: Ni, Ray <ray.ni@...>; Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

Removing '_' seems make the folder hard to read, but not too bad to me though. I am fine with removing '_'. 

Leif and Mike, how do you think?

 

Ex:

Riscv64Ia32X64 compares Riscv64_Ia32_X64.

ArmAArch64 compares to Arm_AArch64.

 

Abner


From: Ni, Ray <ray.ni@...>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner <Abner.Chang@...>; Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io <devel@edk2.groups.io>; quic_llindhol@... <quic_llindhol@...>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.


Abner, Mike, Leif,
"Ia32_X64" is the first case in edk2 that underscore "_" is used as part of file path.
Shall we use "Ia32X64" (removing "_")?

I know that Sunil is following the guideline.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F94912%3Fp%3D%252C%252C%252C20%252C0%252C0%252C0%253A%253Arecentpostdate%252Fsticky%252C%252CUefiCpuPkg%252FCpuTimerLib%252C20%252C2%252C0%252C94233015&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3D&amp;reserved=0

Thanks,
Ray

> -----Original Message-----
> From: Chang, Abner <Abner.Chang@...>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io;
> quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> <sunilvl@...>
> Cc: lichao <lichao@...>; Kirkendall, Garrett
> <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He,
> Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> archs
>
> [AMD Official Use Only - General]
>
> Here is the update of the Wiki page for the consistency with edk2 C Coding
> Standard Spec.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=i5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCjfIU%3D&amp;reserved=0
> Reconstruct-EDK-II-Modules-for-Processor-Architectures-and-Vendors'-
> Implementation
>
> Thanks
> Abner
>
> > -----Original Message-----
> > From: Chang, Abner
> > Sent: Wednesday, October 5, 2022 1:39 PM
> > To: Kinney, Michael D <michael.d.kinney@...>;
> devel@edk2.groups.io;
> > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> > (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > <sunilvl@...>
> > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
> He,
> > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> > archs
> >
> > [AMD Official Use Only - General]
> >
> > PR updated
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore-docs%2Fedk2-&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=YDYXODgrQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3D&amp;reserved=0
> > CCodingStandardsSpecification/pull/2/commits. Please check it.
> >
> > Thanks
> > Abner
> >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@...>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <Abner.Chang@...>; devel@edk2.groups.io;
> > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > <sunilvl@...>; Kinney, Michael D
> > > <michael.d.kinney@...>
> > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
> > He,
> > > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > > for archs
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > I would not add link to Wiki from EDK II C Coding Standard Specification.
> > >
> > > We want documents published from tianocore-docs to support
> standalone
> > > formats such as PDF and if there is a link in one of those documents,
> > > we want to know that it is a permanent link.  I am concerned we may
> > > reorganize Wiki pages and links in PDF would become stale.
> > >
> > > Links from Wiki to specs makes sense.
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: Chang, Abner <Abner.Chang@...>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
> > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall@...>; Grimes, Paul
> <Paul.Grimes@...>;
> > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> <afish@...>
> > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > reconstruction for archs
> > > >
> > > > [AMD Official Use Only - General]
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@...>;
> > > > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > <sunilvl@...>; Kinney, Michael D
> > > > > <michael.d.kinney@...>
> > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > <Paul.Grimes@...>;
> > > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> > <afish@...>
> > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > reconstruction for archs
> > > > >
> > > > > Caution: This message originated from an External Source. Use
> > > > > proper caution when opening attachments, clicking links, or
> responding.
> > > > >
> > > > >
> > > > > Hi Abner,
> > > > >
> > > > > responses below.
> > > > >
> > > > > Mike
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > > > > > Chang, Abner via groups.io
> > > > > > Sent: Sunday, October 2, 2022 10:37 PM
> > > > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > <sunilvl@...>
> > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > <Paul.Grimes@...>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module
> > > > > > reconstruction for archs
> > > > > >
> > > > > > [AMD Official Use Only - General]
> > > > > >
> > > > > > Mike,
> > > > > > Agree. This can be mentioned on the Wiki page. Also, this would
> > > > > > require the discussion between maintainer and contributor. I
> > > > > > would say
> > > > > maintainer has the responsibility to make sure an arch folder is
> > > > > only created when necessary.
> > > > >
> > > > > Agreed
> > > > Ok, I will update Directory and file names section.
> > > > >
> > > > > >
> > > > > > Do you agree with the arch concatenate solution for arch folder?
> > > > > > That
> > > > > means IA32_X64 instead of X86 (I am fine with this)?
> > > > >
> > > > > Yes
> > > > >
> > > > > > However, there is one scenario. Assume there were two arch
> > > > > > folders
> > > > > > IA32_X64 and RISCV64. Then ARM shares the code with IA32_X64,
> we
> > > > > > may
> > > > > rename IA32_X64 to IA32_X64_ARM.
> > > > > > Although the directory naming is not real a problem to the
> > > > > > build, a separate ARM folder seems easier? Or we can just allow
> > > > > > this kind of folder
> > > > > naming structure, however we let maintainer to make the decision?
> > > > >
> > > > > I would let the maintainer make the decision.  For your example,
> > > > > another approach may be to move the IA32_X64 content up a level so
> > > > > it is common and is used by IA32, X64, ARM.  And leave RISCV64
> > > > > folder for an arch that has special requirements.  I think having
> > > > > some flexibility in the guidelines is very beneficial.  The main
> > > > > goal is for consistency when a specific guideline is followed.
> > > > I think we can have the naming rules in the edk2 C coding standard
> > > > spec and
> > > put these guidelines on the Wiki page.
> > > > Is that ok to have a link to Wiki page in the edk2 C coding standard spec?
> > > >
> > > > Abner
> > > >
> > > > >
> > > > > >
> > > > > > Abner
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > > To: Chang, Abner <Abner.Chang@...>;
> > devel@edk2.groups.io;
> > > > > > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil
> > > > > > > V L <sunilvl@...>; Kinney, Michael D
> > > > > > > <michael.d.kinney@...>
> > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > <Paul.Grimes@...>; He, Jiangang
> <Jiangang.He@...>;
> > > > > > > Andrew Fish <afish@...>
> > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > reconstruction for archs
> > > > > > >
> > > > > > > Caution: This message originated from an External Source. Use
> > > > > > > proper caution when opening attachments, clicking links, or
> > responding.
> > > > > > >
> > > > > > >
> > > > > > > Abner,
> > > > > > >
> > > > > > > I think another guideline is to minimize the number of
> > subdirectories.
> > > > > > >
> > > > > > > Only create them if it helps with the organization and long
> > > > > > > term maintenance of the component.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Chang, Abner <Abner.Chang@...>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > <sunilvl@...>
> > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > <Paul.Grimes@...>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@...>; Andrew Fish
> > > > > > > > <afish@...>
> > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > > reconstruction for archs
> > > > > > > >
> > > > > > > > [AMD Official Use Only - General]
> > > > > > > >
> > > > > > > > Hi Mike and Leif,
> > > > > > > > First of all, we don't use arch folder if the module is
> > > > > > > > mainly for a specific arch in obviously. So we will  have
> > > > > > > > both common and arch-specific
> > > > > > > files constructed under module/library root.
> > > > > > > >
> > > > > > >
> > > > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > ed
> > > > > > > k
> > > > > > > 2
> > > > > > >
> > > > >
> > >
> > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=05%7C01%7C
> A
> > > > > > > bner.Chan
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884
> > > > > > > e608e11a
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ
> > > > > > > sb3d8eyJWI
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> > > > > > > 000%7
> > > > > > > >
> > > > > > >
> > > > >
> >
> C%7C%7C&amp;sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> > > > > > > M%3D&amp;r
> > > > > > > > eserved=0
> > > > > > > > SmmCpuFeatureLib\Ia32
> > > > > > > > SmmCpuFeatureLib\X64
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLib.c
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c
> > > > > > > > SmmCpuFeatureLib\IntelSmmCPuFeaturesLib
> > > > > > > > SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib
> > > > > > > >
> > > > > > > >
> > > > > > > > > > Could we concatenate architectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> > > > > > > > Looks like below?
> > > > > > > >
> > > > > > > > CpuDxe\IA32_X64\IA32\abc.nasm
> > CpuDxe\IA32_X64\X64\abc.nasm
> > > > > > > > CpuDxe\IA32_X64\CpuDxe.c CpuDxe\IA32_X64\AmdCpuDxe.c
> > > > > > > > CpuDxe\IA32_X64\IntelCpuDxe.c CpuDxe\RiscV64\CpuDxe.c
> > > > > > > > CpuDxe\ARM\CpuDxe.c CpuDxe\
> > > > > > > >                CpuDxeCommon.c  // If required.
> > > > > > > >                 CpuDxe.inf               // Use INF section arch modifier for
> X86,
> > > > > RISC-V
> > > > > > > and ARM.
> > > > > > > >                 CpuDxeAmd.inf        // Separate INF for AMD.
> > > > > > > >
> > > > > > > > Seems ok, but is AARCH64_RISCV64 a real case?  Or it means
> > > > > > > > we can create a folder "AARCH64_RISCV64" when there are
> some
> > > > > > > > common
> > > > > files
> > > > > > > shared by AARCH64 and RISCV64?
> > > > > > > >
> > > > > > > > For the 32/64 bit support, it can still stay under module
> > > > > > > > root and don't need to assign a folder for them unless the
> > > > > > > > arch has the different
> > > > > > > implementation.
> > > > > > > > Regards,
> > > > > > > > Abner
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io; quic_llindhol@...;
> > > > > > > > > Chang, Abner <Abner.Chang@...>; Ni, Ray
> > > > > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > <sunilvl@...>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@...>
> > > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > <Paul.Grimes@...>; He, Jiangang
> > <Jiangang.He@...>;
> > > > > > > > > Andrew Fish <afish@...>
> > > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > > > reconstruction for archs
> > > > > > > > >
> > > > > > > > > Caution: This message originated from an External Source.
> > > > > > > > > Use proper caution when opening attachments, clicking
> > > > > > > > > links, or
> > > > > responding.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Leif,
> > > > > > > > >
> > > > > > > > > Concatenation is a good idea.  Makes it more obvious and
> > > > > > > > > can be easily adopted for new CPU archs.
> > > > > > > > >
> > > > > > > > > There is an additional case where an implementation does
> > > > > > > > > not have differences based on CPU Arch or Vendor, but it
> > > > > > > > > does have differences based on the bit- width of the CPU.
> > > > > > > > > Take BaseSafeIntLib as
> > > > > > > an example.
> > > > > > > > > It has source files for 32-bit CPUs, 64-bit CPUs, and CPU
> > > > > > > > > arch specific file for Ebc because Ebc adapts to 32-bit or
> > > > > > > > > 64-bit depending on the CPU type the EBC Interpreter is
> running.
> > > > > > > > >
> > > > > > > > > MdePkg/Library/BaseSafeIntLib/
> > > > > > > > >   BaseSafeIntLib.inf
> > > > > > > > >   SafeIntLib.c
> > > > > > > > >   SafeIntLib32.c
> > > > > > > > >   SafeIntLib64.c
> > > > > > > > >   SafeIntLibEbc.c
> > > > > > > > >
> > > > > > > > > Should we add "32" and "64" as supported suffices in file
> names?
> > > > > > > > >
> > > > > > > > > If we wanted to put type content into a subdirectory, what
> > > > > > > > > would be the suggested directory name for "32" and "64".
> > > > > > > > > Or do we want to require this type of difference to always
> > > > > > > > > be files in top level directory of
> > > > > > > the modules/library?
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@...>; Chang, Abner
> > > > > > > <Abner.Chang@...>;
> > > > > > > > > > Ni, Ray <ray.ni@...>; Attar, AbdulLateef (Abdul
> > > > > > > > > > Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > > <sunilvl@...>
> > > > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > <Paul.Grimes@...>;
> > > > > > > > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> > > > > > > <afish@...>
> > > > > > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module
> > > > > > > > > > reconstruction for archs
> > > > > > > > > >
> > > > > > > > > > I agree similar things will certainly happen for
> > > > > > > > > > ARM/AARCH64, which will probably be noticeable when I
> > > > > > > > > > start eradicating ArmPkg and putting the arch-standard
> > > > > > > > > > bits into
> > > (mostly) MdePkg.
> > > > > > > > > >
> > > > > > > > > > But I like the ability to see already at the filesystem
> > > > > > > > > > level which files belong to the architecture I'm
> > > > > > > > > > currently working on and
> > > > > > > which don't.
> > > > > > > > > >
> > > > > > > > > > Could we concatenate architectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> > > > > > > > > >
> > > > > > > > > > /
> > > > > > > > > >      Leif
> > > > > > > > > >
> > > > > > > > > > On 2022-09-30 08:28, Michael D Kinney wrote:
> > > > > > > > > > > Hi Abner,
> > > > > > > > > > >
> > > > > > > > > > > One comment is on adding a new CPU type dir name of
> 'X86'
> > > > > > > > > > > for content that is common for IA32/X64.
> > > > > > > > > > >
> > > > > > > > > > > I can imagine a similar case for ARM/AARCH64 and for
> > > > > > > > > > > the RISCV (32, 64, 128) cases.
> > > > > > > > > > >
> > > > > > > > > > > I think I would prefer to drop X86 and if there are
> > > > > > > > > > > files that are common to multiple CPU architectures
> > > > > > > > > > > then they are considered common and are in top
> > > > > > > > > > > directory of module and the file header and INF file
> > > > > > > > > > > can clearly document which CPU archs the file
> > > > > > > applies.
> > > > > > > > > > >
> > > > > > > > > > > Mike
> > > > > > > > > > >
> > > > > > > > > > >> -----Original Message-----
> > > > > > > > > > >> From: Chang, Abner <Abner.Chang@...>
> > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > > >> <sunilvl@...>; devel@edk2.groups.io;
> > > > > > > > > > >> Kinney, Michael D <michael.d.kinney@...>
> > > > > > > > > > >> Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >> <Paul.Grimes@...>; He, Jiangang
> > > > > <Jiangang.He@...>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >> <afish@...>
> > > > > > > > > > >> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >> module reconstruction for archs
> > > > > > > > > > >>
> > > > > > > > > > >> [AMD Official Use Only - General]
> > > > > > > > > > >>
> > > > > > > > > > >> Thanks Ray, here are my responses.
> > > > > > > > > > >> https://nam11.safelinks.protection.outlook.com/?url=h
> > > > > > > > > > >> tt
> > > > > > > > > > >> ps%3
> > > > > > > > > > >> A%2F
> > > > > > > > > > >> %2Fg
> > > > > > > > > > >> ithub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > CCodingStandardsSpecification
> > > > > > > > > > >> %2Fp
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2
> > > > > > > f4
> > > > > > > > > 86f
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> > > > > > > > > 3800
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > > > JQ
> > > > > > > > > IjoiV
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > > > > > =
> > > > > > > > > HAq
> > > > > > > > > > >>
> > > > > > >
> > > > >
> > ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&amp;reserved=0
> > > > > > > > > > >>
> > > > > > > > > > >> @Kinney, Michael D we may also need your
> > > > > > > > > > >> clarification on the
> > > > > > > comments.
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>> -----Original Message-----
> > > > > > > > > > >>> From: Ni, Ray <ray.ni@...>
> > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@...>; Chang, Abner
> > > > > > > > > > >>> <Abner.Chang@...>; Sunil V L
> > > > > > > > > > >>> <sunilvl@...>; devel@edk2.groups.io
> > > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@...>; He, Jiangang
> > > > > <Jiangang.He@...>;
> > > > > > > > > > >>> Leif Lindholm <quic_llindhol@...>; Andrew
> > > > > > > > > > >>> Fish <afish@...>
> > > > > > > > > > >>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>> module reconstruction for archs
> > > > > > > > > > >>>
> > > > > > > > > > >>> Caution: This message originated from an External
> Source.
> > > > > > > > > > >>> Use proper caution when opening attachments,
> > > > > > > > > > >>> clicking links, or
> > > > > > > responding.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Abner,
> > > > > > > > > > >>> Comments in
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>>
> CCodingStandardsSpecification%2Fpull%2F2%23pullreque
> > > > > > > > > > >>> st
> > > > > > > > > > >>> revi
> > > > > > > > > > >>> ew-
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1124763311&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> 7C%7C%7C&amp;sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> > > > > > > > > > >>> 8jo8%3D&amp;reserved=0
> > > > > > > > > > >>>
> > > > > > > > > > >>> We can discuss more in tomorrow's meeting.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>>> <AbdulLateef.Attar@...>
> > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chang, Abner <Abner.Chang@...>; Sunil V L
> > > > > > > > > > >>>> <sunilvl@...>; devel@edk2.groups.io;
> > > > > > > > > > >>>> Ni, Ray <ray.ni@...>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@...>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@...>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>> <afish@...>
> > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module reconstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Hi Abner,
> > > > > > > > > > >>>>      Looks good to me.
> > > > > > > > > > >>>> Reviewed-by:  Abdul Lateef Attar <abdattar@...>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> AbduL
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Chang, Abner <Abner.Chang@...>
> > > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > > >>>> To: Sunil V L <sunilvl@...>;
> > > > > > > > > > >>>> devel@edk2.groups.io; ray.ni@...
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@...>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@...>; Attar, AbdulLateef
> > > > > > > > > > >>>> (Abdul
> > > > > > > > > > >>>> Lateef) <AbdulLateef.Attar@...>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>> <afish@...>
> > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module reconstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> [AMD Official Use Only - General]
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> I just had created PR to update edkII C coding
> > > > > > > > > > >>>> standard spec for the file and directory naming. We
> > > > > > > > > > >>>> can review and confirm this update first and then
> > > > > > > > > > >>>> go back to the principles of EDK2 module
> > > > > > > > > reconstruction for archs.
> > > > > > > > > > >>>> Here is the PR:
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>> &amp;data=05%7C01%7CAbner.Chang%40amd.c
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> > > > > > > > > > >>> d994e18
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> > > > > > > > > > >>> WIjoiMC4wLj
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > > > > > > > > > >>> 7C%7C&a
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
> > > > > > > > > > >>> mp;reserv
> > > > > > > > > > >>>> ed=0
> > > > > > > > > > >>>> CCodingStandardsSpecification/pull/2
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> The naming rule is mainly for the new module or new
> file
> > IMO.
> > > > > > > > > > >>>> Some existing module may not meet the guidelines
> > > > > > > > > > >>>> mentioned in this
> > > > > > > > > spec.
> > > > > > > > > > >>>> Thus we need the principles of EDK2 module
> > > > > > > > > > >>>> reconstruction on the existing module to support
> > > > > > > > > > >>>> other processor archs and not impacting the
> > > > > > > > > > >>> existing platforms (e.g.
> > > > > > > > > > >>>> rename the INF file or directory to meet the
> guidelines).
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Sunil, seems RISC-V CpuDxe meet the guideline.
> > > > > > > > > > >>>> Please check
> > > > > it.
> > > > > > > > > > >>>> Just feel that having  CpuDxe.c to Riscv64 folder
> > > > > > > > > > >>>> is not quite a best solution. I think at least we
> > > > > > > > > > >>>> can abstract the protocol structure and protocol
> > > > > > > > > > >>>> installation under CpuDxe\ and have the arch
> > > > > > > > > > >>>> implementation under arch folder. We can discuss
> > > > > > > > > > >>>> this later after we confirming the
> > > > > > > > > > >>> guideline and principles.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> Abner
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>> -----Original Message-----
> > > > > > > > > > >>>>> From: Sunil V L <sunilvl@...>
> > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: devel@edk2.groups.io; ray.ni@...
> > > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang@...>; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D <michael.d.kinney@...>; lichao
> > > > > > > > > > >>>>> <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>>> <Paul.Grimes@...>; He, Jiangang
> > > > > > > > > > >>>>> <Jiangang.He@...>; Attar, AbdulLateef (Abdul
> > > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar@...>; Leif
> Lindholm
> > > > > > > > > > >>>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>>> <afish@...>
> > > > > > > > > > >>>>> Subject: Re: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>>> module reconstruction for archs
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Caution: This message originated from an External
> > Source.
> > > > > > > > > > >>>>> Use proper caution when opening attachments,
> > > > > > > > > > >>>>> clicking links, or
> > > > > > > responding.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray
> > wrote:
> > > > > > > > > > >>>>> Hi Ray,
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    1.  When a new arch's implementation is
> > > > > > > > > > >>>>>> introduced to the existing
> > > > > > > > > > >>>>> module which was developed for the specific arch:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    1.  The folder reconstruction:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    *   Create arch folder for the existing arch
> > implementation
> > > > > > > > > > >>>>>> [Ray] Do you move existing arch implementation to
> > > > > > > > > > >>>>>> that arch
> > > > > > > folder?
> > > > > > > > > > >>>>>> It will
> > > > > > > > > > >>>>> break existing platforms a lot.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    *   Create the arch folder for the new introduced
> > arch
> > > > > > > > > > >>>>>> [Ray] I agree. But if we don't create arch folder
> > > > > > > > > > >>>>>> for existing arch
> > > > > > > > > > >>>>> implementation, the pkg layout will be a mess.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> [Ray] Hard for me to understand all the principles
> here.
> > > > > > > > > > >>>>>> Maybe we review
> > > > > > > > > > >>>>> existing code including to-be-upstreamed code and
> > > > > > > > > > >>>>> decide how
> > > > > > > to go.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Could you please take a look below changes which
> > > > > > > > > > >>>>> is trying to add RISC-V support for CpuDxe?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749&amp;
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&amp;reserved=0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&amp;da
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&amp;reserv
> > > > > > > > > > >>>>> ed=0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> What do you suggest with above example?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 1) Common INF for all architectures - but modify
> > > > > > > > > > >>>>> INF alone, no
> > > > > > > > > > >>>>> X86 folder creation.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This is what I have done in the commit above. May
> > > > > > > > > > >>>>> be of least impact to existing code since it is only INF
> > change.
> > > > > > > > > > >>>>> But like you mentioned this is bit weird that X86
> > > > > > > > > > >>>>> files will remain in root folder directly along
> > > > > > > > > > >>>>> with some common
> > > > > files.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 2) Common INF (CpuDxe.inf) + create arch folders
> > > > > > > > > > >>>>> X86, X64, IA32,
> > > > > > > > > > >>>>> RiscV64 etc
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> IMO, this is probably the best approach. What
> > > > > > > > > > >>>>> would be the challenges with this?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 3) Separate INF for arch like CpuDxe.inf for x86,
> > > > > > > > > > >>>>> CpuDxeRiscV64.inf for
> > > > > > > > > > >>>> RISC-V.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This again probably is not a good idea.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 4) If the module/library is specific to one arch (ex:
> > > > > > > > > > >>>>> SMM(X86), SBI(RISC-V)), then create separate INF.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Thanks!
> > > > > > > > > > >>>>> Sunil
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >


Re: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt OpensslLibs

Yao, Jiewen
 

Thank you Mike.

1) I like the idea to combine multiple OpensslLibIA32/X64.inf into one OpensslLibAccel.inf.
Also the cleanup looks good to me.

2) I also like the summary in readme in https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_MergeOptimizedOpensslLibs/CryptoPkg
I notice some algorithms are listed Y(Deprecated) but N(Don't Use), such as Tdes, Arc4, Aes.Ecb*.
But I don't see the use case for those algorithms and I suggest a Y(Deprecated) have Y(Don't Use).

3) About PcdOpensslEcEnabled
I notice it is used in existing code - https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_MergeOptimizedOpensslLibs/CryptoPkg/Library/TlsLib/TlsConfig.c#L1139
Is this right way?

Thank you
Yao, Jiewen

-----Original Message-----
From: Kinney, Michael D <michael.d.kinney@...>
Sent: Tuesday, October 11, 2022 11:04 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang,
Guomin <guomin.jiang@...>; Zurcher, Christopher
<christopher.zurcher@...>; Rebecca Cran
<quic_rcran@...>; Ard Biesheuvel <ardb@...>
Subject: [Patch 00/12] CryptoPkg: Remove EC PCD and merge perf opt
OpensslLibs

The recent addition of the Ecliptic Curve (EC) feature and the performance
optimization features increased the complexity for platforms to integrate
and enable these features. This series simplifies the platform configuration
as much as possible and improves the ability to manage the the size impact
of cryptographic services in each FW phase. A Readme.md is also added
that
provides an overview of the CryptoPkg design and features along with
platform
integration recommendations.

This series also addresses private library class declarations missing from
CryptoPkg.dec and library instances not producing all the APIs defined
by the library classes. A review of the CryptoPkg EDK II meta data files
identified
a number of additional cleanups. The CryptoPkg.dsc file was also updated to
improve CI coverage for future CryptoPkg changes and identified some
unit test bug fixes.

PR: https://github.com/tianocore/edk2/pull/3443
Branch:
https://github.com/mdkinney/edk2/tree/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs
Readme:
https://github.com/mdkinney/edk2/blob/CryptoPkg_RemoveEcPcd_Merge
OptimizedOpensslLibs/CryptoPkg/Readme.md

Change Summary
==============
* Document disabled/deprecated cryptographic services
* Add missing UNI files in BaseCryptLib
* Update BaseCryptLib internal functions to be STATIC and remove EFIAPI
* Add GLOBAL_REMOVE_IF_UNREFERENCED to BaseCryptLib global
variables
* Fix BaseCryptLib unit tests
* Cleanup BaseCryptLib and TlsLib INF files and
* Move SysCall/inet_pton.c from BaseCryptLib to TlsLib that uses it.
* Merge 4 performance optimized INFs into OpensslLib*Accel.inf
* Remove use of PcdOpensslEcEnabled and use OpensslLibFull*.inf instead
* Add OpensslLib and IntrinsicLib to CryptoPkg.dec as private library classes
* Update all OpensslLib instances to always produce all APIs in OpensslLib
class
* Move PrintLib dependency from OpensslLib INF files to BaseCryptLib INF
files
* Update CryptoPkg.dsc files to provide full CI test coverage across all the
supported combinations of OpensslLib, BaseCryptLib, and TlsLib instances.
* Remove PACKAGE profile from CryptoPkg.dsc and add
TARGET_UNIT_TESTS
profile. Adding TARGET_UNIT_TESTS profile is required to prevent a few
unit
test artifacts being included in non unit test builds of components.
* Add CryptoPkg Readme.md with overview and platform integration
details.
* Update host-based unit tests to always use OpensslLibFull.inf and add
unit
test coverage for OpensslLibFullAccel.inf.
* Add Readme.md with CryptoPkg overview and platform integration
documentation

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Cc: Christopher Zurcher <christopher.zurcher@...>
Cc: Rebecca Cran <quic_rcran@...>
Cc: Ard Biesheuvel <ardb@...>
Signed-off-by: Michael D Kinney <michael.d.kinney@...>

Michael D Kinney (12):
CryptoPkg: Document and disable deprecated crypto services
CryptoPkg/Library/BaseCryptLib: Add missing UNI file and fix format
CryptoPkg/Library/BaseCryptLib: Update internal functions/variables
CryptoPkg/Test/UnitTest/Library/BaseCryptLib: Unit test fixes
CryptoPkg/Library: Cleanup BaseCryptLib and TlsLib
CryptoPkg/Library/OpensslLib: Combine all performance optimized INFs
CryptoPkg/Library/OpensslLib: Produce consistent set of APIs
CryptoPkg/Library/OpensslLib: Remove PrintLib from INF files
CryptoPkg: Remove PcdOpensslEcEnabled from CryptoPkg.dec
CryptoPkg: Update DSC to improve CI test coverage
CryptoPkg: Fixed host-based unit tests
CryptoPkg: Add Readme.md

CryptoPkg/CryptoPkg.ci.yaml | 11 +-
CryptoPkg/CryptoPkg.dec | 42 +-
CryptoPkg/CryptoPkg.dsc | 460 +++++++++---
.../Pcd/PcdCryptoServiceFamilyEnable.h | 122 +--
.../Library/BaseCryptLib/BaseCryptLib.inf | 10 +-
.../Library/BaseCryptLib/BaseCryptLib.uni | 2 -
.../Library/BaseCryptLib/Hmac/CryptHmac.c | 7 +
.../Library/BaseCryptLib/Kdf/CryptHkdf.c | 5 +-
.../Library/BaseCryptLib/PeiCryptLib.inf | 8 +-
.../Library/BaseCryptLib/PeiCryptLib.uni | 2 -
.../BaseCryptLib/Pk/CryptAuthenticode.c | 2 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyCommon.c | 3 +-
.../BaseCryptLib/Pk/CryptPkcs7VerifyEku.c | 3 +
CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 44 +-
.../Library/BaseCryptLib/RuntimeCryptLib.inf | 9 +-
.../Library/BaseCryptLib/RuntimeCryptLib.uni | 2 -
.../Library/BaseCryptLib/SecCryptLib.inf | 13 +-
.../{SmmCryptLib.uni => SecCryptLib.uni} | 11 +-
.../Library/BaseCryptLib/SmmCryptLib.inf | 12 -
.../Library/BaseCryptLib/SmmCryptLib.uni | 2 -
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 22 +-
.../Library/Include/openssl/opensslconf.h | 328 +++++++-
.../Include/openssl/opensslconf_generated.h | 333 ---------
CryptoPkg/Library/OpensslLib/EcSm2Null.c | 291 ++++++++
CryptoPkg/Library/OpensslLib/OpensslLib.inf | 133 ++--
CryptoPkg/Library/OpensslLib/OpensslLib.uni | 10 +-
...nsslLibIa32Gcc.inf => OpensslLibAccel.inf} | 189 +++--
.../Library/OpensslLib/OpensslLibAccel.uni | 14 +
.../OpensslLib/OpensslLibConstructor.c | 6 +-
.../Library/OpensslLib/OpensslLibCrypto.inf | 185 +++--
.../Library/OpensslLib/OpensslLibCrypto.uni | 11 +-
.../{OpensslLib.inf => OpensslLibFull.inf} | 143 ++--
.../{OpensslLib.uni => OpensslLibFull.uni} | 10 +-
...sslLibIa32.inf => OpensslLibFullAccel.inf} | 192 +++--
.../OpensslLib/OpensslLibFullAccel.uni | 14 +
.../Library/OpensslLib/OpensslLibX64.inf | 706 ------------------
.../Library/OpensslLib/OpensslLibX64Gcc.inf | 706 ------------------
CryptoPkg/Library/OpensslLib/SslNull.c | 405 ++++++++++
.../SysCall/inet_pton.c | 0
CryptoPkg/Library/TlsLib/TlsConfig.c | 2 +-
CryptoPkg/Library/TlsLib/TlsLib.inf | 12 +-
CryptoPkg/Private/Library/IntrinsicLib.h | 16 +
CryptoPkg/Private/Library/OpensslLib.h | 14 +
CryptoPkg/Readme.md | 498 ++++++++++++
CryptoPkg/Test/CryptoPkgHostUnitTest.dsc | 17 +-
.../UnitTest/Library/BaseCryptLib/HmacTests.c | 17 +-
.../UnitTest/Library/BaseCryptLib/TSTests.c | 2 +-
.../TestBaseCryptLibHostAccel.inf | 55 ++
48 files changed, 2667 insertions(+), 2434 deletions(-)
copy CryptoPkg/Library/BaseCryptLib/{SmmCryptLib.uni =>
SecCryptLib.uni} (74%)
delete mode 100644
CryptoPkg/Library/Include/openssl/opensslconf_generated.h
create mode 100644 CryptoPkg/Library/OpensslLib/EcSm2Null.c
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32Gcc.inf =>
OpensslLibAccel.inf} (79%)
create mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibAccel.uni
copy CryptoPkg/Library/OpensslLib/{OpensslLib.inf => OpensslLibFull.inf}
(80%)
copy CryptoPkg/Library/OpensslLib/{OpensslLib.uni => OpensslLibFull.uni}
(56%)
rename CryptoPkg/Library/OpensslLib/{OpensslLibIa32.inf =>
OpensslLibFullAccel.inf} (79%)
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.uni
delete mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibX64.inf
delete mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf
create mode 100644 CryptoPkg/Library/OpensslLib/SslNull.c
rename CryptoPkg/Library/{BaseCryptLib => TlsLib}/SysCall/inet_pton.c
(100%)
create mode 100644 CryptoPkg/Private/Library/IntrinsicLib.h
create mode 100644 CryptoPkg/Private/Library/OpensslLib.h
create mode 100644 CryptoPkg/Readme.md
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/TestBaseCryptLibHostAccel.i
nf

--
2.37.1.windows.1


Re: The principles of EDK2 module reconstruction for archs

Chang, Abner
 

[AMD Official Use Only - General]

 

I was thinking to remove ‘_’ from edkII coding standard if there is no use case or rare people like it appears in file/dir name.

 

Abner

 

From: Kinney, Michael D <michael.d.kinney@...>
Sent: Wednesday, October 12, 2022 4:16 AM
To: Chang, Abner <Abner.Chang@...>; Ni, Ray <ray.ni@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>; Kinney, Michael D <michael.d.kinney@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.

 

I do not have a strong opinion either way. 

 

Some searching indicates there is some debate between use of spaces, underscores, and dashes in filenames.

 

The filename/dirname requirements for EDK II allow ‘_’ and ‘-‘ as long as they are not the first or last character.  Spaces ‘ ‘ are not allowed.

 

[A-Za-z][_A-Za-z0-9-]*[A-Za-z0-9]+

 

Mike

 

From: Chang, Abner <Abner.Chang@...>
Sent: Monday, October 10, 2022 7:21 PM
To: Ni, Ray <ray.ni@...>; Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io; quic_llindhol@...; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

[AMD Official Use Only - General]

 

Removing '_' seems make the folder hard to read, but not too bad to me though. I am fine with removing '_'. 

Leif and Mike, how do you think?

 

Ex:

Riscv64Ia32X64 compares Riscv64_Ia32_X64.

ArmAArch64 compares to Arm_AArch64.

 

Abner


From: Ni, Ray <ray.ni@...>
Sent: Tuesday, October 11, 2022 9:51:24 AM
To: Chang, Abner <Abner.Chang@...>; Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io <devel@edk2.groups.io>; quic_llindhol@... <quic_llindhol@...>; Attar, AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
Cc: lichao <lichao@...>; Kirkendall, Garrett <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He, Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for archs

 

Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.


Abner, Mike, Leif,
"Ia32_X64" is the first case in edk2 that underscore "_" is used as part of file path.
Shall we use "Ia32X64" (removing "_")?

I know that Sunil is following the guideline.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F94912%3Fp%3D%252C%252C%252C20%252C0%252C0%252C0%253A%253Arecentpostdate%252Fsticky%252C%252CUefiCpuPkg%252FCpuTimerLib%252C20%252C2%252C0%252C94233015&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=5wOiTArZyySLos4A%2FQHOC3gryUIZ8K4SgNxeTwfANMY%3D&amp;reserved=0

Thanks,
Ray

> -----Original Message-----
> From: Chang, Abner <Abner.Chang@...>
> Sent: Thursday, October 6, 2022 4:37 PM
> To: Kinney, Michael D <michael.d.kinney@...>; devel@edk2.groups.io;
> quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> <sunilvl@...>
> Cc: lichao <lichao@...>; Kirkendall, Garrett
> <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>; He,
> Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> archs
>
> [AMD Official Use Only - General]
>
> Here is the update of the Wiki page for the consistency with edk2 C Coding
> Standard Spec.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchangab%2Ftianocore.github.io%2Fwiki%2FThe-Guidelines-of-&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=i5RSe41cuzD48VB32KeG0M3Vp7T%2FEqe3ncKNfGCjfIU%3D&amp;reserved=0
> Reconstruct-EDK-II-Modules-for-Processor-Architectures-and-Vendors'-
> Implementation
>
> Thanks
> Abner
>
> > -----Original Message-----
> > From: Chang, Abner
> > Sent: Wednesday, October 5, 2022 1:39 PM
> > To: Kinney, Michael D <michael.d.kinney@...>;
> devel@edk2.groups.io;
> > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> > (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > <sunilvl@...>
> > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
> He,
> > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction for
> > archs
> >
> > [AMD Official Use Only - General]
> >
> > PR updated
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore-docs%2Fedk2-&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C1c6973cf412c4ba09ef908daab2b1ea6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638010498938218357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=YDYXODgrQhuLlP8DTsLr%2F4ct2JH3aw8y2SPg8tk5fgg%3D&amp;reserved=0
> > CCodingStandardsSpecification/pull/2/commits. Please check it.
> >
> > Thanks
> > Abner
> >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@...>
> > > Sent: Tuesday, October 4, 2022 10:18 PM
> > > To: Chang, Abner <Abner.Chang@...>; devel@edk2.groups.io;
> > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > <sunilvl@...>; Kinney, Michael D
> > > <michael.d.kinney@...>
> > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > <Garrett.Kirkendall@...>; Grimes, Paul <Paul.Grimes@...>;
> > He,
> > > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > > Subject: RE: [edk2-devel] The principles of EDK2 module reconstruction
> > > for archs
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > I would not add link to Wiki from EDK II C Coding Standard Specification.
> > >
> > > We want documents published from tianocore-docs to support
> standalone
> > > formats such as PDF and if there is a link in one of those documents,
> > > we want to know that it is a permanent link.  I am concerned we may
> > > reorganize Wiki pages and links in PDF would become stale.
> > >
> > > Links from Wiki to specs makes sense.
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: Chang, Abner <Abner.Chang@...>
> > > > Sent: Tuesday, October 4, 2022 7:05 AM
> > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > <AbdulLateef.Attar@...>; Sunil V L <sunilvl@...>
> > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > <Garrett.Kirkendall@...>; Grimes, Paul
> <Paul.Grimes@...>;
> > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> <afish@...>
> > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > reconstruction for archs
> > > >
> > > > [AMD Official Use Only - General]
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > Sent: Tuesday, October 4, 2022 12:54 AM
> > > > > To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@...>;
> > > > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > <sunilvl@...>; Kinney, Michael D
> > > > > <michael.d.kinney@...>
> > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > <Paul.Grimes@...>;
> > > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> > <afish@...>
> > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > reconstruction for archs
> > > > >
> > > > > Caution: This message originated from an External Source. Use
> > > > > proper caution when opening attachments, clicking links, or
> responding.
> > > > >
> > > > >
> > > > > Hi Abner,
> > > > >
> > > > > responses below.
> > > > >
> > > > > Mike
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > > > > > Chang, Abner via groups.io
> > > > > > Sent: Sunday, October 2, 2022 10:37 PM
> > > > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > <sunilvl@...>
> > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > <Paul.Grimes@...>;
> > > > > He,
> > > > > > Jiangang <Jiangang.He@...>; Andrew Fish <afish@...>
> > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module
> > > > > > reconstruction for archs
> > > > > >
> > > > > > [AMD Official Use Only - General]
> > > > > >
> > > > > > Mike,
> > > > > > Agree. This can be mentioned on the Wiki page. Also, this would
> > > > > > require the discussion between maintainer and contributor. I
> > > > > > would say
> > > > > maintainer has the responsibility to make sure an arch folder is
> > > > > only created when necessary.
> > > > >
> > > > > Agreed
> > > > Ok, I will update Directory and file names section.
> > > > >
> > > > > >
> > > > > > Do you agree with the arch concatenate solution for arch folder?
> > > > > > That
> > > > > means IA32_X64 instead of X86 (I am fine with this)?
> > > > >
> > > > > Yes
> > > > >
> > > > > > However, there is one scenario. Assume there were two arch
> > > > > > folders
> > > > > > IA32_X64 and RISCV64. Then ARM shares the code with IA32_X64,
> we
> > > > > > may
> > > > > rename IA32_X64 to IA32_X64_ARM.
> > > > > > Although the directory naming is not real a problem to the
> > > > > > build, a separate ARM folder seems easier? Or we can just allow
> > > > > > this kind of folder
> > > > > naming structure, however we let maintainer to make the decision?
> > > > >
> > > > > I would let the maintainer make the decision.  For your example,
> > > > > another approach may be to move the IA32_X64 content up a level so
> > > > > it is common and is used by IA32, X64, ARM.  And leave RISCV64
> > > > > folder for an arch that has special requirements.  I think having
> > > > > some flexibility in the guidelines is very beneficial.  The main
> > > > > goal is for consistency when a specific guideline is followed.
> > > > I think we can have the naming rules in the edk2 C coding standard
> > > > spec and
> > > put these guidelines on the Wiki page.
> > > > Is that ok to have a link to Wiki page in the edk2 C coding standard spec?
> > > >
> > > > Abner
> > > >
> > > > >
> > > > > >
> > > > > > Abner
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > > > Sent: Monday, October 3, 2022 1:18 PM
> > > > > > > To: Chang, Abner <Abner.Chang@...>;
> > devel@edk2.groups.io;
> > > > > > > quic_llindhol@...; Ni, Ray <ray.ni@...>; Attar,
> > > > > > > AbdulLateef (Abdul Lateef) <AbdulLateef.Attar@...>; Sunil
> > > > > > > V L <sunilvl@...>; Kinney, Michael D
> > > > > > > <michael.d.kinney@...>
> > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > <Paul.Grimes@...>; He, Jiangang
> <Jiangang.He@...>;
> > > > > > > Andrew Fish <afish@...>
> > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > reconstruction for archs
> > > > > > >
> > > > > > > Caution: This message originated from an External Source. Use
> > > > > > > proper caution when opening attachments, clicking links, or
> > responding.
> > > > > > >
> > > > > > >
> > > > > > > Abner,
> > > > > > >
> > > > > > > I think another guideline is to minimize the number of
> > subdirectories.
> > > > > > >
> > > > > > > Only create them if it helps with the organization and long
> > > > > > > term maintenance of the component.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Chang, Abner <Abner.Chang@...>
> > > > > > > > Sent: Sunday, October 2, 2022 8:13 PM
> > > > > > > > To: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > devel@edk2.groups.io; quic_llindhol@...; Ni, Ray
> > > > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > <sunilvl@...>
> > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > <Paul.Grimes@...>;
> > > > > > > He,
> > > > > > > > Jiangang <Jiangang.He@...>; Andrew Fish
> > > > > > > > <afish@...>
> > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > > reconstruction for archs
> > > > > > > >
> > > > > > > > [AMD Official Use Only - General]
> > > > > > > >
> > > > > > > > Hi Mike and Leif,
> > > > > > > > First of all, we don't use arch folder if the module is
> > > > > > > > mainly for a specific arch in obviously. So we will  have
> > > > > > > > both common and arch-specific
> > > > > > > files constructed under module/library root.
> > > > > > > >
> > > > > > >
> > > > >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > ed
> > > > > > > k
> > > > > > > 2
> > > > > > >
> > > > >
> > >
> > > .groups.io%2Fg%2Fdevel%2Fmessage%2F94567&amp;data=05%7C01%7C
> A
> > > > > > > bner.Chan
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> g%40amd.com%7Cd49cbbe6d3d942bd69a308daa4fea41b%7C3dd8961fe4884
> > > > > > > e608e11a
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 82d994e183d%7C0%7C0%7C638003710850252776%7CUnknown%7CTWFpbGZ
> > > > > > > sb3d8eyJWI
> > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> > > > > > > 000%7
> > > > > > > >
> > > > > > >
> > > > >
> >
> C%7C%7C&amp;sdata=eiLOC0G9WZWKqm2ALcAiKr7SPBP5AgDdAxogHlv5pI
> > > > > > > M%3D&amp;r
> > > > > > > > eserved=0
> > > > > > > > SmmCpuFeatureLib\Ia32
> > > > > > > > SmmCpuFeatureLib\X64
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLib.c
> > > > > > > > SmmCpuFeatureLib\SmmCpuFeatureLibCommon.c
> > > > > > > > SmmCpuFeatureLib\IntelSmmCPuFeaturesLib
> > > > > > > > SmmCpuFeatureLib\AmdlSmmCPuFeaturesLib
> > > > > > > >
> > > > > > > >
> > > > > > > > > > Could we concatenate architectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> > > > > > > > Looks like below?
> > > > > > > >
> > > > > > > > CpuDxe\IA32_X64\IA32\abc.nasm
> > CpuDxe\IA32_X64\X64\abc.nasm
> > > > > > > > CpuDxe\IA32_X64\CpuDxe.c CpuDxe\IA32_X64\AmdCpuDxe.c
> > > > > > > > CpuDxe\IA32_X64\IntelCpuDxe.c CpuDxe\RiscV64\CpuDxe.c
> > > > > > > > CpuDxe\ARM\CpuDxe.c CpuDxe\
> > > > > > > >                CpuDxeCommon.c  // If required.
> > > > > > > >                 CpuDxe.inf               // Use INF section arch modifier for
> X86,
> > > > > RISC-V
> > > > > > > and ARM.
> > > > > > > >                 CpuDxeAmd.inf        // Separate INF for AMD.
> > > > > > > >
> > > > > > > > Seems ok, but is AARCH64_RISCV64 a real case?  Or it means
> > > > > > > > we can create a folder "AARCH64_RISCV64" when there are
> some
> > > > > > > > common
> > > > > files
> > > > > > > shared by AARCH64 and RISCV64?
> > > > > > > >
> > > > > > > > For the 32/64 bit support, it can still stay under module
> > > > > > > > root and don't need to assign a folder for them unless the
> > > > > > > > arch has the different
> > > > > > > implementation.
> > > > > > > > Regards,
> > > > > > > > Abner
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Kinney, Michael D <michael.d.kinney@...>
> > > > > > > > > Sent: Saturday, October 1, 2022 2:52 AM
> > > > > > > > > To: devel@edk2.groups.io; quic_llindhol@...;
> > > > > > > > > Chang, Abner <Abner.Chang@...>; Ni, Ray
> > > > > > > > > <ray.ni@...>; Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > <sunilvl@...>; Kinney, Michael D
> > > > > > > > > <michael.d.kinney@...>
> > > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > <Paul.Grimes@...>; He, Jiangang
> > <Jiangang.He@...>;
> > > > > > > > > Andrew Fish <afish@...>
> > > > > > > > > Subject: RE: [edk2-devel] The principles of EDK2 module
> > > > > > > > > reconstruction for archs
> > > > > > > > >
> > > > > > > > > Caution: This message originated from an External Source.
> > > > > > > > > Use proper caution when opening attachments, clicking
> > > > > > > > > links, or
> > > > > responding.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Leif,
> > > > > > > > >
> > > > > > > > > Concatenation is a good idea.  Makes it more obvious and
> > > > > > > > > can be easily adopted for new CPU archs.
> > > > > > > > >
> > > > > > > > > There is an additional case where an implementation does
> > > > > > > > > not have differences based on CPU Arch or Vendor, but it
> > > > > > > > > does have differences based on the bit- width of the CPU.
> > > > > > > > > Take BaseSafeIntLib as
> > > > > > > an example.
> > > > > > > > > It has source files for 32-bit CPUs, 64-bit CPUs, and CPU
> > > > > > > > > arch specific file for Ebc because Ebc adapts to 32-bit or
> > > > > > > > > 64-bit depending on the CPU type the EBC Interpreter is
> running.
> > > > > > > > >
> > > > > > > > > MdePkg/Library/BaseSafeIntLib/
> > > > > > > > >   BaseSafeIntLib.inf
> > > > > > > > >   SafeIntLib.c
> > > > > > > > >   SafeIntLib32.c
> > > > > > > > >   SafeIntLib64.c
> > > > > > > > >   SafeIntLibEbc.c
> > > > > > > > >
> > > > > > > > > Should we add "32" and "64" as supported suffices in file
> names?
> > > > > > > > >
> > > > > > > > > If we wanted to put type content into a subdirectory, what
> > > > > > > > > would be the suggested directory name for "32" and "64".
> > > > > > > > > Or do we want to require this type of difference to always
> > > > > > > > > be files in top level directory of
> > > > > > > the modules/library?
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > >
> > > > > > > > > Mike
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: devel@edk2.groups.io <devel@edk2.groups.io> On
> > > > > > > > > > Behalf Of Leif Lindholm
> > > > > > > > > > Sent: Friday, September 30, 2022 9:09 AM
> > > > > > > > > > To: devel@edk2.groups.io; Kinney, Michael D
> > > > > > > > > > <michael.d.kinney@...>; Chang, Abner
> > > > > > > <Abner.Chang@...>;
> > > > > > > > > > Ni, Ray <ray.ni@...>; Attar, AbdulLateef (Abdul
> > > > > > > > > > Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > > <sunilvl@...>
> > > > > > > > > > Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > <Paul.Grimes@...>;
> > > > > > > > > > He, Jiangang <Jiangang.He@...>; Andrew Fish
> > > > > > > <afish@...>
> > > > > > > > > > Subject: Re: [edk2-devel] The principles of EDK2 module
> > > > > > > > > > reconstruction for archs
> > > > > > > > > >
> > > > > > > > > > I agree similar things will certainly happen for
> > > > > > > > > > ARM/AARCH64, which will probably be noticeable when I
> > > > > > > > > > start eradicating ArmPkg and putting the arch-standard
> > > > > > > > > > bits into
> > > (mostly) MdePkg.
> > > > > > > > > >
> > > > > > > > > > But I like the ability to see already at the filesystem
> > > > > > > > > > level which files belong to the architecture I'm
> > > > > > > > > > currently working on and
> > > > > > > which don't.
> > > > > > > > > >
> > > > > > > > > > Could we concatenate architectures?
> > > > > > > > > > I.e. AARCH64_ARM, IA32_X64, AARCH64_RISCV64... ?
> > > > > > > > > >
> > > > > > > > > > /
> > > > > > > > > >      Leif
> > > > > > > > > >
> > > > > > > > > > On 2022-09-30 08:28, Michael D Kinney wrote:
> > > > > > > > > > > Hi Abner,
> > > > > > > > > > >
> > > > > > > > > > > One comment is on adding a new CPU type dir name of
> 'X86'
> > > > > > > > > > > for content that is common for IA32/X64.
> > > > > > > > > > >
> > > > > > > > > > > I can imagine a similar case for ARM/AARCH64 and for
> > > > > > > > > > > the RISCV (32, 64, 128) cases.
> > > > > > > > > > >
> > > > > > > > > > > I think I would prefer to drop X86 and if there are
> > > > > > > > > > > files that are common to multiple CPU architectures
> > > > > > > > > > > then they are considered common and are in top
> > > > > > > > > > > directory of module and the file header and INF file
> > > > > > > > > > > can clearly document which CPU archs the file
> > > > > > > applies.
> > > > > > > > > > >
> > > > > > > > > > > Mike
> > > > > > > > > > >
> > > > > > > > > > >> -----Original Message-----
> > > > > > > > > > >> From: Chang, Abner <Abner.Chang@...>
> > > > > > > > > > >> Sent: Friday, September 30, 2022 12:11 AM
> > > > > > > > > > >> To: Ni, Ray <ray.ni@...>; Attar, AbdulLateef
> > > > > > > > > > >> (Abdul
> > > > > > > > > > >> Lateef) <AbdulLateef.Attar@...>; Sunil V L
> > > > > > > > > > >> <sunilvl@...>; devel@edk2.groups.io;
> > > > > > > > > > >> Kinney, Michael D <michael.d.kinney@...>
> > > > > > > > > > >> Cc: lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >> <Paul.Grimes@...>; He, Jiangang
> > > > > <Jiangang.He@...>;
> > > > > > > Leif
> > > > > > > > > > >> Lindholm <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >> <afish@...>
> > > > > > > > > > >> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >> module reconstruction for archs
> > > > > > > > > > >>
> > > > > > > > > > >> [AMD Official Use Only - General]
> > > > > > > > > > >>
> > > > > > > > > > >> Thanks Ray, here are my responses.
> > > > > > > > > > >> https://nam11.safelinks.protection.outlook.com/?url=h
> > > > > > > > > > >> tt
> > > > > > > > > > >> ps%3
> > > > > > > > > > >> A%2F
> > > > > > > > > > >> %2Fg
> > > > > > > > > > >> ithub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > CCodingStandardsSpecification
> > > > > > > > > > >> %2Fp
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ull%2F2&amp;data=05%7C01%7CAbner.Chang%40amd.com%7C7c3292c8bd2
> > > > > > > f4
> > > > > > > > > 86f
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 920908daa314e8e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6
> > > > > > > > > 3800
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1607445876768%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> > > > > > > JQ
> > > > > > > > > IjoiV
> > > > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > > > > > =
> > > > > > > > > HAq
> > > > > > > > > > >>
> > > > > > >
> > > > >
> > ou4JyY1yxDthuQ1dEKcF7Q3o4W77Oo9rOOvkXNWU%3D&amp;reserved=0
> > > > > > > > > > >>
> > > > > > > > > > >> @Kinney, Michael D we may also need your
> > > > > > > > > > >> clarification on the
> > > > > > > comments.
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>> -----Original Message-----
> > > > > > > > > > >>> From: Ni, Ray <ray.ni@...>
> > > > > > > > > > >>> Sent: Thursday, September 29, 2022 3:42 PM
> > > > > > > > > > >>> To: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>> <AbdulLateef.Attar@...>; Chang, Abner
> > > > > > > > > > >>> <Abner.Chang@...>; Sunil V L
> > > > > > > > > > >>> <sunilvl@...>; devel@edk2.groups.io
> > > > > > > > > > >>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>> <Paul.Grimes@...>; He, Jiangang
> > > > > <Jiangang.He@...>;
> > > > > > > > > > >>> Leif Lindholm <quic_llindhol@...>; Andrew
> > > > > > > > > > >>> Fish <afish@...>
> > > > > > > > > > >>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>> module reconstruction for archs
> > > > > > > > > > >>>
> > > > > > > > > > >>> Caution: This message originated from an External
> Source.
> > > > > > > > > > >>> Use proper caution when opening attachments,
> > > > > > > > > > >>> clicking links, or
> > > > > > > responding.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Abner,
> > > > > > > > > > >>> Comments in
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>>
> CCodingStandardsSpecification%2Fpull%2F2%23pullreque
> > > > > > > > > > >>> st
> > > > > > > > > > >>> revi
> > > > > > > > > > >>> ew-
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 1124763311&amp;data=05%7C01%7CAbner.Chang%40amd.com%7Cd825e24
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 8625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82d994e183d%7C0
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > %7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> 7C%7C%7C&amp;sdata=RXxgpbEr6ivbqP1R6%2B3Rxl%2ByJAnaUJuaYYKdfCH
> > > > > > > > > > >>> 8jo8%3D&amp;reserved=0
> > > > > > > > > > >>>
> > > > > > > > > > >>> We can discuss more in tomorrow's meeting.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Attar, AbdulLateef (Abdul Lateef)
> > > > > > > > > > >>>> <AbdulLateef.Attar@...>
> > > > > > > > > > >>>> Sent: Thursday, September 29, 2022 3:11 PM
> > > > > > > > > > >>>> To: Chang, Abner <Abner.Chang@...>; Sunil V L
> > > > > > > > > > >>>> <sunilvl@...>; devel@edk2.groups.io;
> > > > > > > > > > >>>> Ni, Ray <ray.ni@...>
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@...>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@...>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>> <afish@...>
> > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module reconstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Hi Abner,
> > > > > > > > > > >>>>      Looks good to me.
> > > > > > > > > > >>>> Reviewed-by:  Abdul Lateef Attar <abdattar@...>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> AbduL
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> -----Original Message-----
> > > > > > > > > > >>>> From: Chang, Abner <Abner.Chang@...>
> > > > > > > > > > >>>> Sent: 28 September 2022 20:31
> > > > > > > > > > >>>> To: Sunil V L <sunilvl@...>;
> > > > > > > > > > >>>> devel@edk2.groups.io; ray.ni@...
> > > > > > > > > > >>>> Cc: Kinney, Michael D <michael.d.kinney@...>;
> > > > > > > > > > >>>> lichao <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>> <Paul.Grimes@...>;
> > > > > > > > > > >>> He,
> > > > > > > > > > >>>> Jiangang <Jiangang.He@...>; Attar, AbdulLateef
> > > > > > > > > > >>>> (Abdul
> > > > > > > > > > >>>> Lateef) <AbdulLateef.Attar@...>; Leif Lindholm
> > > > > > > > > > >>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>> <afish@...>
> > > > > > > > > > >>>> Subject: RE: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>> module reconstruction for archs
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> [AMD Official Use Only - General]
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> I just had created PR to update edkII C coding
> > > > > > > > > > >>>> standard spec for the file and directory naming. We
> > > > > > > > > > >>>> can review and confirm this update first and then
> > > > > > > > > > >>>> go back to the principles of EDK2 module
> > > > > > > > > reconstruction for archs.
> > > > > > > > > > >>>> Here is the PR:
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>> ub.com%2Ftianocore-docs%2Fedk2-
> > > > > > > > > > >>> &amp;data=05%7C01%7CAbner.Chang%40amd.c
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> om%7Cd825e248625541e3f43e08daa1ee2883%7C3dd8961fe4884e608e11a82
> > > > > > > > > > >>> d994e18
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 3d%7C0%7C0%7C638000341502885565%7CUnknown%7CTWFpbGZsb3d8eyJ
> > > > > > > > > > >>> WIjoiMC4wLj
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > > > > > > > > > >>> 7C%7C&a
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> mp;sdata=X4z9puj81nIGTqtMxC9igDZyBPOT6OTWSU%2BjoIowo%2BE%3D&a
> > > > > > > > > > >>> mp;reserv
> > > > > > > > > > >>>> ed=0
> > > > > > > > > > >>>> CCodingStandardsSpecification/pull/2
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> The naming rule is mainly for the new module or new
> file
> > IMO.
> > > > > > > > > > >>>> Some existing module may not meet the guidelines
> > > > > > > > > > >>>> mentioned in this
> > > > > > > > > spec.
> > > > > > > > > > >>>> Thus we need the principles of EDK2 module
> > > > > > > > > > >>>> reconstruction on the existing module to support
> > > > > > > > > > >>>> other processor archs and not impacting the
> > > > > > > > > > >>> existing platforms (e.g.
> > > > > > > > > > >>>> rename the INF file or directory to meet the
> guidelines).
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Sunil, seems RISC-V CpuDxe meet the guideline.
> > > > > > > > > > >>>> Please check
> > > > > it.
> > > > > > > > > > >>>> Just feel that having  CpuDxe.c to Riscv64 folder
> > > > > > > > > > >>>> is not quite a best solution. I think at least we
> > > > > > > > > > >>>> can abstract the protocol structure and protocol
> > > > > > > > > > >>>> installation under CpuDxe\ and have the arch
> > > > > > > > > > >>>> implementation under arch folder. We can discuss
> > > > > > > > > > >>>> this later after we confirming the
> > > > > > > > > > >>> guideline and principles.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Thanks
> > > > > > > > > > >>>> Abner
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>> -----Original Message-----
> > > > > > > > > > >>>>> From: Sunil V L <sunilvl@...>
> > > > > > > > > > >>>>> Sent: Wednesday, September 28, 2022 3:34 PM
> > > > > > > > > > >>>>> To: devel@edk2.groups.io; ray.ni@...
> > > > > > > > > > >>>>> Cc: Chang, Abner <Abner.Chang@...>; Kinney,
> > > > > Michael
> > > > > > > > > > >>>>> D <michael.d.kinney@...>; lichao
> > > > > > > > > > >>>>> <lichao@...>; Kirkendall, Garrett
> > > > > > > > > > >>>>> <Garrett.Kirkendall@...>; Grimes, Paul
> > > > > > > > > > >>>>> <Paul.Grimes@...>; He, Jiangang
> > > > > > > > > > >>>>> <Jiangang.He@...>; Attar, AbdulLateef (Abdul
> > > > > > > > > > >>>>> Lateef) <AbdulLateef.Attar@...>; Leif
> Lindholm
> > > > > > > > > > >>>>> <quic_llindhol@...>; Andrew Fish
> > > > > > > > > > >>>>> <afish@...>
> > > > > > > > > > >>>>> Subject: Re: [edk2-devel] The principles of EDK2
> > > > > > > > > > >>>>> module reconstruction for archs
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Caution: This message originated from an External
> > Source.
> > > > > > > > > > >>>>> Use proper caution when opening attachments,
> > > > > > > > > > >>>>> clicking links, or
> > > > > > > responding.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray
> > wrote:
> > > > > > > > > > >>>>> Hi Ray,
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    1.  When a new arch's implementation is
> > > > > > > > > > >>>>>> introduced to the existing
> > > > > > > > > > >>>>> module which was developed for the specific arch:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    1.  The folder reconstruction:
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    *   Create arch folder for the existing arch
> > implementation
> > > > > > > > > > >>>>>> [Ray] Do you move existing arch implementation to
> > > > > > > > > > >>>>>> that arch
> > > > > > > folder?
> > > > > > > > > > >>>>>> It will
> > > > > > > > > > >>>>> break existing platforms a lot.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>>    *   Create the arch folder for the new introduced
> > arch
> > > > > > > > > > >>>>>> [Ray] I agree. But if we don't create arch folder
> > > > > > > > > > >>>>>> for existing arch
> > > > > > > > > > >>>>> implementation, the pkg layout will be a mess.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> [Ray] Hard for me to understand all the principles
> here.
> > > > > > > > > > >>>>>> Maybe we review
> > > > > > > > > > >>>>> existing code including to-be-upstreamed code and
> > > > > > > > > > >>>>> decide how
> > > > > > > to go.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Could you please take a look below changes which
> > > > > > > > > > >>>>> is trying to add RISC-V support for CpuDxe?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2Fbba1a11be47dd091734e185afbed73ea75708749&amp;
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> data=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08d
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> aa123e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2732494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sd
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> ata=Vq6pJLnn8yJrJhFZn7LfLbZzrtpG4n1VLWgAil6J38U%3D&amp;reserved=0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>> https://nam11.safelinks.protection.outlook.com/?url=
> > > > > > > > > > >>> ht
> > > > > > > > > > >>> tps%
> > > > > > > > > > >>> 3A%2
> > > > > > > > > > >>> F%2F
> > > > > > > > > > >>> gith
> > > > > > > > > > >>>>> ub.com%2Ftianocore%2Fedk2-
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> staging%2Fcommit%2F7fccf92a97a6d0618a20f10622220e78b3687906&amp;da
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> ta=05%7C01%7Cabner.chang%40amd.com%7Ca419e6a010d34fde464b08daa1
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 23e080%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63799947273
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2494527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > >
> > > > > > >
> > > > >
> >
> =xFmvUv58vh4AUAM17Qy9G5jZWFZlK2Ozt3njpG1e8%2BY%3D&amp;reserv
> > > > > > > > > > >>>>> ed=0
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> What do you suggest with above example?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 1) Common INF for all architectures - but modify
> > > > > > > > > > >>>>> INF alone, no
> > > > > > > > > > >>>>> X86 folder creation.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This is what I have done in the commit above. May
> > > > > > > > > > >>>>> be of least impact to existing code since it is only INF
> > change.
> > > > > > > > > > >>>>> But like you mentioned this is bit weird that X86
> > > > > > > > > > >>>>> files will remain in root folder directly along
> > > > > > > > > > >>>>> with some common
> > > > > files.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 2) Common INF (CpuDxe.inf) + create arch folders
> > > > > > > > > > >>>>> X86, X64, IA32,
> > > > > > > > > > >>>>> RiscV64 etc
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> IMO, this is probably the best approach. What
> > > > > > > > > > >>>>> would be the challenges with this?
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 3) Separate INF for arch like CpuDxe.inf for x86,
> > > > > > > > > > >>>>> CpuDxeRiscV64.inf for
> > > > > > > > > > >>>> RISC-V.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> This again probably is not a good idea.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> 4) If the module/library is specific to one arch (ex:
> > > > > > > > > > >>>>> SMM(X86), SBI(RISC-V)), then create separate INF.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Thanks!
> > > > > > > > > > >>>>> Sunil
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >


Re: [edk2-platforms][PATCH v1 3/3] TigerlakeSiliconPkg: Fix invalid debug macros

Nate DeSimone
 

Hi Michael,

Please see feedback inline.

Thanks,
Nate

-----Original Message-----
From: mikuback@... <mikuback@...>
Sent: Tuesday, October 4, 2022 9:07 PM
To: devel@edk2.groups.io
Cc: Chaganty, Rangasai V <rangasai.v.chaganty@...>; Desimone,
Nathaniel L <nathaniel.l.desimone@...>; Luo, Heng
<heng.luo@...>
Subject: [edk2-platforms][PATCH v1 3/3] TigerlakeSiliconPkg: Fix invalid
debug macros

From: Michael Kubacki <michael.kubacki@...>

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

Updates several debug macros in TigerlakeSiliconPkg to correctly match print
specifiers to actual arguments.

Cc: Sai Chaganty <rangasai.v.chaganty@...>
Cc: Nate DeSimone <nathaniel.l.desimone@...>
Cc: Heng Luo <heng.luo@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>
---
Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Gbe/LibraryPrivate/PeiDxeSmmGbeMdiLib/GbeMdiLib.c | 2 +-
Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PciExpressHelpersLibrary/PciExpressHelpersLibrary.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Gbe/LibraryPrivate/PeiDxeSmmGbeMdiLib/GbeMdiLib.c b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Gbe/LibraryPrivate/PeiDxeSmmGbeMdiLib/GbeMdiLib.c
index 791747440662..01c097723083 100644
--- a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Gbe/LibraryPrivate/PeiDxeSmmGbeMdiLib/GbeMdiLib.c
+++ b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/Gbe/LibraryPrivate/PeiDxeSmmGbeMdiLib/GbeMdiLib.c
@@ -323,7 +323,7 @@ GbeMdiGetLanPhyRevision (
Status = EFI_DEVICE_ERROR;
goto phy_exit;
}
- DEBUG ((DEBUG_INFO, "GbeMdiGetLanPhyRevision failed to read Revision. Overriding LANPHYPC\n", Status));
+ DEBUG ((DEBUG_INFO, "GbeMdiGetLanPhyRevision failed to read Revision. Overriding LANPHYPC.\n"));;
That does not seem to be what the original author intended. I suspect this is the intent:

DEBUG ((DEBUG_INFO, "GbeMdiGetLanPhyRevision failed to read Revision. Overriding LANPHYPC. Status: %r\n", Status));

//
// Taking over LANPHYPC
// 1. SW signal override - 1st cycle.
diff --git a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PciExpressHelpersLibrary/PciExpressHelpersLibrary.c b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PciExpressHelpersLibrary/PciExpressHelpersLibrary.c
index 401a9fbe7b8a..d1c163c50f63 100644
--- a/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PciExpressHelpersLibrary/PciExpressHelpersLibrary.c
+++ b/Silicon/Intel/TigerlakeSiliconPkg/IpBlock/PcieRp/LibraryPrivate/PciExpressHelpersLibrary/PciExpressHelpersLibrary.c
@@ -1227,7 +1227,7 @@ RecursiveIoApicCheck (
IoApicPresent = FALSE;

if (IsIoApicDevice (SbdfToBase (Sbdf))) {
- DEBUG ((DEBUG_INFO, "IoApicFound @%x:%x:%x:%x\n", Sbdf.Bus, Sbdf.Dev, Sbdf.Func));
+ DEBUG ((DEBUG_INFO, "IoApicFound @%x:%x:%x\n", Sbdf.Bus, Sbdf.Dev, Sbdf.Func));
That does not seem to be what the original author intended. I suspect this is the intent:

DEBUG ((DEBUG_INFO, "IoApicFound @%x:%x:%x:%x\n", Sbdf.Seg, Sbdf.Bus, Sbdf.Dev, Sbdf.Func));

return TRUE;
}
if (HasChildBus (Sbdf, &ChildSbdf)) {
--
2.28.0.windows.1


Re: [edk2-platforms][PATCH v1 2/3] KabylakeSiliconPkg: Fix invalid debug macros

Nate DeSimone
 

Reviewed-by: Nate DeSimone <nathaniel.l.desimone@...>

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Michael
Kubacki
Sent: Tuesday, October 4, 2022 9:07 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@...>; Chaganty, Rangasai V
<rangasai.v.chaganty@...>
Subject: [edk2-devel] [edk2-platforms][PATCH v1 2/3] KabylakeSiliconPkg:
Fix invalid debug macros

From: Michael Kubacki <michael.kubacki@...>

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

Updates several debug macros in KabylakeSiliconPkg to correctly match print
specifiers to actual arguments.

Cc: Chasel Chiu <chasel.chiu@...>
Cc: Sai Chaganty <rangasai.v.chaganty@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>
---

Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPolicy.
c | 19 +++++++++++--------
Silicon/Intel/KabylakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c
| 4 ++--
2 files changed, 13 insertions(+), 10 deletions(-)

diff --git
a/Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPoli
cy.c
b/Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPoli
cy.c
index f13ca92661ae..d20945b7cae3 100644
---
a/Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPoli
cy.c
+++ b/Silicon/Intel/KabylakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPr
+++ intPolicy.c
@@ -39,13 +39,16 @@ CpuPowerMgmtBasicConfigPrint (
)
{
DEBUG ((DEBUG_INFO, "------------------ CPU Power Mgmt Basic Config -----
-------------\n"));
- DEBUG ((DEBUG_INFO, " CPU_POWER_MGMT_BASIC_CONFIG :
OneCoreRatioLimit : 0x%X , TwoCoreRatioLimit = 0x%X , ThreeCoreRatioLimit
= 0x%X , FourCoreRatioLimit = 0x%X \n", CpuPowerMgmtBasicConfig-
OneCoreRatioLimit, \
- CpuPowerMgmtBasicConfig->TwoCoreRatioLimit, \
- CpuPowerMgmtBasicConfig->ThreeCoreRatioLimit, \
- CpuPowerMgmtBasicConfig->FourCoreRatioLimit, \
- CpuPowerMgmtBasicConfig->FiveCoreRatioLimit, \
- CpuPowerMgmtBasicConfig->SixCoreRatioLimit, \
- CpuPowerMgmtBasicConfig->SevenCoreRatioLimit, \
+ DEBUG ((DEBUG_INFO,
+ " CPU_POWER_MGMT_BASIC_CONFIG : OneCoreRatioLimit : 0x%X ,
TwoCoreRatioLimit = 0x%X , ThreeCoreRatioLimit = 0x%X ,
FourCoreRatioLimit = 0x%X\n"
+ " FiveCoreRatioLimit : 0x%X , SixCoreRatioLimit = 0x%X ,
SevenCoreRatioLimit = 0x%X , EightCoreRatioLimit = 0x%X\n",
+ CpuPowerMgmtBasicConfig->OneCoreRatioLimit,
+ CpuPowerMgmtBasicConfig->TwoCoreRatioLimit,
+ CpuPowerMgmtBasicConfig->ThreeCoreRatioLimit,
+ CpuPowerMgmtBasicConfig->FourCoreRatioLimit,
+ CpuPowerMgmtBasicConfig->FiveCoreRatioLimit,
+ CpuPowerMgmtBasicConfig->SixCoreRatioLimit,
+ CpuPowerMgmtBasicConfig->SevenCoreRatioLimit,
CpuPowerMgmtBasicConfig->EightCoreRatioLimit));
DEBUG ((DEBUG_INFO, " CPU_POWER_MGMT_BASIC_CONFIG: Hwp :
0x%x\n", CpuPowerMgmtBasicConfig->Hwp));
DEBUG ((DEBUG_INFO, " CPU_POWER_MGMT_BASIC_CONFIG:
SkipSetBootPState : 0x%x\n", CpuPowerMgmtBasicConfig-
SkipSetBootPState));
@@ -151,7 +154,7 @@ CpuPidTestConfigPrint ( {
UINT32 Index = 0;
DEBUG ((DEBUG_INFO, "------------------ CPU PID Test Config ------------------
\n"));
- DEBUG ((DEBUG_INFO, " CPU_PID_TEST_CONFIG : PidTuning : 0x%X\n",
Index, CpuPidTestConfig->PidTuning));
+ DEBUG ((DEBUG_INFO, " CPU_PID_TEST_CONFIG : PidTuning : 0x%X\n",
+ CpuPidTestConfig->PidTuning));
if ( CpuPidTestConfig->PidTuning == 1) {
for (Index = PID_DOMAIN_KP; Index <= PID_DOMAIN_KD; Index++) {
DEBUG ((DEBUG_INFO, " CPU_PID_TEST_CONFIG : Ratl[%X] : 0x%X\n",
Index, CpuPidTestConfig->Ratl[Index])); diff --git
a/Silicon/Intel/KabylakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c
b/Silicon/Intel/KabylakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c
index e8c8dab6e7ad..467f71bff92b 100644
---
a/Silicon/Intel/KabylakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c
+++ b/Silicon/Intel/KabylakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtL
+++ ib.c
@@ -75,7 +75,7 @@ OcWdtResetCheck (
/// Timeout status bits are cleared by writing '1'
///
if (Readback & (B_PCH_OC_WDT_CTL_ICCSURV_STS |
B_PCH_OC_WDT_CTL_NO_ICCSURV_STS)) {
- DEBUG ((DEBUG_ERROR, "(WDT) Expiration detected.\n", Readback));
+ DEBUG ((DEBUG_ERROR, "(WDT) Expiration detected. Read back =
+ 0x%08x\n", Readback));
Readback |= B_PCH_OC_WDT_CTL_FAILURE_STS;
Readback |= (B_PCH_OC_WDT_CTL_ICCSURV_STS |
B_PCH_OC_WDT_CTL_NO_ICCSURV_STS);
Readback &= ~(B_PCH_OC_WDT_CTL_UNXP_RESET_STS);
@@ -102,7 +102,7 @@ OcWdtResetCheck (
///
/// No WDT expiration and no unexpected reset - clear Failure status
///
- DEBUG ((DEBUG_INFO, "(WDT) Status OK.\n", Readback));
+ DEBUG ((DEBUG_INFO, "(WDT) Status OK.\n"));
Readback &= ~(B_PCH_OC_WDT_CTL_FAILURE_STS);
Readback |= (B_PCH_OC_WDT_CTL_ICCSURV_STS |
B_PCH_OC_WDT_CTL_NO_ICCSURV_STS);
}
--
2.28.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94740): https://edk2.groups.io/g/devel/message/94740
Mute This Topic: https://groups.io/mt/94129546/1767664
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[nathaniel.l.desimone@...]
-=-=-=-=-=-=


Re: [edk2-platforms][PATCH v1 1/3] CoffeelakeSiliconPkg: Fix invalid debug macros

Nate DeSimone
 

Hi Michael,

Please see feedback inline.

Thanks,
Nate

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Michael
Kubacki
Sent: Tuesday, October 4, 2022 9:07 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@...>; Chaganty, Rangasai V
<rangasai.v.chaganty@...>
Subject: [edk2-devel] [edk2-platforms][PATCH v1 1/3] CoffeelakeSiliconPkg:
Fix invalid debug macros

From: Michael Kubacki <michael.kubacki@...>

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

Updates several debug macros in CoffeelakeSiliconPkg to correctly match
print specifiers to actual arguments.

Cc: Chasel Chiu <chasel.chiu@...>
Cc: Sai Chaganty <rangasai.v.chaganty@...>
Signed-off-by: Michael Kubacki <michael.kubacki@...>
---
Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPolicy.c | 2 +-
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiDxeSmmGbeMdiLib/GbeMdiLib.c | 2 +-
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c | 4 ++--
Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/PeiDxeSmmPchPciExpressHelpersLib/PchPciExpressHelpersLibrary.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPolicy.c b/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPolicy.c
index 38cf383e8da2..2e50068ba193 100644
--- a/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPolicy.c
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Cpu/Library/PeiCpuPolicyLib/CpuPrintPolicy.c
@@ -161,7 +161,7 @@ CpuPidTestConfigPrint (
{
UINT32 Index = 0;
DEBUG ((DEBUG_INFO, "------------------ CPU PID Test Config ------------------\n"));
- DEBUG ((DEBUG_INFO, " CPU_PID_TEST_CONFIG : PidTuning : 0x%X\n", Index, CpuPidTestConfig->PidTuning));
+ DEBUG ((DEBUG_INFO, " CPU_PID_TEST_CONFIG : PidTuning : 0x%X\n", CpuPidTestConfig->PidTuning));
if ( CpuPidTestConfig->PidTuning == 1) {
for (Index = PID_DOMAIN_KP; Index <= PID_DOMAIN_KD; Index++) {
DEBUG ((DEBUG_INFO, " CPU_PID_TEST_CONFIG : Ratl[%X] : 0x%X\n", Index, CpuPidTestConfig->Ratl[Index]));
diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiDxeSmmGbeMdiLib/GbeMdiLib.c b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiDxeSmmGbeMdiLib/GbeMdiLib.c
index e5aa10de3b7b..7df011269af5 100644
--- a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiDxeSmmGbeMdiLib/GbeMdiLib.c
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiDxeSmmGbeMdiLib/GbeMdiLib.c
@@ -335,7 +335,7 @@ GbeMdiGetLanPhyRevision (
Status = EFI_DEVICE_ERROR;
goto PHY_EXIT;
}
- DEBUG ((DEBUG_INFO, "GbeMdiGetLanPhyRevision failed to read Revision. Overriding LANPHYPC\n", Status));
+ DEBUG ((DEBUG_INFO, "GbeMdiGetLanPhyRevision failed to read Revision. Overriding LANPHYPC.\n"));
That does not seem to be what the original author intended. I suspect this is the intent:

DEBUG ((DEBUG_INFO, "GbeMdiGetLanPhyRevision failed to read Revision. Overriding LANPHYPC. Status: %r\n", Status));

//
// Taking over LANPHYPC
// 1. SW signal override - 1st cycle.
diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c
index 22f6fb215fcc..e2014f97e58c 100644
--- a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/PeiOcWdtLib/PeiOcWdtLib.c
@@ -71,7 +71,7 @@ OcWdtResetCheck (
/// Timeout status bits are cleared by writing '1'
///
if (Readback & (B_ACPI_IO_OC_WDT_CTL_ICCSURV_STS | B_ACPI_IO_OC_WDT_CTL_NO_ICCSURV_STS)) {
- DEBUG ((DEBUG_ERROR, "(WDT) Expiration detected.\n", Readback));
+ DEBUG ((DEBUG_ERROR, "(WDT) Expiration detected. Read back = 0x%08x\n", Readback));
Readback |= B_ACPI_IO_OC_WDT_CTL_FAILURE_STS;
Readback |= (B_ACPI_IO_OC_WDT_CTL_ICCSURV_STS | B_ACPI_IO_OC_WDT_CTL_NO_ICCSURV_STS);
Readback &= ~(B_ACPI_IO_OC_WDT_CTL_UNXP_RESET_STS);
@@ -98,7 +98,7 @@ OcWdtResetCheck (
///
/// No WDT expiration and no unexpected reset - clear Failure status
///
- DEBUG ((DEBUG_INFO, "(WDT) Status OK.\n", Readback));
+ DEBUG ((DEBUG_INFO, "(WDT) Status OK.\n"));
Readback &= ~(B_ACPI_IO_OC_WDT_CTL_FAILURE_STS);
Readback |= (B_ACPI_IO_OC_WDT_CTL_ICCSURV_STS | B_ACPI_IO_OC_WDT_CTL_NO_ICCSURV_STS);
}
diff --git a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/PeiDxeSmmPchPciExpressHelpersLib/PchPciExpressHelpersLibrary.c b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/PeiDxeSmmPchPciExpressHelpersLib/PchPciExpressHelpersLibrary.c
index dcb43285b73e..c55fa4efe188 100644
--- a/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/PeiDxeSmmPchPciExpressHelpersLib/PchPciExpressHelpersLibrary.c
+++ b/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Library/Private/PeiDxeSmmPchPciExpressHelpersLib/PchPciExpressHelpersLibrary.c
@@ -1800,7 +1800,7 @@ RecursiveIoApicCheck (
IoApicPresent = FALSE;

if (IsIoApicDevice (SbdfToBase (Sbdf))) {
- DEBUG ((DEBUG_INFO, "IoApicFound @%x:%x:%x:%x\n", Sbdf.Bus, Sbdf.Dev, Sbdf.Func));
+ DEBUG ((DEBUG_INFO, "IoApicFound @%x:%x:%x\n", Sbdf.Bus, Sbdf.Dev, Sbdf.Func));
That does not seem to be what the original author intended. I suspect this is the intent:

DEBUG ((DEBUG_INFO, "IoApicFound @%x:%x:%x:%x\n", Sbdf.Seg, Sbdf.Bus, Sbdf.Dev, Sbdf.Func));

return TRUE;
}
if (HasChildBus (Sbdf, &ChildSbdf)) {
--
2.28.0.windows.1


Re: [PATCH 0/3] CryptoPkg: Add EC key retrieving and signature interface.

Yao, Jiewen
 

Thanks Qi
Please change the protocol version!

-----Original Message-----
From: Zhang, Qi1 <qi1.zhang@...>
Sent: Tuesday, October 11, 2022 2:37 PM
To: devel@edk2.groups.io
Cc: Zhang, Qi1 <qi1.zhang@...>; Yao, Jiewen
<jiewen.yao@...>; Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>
Subject: [PATCH 0/3] CryptoPkg: Add EC key retrieving and signature
interface.

This patch is used to retrieve EC key from PEM and X509 and
carry out the EC-DSA signature and verify it.

The interface was tested by:
1. DeviceSecurity on edk2-staging
https://github.com/tianocore/edk2-staging/tree/DeviceSecurity.
2. Unit test in CryptoPkg/Test

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4102
PR: https://github.com/tianocore/edk2/pull/3464

Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Signed-off-by: Qi Zhang <qi1.zhang@...>

Qi Zhang (3):
CryptoPkg: Add EC key retrieving and signature interface.
CryptoPkg: Add EC key interface to DXE and protocol
CryptoPkg: add unit test for EC key interface.

CryptoPkg/Driver/Crypto.c | 143 +++++++++-
CryptoPkg/Include/Library/BaseCryptLib.h | 129 +++++++++
.../Pcd/PcdCryptoServiceFamilyEnable.h | 4 +
CryptoPkg/Library/BaseCryptLib/Pem/CryptPem.c | 87 ++++++
.../Library/BaseCryptLib/Pem/CryptPemNull.c | 30 ++
CryptoPkg/Library/BaseCryptLib/Pk/CryptEc.c | 258
++++++++++++++++++
.../Library/BaseCryptLib/Pk/CryptEcNull.c | 82 ++++++
CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c | 83 ++++++
.../Library/BaseCryptLib/Pk/CryptX509Null.c | 28 ++
.../BaseCryptLibNull/Pem/CryptPemNull.c | 30 ++
.../Library/BaseCryptLibNull/Pk/CryptEcNull.c | 82 ++++++
.../BaseCryptLibNull/Pk/CryptX509Null.c | 28 ++
.../BaseCryptLibOnProtocolPpi/CryptLib.c | 136 +++++++++
CryptoPkg/Private/Protocol/Crypto.h | 129 +++++++++
.../UnitTest/Library/BaseCryptLib/EcTests.c | 156 +++++++++++
15 files changed, 1404 insertions(+), 1 deletion(-)

--
2.26.2.windows.1