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

[PierreGondois]

From: Pierre Gondois 

The "-tc" option of the iasl compiler allows to generate a
.hex file containing a C array storing AML bytecode.

An online discussion suggested that this "-tc" option
was specific to the iasl compiler and it shouldn't be relied
on. This conversation is available at:
https://edk2.groups.io/g/devel/topic/39786201#49659

A way to address this issue is to implement a compiler
independent script that takes an AML file as input, and
generates a .hex file.

This patch implements a Python script that converts an AML
file to a .hex file, containing a C array storing AML bytecode.
This scipt has been tested with the AML output from the
following compilers supported by the EDKII implementation:
  * Intel ASL compiler
  * Microsoft ASL compiler

Signed-off-by: Pierre Gondois 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/tree/718_asl_to_hex_script_converter_v3

Notes:
v3:
 - When a file without a DSDT or SSDT signature is given as input,
   give a warning instead of an error. [Pierre]
 - Return None value instead of nothing in functions. [Pierre]

 BaseTools/BinWrappers/PosixLike/AmlToHex   |  14 ++
 BaseTools/BinWrappers/WindowsLike/AmlToHex.bat |   3 +
 BaseTools/Conf/build_rule.template |   3 +
 BaseTools/Source/Python/AmlToHex/AmlToHex.py   | 158 
 4 files changed, 178 insertions(+)

diff --git a/BaseTools/BinWrappers/PosixLike/AmlToHex 
b/BaseTools/BinWrappers/PosixLike/AmlToHex
new file mode 100755
index 
..1dd28e966288f6ea4fc52d42e2dc7b1f74226c23
--- /dev/null
+++ b/BaseTools/BinWrappers/PosixLike/AmlToHex
@@ -0,0 +1,14 @@
+#!/usr/bin/env bash
+#python `dirname $0`/RunToolFromSource.py `basename $0` $*
+
+# If a ${PYTHON_COMMAND} command is available, use it in preference to python
+if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then
+python_exe=${PYTHON_COMMAND}
+fi
+
+full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here
+dir=$(dirname "$full_cmd")
+exe=$(basename "$full_cmd")
+
+export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
+exec "${python_exe:-python}" "$dir/../../Source/Python/$exe/$exe.py" "$@"
diff --git a/BaseTools/BinWrappers/WindowsLike/AmlToHex.bat 
b/BaseTools/BinWrappers/WindowsLike/AmlToHex.bat
new file mode 100644
index 
..9616cd893bec9902451e6d8591f537cc408bd5e5
--- /dev/null
+++ b/BaseTools/BinWrappers/WindowsLike/AmlToHex.bat
@@ -0,0 +1,3 @@
+@setlocal
+@set ToolName=%~n0%
+@%PYTHON_COMMAND% %BASE_TOOLS_PATH%\Source\Python\%ToolName%\%ToolName%.py %*
diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 
51748bc0655a5c656258a3007b4db6b2dc941ea0..0822b681fcd9f61c6508e6f93ffc31fa70fd7059
 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -1,6 +1,7 @@
 #
 #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
 #  Portions copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
+#  Copyright (c) 2020, ARM Ltd. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 
@@ -427,12 +428,14 @@
 "$(ASLPP)" $(DEPS_FLAGS) $(ASLPP_FLAGS) $(INC) /I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
+-AmlToHex $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml
 
 
 Trim --asl-file --asl-deps -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i 
-i $(INC_LIST) ${src}
 "$(ASLPP)" $(DEPS_FLAGS) $(ASLPP_FLAGS) $(INC) -I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
+-AmlToHex $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml
 
 [C-Code-File.AcpiTable]
 
diff --git a/BaseTools/Source/Python/AmlToHex/AmlToHex.py 
b/BaseTools/Source/Python/AmlToHex/AmlToHex.py
new file mode 100644
index 
..7fe294a5aad6b6d3e32316a68478db5938ec856a
--- /dev/null
+++ b/BaseTools/Source/Python/AmlToHex/AmlToHex.py
@@ -0,0 +1,158 @@
+## @file
+#
+# Convert an AML file to a .hex file containing the AML bytecode stored in a
+# C array.
+# By default, "Tables\Dsdt.aml" will generate "Tables\Dsdt.hex".
+# "Tables\Dsdt.hex" will contain a C array named "dsdt_aml_code" that contains
+# the AML bytecode.
+#
+# Copyright (c) 2020, ARM Limited. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+import argparse
+import Common.EdkLogger as EdkLogger
+from 

Re: [edk2-devel] [Patch] CryptoPkg/BaseCryptLibNull: Add missing HkdfSha256ExtractAndExpand()

[Michael D Kinney]

Jian,

Thanks for the review.

I did not modify that file at all.  I just copied
it from another directory.  That is why I left
the Copyright year unmodified.

Mike

> -Original Message-
> From: Wang, Jian J 
> Sent: Tuesday, February 4, 2020 6:46 AM
> To: devel@edk2.groups.io; Kinney, Michael D
> 
> Cc: Lu, XiaoyuX 
> Subject: RE: [edk2-devel] [Patch]
> CryptoPkg/BaseCryptLibNull: Add missing
> HkdfSha256ExtractAndExpand()
> 
> The copyright year of file CryptHkdfNull.c was not
> updated. With it addressed,
> 
> Reviewed-by: Jian J Wang 
> 
> Regards,
> Jian
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On
> Behalf Of Michael D
> > Kinney
> > Sent: Thursday, January 30, 2020 8:17 AM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J ; Lu, XiaoyuX
> 
> > Subject: [edk2-devel] [Patch]
> CryptoPkg/BaseCryptLibNull: Add missing
> > HkdfSha256ExtractAndExpand()
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2493
> >
> > The BaseCryptLib was expanded to add the
> HkdfSha256ExtractAndExpand()
> > service in the following commit:
> >
> >
> https://github.com/tianocore/edk2/commit/4b1b7c1913092d
> 73d689d8086dcfa
> > 579c0217dc8
> >
> > When BaseCryptLibNull was added in the commit below,
> this new
> > service was not included.
> >
> >
> https://github.com/tianocore/edk2/commit/d95de082da01f4
> a4cb3ebf87e1597
> > 2a12d0f8d53
> >
> > Cc: Jian J Wang 
> > Cc: Xiaoyu Lu 
> > Signed-off-by: Michael D Kinney
> 
> > ---
> >  .../BaseCryptLibNull/BaseCryptLibNull.inf |  3
> +-
> >  .../BaseCryptLibNull/Kdf/CryptHkdfNull.c  | 43
> +++
> >  2 files changed, 45 insertions(+), 1 deletion(-)
> >  create mode 100644
> CryptoPkg/Library/BaseCryptLibNull/Kdf/CryptHkdfNull.c
> >
> > diff --git
> a/CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.i
> nf
> >
> b/CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.i
> nf
> > index 1e4807968a..8f53b0dfd0 100644
> > ---
> a/CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.i
> nf
> > +++
> b/CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.i
> nf
> > @@ -6,7 +6,7 @@
> >  #  This external input must be validated carefully
> to avoid security issues such as
> >  #  buffer overflow or integer overflow.
> >  #
> > -#  Copyright (c) 2009 - 2019, Intel Corporation. All
> rights reserved.
> > +#  Copyright (c) 2009 - 2020, Intel Corporation. All
> rights reserved.
> >  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #
> >  ##
> > @@ -37,6 +37,7 @@ [Sources]
> >Hmac/CryptHmacMd5Null.c
> >Hmac/CryptHmacSha1Null.c
> >Hmac/CryptHmacSha256Null.c
> > +  Kdf/CryptHkdfNull.c
> >Cipher/CryptAesNull.c
> >Cipher/CryptTdesNull.c
> >Cipher/CryptArc4Null.c
> > diff --git
> a/CryptoPkg/Library/BaseCryptLibNull/Kdf/CryptHkdfNull.
> c
> >
> b/CryptoPkg/Library/BaseCryptLibNull/Kdf/CryptHkdfNull.
> c
> > new file mode 100644
> > index 00..19d795a4cc
> > --- /dev/null
> > +++
> b/CryptoPkg/Library/BaseCryptLibNull/Kdf/CryptHkdfNull.
> c
> > @@ -0,0 +1,43 @@
> > +/** @file
> > +  HMAC-SHA256 KDF Wrapper Implementation which does
> not provide real
> > capabilities.
> > +
> > +Copyright (c) 2018 - 2019, Intel Corporation. All
> rights reserved.
> > +SPDX-License-Identifier: BSD-2-Clause-Patent
> > +
> > +**/
> > +
> > +#include 
> > +#include 
> > +
> > +/**
> > +  Derive key data using HMAC-SHA256 based KDF.
> > +
> > +  @param[in]   Key  Pointer to the user-
> supplied key.
> > +  @param[in]   KeySize  Key size in bytes.
> > +  @param[in]   Salt Pointer to the
> salt(non-secret) value.
> > +  @param[in]   SaltSize Salt size in bytes.
> > +  @param[in]   Info Pointer to the
> application specific info.
> > +  @param[in]   InfoSize Info size in bytes.
> > +  @param[out]  Out  Pointer to buffer to
> receive hkdf value.
> > +  @param[in]   OutSize  Size of hkdf bytes
> to generate.
> > +
> > +  @retval TRUE   Hkdf generated successfully.
> > +  @retval FALSE  Hkdf generation failed.
> > +
> > +**/
> > +BOOLEAN
> > +EFIAPI
> > +HkdfSha256ExtractAndExpand (
> > +  IN   CONST UINT8  *Key,
> > +  IN   UINTNKeySize,
> > +  IN   CONST UINT8  *Salt,
> > +  IN   UINTNSaltSize,
> > +  IN   CONST UINT8  *Info,
> > +  IN   UINTNInfoSize,
> > +  OUT  UINT8*Out,
> > +  IN   UINTNOutSize
> > +  )
> > +{
> > +  ASSERT (FALSE);
> > +  return FALSE;
> > +}
> > --
> > 2.21.0.windows.1
> >
> >
> > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53732): https://edk2.groups.io/g/devel/message/53732
Mute This Topic: https://groups.io/mt/70261270/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Michael D Kinney]

Liming,

Can you please provide a few more details on the failure.

For the UnitTestFrameworkPkg patch set, I had to add the
following to get host based unit test applications to build
and run.  I was seeing link failures between FW libs and 
host libs when building the POSIX host application.

[BuildOptions]
  GCC:*_*_*_CC_FLAGS = -fno-pie

I think with the proposed change below, I could remove
this. Do you agree?

Thanks,

Mike


> -Original Message-
> From: devel@edk2.groups.io  On
> Behalf Of Liming Gao
> Sent: Tuesday, February 4, 2020 4:52 AM
> To: Laszlo Ersek ;
> devel@edk2.groups.io
> Cc: Feng, Bob C ; Ard Biesheuvel
> ; Gao, Liming
> 
> Subject: Re: [edk2-devel] [Patch] BaseTools
> tools_def.template: Add back -fno-pie option in GCC49
> tool chain
> 
> Laszlo:
> 
> > -Original Message-
> > From: Laszlo Ersek 
> > Sent: Tuesday, February 4, 2020 8:02 PM
> > To: devel@edk2.groups.io; Gao, Liming
> 
> > Cc: Feng, Bob C ; Ard
> Biesheuvel 
> > Subject: Re: [edk2-devel] [Patch] BaseTools
> tools_def.template: Add back -fno-pie option in GCC49
> tool chain
> >
> > (+Ard)
> >
> > On 02/04/20 05:54, Liming Gao wrote:
> > > BZ:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2502
> > > This option is required to make GCC49 tool chain
> work with the high
> > > version GCC compiler.
> > >
> > > Cc: Bob Feng 
> > > Signed-off-by: Liming Gao 
> > > ---
> > >  BaseTools/Conf/tools_def.template | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> > > index feee2bbf16..d02424ae44 100755
> > > --- a/BaseTools/Conf/tools_def.template
> > > +++ b/BaseTools/Conf/tools_def.template
> > > @@ -1974,7 +1974,7 @@ DEFINE
> GCC48_ARM_ASLDLINK_FLAGS  =
> DEF(GCC_ARM_ASLDLINK_FLAGS) -Wl,--oformat
> > >  DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  =
> DEF(GCC_AARCH64_ASLDLINK_FLAGS)
> > >  DEFINE GCC48_ASLCC_FLAGS =
> DEF(GCC_ASLCC_FLAGS)
> > >
> > > -DEFINE GCC49_IA32_CC_FLAGS   =
> DEF(GCC48_IA32_CC_FLAGS)
> > > +DEFINE GCC49_IA32_CC_FLAGS   =
> DEF(GCC48_IA32_CC_FLAGS) -fno-pic -fno-pie
> > >  DEFINE GCC49_X64_CC_FLAGS=
> DEF(GCC48_X64_CC_FLAGS)
> > >  DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -
> Wl,-n,-q,--gc-sections -z common-page-size=0x40
> > >  DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS =
> DEF(GCC49_IA32_X64_DLINK_COMMON) -Wl,--
> defsym=PECOFF_HEADER_SIZE=0
> > DEF(GCC_DLINK2_FLAGS_COMMON) -Wl,--
> entry,ReferenceAcpiTable -u ReferenceAcpiTable
> > > @@ -1997,7 +1997,7 @@ DEFINE
> GCC49_ARM_ASLDLINK_FLAGS  =
> DEF(GCC48_ARM_ASLDLINK_FLAGS)
> > >  DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  =
> DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
> > >  DEFINE GCC49_ASLCC_FLAGS =
> DEF(GCC48_ASLCC_FLAGS)
> > >
> > > -DEFINE GCC5_IA32_CC_FLAGS=
> DEF(GCC49_IA32_CC_FLAGS) -fno-pic -fno-pie
> > > +DEFINE GCC5_IA32_CC_FLAGS=
> DEF(GCC49_IA32_CC_FLAGS)
> > >  DEFINE GCC5_X64_CC_FLAGS =
> DEF(GCC49_X64_CC_FLAGS)
> > >  DEFINE GCC5_IA32_X64_DLINK_COMMON=
> DEF(GCC49_IA32_X64_DLINK_COMMON)
> > >  DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  =
> DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
> > >
> >
> > - What has changed relative to commit 11d0cd23dd1b
> ("BaseTools/tools_def
> > IA32: drop -no-pie linker option for GCC49", 2018-06-
> 18)?
> >
> > - Also, if we are reverting one half of 11d0cd23dd1b
> (the compiler
> > flags), shouldn't we then revert the other half too
> (the linker flags)?
> 
> Yes. Half change is revert. CC_FLAGS is added back.
> DLINK flag is not,
> because GCC4.9 doesn't know the link option -no-pie.
> But, GCC 4.9 accepts the CC option -fno-pie.
> I verify this change. CC flags -fno-pie can resolve the
> build failure with GCC7.4. I also see -fno-pie option
> Is in GCC ARM and AARCH64 arch. So, I think this change
> is enough.
> 
> >
> > - The commit message says, "work with the high
> version GCC compiler".
> > What does that mean? If it is 4.9.x, with x>2, then I
> agree the patch is
> > justified (because commit 11d0cd23dd1b was apparently
> made for 4.9.2).
> > But if the phrase stands for gcc8 or so (just an
> example), then I don't
> > think the patch is a good idea; users of gcc8 can
> just specify the GCC5
> > toolchain.
> >
> > Ah, indeed, I need only look at TianoCore#2502:
> >
> > "GCC49 tool chain meets with the build failure when
> GCC7.4 compiler".
> >
> > So I think this approach is wrong. Unless there is a
> new gcc-4.9.x
> > release, i.e., after gcc-4.9.2, I think we still need
> commit
> > 11d0cd23dd1b in place. And, please use GCC5 for gcc-
> 7.4 -- is there a
> > problem with that?
> 
> By design, GCC49 can work with the high version GCC
> compiler like GCC5.
> GCC49 is the tool chain without LTO enable. GCC5 is the
> tool chain with LTO.
> So, they are for two different GCC setting. They should
> both support
> high version GCC compiler. GCC49 supported GCC compiler
> version is from GCC 4.9.
> GCC5 

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

[Laszlo Ersek]

On 02/04/20 13:52, Gao, Liming wrote:
> Laszlo:
> 
>> -Original Message-
>> From: Laszlo Ersek 
>> Sent: Tuesday, February 4, 2020 8:02 PM
>> To: devel@edk2.groups.io; Gao, Liming 
>> Cc: Feng, Bob C ; Ard Biesheuvel 
>> 
>> Subject: Re: [edk2-devel] [Patch] BaseTools tools_def.template: Add back 
>> -fno-pie option in GCC49 tool chain
>>
>> (+Ard)
>>
>> On 02/04/20 05:54, Liming Gao wrote:
>>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2502
>>> This option is required to make GCC49 tool chain work with the high
>>> version GCC compiler.
>>>
>>> Cc: Bob Feng 
>>> Signed-off-by: Liming Gao 
>>> ---
>>>  BaseTools/Conf/tools_def.template | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/BaseTools/Conf/tools_def.template 
>>> b/BaseTools/Conf/tools_def.template
>>> index feee2bbf16..d02424ae44 100755
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -1974,7 +1974,7 @@ DEFINE GCC48_ARM_ASLDLINK_FLAGS  = 
>>> DEF(GCC_ARM_ASLDLINK_FLAGS) -Wl,--oformat
>>>  DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_ASLDLINK_FLAGS)
>>>  DEFINE GCC48_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS)
>>>
>>> -DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS)
>>> +DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS) -fno-pic 
>>> -fno-pie
>>>  DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
>>>  DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections 
>>> -z common-page-size=0x40
>>>  DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
>>> -Wl,--defsym=PECOFF_HEADER_SIZE=0
>> DEF(GCC_DLINK2_FLAGS_COMMON) -Wl,--entry,ReferenceAcpiTable -u 
>> ReferenceAcpiTable
>>> @@ -1997,7 +1997,7 @@ DEFINE GCC49_ARM_ASLDLINK_FLAGS  = 
>>> DEF(GCC48_ARM_ASLDLINK_FLAGS)
>>>  DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>>>  DEFINE GCC49_ASLCC_FLAGS = DEF(GCC48_ASLCC_FLAGS)
>>>
>>> -DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-pic 
>>> -fno-pie
>>> +DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS)
>>>  DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
>>>  DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)
>>>  DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
>>>
>>
>> - What has changed relative to commit 11d0cd23dd1b ("BaseTools/tools_def
>> IA32: drop -no-pie linker option for GCC49", 2018-06-18)?
>>
>> - Also, if we are reverting one half of 11d0cd23dd1b (the compiler
>> flags), shouldn't we then revert the other half too (the linker flags)?
> 
> Yes. Half change is revert. CC_FLAGS is added back. DLINK flag is not,
> because GCC4.9 doesn't know the link option -no-pie. But, GCC 4.9 accepts the 
> CC option -fno-pie.
> I verify this change. CC flags -fno-pie can resolve the build failure with 
> GCC7.4. I also see -fno-pie option 
> Is in GCC ARM and AARCH64 arch. So, I think this change is enough. 
> 
>>
>> - The commit message says, "work with the high version GCC compiler".
>> What does that mean? If it is 4.9.x, with x>2, then I agree the patch is
>> justified (because commit 11d0cd23dd1b was apparently made for 4.9.2).
>> But if the phrase stands for gcc8 or so (just an example), then I don't
>> think the patch is a good idea; users of gcc8 can just specify the GCC5
>> toolchain.
>>
>> Ah, indeed, I need only look at TianoCore#2502:
>>
>> "GCC49 tool chain meets with the build failure when GCC7.4 compiler".
>>
>> So I think this approach is wrong. Unless there is a new gcc-4.9.x
>> release, i.e., after gcc-4.9.2, I think we still need commit
>> 11d0cd23dd1b in place. And, please use GCC5 for gcc-7.4 -- is there a
>> problem with that?
> 
> By design, GCC49 can work with the high version GCC compiler like GCC5. 
> GCC49 is the tool chain without LTO enable. GCC5 is the tool chain with LTO. 
> So, they are for two different GCC setting. They should both support 
> high version GCC compiler. GCC49 supported GCC compiler version is from GCC 
> 4.9.
> GCC5 supported GCC compiler version is from GCC 5.0. I know GCC49 or GCC5 
> tool chain 
> name brings a little confuse. I will add more detail info in tools_def.txt 
> for them. 

Ah right, thanks for reminding me of this!

OK, I no longer object to this patch.

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53737): https://edk2.groups.io/g/devel/message/53737
Mute This Topic: https://groups.io/mt/70966421/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[PierreGondois]

[From Liming]
> If so, this is not the error for other ACPI table. I suggest to print INFO 
> message and directly return with success return value.
I've put a EdkLogger.warn(), so it doesn't stop the execution of the script and 
the message has a log level high enough to be printed.

Regards,
Pierre
 
-Original Message-
From: PierreGondois  
Sent: 04 February 2020 15:48
To: devel@edk2.groups.io
Cc: Pierre Gondois ; ard.biesheu...@linaro.org; 
bob.c.f...@intel.com; liming@intel.com; Sami Mujawar 
; nd 
Subject: [PATCH v3 1/1] BaseTools: Script for converting .aml to .hex

From: Pierre Gondois 

The "-tc" option of the iasl compiler allows to generate a .hex file containing 
a C array storing AML bytecode.

An online discussion suggested that this "-tc" option was specific to the iasl 
compiler and it shouldn't be relied on. This conversation is available at:
https://edk2.groups.io/g/devel/topic/39786201#49659

A way to address this issue is to implement a compiler independent script that 
takes an AML file as input, and generates a .hex file.

This patch implements a Python script that converts an AML file to a .hex file, 
containing a C array storing AML bytecode.
This scipt has been tested with the AML output from the following compilers 
supported by the EDKII implementation:
  * Intel ASL compiler
  * Microsoft ASL compiler

Signed-off-by: Pierre Gondois 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/tree/718_asl_to_hex_script_converter_v3

Notes:
v3:
 - When a file without a DSDT or SSDT signature is given as input,
   give a warning instead of an error. [Pierre]
 - Return None value instead of nothing in functions. [Pierre]

 BaseTools/BinWrappers/PosixLike/AmlToHex   |  14 ++
 BaseTools/BinWrappers/WindowsLike/AmlToHex.bat |   3 +
 BaseTools/Conf/build_rule.template |   3 +
 BaseTools/Source/Python/AmlToHex/AmlToHex.py   | 158 
 4 files changed, 178 insertions(+)

diff --git a/BaseTools/BinWrappers/PosixLike/AmlToHex 
b/BaseTools/BinWrappers/PosixLike/AmlToHex
new file mode 100755
index 
..1dd28e966288f6ea4fc52d42e2dc7b1f74226c23
--- /dev/null
+++ b/BaseTools/BinWrappers/PosixLike/AmlToHex
@@ -0,0 +1,14 @@
+#!/usr/bin/env bash
+#python `dirname $0`/RunToolFromSource.py `basename $0` $*
+
+# If a ${PYTHON_COMMAND} command is available, use it in preference to 
+python if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then
+python_exe=${PYTHON_COMMAND}
+fi
+
+full_cmd=${BASH_SOURCE:-$0} # see 
+http://mywiki.wooledge.org/BashFAQ/028 for a discussion of why $0 is 
+not a good choice here dir=$(dirname "$full_cmd") exe=$(basename 
+"$full_cmd")
+
+export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
+exec "${python_exe:-python}" "$dir/../../Source/Python/$exe/$exe.py" "$@"
diff --git a/BaseTools/BinWrappers/WindowsLike/AmlToHex.bat 
b/BaseTools/BinWrappers/WindowsLike/AmlToHex.bat
new file mode 100644
index 
..9616cd893bec9902451e6d8591f537cc408bd5e5
--- /dev/null
+++ b/BaseTools/BinWrappers/WindowsLike/AmlToHex.bat
@@ -0,0 +1,3 @@
+@setlocal
+@set ToolName=%~n0%
+@%PYTHON_COMMAND% 
+%BASE_TOOLS_PATH%\Source\Python\%ToolName%\%ToolName%.py %*
diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 
51748bc0655a5c656258a3007b4db6b2dc941ea0..0822b681fcd9f61c6508e6f93ffc31fa70fd7059
 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -1,6 +1,7 @@
 #
 #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.  #  
Portions copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
+#  Copyright (c) 2020, ARM Ltd. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent  #
 
@@ -427,12 +428,14 @@
 "$(ASLPP)" $(DEPS_FLAGS) $(ASLPP_FLAGS) $(INC) /I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
+-AmlToHex $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml
 
 
 Trim --asl-file --asl-deps -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i 
-i $(INC_LIST) ${src}
 "$(ASLPP)" $(DEPS_FLAGS) $(ASLPP_FLAGS) $(INC) -I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
+-AmlToHex $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml
 
 [C-Code-File.AcpiTable]
 
diff --git a/BaseTools/Source/Python/AmlToHex/AmlToHex.py 
b/BaseTools/Source/Python/AmlToHex/AmlToHex.py
new file mode 100644
index 

[edk2-devel] [PATCH v3 1/1] BaseTools: Build ASL files before C files

[PierreGondois]

From: Pierre Gondois 

The dependencies for C files are satisfied by the build system.
However, there are use cases where source files with different
languages are inter-dependent. The EDKII build framework
currently doesn't have options to specify such dependencies.
E.g. It may be necessary to specify the build order between
 ASL files and C files. The use case being that the AML
 blob generated by compiling the ASL files is loaded and
 parsed by some C code.

This patch allows to describe dependencies between files listed
in the '[Sources]' section of '.inf' files. The list of source
files to build prior starts with a colon (':'), e.g.:
[Sources]
  FileName1.X
  FileName2.Y : FileName1.X
  FileName3.Z : FileName1.X FileName3.Z

In the example above:
  * FileName1.X will be built prior to FileName2.Y.
  * FileName1.X and FileName2.Y will be built prior to
FileName3.Z.

This does not affect the file specific build options,
which are pipe separated, e.g.:
  FileName2.Y | GCC : FileName1.X

The list of colon separated files must be part of the module,
i.e. they must be present in the [Sources] section.

Their file extension must be described in the
BaseTools/Conf/build_rule.template file, and generate
an output file, i.e. have a non-empty '' section.

Declaring a dependency in the [Sources] sections leads to
the creation of makefile rules between these files in the
build. The makefile rule is between the generated files.
E.g.:
  FileName1.X generates FileName1.objx
  FileName2.Y generates FileName2.objy
  Then
FileName2.Y : FileName1.X
  will create the following makefile rule:
FileName2.objy : FileName1.objx

INF Specification updates:
s3.2.1, "Common Definitions":
   ::= ":"
 ::=   

s2.5, "[Sources] Section":
  To describe a build order dependency between source
  files, specify the source files to build prior by
  listing them, colon separated.
   ::=  [] []
   ::=  [FileNameDependency]*

Signed-off-by: Pierre Gondois 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/tree/676_build_asl_first_v3

Notes:
v3:
 - In .inf files, after the first colon starting the list of file
   dependencies, the list of files are space separated. In v2,
   a colon was required before each file. Cf the example in the
   commit message. [Pierre]

 BaseTools/Source/Python/AutoGen/BuildEngine.py  |  6 
 BaseTools/Source/Python/AutoGen/GenMake.py  |  7 +
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py| 17 +++
 BaseTools/Source/Python/Common/DataType.py  |  3 +-
 BaseTools/Source/Python/Common/Misc.py  |  3 ++
 BaseTools/Source/Python/Workspace/InfBuildData.py   | 32 ++--
 BaseTools/Source/Python/Workspace/MetaFileParser.py | 18 +--
 7 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/BuildEngine.py 
b/BaseTools/Source/Python/AutoGen/BuildEngine.py
index 
d602414ca41f37155c9c6d00eec54ea3918840c3..687617756619a5b547f18c99c4773842a8328ae8
 100644
--- a/BaseTools/Source/Python/AutoGen/BuildEngine.py
+++ b/BaseTools/Source/Python/AutoGen/BuildEngine.py
@@ -2,6 +2,8 @@
 # The engine for building files
 #
 # Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2020, ARM Limited. All rights reserved.
+#
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 
@@ -53,6 +55,7 @@ class TargetDescBlock(object):
 self.Outputs = Outputs
 self.Commands = Commands
 self.Dependencies = Dependencies
+self.SourceFileDependencies = None
 if self.Outputs:
 self.Target = self.Outputs[0]
 else:
@@ -277,6 +280,9 @@ class FileBuildRule:
 TargetDesc.GenListFile = self.GenListFile
 TargetDesc.GenIncListFile = self.GenIncListFile
 self.BuildTargets[DstFile[0]] = TargetDesc
+
+TargetDesc.SourceFileDependencies = SourceFile.SourceFileDependencies
+
 return TargetDesc
 
 def _BuildCommand(self, Macros):
diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index 
ba199c1aa73dc46856b41c13e07e3d9770081acd..9d9ac328b1f1fd781e3057d34116485e5ac99afd
 100755
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -2,6 +2,8 @@
 # Create makefile for MS nmake and GNU make
 #
 # Copyright (c) 2007 - 2020, Intel Corporation. All rights reserved.
+# Copyright (c) 2020, ARM Limited. All rights reserved.
+#
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 
@@ -1002,6 +1004,11 @@ cleanlib:
 
 Deps = []
 CCodeDeps = []
+
+if T.SourceFileDependencies:
+for File in T.SourceFileDependencies:
+Deps.append(self.PlaceMacro(str(File), self.Macros))
+
 # Add force-dependencies
 for Dep in T.Dependencies:
 

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

[Sukerkar, Amol N]

Hi Jiewen and Mike,

I agree with general statement that MD4 and MD5 are deprecated. However, 
Although not MD4, UEFI spec 2.8 still mentions MD5 (and does not mention that 
it is deprecated). That is the reason MD4 and MD5 were included.

If there is going to be an update to UEFI spec deprecating MD5 as well, we can 
definitely go ahead and remove MD5 (and MD4). I believe the decision is should 
we wait until the change to UEFI spec or make the change right now. Let me know 
which approach we should be following.

Thanks,
Amol

-Original Message-
From: Kinney, Michael D  
Sent: Tuesday, February 04, 2020 9:26 AM
To: Yao, Jiewen ; devel@edk2.groups.io; Kinney, Michael D 
; Sukerkar, Amol N 
Cc: Wang, Jian J 
Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash 
Calculation API

Jiewen,

I think UINT8 is fine.  We can change default to 0x04 in DEC file.

I will let Amol comment on why MD4 and MD5 are included.  If they are not 
required, then I agree they should be removed.

I do not see a reason to align with TCG spec.  The HashApiLib is a layer on top 
of BaseCryptLib and the use of hash algorithms is not limited to TCG related 
content.  The BaseCryptLib could potentially adopt hash algorithms that are not 
defined in the TCG specification.  We also do not want CryptoPkg to depend on 
the SecurityPkg.

Thanks,

Mike

> -Original Message-
> From: Yao, Jiewen 
> Sent: Monday, February 3, 2020 6:54 PM
> To: Kinney, Michael D ; 
> devel@edk2.groups.io
> Cc: Sukerkar, Amol N ; Wang, Jian J 
> 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> Implement Unified Hash Calculation API
> 
> Thanks Mike, to cover us during Chinese New Year holiday.
> 
> I am just back from vocation. A minor comment:
> 
> The PcdHashApiLibPolicy is UINT8, but the value is shown as 32bit 
> 0x0004.
> 
> There are couple of ways to enhance:
> 1) Define UINT8, and use 8bit style 0x04.
> 2) Define UINT32, and use 32bit style 0x0004.
> 3) Define UINT16 (match TCG definition), and use TCG defined value. 
> (Tpm20.h)
> #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> 
> MD4 and MD5 are known as insecure and deprecated. I doubt if we want 
> to add such support. (I strong recommend NO).
> 
> If we can remove MD4 and MD5, I think we can use #3.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Tuesday, February 4, 2020 7:36 AM
> > To: devel@edk2.groups.io
> > Cc: Sukerkar, Amol N ;
> Yao, Jiewen
> > ; Wang, Jian J
> 
> > Subject: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> Implement Unified Hash
> > Calculation API
> >
> > From: Amol N Sukerkar 
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2151
> >
> > This commit introduces a Unified Hash API to
> calculate hash using a
> > hashing algorithm specified by the PCD,
> PcdHashApiLibPolicy. This library
> > interfaces with the various hashing API, such as,
> MD4, MD5, SHA1, SHA256,
> > SHA512 and SM3_256 implemented in BaseCryptLib. The
> user can calculate
> > the desired hash by setting PcdHashApiLibPolicy to
> appropriate value.
> >
> > This feature is documented in the Bugzilla, 
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2151.
> >
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Cc: Michael D Kinney 
> > Signed-off-by: Amol N Sukerkar
> 
> > Reviewed-by: Michael D Kinney
> 
> > ---
> >  CryptoPkg/CryptoPkg.dec   |  20
> ++
> >  CryptoPkg/CryptoPkg.dsc   |   4
> +-
> >  CryptoPkg/CryptoPkg.uni   |  18
> +-
> >  CryptoPkg/Include/Library/HashApiLib.h| 122
> +++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.c   | 330
> ++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.inf |  44
> +++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.uni |  17
> +
> >  7 files changed, 553 insertions(+), 2 deletions(-)  create mode 
> > 100644
> CryptoPkg/Include/Library/HashApiLib.h
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.c
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.uni
> >
> > diff --git a/CryptoPkg/CryptoPkg.dec
> b/CryptoPkg/CryptoPkg.dec
> > index 41af6e879e..8ad0fb5d61 100644
> > --- a/CryptoPkg/CryptoPkg.dec
> > +++ b/CryptoPkg/CryptoPkg.dec
> > @@ -33,9 +33,29 @@ [LibraryClasses]
> >##
> >TlsLib|Include/Library/TlsLib.h
> >
> > +  ##  @libraryclass  Provides Unified API for
> different hash implementations.
> > +  #
> > +  HashApiLib|Include/Library/HashApiLib.h
> > +
> >  [Guids]
> >## Crypto package token space guid.
> >gEfiCryptoPkgTokenSpaceGuid  = { 0x6bd7de60,
> 0x9ef7, 0x4899, { 0x97,
> > 0xd0, 0xab, 0xff, 0xfd, 

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

[Michael D Kinney]

Jiewen,

I think UINT8 is fine.  We can change default to 0x04 in DEC file.

I will let Amol comment on why MD4 and MD5 are included.  If
they are not required, then I agree they should be removed.

I do not see a reason to align with TCG spec.  The HashApiLib
is a layer on top of BaseCryptLib and the use of hash algorithms
is not limited to TCG related content.  The BaseCryptLib
could potentially adopt hash algorithms that are not defined
in the TCG specification.  We also do not want CryptoPkg to
depend on the SecurityPkg.

Thanks,

Mike

> -Original Message-
> From: Yao, Jiewen 
> Sent: Monday, February 3, 2020 6:54 PM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Sukerkar, Amol N ; Wang,
> Jian J 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> Implement Unified Hash Calculation API
> 
> Thanks Mike, to cover us during Chinese New Year
> holiday.
> 
> I am just back from vocation. A minor comment:
> 
> The PcdHashApiLibPolicy is UINT8, but the value is
> shown as 32bit 0x0004.
> 
> There are couple of ways to enhance:
> 1) Define UINT8, and use 8bit style 0x04.
> 2) Define UINT32, and use 32bit style 0x0004.
> 3) Define UINT16 (match TCG definition), and use TCG
> defined value. (Tpm20.h)
> #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> 
> MD4 and MD5 are known as insecure and deprecated. I
> doubt if we want to add such support. (I strong
> recommend NO).
> 
> If we can remove MD4 and MD5, I think we can use #3.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Tuesday, February 4, 2020 7:36 AM
> > To: devel@edk2.groups.io
> > Cc: Sukerkar, Amol N ;
> Yao, Jiewen
> > ; Wang, Jian J
> 
> > Subject: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> Implement Unified Hash
> > Calculation API
> >
> > From: Amol N Sukerkar 
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2151
> >
> > This commit introduces a Unified Hash API to
> calculate hash using a
> > hashing algorithm specified by the PCD,
> PcdHashApiLibPolicy. This library
> > interfaces with the various hashing API, such as,
> MD4, MD5, SHA1, SHA256,
> > SHA512 and SM3_256 implemented in BaseCryptLib. The
> user can calculate
> > the desired hash by setting PcdHashApiLibPolicy to
> appropriate value.
> >
> > This feature is documented in the Bugzilla,
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2151.
> >
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Cc: Michael D Kinney 
> > Signed-off-by: Amol N Sukerkar
> 
> > Reviewed-by: Michael D Kinney
> 
> > ---
> >  CryptoPkg/CryptoPkg.dec   |  20
> ++
> >  CryptoPkg/CryptoPkg.dsc   |   4
> +-
> >  CryptoPkg/CryptoPkg.uni   |  18
> +-
> >  CryptoPkg/Include/Library/HashApiLib.h| 122
> +++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.c   | 330
> ++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.inf |  44
> +++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.uni |  17
> +
> >  7 files changed, 553 insertions(+), 2 deletions(-)
> >  create mode 100644
> CryptoPkg/Include/Library/HashApiLib.h
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.c
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.uni
> >
> > diff --git a/CryptoPkg/CryptoPkg.dec
> b/CryptoPkg/CryptoPkg.dec
> > index 41af6e879e..8ad0fb5d61 100644
> > --- a/CryptoPkg/CryptoPkg.dec
> > +++ b/CryptoPkg/CryptoPkg.dec
> > @@ -33,9 +33,29 @@ [LibraryClasses]
> >##
> >TlsLib|Include/Library/TlsLib.h
> >
> > +  ##  @libraryclass  Provides Unified API for
> different hash implementations.
> > +  #
> > +  HashApiLib|Include/Library/HashApiLib.h
> > +
> >  [Guids]
> >## Crypto package token space guid.
> >gEfiCryptoPkgTokenSpaceGuid  = { 0x6bd7de60,
> 0x9ef7, 0x4899, { 0x97,
> > 0xd0, 0xab, 0xff, 0xfd, 0xe9, 0x70, 0xf2 } }
> >
> > +[PcdsFixedAtBuild, PcdsPatchableInModule,
> PcdsDynamic, PcdsDynamicEx]
> > +  ## This PCD indicates the HASH algorithm to
> calculate hash of data
> > +  #  Based on the value set, the required algorithm
> is chosen to calculate
> > +  #  the hash of data.
> > +  #  The default hashing algorithm for
> BaseHashApiLib is set to SHA256.
> > +  # 0x0001- MD4.
> > +  # 0x0002- MD5.
> > +  # 0x0003- SHA1.
> > +  # 0x0004- SHA256.
> > +  # 0x0005- SHA384.
> > +  # 0x0006- SHA512.
> > +  # 0x0007- SM3_256.
> > +  # @Prompt Set policy for hashing unsigned image
> for Secure Boot.
> > +  # @ValidRange 0x8001 | 0x0001 - 0x0007
> > +
> >
> gEfiCryptoPkgTokenSpaceGuid.PcdHashApiLibPolicy|0x04|UI
> 

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

[Sukerkar, Amol N]

Hi Mike, Jiewen and Jian,

Do I need to follow any crypto review guidelines for this patch? I am not 
enabling any new crypto. Need your input.

Thanks,
Amol

-Original Message-
From: Sukerkar, Amol N  
Sent: Tuesday, February 04, 2020 10:10 AM
To: Kinney, Michael D ; Yao, Jiewen 
; devel@edk2.groups.io
Cc: Wang, Jian J ; Sukerkar, Amol N 

Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash 
Calculation API

Hi Jiewen and Mike,

I agree with general statement that MD4 and MD5 are deprecated. However, 
Although not MD4, UEFI spec 2.8 still mentions MD5 (and does not mention that 
it is deprecated). That is the reason MD4 and MD5 were included.

If there is going to be an update to UEFI spec deprecating MD5 as well, we can 
definitely go ahead and remove MD5 (and MD4). I believe the decision is should 
we wait until the change to UEFI spec or make the change right now. Let me know 
which approach we should be following.

Thanks,
Amol

-Original Message-
From: Kinney, Michael D 
Sent: Tuesday, February 04, 2020 9:26 AM
To: Yao, Jiewen ; devel@edk2.groups.io; Kinney, Michael D 
; Sukerkar, Amol N 
Cc: Wang, Jian J 
Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash 
Calculation API

Jiewen,

I think UINT8 is fine.  We can change default to 0x04 in DEC file.

I will let Amol comment on why MD4 and MD5 are included.  If they are not 
required, then I agree they should be removed.

I do not see a reason to align with TCG spec.  The HashApiLib is a layer on top 
of BaseCryptLib and the use of hash algorithms is not limited to TCG related 
content.  The BaseCryptLib could potentially adopt hash algorithms that are not 
defined in the TCG specification.  We also do not want CryptoPkg to depend on 
the SecurityPkg.

Thanks,

Mike

> -Original Message-
> From: Yao, Jiewen 
> Sent: Monday, February 3, 2020 6:54 PM
> To: Kinney, Michael D ; 
> devel@edk2.groups.io
> Cc: Sukerkar, Amol N ; Wang, Jian J 
> 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> Implement Unified Hash Calculation API
> 
> Thanks Mike, to cover us during Chinese New Year holiday.
> 
> I am just back from vocation. A minor comment:
> 
> The PcdHashApiLibPolicy is UINT8, but the value is shown as 32bit 
> 0x0004.
> 
> There are couple of ways to enhance:
> 1) Define UINT8, and use 8bit style 0x04.
> 2) Define UINT32, and use 32bit style 0x0004.
> 3) Define UINT16 (match TCG definition), and use TCG defined value. 
> (Tpm20.h)
> #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> 
> MD4 and MD5 are known as insecure and deprecated. I doubt if we want 
> to add such support. (I strong recommend NO).
> 
> If we can remove MD4 and MD5, I think we can use #3.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Tuesday, February 4, 2020 7:36 AM
> > To: devel@edk2.groups.io
> > Cc: Sukerkar, Amol N ;
> Yao, Jiewen
> > ; Wang, Jian J
> 
> > Subject: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> Implement Unified Hash
> > Calculation API
> >
> > From: Amol N Sukerkar 
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2151
> >
> > This commit introduces a Unified Hash API to
> calculate hash using a
> > hashing algorithm specified by the PCD,
> PcdHashApiLibPolicy. This library
> > interfaces with the various hashing API, such as,
> MD4, MD5, SHA1, SHA256,
> > SHA512 and SM3_256 implemented in BaseCryptLib. The
> user can calculate
> > the desired hash by setting PcdHashApiLibPolicy to
> appropriate value.
> >
> > This feature is documented in the Bugzilla, 
> > https://bugzilla.tianocore.org/show_bug.cgi?id=2151.
> >
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Cc: Michael D Kinney 
> > Signed-off-by: Amol N Sukerkar
> 
> > Reviewed-by: Michael D Kinney
> 
> > ---
> >  CryptoPkg/CryptoPkg.dec   |  20
> ++
> >  CryptoPkg/CryptoPkg.dsc   |   4
> +-
> >  CryptoPkg/CryptoPkg.uni   |  18
> +-
> >  CryptoPkg/Include/Library/HashApiLib.h| 122
> +++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.c   | 330
> ++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.inf |  44
> +++
> >  .../Library/BaseHashApiLib/BaseHashApiLib.uni |  17
> +
> >  7 files changed, 553 insertions(+), 2 deletions(-)  create mode
> > 100644
> CryptoPkg/Include/Library/HashApiLib.h
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.c
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf
> >  create mode 100644
> CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.uni
> >
> > diff --git a/CryptoPkg/CryptoPkg.dec
> b/CryptoPkg/CryptoPkg.dec
> > index 41af6e879e..8ad0fb5d61 100644
> > --- 

Re: [edk2-devel] [edk2-rfc] [RFC] code-first process for UEFI-forum specifications

[Michael D Kinney]

Leif,

A few comments included below.

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On
> Behalf Of Laszlo Ersek
> Sent: Monday, January 20, 2020 10:42 AM
> To: r...@edk2.groups.io; l...@nuviainc.com;
> devel@edk2.groups.io
> Subject: Re: [edk2-devel] [edk2-rfc] [RFC] code-first
> process for UEFI-forum specifications
> 
> On 01/20/20 17:58, Leif Lindholm wrote:
> > This is a proposal for a process by which new
> features can be added to UEFI
> > forum specifications after first having been designed
> and prototyped in the
> > open.
> >
> > This process lets changes and the development of new
> features happen in the
> > open, without violating the UEFI forum bylaws which
> prevent publication of
> > code for in-draft features/changes.
> >
> > The process does not in fact change the UEFI bylaws -
> the change is that the
> > development (of both specification and code) happens
> in the open. The resulting
> > specification update is then submitted to the
> appropriate working goup as an
> > Engineering Change Request (ECR), and voted on. For
> the UEFI Forum, this is a
> > change in workflow, not a change in process.
> >
> > ECRs are tracked in a UEFI Forum Mantis instance,
> access restricted to UEFI
> > Forum Members. TianoCore will enable this new process
> by providing areas on
> > https://bugzilla.tianocore.org/ to track both
> specification updates and
> > reference implementations and new repositories under
> > https://github.com/tianocore/ dedicated to hold "code
> first".
> >
> >
> > ## Bugzilla
> >
> > bugzilla.tianocore.oorg will have a product category
> each for
> 
> s/oorg/org/
> 
> >   * ACPI Specification
> >   * PI Specification
> >   * UEFI Specification
> >
> > Each product category will have a separate components
> for
> >   * Specification
> >   * Reference implementation
> >
> >
> > ## Github
> > New repositories will be added for holding the text
> changes and the source code.
> >
> > Specification text changes will be held within the
> affected source repository.
> 
> This seems to require that the specifications be
> available as something
> "patchable" (e.g. GitBook source code), and offered in
> some public git repo.
> 

I recommend we use MarkDown.  GitHub flavored MarkDown
may be a good choice so an ECR can be viewed from the
web view of GitHub.  This also support text based patch
reviews of the ECR content.

> > (This one may break down where we have a
> specification change affecting multiple
> > specifications, but at that point we can track it
> with multiple BZ entries)
> >
> > Initially, edk2-spec-update will be created to hold
> the reference
> > implementations. Additional repositories for
> implementing reference features in
> > additional open source projects can be added in the
> future, as required.

I recommend using branches in the existing edk2-staging
repository for changes that only impact EDK II firmware
components/tools.

> >
> >
> > ## Intended workflow
> > The entity initiating a specifiation update raises a
> Bugzilla in the appropriate
> > area in bugzilla.tianocore.org. This entry contains
> the outline of the change,
> > and the full initial draft text is attached.
> 
> How does this play together with *patches* for specs
> (see above)?
> Attaching patches to BZs is not good practice. Should
> we attach complete
> renderings of the patched (huge) specs?
> 
> >
> > If multiple specification updates are interdependent,
> especially if between
> > different specifications, then multiple bugzilla
> entries should be created.
> > These bugzilla entries *must* be linked together with
> dependencies.
> >
> > After the BZs have been created, new branches should
> be created in the relevant
> > repositories for each bugzilla - the branch names
> should be BZ, where 
> > describes the bugzilla ID assigned, optionally
> followed by a '-' and something
> > more descriptive. If multipls bugzilla entries must
> coexist on a single branch,
> 
> s/multipls/multiple/
> 
> > one of them is designated the 'top-level', with
> dependencies properly tracked.
> > That BZ will be the one naming the branch.
> >
> >
> > ## Source code
> > In order to ensure draft code does not accidentally
> leak into production use,
> > and to signify when the changeover from draft to
> final happens, *all* new or
> > modified[1] identifiers need to be prefixed with the
> relevant BZ.
> >
> > [1] Modified in a non-backwards-compatible way. If,
> for example, a statically
> > sized array is grown - this does not need to be
> prefixed. (Question: but a
> > tag in a comment?)
> >

It would be good to clarify when the BZ### prefix is required
and not required and to describe a few more use cases.  Here 
are a few.  I am sure this list will be expanded when real
examples are implemented.

1) New/modified interfaces require prefix.
  a) New structures.  Only top level struct require a prefix.  Fields and sub 
structures do not.
2) New public header 

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

[Yao, Jiewen]

Amol
We are in the process to deprecating SHA1.
Currently SHA256 is default one.
Some products are moving from SHA256 to SHA384.

We did crypto usage analysis before.
In the current EDKII code base, there is no code using MD4.
The only code that using MD5 is the iSCSI.

TPM1.2 has to use SHA1 - that is updated by the TPM2.
Some old certificate was using SHA1. It will be deprecated and move to SHA256.

Even UEFI spec defines MD5, but it does not mean a product has to use MD5. UEFI 
spec does not mandate that you must support MD5.
Do you see any MD5 usage in BIOS except iSCSI?

If no, I prefer to drop MD4/MD5 in this patch.

Thank you
Yao Jiewen


> -Original Message-
> From: Sukerkar, Amol N 
> Sent: Wednesday, February 5, 2020 1:10 AM
> To: Kinney, Michael D ; Yao, Jiewen
> ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Sukerkar, Amol N
> 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash
> Calculation API
> 
> Hi Jiewen and Mike,
> 
> I agree with general statement that MD4 and MD5 are deprecated. However,
> Although not MD4, UEFI spec 2.8 still mentions MD5 (and does not mention that
> it is deprecated). That is the reason MD4 and MD5 were included.
> 
> If there is going to be an update to UEFI spec deprecating MD5 as well, we can
> definitely go ahead and remove MD5 (and MD4). I believe the decision is should
> we wait until the change to UEFI spec or make the change right now. Let me
> know which approach we should be following.
> 
> Thanks,
> Amol
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, February 04, 2020 9:26 AM
> To: Yao, Jiewen ; devel@edk2.groups.io; Kinney,
> Michael D ; Sukerkar, Amol N
> 
> Cc: Wang, Jian J 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash
> Calculation API
> 
> Jiewen,
> 
> I think UINT8 is fine.  We can change default to 0x04 in DEC file.
> 
> I will let Amol comment on why MD4 and MD5 are included.  If they are not
> required, then I agree they should be removed.
> 
> I do not see a reason to align with TCG spec.  The HashApiLib is a layer on 
> top of
> BaseCryptLib and the use of hash algorithms is not limited to TCG related
> content.  The BaseCryptLib could potentially adopt hash algorithms that are 
> not
> defined in the TCG specification.  We also do not want CryptoPkg to depend on
> the SecurityPkg.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Monday, February 3, 2020 6:54 PM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io
> > Cc: Sukerkar, Amol N ; Wang, Jian J
> > 
> > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > Implement Unified Hash Calculation API
> >
> > Thanks Mike, to cover us during Chinese New Year holiday.
> >
> > I am just back from vocation. A minor comment:
> >
> > The PcdHashApiLibPolicy is UINT8, but the value is shown as 32bit
> > 0x0004.
> >
> > There are couple of ways to enhance:
> > 1) Define UINT8, and use 8bit style 0x04.
> > 2) Define UINT32, and use 32bit style 0x0004.
> > 3) Define UINT16 (match TCG definition), and use TCG defined value.
> > (Tpm20.h)
> > #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> > #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> > #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> > #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> > #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> >
> > MD4 and MD5 are known as insecure and deprecated. I doubt if we want
> > to add such support. (I strong recommend NO).
> >
> > If we can remove MD4 and MD5, I think we can use #3.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Tuesday, February 4, 2020 7:36 AM
> > > To: devel@edk2.groups.io
> > > Cc: Sukerkar, Amol N ;
> > Yao, Jiewen
> > > ; Wang, Jian J
> > 
> > > Subject: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > Implement Unified Hash
> > > Calculation API
> > >
> > > From: Amol N Sukerkar 
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2151
> > >
> > > This commit introduces a Unified Hash API to
> > calculate hash using a
> > > hashing algorithm specified by the PCD,
> > PcdHashApiLibPolicy. This library
> > > interfaces with the various hashing API, such as,
> > MD4, MD5, SHA1, SHA256,
> > > SHA512 and SM3_256 implemented in BaseCryptLib. The
> > user can calculate
> > > the desired hash by setting PcdHashApiLibPolicy to
> > appropriate value.
> > >
> > > This feature is documented in the Bugzilla,
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2151.
> > >
> > > Cc: Jiewen Yao 
> > > Cc: Jian J Wang 
> > > Cc: Michael D Kinney 
> > > Signed-off-by: Amol N Sukerkar
> > 
> > > Reviewed-by: Michael D Kinney
> > 
> > > ---
> > >  CryptoPkg/CryptoPkg.dec   |  20
> > ++
> > >  CryptoPkg/CryptoPkg.dsc   |   4
> > +-
> > >  CryptoPkg/CryptoPkg.uni   |  18
> > +-
> > >  

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

[Yao, Jiewen]

Thank Amol.
You may want to keep SHA1. I still feel that SHA1 is used in some special case.
It is safety to just drop MD4 and MD5 at this moment.

We may consider to drop SHA1 later, when we do not see any usage.

With this patch, I believe it will be easy for us to move from SHA256 to SHA384 
later.
Good work!

Thank you
Yao Jiewen

> -Original Message-
> From: Sukerkar, Amol N 
> Sent: Wednesday, February 5, 2020 7:15 AM
> To: Yao, Jiewen ; Kinney, Michael D
> ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Sukerkar, Amol N
> 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash
> Calculation API
> 
> Thanks for the feedback, Jiewen!
> 
> In that case, I agree we should deprecate MD4, MD5 and SHA1 in
> BaseHashApiLib.
> 
> If the above statement is accurate, I can start next set of patches to remove 
> the
> deprecated algorithms by creating a Bugzilla ticket. Please confirm.
> 
> Thanks,
> Amol
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Tuesday, February 04, 2020 4:06 PM
> To: Sukerkar, Amol N ; Kinney, Michael D
> ; devel@edk2.groups.io
> Cc: Wang, Jian J 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash
> Calculation API
> 
> Amol
> We are in the process to deprecating SHA1.
> Currently SHA256 is default one.
> Some products are moving from SHA256 to SHA384.
> 
> We did crypto usage analysis before.
> In the current EDKII code base, there is no code using MD4.
> The only code that using MD5 is the iSCSI.
> 
> TPM1.2 has to use SHA1 - that is updated by the TPM2.
> Some old certificate was using SHA1. It will be deprecated and move to SHA256.
> 
> Even UEFI spec defines MD5, but it does not mean a product has to use MD5.
> UEFI spec does not mandate that you must support MD5.
> Do you see any MD5 usage in BIOS except iSCSI?
> 
> If no, I prefer to drop MD4/MD5 in this patch.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Sukerkar, Amol N 
> > Sent: Wednesday, February 5, 2020 1:10 AM
> > To: Kinney, Michael D ; Yao, Jiewen
> > ; devel@edk2.groups.io
> > Cc: Wang, Jian J ; Sukerkar, Amol N
> > 
> > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement
> > Unified Hash Calculation API
> >
> > Hi Jiewen and Mike,
> >
> > I agree with general statement that MD4 and MD5 are deprecated.
> > However, Although not MD4, UEFI spec 2.8 still mentions MD5 (and does
> > not mention that it is deprecated). That is the reason MD4 and MD5 were
> included.
> >
> > If there is going to be an update to UEFI spec deprecating MD5 as
> > well, we can definitely go ahead and remove MD5 (and MD4). I believe
> > the decision is should we wait until the change to UEFI spec or make
> > the change right now. Let me know which approach we should be following.
> >
> > Thanks,
> > Amol
> >
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Tuesday, February 04, 2020 9:26 AM
> > To: Yao, Jiewen ; devel@edk2.groups.io; Kinney,
> > Michael D ; Sukerkar, Amol N
> > 
> > Cc: Wang, Jian J 
> > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement
> > Unified Hash Calculation API
> >
> > Jiewen,
> >
> > I think UINT8 is fine.  We can change default to 0x04 in DEC file.
> >
> > I will let Amol comment on why MD4 and MD5 are included.  If they are
> > not required, then I agree they should be removed.
> >
> > I do not see a reason to align with TCG spec.  The HashApiLib is a
> > layer on top of BaseCryptLib and the use of hash algorithms is not
> > limited to TCG related content.  The BaseCryptLib could potentially
> > adopt hash algorithms that are not defined in the TCG specification.
> > We also do not want CryptoPkg to depend on the SecurityPkg.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Monday, February 3, 2020 6:54 PM
> > > To: Kinney, Michael D ;
> > > devel@edk2.groups.io
> > > Cc: Sukerkar, Amol N ; Wang, Jian J
> > > 
> > > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > > Implement Unified Hash Calculation API
> > >
> > > Thanks Mike, to cover us during Chinese New Year holiday.
> > >
> > > I am just back from vocation. A minor comment:
> > >
> > > The PcdHashApiLibPolicy is UINT8, but the value is shown as 32bit
> > > 0x0004.
> > >
> > > There are couple of ways to enhance:
> > > 1) Define UINT8, and use 8bit style 0x04.
> > > 2) Define UINT32, and use 32bit style 0x0004.
> > > 3) Define UINT16 (match TCG definition), and use TCG defined value.
> > > (Tpm20.h)
> > > #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> > > #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> > > #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> > > #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> > > #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> > >
> > > MD4 and MD5 are known as insecure and deprecated. I doubt if we want
> > > to add such support. (I strong recommend NO).
> > >
> > > If we can remove 

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

[Laszlo Ersek]

On 02/04/20 23:49, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> This series improves PatchCheck.py so Mergify can catch
> the emails rewritten by the mailing list.
> Also it enable mailmap usage by default in the git config.
> 
> Regards,
> 
> Phil.
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> 
> Philippe Mathieu-Daudé (3):
>   BaseTools/Scripts/PatchCheck.py: Do not use mailmap
>   BaseTools/Scripts/PatchCheck.py: Detect emails rewritten by Groups.Io
>   BaseTools/Scripts: Add log.mailmap to SetupGit.py
> 
>  BaseTools/Scripts/PatchCheck.py | 10 --
>  BaseTools/Scripts/SetupGit.py   |  1 +
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 

Reviewed-by: Laszlo Ersek 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53790): https://edk2.groups.io/g/devel/message/53790
Mute This Topic: https://groups.io/mt/70984702/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Philippe Mathieu-Daudé]

Hi,

This series improves PatchCheck.py so Mergify can catch
the emails rewritten by the mailing list.
Also it enable mailmap usage by default in the git config.

Regards,

Phil.

Cc: Bob Feng 
Cc: Liming Gao 

Philippe Mathieu-Daudé (3):
  BaseTools/Scripts/PatchCheck.py: Do not use mailmap
  BaseTools/Scripts/PatchCheck.py: Detect emails rewritten by Groups.Io
  BaseTools/Scripts: Add log.mailmap to SetupGit.py

 BaseTools/Scripts/PatchCheck.py | 10 --
 BaseTools/Scripts/SetupGit.py   |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

-- 
2.21.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53743): https://edk2.groups.io/g/devel/message/53743
Mute This Topic: https://groups.io/mt/70984702/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/3] BaseTools/Scripts/PatchCheck.py: Detect emails rewritten by Groups.Io

[Philippe Mathieu-Daudé]

From: Philippe Mathieu-Daudé 

Due to strict DMARC / DKIM / SPF rules, Groups.Io sometimes rewrite
the author email. See for example commit df851da3ceff5b6bcf5e12616.
Add a check to detect these rewrites with PatchCheck.py.

Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: Philippe Mathieu-Daude 
---
 BaseTools/Scripts/PatchCheck.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/BaseTools/Scripts/PatchCheck.py b/BaseTools/Scripts/PatchCheck.py
index 07881abaf64e..13da6967785d 100755
--- a/BaseTools/Scripts/PatchCheck.py
+++ b/BaseTools/Scripts/PatchCheck.py
@@ -79,6 +79,10 @@ class EmailAddressCheck:
 self.error("The email address cannot contain a space: " +
mo.group(3))
 
+if ' via Groups.Io' in name and mo.group(3).endswith('@groups.io'):
+self.error("Email rewritten by lists DMARC / DKIM / SPF: " +
+   email)
+
 class CommitMessageCheck:
 """Checks the contents of a git commit message."""
 
-- 
2.21.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53745): https://edk2.groups.io/g/devel/message/53745
Mute This Topic: https://groups.io/mt/70984707/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 3/3] BaseTools/Scripts: Add log.mailmap to SetupGit.py

[Philippe Mathieu-Daudé]

From: Philippe Mathieu-Daudé 

We added .mailmap to the repository in commit 4a1aeca3bd02d04e01c2d
to display commit mistakes fixed. Use this option by default in our
git setup.

Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: Philippe Mathieu-Daude 
---
 BaseTools/Scripts/SetupGit.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/BaseTools/Scripts/SetupGit.py b/BaseTools/Scripts/SetupGit.py
index 514f1c4d42d4..e320ba2f887e 100644
--- a/BaseTools/Scripts/SetupGit.py
+++ b/BaseTools/Scripts/SetupGit.py
@@ -74,6 +74,7 @@ OPTIONS = [
 {'section': 'format',  'option': 'coverLetter',   'value': True},
 {'section': 'format',  'option': 'numbered',  'value': True},
 {'section': 'format',  'option': 'signoff',   'value': False},
+{'section': 'log', 'option': 'mailmap',   'value': True},
 {'section': 'notes',   'option': 'rewriteRef','value': 
'refs/notes/commits'},
 {'section': 'sendemail',   'option': 'chainreplyto',  'value': False},
 {'section': 'sendemail',   'option': 'thread','value': True},
-- 
2.21.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53744): https://edk2.groups.io/g/devel/message/53744
Mute This Topic: https://groups.io/mt/70984705/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/3] BaseTools/Scripts/PatchCheck.py: Do not use mailmap

[Philippe Mathieu-Daudé]

From: Philippe Mathieu-Daudé 

We check the author/committer name/email are properly displayed
since commits 8ffa47fb3ab..c0328cf3803. However if PatchCheck.py
uses the mailmap, it will check sanitized names/emails.
Use the --no-use-mailmap option so PatchCheck.py will check
unsanitized input.

Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: Philippe Mathieu-Daude 
---
 BaseTools/Scripts/PatchCheck.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Scripts/PatchCheck.py b/BaseTools/Scripts/PatchCheck.py
index 6823cc69bb9f..07881abaf64e 100755
--- a/BaseTools/Scripts/PatchCheck.py
+++ b/BaseTools/Scripts/PatchCheck.py
@@ -643,11 +643,13 @@ class CheckGitCommits:
 
 def read_patch_from_git(self, commit):
 # Run git to get the commit patch
-return self.run_git('show', '--pretty=email', '--no-textconv', commit)
+return self.run_git('show', '--pretty=email', '--no-textconv',
+'--no-use-mailmap', commit)
 
 def read_committer_email_address_from_git(self, commit):
 # Run git to get the committer email
-return self.run_git('show', '--pretty=%cn <%ce>', '--no-patch', commit)
+return self.run_git('show', '--pretty=%cn <%ce>', '--no-patch',
+'--no-use-mailmap', commit)
 
 def run_git(self, *args):
 cmd = [ 'git' ]
-- 
2.21.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53742): https://edk2.groups.io/g/devel/message/53742
Mute This Topic: https://groups.io/mt/70984701/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 36/40] UefiCpuPkg/MpInitLib: Add a CPU MP data flag to indicate if SEV-ES is enabled

[Lendacky, Thomas]

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

When starting APs in an SMP configuration, the AP needs to know if it is
running as an SEV-ES guest in order to assign a GHCB page.

Add a field to the CPU_MP_DATA structure that will indicate if SEV-ES is
enabled. This new field is set during MP library initialization with the
PCD value PcdSevEsIsEnabled. This flag can then be used to determine if
SEV-ES is enabled.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
 UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 1 +
 UefiCpuPkg/Library/MpInitLib/MpLib.h  | 2 ++
 UefiCpuPkg/Library/MpInitLib/MpLib.c  | 1 +
 4 files changed, 5 insertions(+)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf 
b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
index bf5d18d521e9..2c26f20c1972 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
@@ -69,5 +69,6 @@ [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode   ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate   ## 
SOMETIMES_CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuShadowMicrocodeByFit ## CONSUMES
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled  ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard  ## CONSUMES
 
diff --git a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf 
b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
index 555125a7c575..66b2acfe98e7 100644
--- a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
+++ b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
@@ -61,6 +61,7 @@ [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode   ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate   ## 
SOMETIMES_CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuShadowMicrocodeByFit ## CONSUMES
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled  ## CONSUMES
 
 [Guids]
   gEdkiiS3SmmInitDoneGuid
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
b/UefiCpuPkg/Library/MpInitLib/MpLib.h
index 7c62d75accfb..864b16872010 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
@@ -273,6 +273,8 @@ struct _CPU_MP_DATA {
   // driver.
   //
   BOOLEANWakeUpByInitSipiSipi;
+
+  BOOLEANSevEsIsEnabled;
 };
 
 extern EFI_GUID mCpuInitMpLibHobGuid;
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 855d37ba3ed8..5e3183c2493b 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -1687,6 +1687,7 @@ MpInitLibInitialize (
 CpuMpData->MicrocodePatchAddress= OldCpuMpData->MicrocodePatchAddress;
   }
   InitializeSpinLock(>MpLock);
+  CpuMpData->SevEsIsEnabled = PcdGetBool (PcdSevEsIsEnabled);
 
   //
   // Make sure no memory usage outside of the allocated buffer.
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53783): https://edk2.groups.io/g/devel/message/53783
Mute This Topic: https://groups.io/mt/70985006/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 34/40] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ES is enabled

[Lendacky, Thomas]

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

The flash detection routine will attempt to determine how the flash
device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
the flash device behaves as a ROM device (meaning it is marked read-only
by the hypervisor), this check may result in an infinite nested page fault
because of the attempted write. Since the instruction cannot be emulated
when SEV-ES is enabled, the RIP is never advanced, resulting in repeated
nested page faults.

When SEV-ES is enabled, exit the flash detection early and assume that
the FD behaves as Flash. This will result in QemuFlashWrite() being called
to store EFI variables, which will also result in an infinite nested page
fault when the write is performed. In this case, update QemuFlashWrite()
to use the VmgMmioWrite function from the VmgExitLib library to have the
hypervisor perform the write without having to emulate the instruction.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgIa32.dsc   |  1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|  1 +
 OvmfPkg/OvmfPkgX64.dsc|  1 +
 .../FvbServicesRuntimeDxe.inf |  2 ++
 .../QemuFlash.h   |  6 +
 .../QemuFlash.c   | 23 ---
 .../QemuFlashDxe.c| 15 
 .../QemuFlashSmm.c|  9 
 8 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index c364da521579..ac67fc1bd8b8 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -320,6 +320,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 0adae1e0be30..ecf5c2ad54a3 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -325,6 +325,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 4b5e96a32b0b..33f7571d4df0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -325,6 +325,7 @@ [LibraryClasses.common.DXE_RUNTIME_DRIVER]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index ca6326e833ed..0b7741ac07f8 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -38,6 +38,7 @@ [Sources]
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
@@ -52,6 +53,7 @@ [LibraryClasses]
   UefiBootServicesTableLib
   UefiDriverEntryPoint
   UefiRuntimeLib
+  VmgExitLib
 
 [Guids]
   gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
index f1afabcbe6ae..19ac1f733279 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
@@ -89,5 +89,11 @@ QemuFlashBeforeProbe (
   IN  UINTN   FdBlockCount
   );
 
+VOID
+QemuFlashPtrWrite (
+  INvolatile UINT8*Ptr,
+  INUINT8 Value
+  );
+
 #endif
 
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
index c81c58972bf2..ccf5ad7f7afb 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "QemuFlash.h"
@@ -80,6 +81,21 @@ QemuFlashDetected (
 
   DEBUG ((EFI_D_INFO, "QEMU Flash: Attempting flash detection at %p\n", Ptr));
 

[edk2-devel] [PATCH v4 30/40] OvmfPkg: Reserve a page in memory for the SEV-ES usage

[Lendacky, Thomas]

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

Reserve a fixed area of memory for SEV-ES use and set a fixed PCD,
PcdSevEsWorkAreaBase, to this value.

This area will be used by SEV-ES support for two purposes:
  1. Communicating the SEV-ES status during BSP boot to SEC:
 Using a byte of memory from the page, the BSP reset vector code can
 communicate the SEV-ES status to SEC for use before exception
 handling can be enabled in SEC. After SEC, this field is no longer
 valid and the standard way of determine if SEV-ES is active should
 be used.

  2. Establishing an area of memory for AP boot support:
 A hypervisor is not allowed to update an SEV-ES guest's register
 state, so when booting an SEV-ES guest AP, the hypervisor is not
 allowed to set the RIP to the guest requested value. Instead an
 SEV-ES AP must be re-directed from within the guest to the actual
 requested staring location as specified in the INIT-SIPI-SIPI
 sequence.

 Use this memory for reset vector code that can be programmed to have
 the AP jump to the desired RIP location after starting the AP. This
 is required for only the very first AP reset.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgX64.fdf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index f541481dc95c..3504aa35dc37 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -82,6 +82,9 @@ [FD.MEMFD]
 0x009000|0x002000
 
gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbBase|gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbSize
 
+0x00B000|0x001000
+gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53777): https://edk2.groups.io/g/devel/message/53777
Mute This Topic: https://groups.io/mt/70984999/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 33/40] OvmfPkg/Sec: Enable cache early to speed up booting

[Lendacky, Thomas]

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

Currently, the OVMF code relies on the hypervisor to enable the cache
support on the processor in order to improve the boot speed. However,
with SEV-ES, the hypervisor is not allowed to change the CR0 register
to enable caching.

Update the OVMF Sec support to enable caching in order to improve the
boot speed when running as an SEV-ES guest.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Sec/SecMain.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index 2bab7128ade2..439c8a09be17 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -800,6 +800,13 @@ SecCoreStartupWithStack (
 // For non SEV-ES guests, just load the IDTR.
 //
 AsmWriteIdtr ();
+  } else {
+//
+// Under SEV-ES, the hypervisor can't modify CR0 and so can't enable
+// caching in order to speed up the boot. Enable caching early for
+// an SEV-ES guest.
+//
+AsmEnableCache ();
   }
 
   DEBUG ((EFI_D_INFO,
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53780): https://edk2.groups.io/g/devel/message/53780
Mute This Topic: https://groups.io/mt/70985003/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 39/40] OvmfPkg: Move the GHCB allocations into reserved memory

[Lendacky, Thomas]

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

After having transitioned from UEFI to the OS, the OS will need to boot
the APs. For an SEV-ES guest, the APs will have been parked by UEFI using
GHCB pages allocated by UEFI. The hypervisor will write to the GHCB
SW_EXITINFO2 field of the GHCB when the AP is booted. As a result, the
GHCB pages must be marked reserved so that the OS does not attempt to use
them and experience memory corruption because of the hypervisor write.

Change the GHCB allocation from the default boot services memory to
reserved memory.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/PlatformPei/AmdSev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index b3fd2d86541a..84b337325d5c 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -49,9 +49,11 @@ AmdSevEsInitialize (
 
   //
   // Allocate GHCB and per-CPU variable pages.
+  //   Since the pages must survive across the UEFI to OS transition
+  //   make them reserved.
   //
   GhcbPageCount = mMaxCpuCount * 2;
-  GhcbBase = AllocatePages (GhcbPageCount);
+  GhcbBase = AllocateReservedPages (GhcbPageCount);
   ASSERT (GhcbBase != NULL);
 
   GhcbBasePa = (PHYSICAL_ADDRESS)(UINTN) GhcbBase;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53786): https://edk2.groups.io/g/devel/message/53786
Mute This Topic: https://groups.io/mt/70985009/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 29/40] UefiCpuPkg: Create an SEV-ES workarea PCD

[Lendacky, Thomas]

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

Create an SEV-ES workarea PCD. This PCD will be used for BSP communication
during SEC and for AP startup during PEI and DXE phases, the latter is the
reason for creating it in the UefiCpuPkg.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/UefiCpuPkg.dec | 8 
 1 file changed, 8 insertions(+)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 893d2d06b0f2..16218ab4b2f4 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -172,6 +172,14 @@ [PcdsFixedAtBuild]
   # @Prompt SEC GHCB Size
   gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbSize|0|UINT32|0x30002004
 
+  ## Area of memory where the SEV-ES work area block lives.
+  # @Prompt Configure the SEV-ES work area base
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|0x0|UINT32|0x30002005
+
+  ## Size of teh area of memory where the SEV-ES work area block lives.
+  # @Prompt Configure the SEV-ES work area base
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize|0x0|UINT32|0x30002006
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## This value is the CPU Local APIC base address, which aligns the address 
on a 4-KByte boundary.
   # @Prompt Configure base address of CPU Local APIC
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53776): https://edk2.groups.io/g/devel/message/53776
Mute This Topic: https://groups.io/mt/70984952/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 35/40] UefiCpuPkg: Add a 16-bit protected mode code segment descriptor

[Lendacky, Thomas]

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

A hypervisor is not allowed to update an SEV-ES guests register state,
so when booting an SEV-ES guest AP, the hypervisor is not allowed to
set the RIP to the guest requested value. Instead, an SEV-ES AP must be
transition from 64-bit long mode to 16-bit real mode in response to an
INIT-SIPI-SIPI sequence. This requires a 16-bit code segment descriptor.
For PEI, create this descriptor in the reset vector GDT table. For DXE,
create this descriptor from the newly reserved entry at location 0x28.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/CpuDxe/CpuGdt.h  | 4 ++--
 UefiCpuPkg/CpuDxe/CpuGdt.c  | 8 
 UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm | 9 +
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuGdt.h b/UefiCpuPkg/CpuDxe/CpuGdt.h
index e5c36f37b96a..80e224b47fcd 100644
--- a/UefiCpuPkg/CpuDxe/CpuGdt.h
+++ b/UefiCpuPkg/CpuDxe/CpuGdt.h
@@ -36,7 +36,7 @@ struct _GDT_ENTRIES {
   GDT_ENTRY LinearCode;
   GDT_ENTRY SysData;
   GDT_ENTRY SysCode;
-  GDT_ENTRY Spare4;
+  GDT_ENTRY SysCode16;
   GDT_ENTRY LinearData64;
   GDT_ENTRY LinearCode64;
   GDT_ENTRY Spare5;
@@ -49,7 +49,7 @@ struct _GDT_ENTRIES {
 #define LINEAR_CODE_SEL   OFFSET_OF (GDT_ENTRIES, LinearCode)
 #define SYS_DATA_SEL  OFFSET_OF (GDT_ENTRIES, SysData)
 #define SYS_CODE_SEL  OFFSET_OF (GDT_ENTRIES, SysCode)
-#define SPARE4_SELOFFSET_OF (GDT_ENTRIES, Spare4)
+#define SYS_CODE16_SELOFFSET_OF (GDT_ENTRIES, SysCode16)
 #define LINEAR_DATA64_SEL OFFSET_OF (GDT_ENTRIES, LinearData64)
 #define LINEAR_CODE64_SEL OFFSET_OF (GDT_ENTRIES, LinearCode64)
 #define SPARE5_SELOFFSET_OF (GDT_ENTRIES, Spare5)
diff --git a/UefiCpuPkg/CpuDxe/CpuGdt.c b/UefiCpuPkg/CpuDxe/CpuGdt.c
index 87fd6955f24b..6a80829be884 100644
--- a/UefiCpuPkg/CpuDxe/CpuGdt.c
+++ b/UefiCpuPkg/CpuDxe/CpuGdt.c
@@ -70,14 +70,14 @@ STATIC GDT_ENTRIES GdtTemplate = {
 0x0,
   },
   //
-  // SPARE4_SEL
+  // SYS_CODE16_SEL
   //
   {
-0x0,// limit 15:0
+0x0,// limit 15:0
 0x0,// base 15:0
 0x0,// base 23:16
-0x0,// type
-0x0,// limit 19:16, flags
+0x09A,  // present, ring 0, code, execute/read
+0x08F,  // page-granular, 16-bit
 0x0,// base 31:24
   },
   //
diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm 
b/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
index ce4ebfffb688..0e79a3984b16 100644
--- a/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
+++ b/UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
@@ -129,5 +129,14 @@ LINEAR_CODE64_SEL   equ $-GDT_BASE
 DB  0; base 31:24
 %endif
 
+; linear code segment descriptor
+LINEAR_CODE16_SEL equ $-GDT_BASE
+DW  0x   ; limit 15:0
+DW  0; base 15:0
+DB  0; base 23:16
+DB  PRESENT_FLAG(1)|DPL(0)|SYSTEM_FLAG(1)|DESC_TYPE(CODE32_TYPE)
+DB  
GRANULARITY_FLAG(1)|DEFAULT_SIZE32(0)|CODE64_FLAG(0)|UPPER_LIMIT(0xf)
+DB  0; base 31:24
+
 GDT_END:
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53782): https://edk2.groups.io/g/devel/message/53782
Mute This Topic: https://groups.io/mt/70985005/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 38/40] OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector

[Lendacky, Thomas]

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

A hypervisor is not allowed to update an SEV-ES guest's register state,
so when booting an SEV-ES guest AP, the hypervisor is not allowed to
set the RIP to the guest requested value. Instead an SEV-ES AP must be
re-directed from within the guest to the actual requested staring location
as specified in the INIT-SIPI-SIPI sequence.

Use the SEV-ES work area for the reset vector code that contains support
to jump to the desired RIP location after having been started. This is
required for only the very first AP reset.

This new OVMF source file, ResetVectorVtf0.asm, is used in place of the
original file through the use of the include path order set in
OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]".

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 100 +++
 OvmfPkg/ResetVector/ResetVector.nasmb|   1 +
 2 files changed, 101 insertions(+)
 create mode 100644 OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm

diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm 
b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
new file mode 100644
index ..980e0138e7fe
--- /dev/null
+++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
@@ -0,0 +1,100 @@
+;--
+; @file
+; First code executed by processor after resetting.
+; Derived from UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
+;
+; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;--
+
+BITS16
+
+ALIGN   16
+
+;
+; Pad the image size to 4k when page tables are in VTF0
+;
+; If the VTF0 image has page tables built in, then we need to make
+; sure the end of VTF0 is 4k above where the page tables end.
+;
+; This is required so the page tables will be 4k aligned when VTF0 is
+; located just below 0x1 (4GB) in the firmware device.
+;
+%ifdef ALIGN_TOP_TO_4K_FOR_PAGING
+TIMES (0x1000 - ($ - EndOfPageTables) - 0x20) DB 0
+%endif
+
+;
+; SEV-ES Processor Reset support
+;
+; sevEsResetBlock:
+;   For the initial boot of an AP under SEV-ES, the "reset" RIP must be
+;   programmed to the RAM area defined by SEV_ES_AP_RESET_IP. A known offset
+;   and GUID will be used to locate this block in the firmware and extract
+;   the build time RIP value. The GUID must always be 48 bytes from the
+;   end of the firmware.
+;
+;   0xffca (-0x36) - IP value
+;   0xffcc (-0x34) - CS segment base [31:16]
+;   0xffce (-0x32) - Size of the SEV-ES reset block
+;   0xffd0 (-0x30) - SEV-ES reset block GUID
+;(00f771de-1a7e-4fcb-890e-68c77e2fb44e)
+;
+;   A hypervisor reads the CS segement base and IP value. The CS segment base
+;   value represents the high order 16-bits of the CS segment base, so the
+;   hypervisor must left shift the value of the CS segement base by 16 bits to
+;   form the full CS segment base for the CS segment register. It would then
+;   program the EIP register with the IP value as read.
+;
+
+TIMES (32 - (sevEsResetBlockEnd - sevEsResetBlockStart)) DB 0
+
+sevEsResetBlockStart:
+DD  SEV_ES_AP_RESET_IP
+DW  sevEsResetBlockEnd - sevEsResetBlockStart
+DB  0xDE, 0x71, 0xF7, 0x00, 0x7E, 0x1A, 0xCB, 0x4F
+DB  0x89, 0x0E, 0x68, 0xC7, 0x7E, 0x2F, 0xB4, 0x4E
+sevEsResetBlockEnd:
+
+ALIGN   16
+
+applicationProcessorEntryPoint:
+;
+; Application Processors entry point
+;
+; GenFv generates code aligned on a 4k boundary which will jump to this
+; location.  (0xffe0)  This allows the Local APIC Startup IPI to be
+; used to wake up the application processors.
+;
+jmp EarlyApInitReal16
+
+ALIGN   8
+
+DD  0
+
+;
+; The VTF signature
+;
+; VTF-0 means that the VTF (Volume Top File) code does not require
+; any fixups.
+;
+vtfSignature:
+DB  'V', 'T', 'F', 0
+
+ALIGN   16
+
+resetVector:
+;
+; Reset Vector
+;
+; This is where the processor will begin execution
+;
+nop
+nop
+jmp EarlyBspInitReal16
+
+ALIGN   16
+
+fourGigabytes:
+
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 97e36ef591ab..12265e7746c1 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -82,5 +82,6 @@
 
 %include "Main.asm"
 
+  %define SEV_ES_AP_RESET_IP  FixedPcdGet32 (PcdSevEsWorkAreaBase)
 %include "Ia16/ResetVectorVtf0.asm"
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53784): https://edk2.groups.io/g/devel/message/53784
Mute This Topic: https://groups.io/mt/70985007/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 24/40] OvmfPkg: Add support to perform SEV-ES initialization

[Lendacky, Thomas]

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

When SEV-ES is enabled, then SEV is also enabled. Add support to the SEV
initialization function to also check for SEV-ES being enabled, and if
enabled, set the SEV-ES enabled PCD (PcdSevEsIsEnabled).

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgIa32.dsc |  3 +++
 OvmfPkg/OvmfPkgIa32X64.dsc  |  3 +++
 OvmfPkg/OvmfPkgX64.dsc  |  3 +++
 OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
 OvmfPkg/PlatformPei/AmdSev.c| 26 ++
 5 files changed, 36 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 41ec761e3f17..6642f2b008dc 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -568,6 +568,9 @@ [PcdsDynamicDefault]
   # Set memory encryption mask
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
+  # Set SEV-ES defaults
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
+
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 41cc3eec3757..66589b2228c4 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -580,6 +580,9 @@ [PcdsDynamicDefault]
   # Set memory encryption mask
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
+  # Set SEV-ES defaults
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
+
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 46a679a0073e..2e5c30d5c631 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -579,6 +579,9 @@ [PcdsDynamicDefault]
   # Set memory encryption mask
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
+  # Set SEV-ES defaults
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
+
 !if $(SMM_REQUIRE) == TRUE
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 30eaebdfae63..8af236a5c23e 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -100,6 +100,7 @@ [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
   gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled
 
 [FixedPcd]
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index 2ae8126ccf8a..c12aea46d94e 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -19,6 +19,27 @@
 
 #include "Platform.h"
 
+/**
+
+  Initialize SEV-ES support if running as an SEV-ES guest.
+
+  **/
+STATIC
+VOID
+AmdSevEsInitialize (
+  VOID
+  )
+{
+  RETURN_STATUS PcdStatus;
+
+  if (!MemEncryptSevEsIsEnabled ()) {
+return;
+  }
+
+  PcdStatus = PcdSetBoolS (PcdSevEsIsEnabled, TRUE);
+  ASSERT_RETURN_ERROR (PcdStatus);
+}
+
 /**
 
   Function checks if SEV support is available, if present then it sets
@@ -89,4 +110,9 @@ AmdSevInitialize (
   EfiBootServicesData// MemoryType
   );
   }
+
+  //
+  // Check and perform SEV-ES initialization if required.
+  //
+  AmdSevEsInitialize ();
 }
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53771): https://edk2.groups.io/g/devel/message/53771
Mute This Topic: https://groups.io/mt/70984947/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 26/40] OvmfPkg/PlatformPei: Reserve GHCB-related areas if S3 is supported

[Lendacky, Thomas]

Protect the memory used by an SEV-ES guest when S3 is supported. This
includes the page table used to break down the 2MB page that contains
the GHCB so that it can be marked un-encrypted, as well as the GHCB
area.

Regarding the lifecycle of the GHCB-related memory areas:
  PcdOvmfSecGhcbPageTableBase
  PcdOvmfSecGhcbBase

(a) when and how it is initialized after first boot of the VM

  If SEV-ES is enabled, the GHCB-related areas are initialized during
  the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm].

(b) how it is protected from memory allocations during DXE

  If S3 and SEV-ES are enabled, then InitializeRamRegions()
  [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS
  memory allocation HOB, in PEI.

  If S3 is disabled, then these ranges are not protected. DXE's own page
  tables are first built while still in PEI (see HandOffToDxeCore()
  [MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c]). Those tables are
  located in permanent PEI memory. After CR3 is switched over to them
  (which occurs before jumping to the DXE core entry point), we don't have
  to preserve PcdOvmfSecGhcbPageTableBase. PEI switches to GHCB pages in
  permanent PEI memory and DXE will use these PEI GHCB pages, so we don't
  have to preserve PcdOvmfSecGhcbBase.

(c) how it is protected from the OS

  If S3 is enabled, then (b) reserves it from the OS too.

  If S3 is disabled, then the range needs no protection.

(d) how it is accessed on the S3 resume path

  It is rewritten same as in (a), which is fine because (b) reserved it.

(e) how it is accessed on the warm reset path

  It is rewritten same as in (a).

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/PlatformPei/PlatformPei.inf |  4 
 OvmfPkg/PlatformPei/MemDetect.c | 23 +++
 2 files changed, 27 insertions(+)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 8af236a5c23e..3f24cce678c0 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -72,6 +72,8 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
@@ -100,6 +102,8 @@ [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
   gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize
+  gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbBase
+  gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbSize
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled
 
 [FixedPcd]
diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index d451989f31c9..677e65e86d7b 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -26,6 +26,7 @@ Module Name:
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -805,6 +806,28 @@ InitializeRamRegions (
   (UINT64)(UINTN) PcdGet32 (PcdOvmfSecPageTablesSize),
   EfiACPIMemoryNVS
   );
+
+if (MemEncryptSevEsIsEnabled ()) {
+  //
+  // If SEV-ES is enabled, reserve the GHCB-related memory area. This
+  // includes the extra page table used to break down the 2MB page
+  // mapping into 4KB page entries where the GHCB resides and the
+  // GHCB area itself.
+  //
+  // Since this memory range will be used by the Reset Vector on S3
+  // resume, it must be reserved as ACPI NVS.
+  //
+  BuildMemoryAllocationHob (
+(EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfSecGhcbPageTableBase),
+(UINT64)(UINTN) PcdGet32 (PcdOvmfSecGhcbPageTableSize),
+EfiACPIMemoryNVS
+);
+  BuildMemoryAllocationHob (
+(EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdSecGhcbBase),
+(UINT64)(UINTN) PcdGet32 (PcdSecGhcbSize),
+EfiACPIMemoryNVS
+);
+}
 #endif
   }
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53775): https://edk2.groups.io/g/devel/message/53775
Mute This Topic: https://groups.io/mt/70984951/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 31/40] OvmfPkg/ResetVector: Add support for a 32-bit SEV check

[Lendacky, Thomas]

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

During BSP startup, the reset vector code will issue a CPUID instruction
while in 32-bit mode. When running as an SEV-ES guest, this will trigger
a #VC exception.

Add exception handling support to the early reset vector code to catch
these exceptions.  Also, since the guest is in 32-bit mode at this point,
writes to the GHCB will be encrypted and thus not able to be read by the
hypervisor, so use the GHCB CPUID request/response protocol to obtain the
requested CPUID function values and provide these to the guest.

The exception handling support is active during the SEV check and uses the
OVMF temporary RAM space for a stack. After the SEV check is complete, the
exception handling support is removed and the stack pointer cleared.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/ResetVector/ResetVector.inf   |   3 +
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 275 +-
 OvmfPkg/ResetVector/ResetVector.nasmb |   2 +
 3 files changed, 277 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index 9aedbe9b3640..f9e9578d22b2 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -36,7 +36,10 @@ [BuildOptions]
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbBase
   gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbSize
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 9f86ddf6f08f..7c72128a84d6 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -36,13 +36,58 @@ BITS32
PAGE_READ_WRITE + \
PAGE_PRESENT)
 
+;
+; SEV-ES #VC exception handler support
+;
+; #VC handler local variable locations
+;
+%define VC_CPUID_RESULT_EAX 0
+%define VC_CPUID_RESULT_EBX 4
+%define VC_CPUID_RESULT_ECX 8
+%define VC_CPUID_RESULT_EDX12
+%define VC_GHCB_MSR_EDX16
+%define VC_GHCB_MSR_EAX20
+%define VC_CPUID_REQUEST_REGISTER  24
+%define VC_CPUID_FUNCTION  28
+
+; #VC handler total local variable size
+;
+%define VC_VARIABLE_SIZE   32
+
+; #VC handler GHCB CPUID request/response protocol values
+;
+%define GHCB_CPUID_REQUEST  4
+%define GHCB_CPUID_RESPONSE 5
+%define GHCB_CPUID_REGISTER_SHIFT  30
+%define CPUID_INSN_LEN  2
+
+
 ; Check if Secure Encrypted Virtualization (SEV) feature is enabled
 ;
-; If SEV is enabled then EAX will be at least 32
+; Modified:  EAX, EBX, ECX, EDX, ESP
+;
+; If SEV is enabled then EAX will be at least 32.
 ; If SEV is disabled then EAX will be zero.
 ;
 CheckSevFeature:
+; Set the first byte of the workarea to zero to communicate to the SEC
+; phase that SEV-ES is not enabled. If SEV-ES is enabled, the CPUID
+; instruction will trigger a #VC exception where the first byte of the
+; workarea will be set to one.
+mov byte[SEV_ES_WORK_AREA], 0
+
+;
+; Set up exception handlers to check for SEV-ES
+;   Load temporary RAM stack based on PCDs (see SevEsIdtVmmComm for
+;   stack usage)
+;   Establish exception handlers
+;
+mov   esp, SEV_ES_VC_TOP_OF_STACK
+mov   eax, ADDR_OF(Idtr)
+lidt  [cs:eax]
+
 ; Check if we have a valid (0x8000_001F) CPUID leaf
+;   CPUID raises a #VC exception if running as an SEV-ES guest
 mov   eax, 0x8000
 cpuid
 
@@ -53,8 +98,8 @@ CheckSevFeature:
 jlNoSev
 
 ; Check for memory encryption feature:
-;  CPUID  Fn8000_001F[EAX] - Bit 1
-;
+; CPUID  Fn8000_001F[EAX] - Bit 1
+;   CPUID raises a #VC exception if running as an SEV-ES guest
 mov   eax,  0x801f
 cpuid
 bteax, 1
@@ -78,6 +123,15 @@ NoSev:
 xor   eax, eax
 
 SevExit:
+;
+; Clear exception handlers and stack
+;
+push  eax
+mov   eax, ADDR_OF(IdtrClear)
+lidt  [cs:eax]
+pop   eax
+mov   esp, 0
+
 OneTimeCallRet CheckSevFeature
 
 ; Check if Secure Encrypted Virtualization - Encrypted State (SEV-ES) feature
@@ -222,3 +276,218 @@ SetCr3:
 mov cr3, eax
 
 OneTimeCallRet SetCr3ForPageTables64
+
+;
+; Start of #VC exception handling routines
+;
+
+SevEsIdtNotCpuid:
+;
+; Use VMGEXIT to request termination.
+;   1 - #VC was not for CPUID
+;
+mov eax, 1
+jmp SevEsIdtTerminate
+

[edk2-devel] [PATCH v4 28/40] OvmfPkg/PlatformPei: Move early GDT into ram when SEV-ES is enabled

[Lendacky, Thomas]

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

The SEV support will clear the C-bit from non-RAM areas.  The early GDT
lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT
will be read as un-encrypted even though it is encrypted. This will result
in a failure to be able to handle the exception.

Move the GDT into RAM so it can be accessed without error when running as
an SEV-ES guest.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/PlatformPei/AmdSev.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index 900b0d977d61..b3fd2d86541a 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -37,6 +37,8 @@ AmdSevEsInitialize (
   PHYSICAL_ADDRESS  GhcbBasePa;
   UINTN GhcbPageCount;
   RETURN_STATUS PcdStatus, DecryptStatus;
+  IA32_DESCRIPTOR   Gdtr;
+  VOID  *Gdt;
 
   if (!MemEncryptSevEsIsEnabled ()) {
 return;
@@ -74,6 +76,22 @@ AmdSevEsInitialize (
 (UINT64)GhcbPageCount, GhcbBase));
 
   AsmWriteMsr64 (MSR_SEV_ES_GHCB, GhcbBasePa);
+
+  //
+  // The SEV support will clear the C-bit from non-RAM areas.  The early GDT
+  // lives in a non-RAM area, so when an exception occurs (like a #VC) the GDT
+  // will be read as un-encrypted even though it was created before the C-bit
+  // was cleared (encrypted). This will result in a failure to be able to
+  // handle the exception.
+  //
+  AsmReadGdtr ();
+
+  Gdt = AllocatePages (EFI_SIZE_TO_PAGES ((UINTN) Gdtr.Limit + 1));
+  ASSERT (Gdt != NULL);
+
+  CopyMem (Gdt, (VOID *) Gdtr.Base, Gdtr.Limit + 1);
+  Gdtr.Base = (UINTN) Gdt;
+  AsmWriteGdtr ();
 }
 
 /**
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53774): https://edk2.groups.io/g/devel/message/53774
Mute This Topic: https://groups.io/mt/70984950/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 25/40] OvmfPkg: Create a GHCB page for use during Sec phase

[Lendacky, Thomas]

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

A GHCB page is needed during the Sec phase, so this new page must be
created. Since the #VC exception handler routines assume that a per-CPU
variable area is immediately after the GHCB, this per-CPU variable area
must also be created. Since the GHCB must be marked as an un-encrypted,
or shared, page, an additional pagetable page is required to break down
the 2MB region where the GHCB page lives into 4K pagetable entries.

Create a new entry in the OVMF memory layout for the new page table
page and for the SEC GHCB and per-CPU variable pages. After breaking down
the 2MB page, update the GHCB page table entry to remove the encryption
mask.

The GHCB page will be used by the SEC #VC exception handler. The #VC
exception handler will fill in the necessary fields of the GHCB and exit
to the hypervisor using the VMGEXIT instruction. The hypervisor then
accesses the GHCB in order to perform the requested function.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkg.dec   |  5 ++
 OvmfPkg/OvmfPkgX64.fdf|  6 ++
 OvmfPkg/ResetVector/ResetVector.inf   |  5 ++
 OvmfPkg/ResetVector/Ia32/PageTables64.asm | 76 +++
 OvmfPkg/ResetVector/ResetVector.nasmb | 17 +
 5 files changed, 109 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index d5fee805ef4a..19723786d729 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -228,6 +228,11 @@ [PcdsFixedAtBuild]
   ## Number of page frames to use for storing grant table entries.
   gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
 
+  ## Specify the extra page table needed to mark the GHCB as unencrypted.
+  #  The value should be a multiple of 4KB for each.
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|0x0|UINT32|0x34
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize|0x0|UINT32|0x35
+
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 0488e5d95ffe..f541481dc95c 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -76,6 +76,12 @@ [FD.MEMFD]
 0x007000|0x001000
 
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
 
+0x008000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
+
+0x009000|0x002000
+gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbBase|gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbSize
+
 0x01|0x01
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index b0ddfa5832a2..9aedbe9b3640 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -26,6 +26,7 @@ [Sources]
 [Packages]
   OvmfPkg/OvmfPkg.dec
   MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
 
 [BuildOptions]
@@ -33,5 +34,9 @@ [BuildOptions]
*_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
 
 [Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbBase
+  gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index abad009f20f5..9f86ddf6f08f 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -21,6 +21,11 @@ BITS32
 %define PAGE_2M_MBO0x080
 %define PAGE_2M_PAT  0x01000
 
+%define PAGE_4K_PDE_ATTR (PAGE_ACCESSED + \
+  PAGE_DIRTY + \
+  PAGE_READ_WRITE + \
+  PAGE_PRESENT)
+
 %define PAGE_2M_PDE_ATTR (PAGE_2M_MBO + \
   PAGE_ACCESSED + \
   PAGE_DIRTY + \
@@ -75,6 +80,37 @@ NoSev:
 SevExit:
 OneTimeCallRet CheckSevFeature
 
+; Check if Secure Encrypted Virtualization - Encrypted State (SEV-ES) feature
+; is enabled.
+;
+; Modified:  EAX, EBX, ECX
+;
+; If SEV-ES is enabled then EAX will be non-zero.
+; If SEV-ES is disabled then EAX will be zero.
+;
+CheckSevEsFeature:
+xor   eax, eax
+
+; SEV-ES can't be enabled if SEV isn't, so first check the encryption
+; mask.
+test  edx, edx
+jzNoSevEs
+
+; Save current value of encryption mask
+mov   ebx, edx
+
+; Check if SEV-ES is enabled
+;  MSR_0xC0010131 - Bit 1 (SEV-ES enabled)
+mov   ecx, 0xc0010131
+ 

[edk2-devel] [PATCH v4 27/40] OvmfPkg: Create GHCB pages for use during Pei and Dxe phase

[Lendacky, Thomas]

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

Allocate memory for the GHCB pages and the per-CPU variable pages during
SEV initialization for use during Pei and Dxe phases. The GHCB page(s)
must be shared pages, so clear the encryption mask from the current page
table entries. Upon successful allocation, set the GHCB PCDs (PcdGhcbBase
and PcdGhcbSize).

The per-CPU variable page needs to be unique per AP. Using the page after
the GHCB ensures that it is unique per AP. But, it also ends up being
marked shared/unencrypted when it doesn't need to be. It is possible
during PEI to mark only the GHCB pages as shared (and that is done), but
DXE is not as easy. There needs to be a way to change the pagetables
created for DXE using CreateIdentityMappingPageTables() before switching
to them.

The GHCB pages (one per vCPU) will be used by the PEI and DXE #VC
exception handlers. The #VC exception handler will fill in the necessary
fields of the GHCB and exit to the hypervisor using the VMGEXIT
instruction. The hypervisor then accesses the GHCB associated with the
vCPU in order to perform the requested function.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgIa32.dsc |  2 ++
 OvmfPkg/OvmfPkgIa32X64.dsc  |  2 ++
 OvmfPkg/OvmfPkgX64.dsc  |  2 ++
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 ++
 OvmfPkg/PlatformPei/AmdSev.c| 38 -
 5 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6642f2b008dc..c364da521579 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -569,6 +569,8 @@ [PcdsDynamicDefault]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
   # Set SEV-ES defaults
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
 
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 66589b2228c4..0adae1e0be30 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -581,6 +581,8 @@ [PcdsDynamicDefault]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
   # Set SEV-ES defaults
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
 
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2e5c30d5c631..4b5e96a32b0b 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -580,6 +580,8 @@ [PcdsDynamicDefault]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
 
   # Set SEV-ES defaults
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0
   gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|0
 
 !if $(SMM_REQUIRE) == TRUE
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 3f24cce678c0..397d4d33c5b9 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -97,6 +97,8 @@ [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
   gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber
diff --git a/OvmfPkg/PlatformPei/AmdSev.c b/OvmfPkg/PlatformPei/AmdSev.c
index c12aea46d94e..900b0d977d61 100644
--- a/OvmfPkg/PlatformPei/AmdSev.c
+++ b/OvmfPkg/PlatformPei/AmdSev.c
@@ -9,12 +9,15 @@
 //
 // The package level header files this module uses
 //
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "Platform.h"
@@ -30,7 +33,10 @@ AmdSevEsInitialize (
   VOID
   )
 {
-  RETURN_STATUS PcdStatus;
+  VOID  *GhcbBase;
+  PHYSICAL_ADDRESS  GhcbBasePa;
+  UINTN GhcbPageCount;
+  RETURN_STATUS PcdStatus, DecryptStatus;
 
   if (!MemEncryptSevEsIsEnabled ()) {
 return;
@@ -38,6 +44,36 @@ AmdSevEsInitialize (
 
   PcdStatus = PcdSetBoolS (PcdSevEsIsEnabled, TRUE);
   ASSERT_RETURN_ERROR (PcdStatus);
+
+  //
+  // Allocate GHCB and per-CPU variable pages.
+  //
+  GhcbPageCount = mMaxCpuCount * 2;
+  GhcbBase = AllocatePages (GhcbPageCount);
+  ASSERT (GhcbBase != NULL);
+
+  GhcbBasePa = (PHYSICAL_ADDRESS)(UINTN) GhcbBase;
+
+  DecryptStatus = MemEncryptSevClearPageEncMask (
+0,
+GhcbBasePa,
+GhcbPageCount,
+TRUE
+);
+  ASSERT_RETURN_ERROR (DecryptStatus);
+
+  ZeroMem (GhcbBase, EFI_PAGES_TO_SIZE (GhcbPageCount));
+
+  PcdStatus = PcdSet64S (PcdGhcbBase, 

[edk2-devel] [PATCH v4 05/40] MdePkg/BaseLib: Add support for the XGETBV instruction

[Lendacky, Thomas]

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

Under SEV-ES, a CPUID instruction requires the current value of the XCR0
register. In order to retrieve that value, the XGETBV instruction needs
to be executed.

Provide the necessary support to execute the XGETBV instruction.

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Library/BaseLib/BaseLib.inf  |  2 ++
 MdePkg/Include/Library/BaseLib.h| 17 +
 MdePkg/Library/BaseLib/Ia32/GccInline.c | 28 
 MdePkg/Library/BaseLib/X64/GccInline.c  | 30 ++
 MdePkg/Library/BaseLib/Ia32/XGetBv.nasm | 31 ++
 MdePkg/Library/BaseLib/X64/XGetBv.nasm  | 34 +
 6 files changed, 142 insertions(+)
 create mode 100644 MdePkg/Library/BaseLib/Ia32/XGetBv.nasm
 create mode 100644 MdePkg/Library/BaseLib/X64/XGetBv.nasm

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index 3586beb0ab5c..d7a1dd017e95 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -152,6 +152,7 @@ [Sources.Ia32]
   Ia32/ARShiftU64.c | MSFT
   Ia32/EnableCache.c | MSFT
   Ia32/DisableCache.c | MSFT
+  Ia32/XGetBv.nasm | MSFT
 
 
   Ia32/GccInline.c | GCC
@@ -286,6 +287,7 @@ [Sources.X64]
   X64/ReadCr2.nasm| MSFT
   X64/ReadCr0.nasm| MSFT
   X64/ReadEflags.nasm| MSFT
+  X64/XGetBv.nasm | MSFT
 
 
   X64/Non-existing.c
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index ecadff8b235e..d0cbb52ed8f9 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -7889,6 +7889,23 @@ AsmLfence (
   VOID
   );
 
+/**
+  Executes a XGETBV instruction
+
+  Executes a XGETBV instruction. This function is only available on IA-32 and
+  x64.
+
+  @param[in] IndexExtended control register index
+
+  @retval The current value of the extended control register
+**/
+UINT64
+EFIAPI
+AsmXGetBv (
+  IN UINT32  Index
+  );
+
+
 /**
   Patch the immediate operand of an IA32 or X64 instruction such that the byte,
   word, dword or qword operand is encoded at the end of the instruction's
diff --git a/MdePkg/Library/BaseLib/Ia32/GccInline.c 
b/MdePkg/Library/BaseLib/Ia32/GccInline.c
index 5287200f8754..591f0bb0e097 100644
--- a/MdePkg/Library/BaseLib/Ia32/GccInline.c
+++ b/MdePkg/Library/BaseLib/Ia32/GccInline.c
@@ -1763,3 +1763,31 @@ AsmFlushCacheLine (
 }
 
 
+/**
+  Executes a XGETBV instruction
+
+  Executes a XGETBV instruction. This function is only available on IA-32 and
+  x64.
+
+  @param[in] IndexExtended control register index
+
+  @retval The current value of the extended control register
+**/
+UINT64
+EFIAPI
+AsmXGetBv (
+  IN UINT32 Index
+  )
+{
+  UINT64 Data;
+
+  __asm__ __volatile__ (
+"xgetbv"
+: "=A" (Data)
+: "c"  (Index)
+);
+
+  return Data;
+}
+
+
diff --git a/MdePkg/Library/BaseLib/X64/GccInline.c 
b/MdePkg/Library/BaseLib/X64/GccInline.c
index 154ce1f57e92..3eed1205adb2 100644
--- a/MdePkg/Library/BaseLib/X64/GccInline.c
+++ b/MdePkg/Library/BaseLib/X64/GccInline.c
@@ -1798,3 +1798,33 @@ AsmFlushCacheLine (
 }
 
 
+/**
+  Executes a XGETBV instruction
+
+  Executes a XGETBV instruction. This function is only available on IA-32 and
+  x64.
+
+  @param[in] IndexExtended control register index
+
+  @retval The current value of the extended control register
+**/
+UINT64
+EFIAPI
+AsmXGetBv (
+  IN UINT32 Index
+  )
+{
+  UINT32 LowData;
+  UINT32 HighData;
+
+  __asm__ __volatile__ (
+"xgetbv"
+: "=a" (LowData),
+  "=d" (HighData)
+: "c"  (Index)
+);
+
+  return (((UINT64)HighData) << 32) | LowData;
+}
+
+
diff --git a/MdePkg/Library/BaseLib/Ia32/XGetBv.nasm 
b/MdePkg/Library/BaseLib/Ia32/XGetBv.nasm
new file mode 100644
index ..23ad38df0710
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Ia32/XGetBv.nasm
@@ -0,0 +1,31 @@
+;--
+;
+; Copyright (c) 2019, Advanced Micro Devices, Inc. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+;   XGetBv.Asm
+;
+; Abstract:
+;
+;   AsmXgetBv function
+;
+; Notes:
+;
+;--
+
+SECTION .text
+
+;--
+; UINT64
+; EFIAPI
+; AsmXGetBv (
+;   IN UINT32  Index
+;   );
+;--
+global ASM_PFX(AsmXGetBv)
+ASM_PFX(AsmXGetBv):
+mov ecx, [esp + 4]
+xgetbv
+ret
diff --git a/MdePkg/Library/BaseLib/X64/XGetBv.nasm 
b/MdePkg/Library/BaseLib/X64/XGetBv.nasm
new file mode 100644
index ..cd73e972d31b
--- /dev/null
+++ b/MdePkg/Library/BaseLib/X64/XGetBv.nasm
@@ -0,0 +1,34 @@

Re: [edk2-devel] [PATCH v2 0/2] ShellPkg: Document the use of EFI_INVALID_PARAMETER by two functions

[Philippe Mathieu-Daudé]

On 1/31/20 6:31 AM, Gao, Zhichao wrote:

Hi,

I have tried with the commit. It pass the check.


Good news, thanks for checking :)

Is there anything else I should do to get this series applied?

Thanks,

Phil.


-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
Philippe Mathieu-Daudé
Sent: Tuesday, January 21, 2020 7:24 PM
To: Gao, Zhichao ; devel@edk2.groups.io
Cc: Ni, Ray 
Subject: Re: [edk2-devel] [PATCH v2 0/2] ShellPkg: Document the use of
EFI_INVALID_PARAMETER by two functions

Hi Zhichao,

On 1/7/20 8:37 AM, Gao, Zhichao wrote:

-Original Message-
From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
Sent: Tuesday, January 7, 2020 3:10 PM
To: Gao, Zhichao ; devel@edk2.groups.io
Cc: Ni, Ray 
Subject: Re: [PATCH v2 0/2] ShellPkg: Document the use of
EFI_INVALID_PARAMETER by two functions

On 1/7/20 8:01 AM, Gao, Zhichao wrote:

-Original Message-
From: Philippe Mathieu-Daude 
Sent: Thursday, December 19, 2019 10:10 PM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Gao, Zhichao
; Philippe Mathieu-Daude 
Subject: [PATCH v2 0/2] ShellPkg: Document the use of
EFI_INVALID_PARAMETER by two functions

Complete the list of values the functios ParseCommandLineToArgs()
and
UpdateArgcArgv() can return.

The documentation was found to be incomplete while reviewing BZ#2395:
https://edk2.groups.io/g/devel/message/51512

v2:
- Shortened patch #1 subject to fit 72 chars


The subject should be less than 72 chars (do not include 72 chars).


What is the rationale for this restriction? Some tool limitation?


Yes. There is a patch check tool in BaseTools\Scripts\ PatchCheck.py. And the

patch #1 can't pass the check.

Since the patch "BaseTools/PatchCheck.py: Ignore CR and LF characters in
subject length" got merged as commit 2649a735b24, can you retry to merge this
patch?

Thanks,

Phil.








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53787): https://edk2.groups.io/g/devel/message/53787
Mute This Topic: https://groups.io/mt/68831521/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Sukerkar, Amol N]

Thanks for the feedback, Jiewen!

In that case, I agree we should deprecate MD4, MD5 and SHA1 in BaseHashApiLib.

If the above statement is accurate, I can start next set of patches to remove 
the deprecated algorithms by creating a Bugzilla ticket. Please confirm.

Thanks,
Amol

-Original Message-
From: Yao, Jiewen  
Sent: Tuesday, February 04, 2020 4:06 PM
To: Sukerkar, Amol N ; Kinney, Michael D 
; devel@edk2.groups.io
Cc: Wang, Jian J 
Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash 
Calculation API

Amol
We are in the process to deprecating SHA1.
Currently SHA256 is default one.
Some products are moving from SHA256 to SHA384.

We did crypto usage analysis before.
In the current EDKII code base, there is no code using MD4.
The only code that using MD5 is the iSCSI.

TPM1.2 has to use SHA1 - that is updated by the TPM2.
Some old certificate was using SHA1. It will be deprecated and move to SHA256.

Even UEFI spec defines MD5, but it does not mean a product has to use MD5. UEFI 
spec does not mandate that you must support MD5.
Do you see any MD5 usage in BIOS except iSCSI?

If no, I prefer to drop MD4/MD5 in this patch.

Thank you
Yao Jiewen


> -Original Message-
> From: Sukerkar, Amol N 
> Sent: Wednesday, February 5, 2020 1:10 AM
> To: Kinney, Michael D ; Yao, Jiewen 
> ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Sukerkar, Amol N 
> 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement 
> Unified Hash Calculation API
> 
> Hi Jiewen and Mike,
> 
> I agree with general statement that MD4 and MD5 are deprecated. 
> However, Although not MD4, UEFI spec 2.8 still mentions MD5 (and does 
> not mention that it is deprecated). That is the reason MD4 and MD5 were 
> included.
> 
> If there is going to be an update to UEFI spec deprecating MD5 as 
> well, we can definitely go ahead and remove MD5 (and MD4). I believe 
> the decision is should we wait until the change to UEFI spec or make 
> the change right now. Let me know which approach we should be following.
> 
> Thanks,
> Amol
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Tuesday, February 04, 2020 9:26 AM
> To: Yao, Jiewen ; devel@edk2.groups.io; Kinney, 
> Michael D ; Sukerkar, Amol N 
> 
> Cc: Wang, Jian J 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement 
> Unified Hash Calculation API
> 
> Jiewen,
> 
> I think UINT8 is fine.  We can change default to 0x04 in DEC file.
> 
> I will let Amol comment on why MD4 and MD5 are included.  If they are 
> not required, then I agree they should be removed.
> 
> I do not see a reason to align with TCG spec.  The HashApiLib is a 
> layer on top of BaseCryptLib and the use of hash algorithms is not 
> limited to TCG related content.  The BaseCryptLib could potentially 
> adopt hash algorithms that are not defined in the TCG specification.
> We also do not want CryptoPkg to depend on the SecurityPkg.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Monday, February 3, 2020 6:54 PM
> > To: Kinney, Michael D ; 
> > devel@edk2.groups.io
> > Cc: Sukerkar, Amol N ; Wang, Jian J 
> > 
> > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > Implement Unified Hash Calculation API
> >
> > Thanks Mike, to cover us during Chinese New Year holiday.
> >
> > I am just back from vocation. A minor comment:
> >
> > The PcdHashApiLibPolicy is UINT8, but the value is shown as 32bit 
> > 0x0004.
> >
> > There are couple of ways to enhance:
> > 1) Define UINT8, and use 8bit style 0x04.
> > 2) Define UINT32, and use 32bit style 0x0004.
> > 3) Define UINT16 (match TCG definition), and use TCG defined value.
> > (Tpm20.h)
> > #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> > #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> > #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> > #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> > #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> >
> > MD4 and MD5 are known as insecure and deprecated. I doubt if we want 
> > to add such support. (I strong recommend NO).
> >
> > If we can remove MD4 and MD5, I think we can use #3.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Tuesday, February 4, 2020 7:36 AM
> > > To: devel@edk2.groups.io
> > > Cc: Sukerkar, Amol N ;
> > Yao, Jiewen
> > > ; Wang, Jian J
> > 
> > > Subject: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > Implement Unified Hash
> > > Calculation API
> > >
> > > From: Amol N Sukerkar 
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2151
> > >
> > > This commit introduces a Unified Hash API to
> > calculate hash using a
> > > hashing algorithm specified by the PCD,
> > PcdHashApiLibPolicy. This library
> > > interfaces with the various hashing API, such as,
> > MD4, MD5, SHA1, SHA256,
> > > SHA512 and SM3_256 implemented in BaseCryptLib. The
> > user can calculate
> > > the desired hash by setting 

Re: [edk2-devel] [Patch] BaseTools/DscBuildData: Fix PCD autogen include file conflict

[Michael D Kinney]

Liming,

I have entered the following BZ:

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

Mike

> -Original Message-
> From: Gao, Liming 
> Sent: Monday, February 3, 2020 10:45 PM
> To: Kinney, Michael D ;
> devel@edk2.groups.io
> Cc: Feng, Bob C ; Gao, Liming
> 
> Subject: RE: [Patch] BaseTools/DscBuildData: Fix PCD
> autogen include file conflict
> 
> Mike:
>   If we document this assumption in build
> specification, I agree this patch. Can you enter one BZ
> for build spec update?
> 
>   For this patch, Reviewed-by: Liming Gao
> 
> 
> Thanks
> Liming
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Tuesday, February 4, 2020 1:52 AM
> > To: Gao, Liming ;
> devel@edk2.groups.io; Kinney, Michael D
> 
> > Cc: Feng, Bob C 
> > Subject: RE: [Patch] BaseTools/DscBuildData: Fix PCD
> autogen include file conflict
> >
> > Liming,
> >
> > Yes.  I think that is a reasonable assumption.
> >
> > We can document that restriction in the EDK II Build
> Specification
> > that standard POSIX include files (e.g. )
> must never be
> > placed in the same directory with other include files
> that are
> > required for Structured PCD data types or
> defines/enums that may
> > be used to set Structured PCD field values.  We can
> enter a
> > Tianocore BZ to update the specifications.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Gao, Liming 
> > > Sent: Sunday, February 2, 2020 11:33 PM
> > > To: Kinney, Michael D ;
> > > devel@edk2.groups.io
> > > Cc: Feng, Bob C 
> > > Subject: RE: [Patch] BaseTools/DscBuildData: Fix
> PCD
> > > autogen include file conflict
> > >
> > > Mike:
> > >   Yes. Build tool needs to know host OS behavior
> and
> > > get the full include path. For this patch, it skips
> > > some include paths. If this include path also
> includes
> > > other required header file, it will cause the build
> > > break. Can we have the assumption that all sys
> header
> > > files and other non-sys header files are not in the
> > > same include directory?
> > >
> > > Thanks
> > > Liming
> > > > -Original Message-
> > > > From: Kinney, Michael D
> 
> > > > Sent: Monday, February 3, 2020 2:40 PM
> > > > To: Gao, Liming ;
> > > devel@edk2.groups.io; Kinney, Michael D
> > > 
> > > > Cc: Feng, Bob C 
> > > > Subject: RE: [Patch] BaseTools/DscBuildData: Fix
> PCD
> > > autogen include file conflict
> > > >
> > > > Liming,
> > > >
> > > > The build tools would need to know which env var
> to
> > > query for
> > > > all OS/host tool chain combinations and how to
> parse
> > > that
> > > > information for full paths in an OS specific
> manner.
> > > We should
> > > > not build that type of information into the build
> > > tools.
> > > >
> > > > The fix I have provided does not need this
> > > information.
> > > >
> > > > Mike
> > > >
> > > > > -Original Message-
> > > > > From: Gao, Liming 
> > > > > Sent: Sunday, February 2, 2020 4:59 PM
> > > > > To: Kinney, Michael D
> ;
> > > > > devel@edk2.groups.io
> > > > > Cc: Feng, Bob C 
> > > > > Subject: RE: [Patch] BaseTools/DscBuildData:
> Fix
> > > PCD
> > > > > autogen include file conflict
> > > > >
> > > > > Mike:
> > > > >   Can we consider to parse INCLUDE env value
> and
> > > add
> > > > > those path to -I options as the first priority?
> > > > >
> > > > > Thanks
> > > > > Liming
> > > > > > -Original Message-
> > > > > > From: Kinney, Michael D
> > > 
> > > > > > Sent: Thursday, January 30, 2020 8:46 AM
> > > > > > To: devel@edk2.groups.io
> > > > > > Cc: Feng, Bob C ; Gao,
> > > Liming
> > > > > 
> > > > > > Subject: [Patch] BaseTools/DscBuildData: Fix
> PCD
> > > > > autogen include file conflict
> > > > > >
> > > > > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2494
> > > > > >
> > > > > > When using structured PCDs, a C application
> is
> > > auto
> > > > > generated
> > > > > > to fill in the structured PCD value.  The C
> > > > > application uses
> > > > > > the standard include files ,
> ,
> > > and
> > > > > .
> > > > > > This C application also supports include
> paths
> > > from
> > > > > package DEC
> > > > > > files when a structured PCD declaration
> provides
> > > a
> > > > > 
> > > > > > list.  The complete list of include paths are
> -I
> > > > > options for
> > > > > > include paths from package DEC files and the
> > > > > compiler's standard
> > > > > > include paths.
> > > > > >
> > > > > > -I include paths are higher priority than the
> > > > > standard include
> > > > > > paths.  If the -I included paths from package
> DEC
> > > > > files contain
> > > > > > , , or  the
> wrong
> > > > > include files are
> > > > > > used to compile the C application for the
> > > structured
> > > > > PCD value.
> > > > > >
> > > > > > Update GenerateByteArrayValue() to skip a
> package
> > > DEC
> > > > > include
> > > > > > paths that contain , , or
> > > > > .
> > > > > >
> > > > > > Build failures were observed when adding a
> > > structured
> > > > > PCD to
> > > > > 

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

[Sukerkar, Amol N]

Thanks, Jiewen! I will start the process.

~ Amol

-Original Message-
From: Yao, Jiewen  
Sent: Tuesday, February 04, 2020 4:20 PM
To: Sukerkar, Amol N ; Kinney, Michael D 
; devel@edk2.groups.io
Cc: Wang, Jian J 
Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash 
Calculation API

Thank Amol.
You may want to keep SHA1. I still feel that SHA1 is used in some special case.
It is safety to just drop MD4 and MD5 at this moment.

We may consider to drop SHA1 later, when we do not see any usage.

With this patch, I believe it will be easy for us to move from SHA256 to SHA384 
later.
Good work!

Thank you
Yao Jiewen

> -Original Message-
> From: Sukerkar, Amol N 
> Sent: Wednesday, February 5, 2020 7:15 AM
> To: Yao, Jiewen ; Kinney, Michael D 
> ; devel@edk2.groups.io
> Cc: Wang, Jian J ; Sukerkar, Amol N 
> 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement 
> Unified Hash Calculation API
> 
> Thanks for the feedback, Jiewen!
> 
> In that case, I agree we should deprecate MD4, MD5 and SHA1 in 
> BaseHashApiLib.
> 
> If the above statement is accurate, I can start next set of patches to 
> remove the deprecated algorithms by creating a Bugzilla ticket. Please 
> confirm.
> 
> Thanks,
> Amol
> 
> -Original Message-
> From: Yao, Jiewen 
> Sent: Tuesday, February 04, 2020 4:06 PM
> To: Sukerkar, Amol N ; Kinney, Michael D 
> ; devel@edk2.groups.io
> Cc: Wang, Jian J 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement 
> Unified Hash Calculation API
> 
> Amol
> We are in the process to deprecating SHA1.
> Currently SHA256 is default one.
> Some products are moving from SHA256 to SHA384.
> 
> We did crypto usage analysis before.
> In the current EDKII code base, there is no code using MD4.
> The only code that using MD5 is the iSCSI.
> 
> TPM1.2 has to use SHA1 - that is updated by the TPM2.
> Some old certificate was using SHA1. It will be deprecated and move to SHA256.
> 
> Even UEFI spec defines MD5, but it does not mean a product has to use MD5.
> UEFI spec does not mandate that you must support MD5.
> Do you see any MD5 usage in BIOS except iSCSI?
> 
> If no, I prefer to drop MD4/MD5 in this patch.
> 
> Thank you
> Yao Jiewen
> 
> 
> > -Original Message-
> > From: Sukerkar, Amol N 
> > Sent: Wednesday, February 5, 2020 1:10 AM
> > To: Kinney, Michael D ; Yao, Jiewen 
> > ; devel@edk2.groups.io
> > Cc: Wang, Jian J ; Sukerkar, Amol N 
> > 
> > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement 
> > Unified Hash Calculation API
> >
> > Hi Jiewen and Mike,
> >
> > I agree with general statement that MD4 and MD5 are deprecated.
> > However, Although not MD4, UEFI spec 2.8 still mentions MD5 (and 
> > does not mention that it is deprecated). That is the reason MD4 and 
> > MD5 were
> included.
> >
> > If there is going to be an update to UEFI spec deprecating MD5 as 
> > well, we can definitely go ahead and remove MD5 (and MD4). I believe 
> > the decision is should we wait until the change to UEFI spec or make 
> > the change right now. Let me know which approach we should be following.
> >
> > Thanks,
> > Amol
> >
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Tuesday, February 04, 2020 9:26 AM
> > To: Yao, Jiewen ; devel@edk2.groups.io; 
> > Kinney, Michael D ; Sukerkar, Amol N 
> > 
> > Cc: Wang, Jian J 
> > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement 
> > Unified Hash Calculation API
> >
> > Jiewen,
> >
> > I think UINT8 is fine.  We can change default to 0x04 in DEC file.
> >
> > I will let Amol comment on why MD4 and MD5 are included.  If they 
> > are not required, then I agree they should be removed.
> >
> > I do not see a reason to align with TCG spec.  The HashApiLib is a 
> > layer on top of BaseCryptLib and the use of hash algorithms is not 
> > limited to TCG related content.  The BaseCryptLib could potentially 
> > adopt hash algorithms that are not defined in the TCG specification.
> > We also do not want CryptoPkg to depend on the SecurityPkg.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Monday, February 3, 2020 6:54 PM
> > > To: Kinney, Michael D ; 
> > > devel@edk2.groups.io
> > > Cc: Sukerkar, Amol N ; Wang, Jian J 
> > > 
> > > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > > Implement Unified Hash Calculation API
> > >
> > > Thanks Mike, to cover us during Chinese New Year holiday.
> > >
> > > I am just back from vocation. A minor comment:
> > >
> > > The PcdHashApiLibPolicy is UINT8, but the value is shown as 32bit 
> > > 0x0004.
> > >
> > > There are couple of ways to enhance:
> > > 1) Define UINT8, and use 8bit style 0x04.
> > > 2) Define UINT32, and use 32bit style 0x0004.
> > > 3) Define UINT16 (match TCG definition), and use TCG defined value.
> > > (Tpm20.h)
> > > #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> > > #define TPM_ALG_SHA256 

[edk2-devel] [PATCH] MdePkg: Add PCI Express 5.0 Header File

[Felix Polyudov]

The header includes Physical Layer PCI Express Extended Capability
definitions based on section 7.7.6 of PCI Express Base Specification 5.0.

Signed-off-by: Felix Polyudov 
---
 MdePkg/Include/IndustryStandard/PciExpress50.h | 136 +
 1 file changed, 136 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/PciExpress50.h

diff --git a/MdePkg/Include/IndustryStandard/PciExpress50.h 
b/MdePkg/Include/IndustryStandard/PciExpress50.h
new file mode 100644
index 000..26eae0b
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/PciExpress50.h
@@ -0,0 +1,136 @@
+/** @file
+Support for the PCI Express 5.0 standard.
+
+This header file may not define all structures.  Please extend as required.
+
+Copyright (c) 2020, American Megatrends International LLC. All rights 
reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _PCIEXPRESS50_H_
+#define _PCIEXPRESS50_H_
+
+#include 
+
+#pragma pack(1)
+
+/// The Physical Layer PCI Express Extended Capability definitions.
+///
+/// Based on section 7.7.6 of PCI Express Base Specification 5.0.
+///@{
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_32_0_ID0x002A
+#define PCI_EXPRESS_EXTENDED_CAPABILITY_PHYSICAL_LAYER_32_0_VER1  0x1
+
+// Register offsets from Physical Layer PCI-E Ext Cap Header
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_CAPABILITIES_OFFSET
 0x04
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_CONTROL_OFFSET 
 0x08
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_STATUS_OFFSET  
 0x0C
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_RCVD_MODIFIED_TS_DATA1_OFFSET  
 0x10
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_RCVD_MODIFIED_TS_DATA2_OFFSET  
 0x14
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_TRANS_MODIFIED_TS_DATA1_OFFSET 
 0x18
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_TRANS_MODIFIED_TS_DATA2_OFFSET 
 0x1C
+#define PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_LANE_EQUALIZATION_CONTROL_OFFSET   
 0x20
+
+typedef union {
+  struct {
+UINT32 EqualizationByPassToHighestRateSupport  : 1; // bit 0
+UINT32 NoEqualizationNeededSupport : 1; // bit 
1
+UINT32 Reserved1   : 6; // 
Reserved bit 2:7
+UINT32 ModifiedTSUsageMode0Support : 1; // bit 
8
+UINT32 ModifiedTSUsageMode1Support : 1; // bit 
9
+UINT32 ModifiedTSUsageMode2Support : 1; // bit 
10
+UINT32 ModifiedTSReservedUsageModes: 5; // bit 
11:15
+UINT32 Reserved2   : 16; // 
Reserved bit 16:31
+  } Bits;
+  UINT32   Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_CAPABILITIES;
+
+typedef union {
+  struct {
+UINT32 EqualizationByPassToHighestRateDisable  : 1; // bit 0
+UINT32 NoEqualizationNeededDisable : 1; // bit 
1
+UINT32 Reserved1   : 6; // 
Reserved bit 2:7
+UINT32 ModifiedTSUsageModeSelected : 3; // bit 
8:10
+UINT32 Reserved2   : 21; // 
Reserved bit 11:31
+  } Bits;
+  UINT32   Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_CONTROL;
+
+typedef union {
+  struct {
+UINT32 EqualizationComplete  : 1; // bit 0
+UINT32 EqualizationPhase1Success : 1; // bit 1
+UINT32 EqualizationPhase2Success : 1; // bit 2
+UINT32 EqualizationPhase3Success : 1; // bit 3
+UINT32 LinkEqualizationRequest   : 1; // bit 4
+UINT32 ModifiedTSRcvd: 1; // bit 5
+UINT32 RcvdEnhancedLinkControl   : 2; // bit 6:7
+UINT32 TransmitterPrecodingOn: 1; // bit 8
+UINT32 TransmitterPrecodeRequest : 1; // bit 9
+UINT32 NoEqualizationNeededRcvd  : 1; // bit 10
+UINT32 Reserved  : 21; // Reserved bit 11:31
+  } Bits;
+  UINT32   Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_STATUS;
+
+typedef union {
+  struct {
+UINT32 RcvdModifiedTSUsageMode   : 3; // bit 0:2
+UINT32 RcvdModifiedTSUsageInfo1  : 13; // bit 3:15
+UINT32 RcvdModifiedTSVendorId: 16; // bit 16:31
+  } Bits;
+  UINT32   Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_RCVD_MODIFIED_TS_DATA1;
+
+typedef union {
+  struct {
+UINT32 RcvdModifiedTSUsageInfo2 : 24; // bit 0:23
+UINT32 AltProtocolNegotiationStatus : 2; // bit 24:25
+UINT32 Reserved : 6; // Reserved bit 26:31
+  } Bits;
+  UINT32   Uint32;
+} PCI_EXPRESS_REG_PHYSICAL_LAYER_32_0_RCVD_MODIFIED_TS_DATA2;
+
+typedef union {
+  struct {
+UINT32 TransModifiedTSUsageMode   : 3; // bit 0:2
+UINT32 TransModifiedTSUsageInfo1  : 13; // bit 3:15
+UINT32 TransModifiedTSVendorId: 16; // bit 16:31
+  } Bits;
+  UINT32   Uint32;
+} 

[edk2-devel] [PATCH 1/1] SecurityPkg: Fix incorrect return value in documentation

[Philippe Mathieu-Daudé]

The DxeTpmMeasureBootHandler and DxeTpm2MeasureBootHandler handlers
are SECURITY2_FILE_AUTHENTICATION_HANDLER prototype. This prototype
can not return EFI_INVALID_PARAMETER.

The prototype documentation states it returns EFI_ACCESS_DENIED if:

  "The file specified by File and FileBuffer did not authenticate,
   and the platform policy dictates that the DXE Foundation may not
   use File."

Note in practice both functions return EFI_SECURITY_VIOLATION:

  "The file specified by DevicePath and FileBuffer did not
   authenticate, and the platform policy dictates that the file
   should be placed in the untrusted state. The image has been
   added to the file execution table."

Noticed while reviewing commit 6d57592740cdd0b6868baeef7929d6e6fef.

Cc: Jiewen Yao 
Cc: Jian J Wang 
Cc: Chao Zhang 
Signed-off-by: Philippe Mathieu-Daude 
---
 .../Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c   | 2 +-
 SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c 
b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
index 04b9b0d7fbf3..0c07f65c6835 100644
--- a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
+++ b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
@@ -384,7 +384,7 @@ Finish:
   and other exception operations.  The File parameter allows for possible 
logging
   within the SAP of the driver.
 
-  If File is NULL, then EFI_INVALID_PARAMETER is returned.
+  If File is NULL, then EFI_ACCESS_DENIED is returned.
 
   If the file specified by File with an authentication status specified by
   AuthenticationStatus is safe for the DXE Core to use, then EFI_SUCCESS is 
returned.
diff --git a/SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c 
b/SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c
index 1f2eed29a1df..0dccbb66eb26 100644
--- a/SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c
+++ b/SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c
@@ -678,7 +678,7 @@ Finish:
   and other exception operations.  The File parameter allows for possible 
logging
   within the SAP of the driver.
 
-  If File is NULL, then EFI_INVALID_PARAMETER is returned.
+  If File is NULL, then EFI_ACCESS_DENIED is returned.
 
   If the file specified by File with an authentication status specified by
   AuthenticationStatus is safe for the DXE Core to use, then EFI_SUCCESS is 
returned.
-- 
2.21.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53741): https://edk2.groups.io/g/devel/message/53741
Mute This Topic: https://groups.io/mt/70984329/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Yao, Jiewen]

Mike
The problem of defining a set of algo ID is that I have to remember the ID.
I feel frustrated whenever I need match one ID to the other ID.

Currently, UEFI secure boot and TCG trusted boot are important feature. If we 
can align to one of them, it is easier. I believe if we have a consistent ID 
mapping, it will be much better for developer.

Current TPM20.h is defined in MdePkg (not in SecurityPkg) and is considered as 
an industry standard. I do not see any dependency issue.

We can define a new set - not a technical problem. I am just not sure why we 
have to. Or we can define it with the same value as TPM. See below list. I 
believe it will cover majority of current usage and current standard.
> > > +  # 0x0004- SHA1.
> > > +  # 0x000B- SHA256.
> > > +  # 0x000C- SHA384.
> > > +  # 0x000D- SHA512.
> > > +  # 0x0012- SM3_256.
> > > +  # 0x0027- SHA3_256.
> > > +  # 0x0028- SHA3_384.
> > > +  # 0x0029- SHA3_512.




> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, February 5, 2020 12:26 AM
> To: Yao, Jiewen ; devel@edk2.groups.io; Kinney,
> Michael D ; Sukerkar, Amol N
> 
> Cc: Wang, Jian J 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash
> Calculation API
> 
> Jiewen,
> 
> I think UINT8 is fine.  We can change default to 0x04 in DEC file.
> 
> I will let Amol comment on why MD4 and MD5 are included.  If
> they are not required, then I agree they should be removed.
> 
> I do not see a reason to align with TCG spec.  The HashApiLib
> is a layer on top of BaseCryptLib and the use of hash algorithms
> is not limited to TCG related content.  The BaseCryptLib
> could potentially adopt hash algorithms that are not defined
> in the TCG specification.  We also do not want CryptoPkg to
> depend on the SecurityPkg.
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Monday, February 3, 2020 6:54 PM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io
> > Cc: Sukerkar, Amol N ; Wang,
> > Jian J 
> > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > Implement Unified Hash Calculation API
> >
> > Thanks Mike, to cover us during Chinese New Year
> > holiday.
> >
> > I am just back from vocation. A minor comment:
> >
> > The PcdHashApiLibPolicy is UINT8, but the value is
> > shown as 32bit 0x0004.
> >
> > There are couple of ways to enhance:
> > 1) Define UINT8, and use 8bit style 0x04.
> > 2) Define UINT32, and use 32bit style 0x0004.
> > 3) Define UINT16 (match TCG definition), and use TCG
> > defined value. (Tpm20.h)
> > #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> > #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> > #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> > #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> > #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> >
> > MD4 and MD5 are known as insecure and deprecated. I
> > doubt if we want to add such support. (I strong
> > recommend NO).
> >
> > If we can remove MD4 and MD5, I think we can use #3.
> >
> > Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Tuesday, February 4, 2020 7:36 AM
> > > To: devel@edk2.groups.io
> > > Cc: Sukerkar, Amol N ;
> > Yao, Jiewen
> > > ; Wang, Jian J
> > 
> > > Subject: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > Implement Unified Hash
> > > Calculation API
> > >
> > > From: Amol N Sukerkar 
> > >
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2151
> > >
> > > This commit introduces a Unified Hash API to
> > calculate hash using a
> > > hashing algorithm specified by the PCD,
> > PcdHashApiLibPolicy. This library
> > > interfaces with the various hashing API, such as,
> > MD4, MD5, SHA1, SHA256,
> > > SHA512 and SM3_256 implemented in BaseCryptLib. The
> > user can calculate
> > > the desired hash by setting PcdHashApiLibPolicy to
> > appropriate value.
> > >
> > > This feature is documented in the Bugzilla,
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2151.
> > >
> > > Cc: Jiewen Yao 
> > > Cc: Jian J Wang 
> > > Cc: Michael D Kinney 
> > > Signed-off-by: Amol N Sukerkar
> > 
> > > Reviewed-by: Michael D Kinney
> > 
> > > ---
> > >  CryptoPkg/CryptoPkg.dec   |  20
> > ++
> > >  CryptoPkg/CryptoPkg.dsc   |   4
> > +-
> > >  CryptoPkg/CryptoPkg.uni   |  18
> > +-
> > >  CryptoPkg/Include/Library/HashApiLib.h| 122
> > +++
> > >  .../Library/BaseHashApiLib/BaseHashApiLib.c   | 330
> > ++
> > >  .../Library/BaseHashApiLib/BaseHashApiLib.inf |  44
> > +++
> > >  .../Library/BaseHashApiLib/BaseHashApiLib.uni |  17
> > +
> > >  7 files changed, 553 insertions(+), 2 deletions(-)
> > >  create mode 100644
> > CryptoPkg/Include/Library/HashApiLib.h
> > >  create mode 100644
> > CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.c
> > >  create mode 100644
> > 

[edk2-devel] [PATCH v4 09/40] UefiCpuPkg/CpuExceptionHandler: Add support for IOIO_PROT NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a IOIO_PROT intercept generates a #VC exception. VMGEXIT
must be used to allow the hypervisor to handle this intercept.

Add support to construct the required GHCB values to support a IOIO_PROT
NAE event.  Parse the instruction that generated the #VC exception,
setting the required register values in the GHCB and creating the proper
SW_EXITINFO1 value in the GHCB.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 463 +-
 1 file changed, 449 insertions(+), 14 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index cee5ce806473..48eb5c2358ed 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -11,6 +11,431 @@
 #include 
 #include "AMDSevVcCommon.h"
 
+typedef enum {
+  LongMode64Bit= 0,
+  LongModeCompat32Bit,
+  LongModeCompat16Bit,
+} SEV_ES_INSTRUCTION_MODE;
+
+typedef enum {
+  Size8Bits= 0,
+  Size16Bits,
+  Size32Bits,
+  Size64Bits,
+} SEV_ES_INSTRUCTION_SIZE;
+
+typedef enum {
+  SegmentEs= 0,
+  SegmentCs,
+  SegmentSs,
+  SegmentDs,
+  SegmentFs,
+  SegmentGs,
+} SEV_ES_INSTRUCTION_SEGMENT;
+
+typedef enum {
+  RepNone  = 0,
+  RepZ,
+  RepNZ,
+} SEV_ES_INSTRUCTION_REP;
+
+typedef union {
+  struct {
+UINT8  B:1;
+UINT8  X:1;
+UINT8  R:1;
+UINT8  W:1;
+UINT8  REX:4;
+  } Bits;
+
+  UINT8  Uint8;
+} SEV_ES_INSTRUCTION_REX_PREFIX;
+
+typedef union {
+  struct {
+UINT8  Rm:3;
+UINT8  Reg:3;
+UINT8  Mod:2;
+  } Bits;
+
+  UINT8  Uint8;
+} SEV_ES_INSTRUCTION_MODRM;
+
+typedef union {
+  struct {
+UINT8  Base:3;
+UINT8  Index:3;
+UINT8  Scale:2;
+  } Bits;
+
+  UINT8  Uint8;
+} SEV_ES_INSTRUCTION_SIB;
+
+typedef struct {
+  struct {
+UINT8  Rm;
+UINT8  Reg;
+UINT8  Mod;
+  } ModRm;
+
+  struct {
+UINT8  Base;
+UINT8  Index;
+UINT8  Scale;
+  } Sib;
+
+  UINTN  RegData;
+  UINTN  RmData;
+} SEV_ES_INSTRUCTION_OPCODE_EXT;
+
+typedef struct {
+  GHCB   *Ghcb;
+
+  SEV_ES_INSTRUCTION_MODEMode;
+  SEV_ES_INSTRUCTION_SIZEDataSize;
+  SEV_ES_INSTRUCTION_SIZEAddrSize;
+  BOOLEANSegmentSpecified;
+  SEV_ES_INSTRUCTION_SEGMENT Segment;
+  SEV_ES_INSTRUCTION_REP RepMode;
+
+  UINT8  *Begin;
+  UINT8  *End;
+
+  UINT8  *Prefixes;
+  UINT8  *OpCodes;
+  UINT8  *Displacement;
+  UINT8  *Immediate;
+
+  SEV_ES_INSTRUCTION_REX_PREFIX  RexPrefix;
+
+  BOOLEANModRmPresent;
+  SEV_ES_INSTRUCTION_MODRM   ModRm;
+
+  BOOLEANSibPresent;
+  SEV_ES_INSTRUCTION_SIB Sib;
+
+  UINT8  PrefixSize;
+  UINT8  OpCodeSize;
+  UINT8  DisplacementSize;
+  UINT8  ImmediateSize;
+
+  SEV_ES_INSTRUCTION_OPCODE_EXT  Ext;
+} SEV_ES_INSTRUCTION_DATA;
+
+typedef
+UINT64
+(*NAE_EXIT) (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  );
+
+
+STATIC
+BOOLEAN
+GhcbIsRegValid (
+  GHCB*Ghcb,
+  GHCB_REGISTER   Reg
+  )
+{
+  UINT32  RegIndex = Reg / 8;
+  UINT32  RegBit   = Reg & 0x07;
+
+  return (Ghcb->SaveArea.ValidBitmap[RegIndex] & (1 << RegBit));
+}
+
+STATIC
+VOID
+GhcbSetRegValid (
+  GHCB*Ghcb,
+  GHCB_REGISTER   Reg
+  )
+{
+  UINT32  RegIndex = Reg / 8;
+  UINT32  RegBit   = Reg & 0x07;
+
+  Ghcb->SaveArea.ValidBitmap[RegIndex] |= (1 << RegBit);
+}
+
+STATIC
+VOID
+DecodePrefixes (
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_MODE  Mode;
+  SEV_ES_INSTRUCTION_SIZE  ModeDataSize;
+  SEV_ES_INSTRUCTION_SIZE  ModeAddrSize;
+  UINT8*Byte;
+
+  /*TODO: Determine current mode - 64-bit for now */
+  Mode = LongMode64Bit;
+  ModeDataSize = Size32Bits;
+  ModeAddrSize = Size64Bits;
+
+  InstructionData->Mode = Mode;
+  InstructionData->DataSize = ModeDataSize;
+  InstructionData->AddrSize = ModeAddrSize;
+
+  InstructionData->Prefixes = InstructionData->Begin;
+
+  Byte = InstructionData->Prefixes;
+  for ( ; ; Byte++, InstructionData->PrefixSize++) {
+switch (*Byte) {
+case 0x26:
+case 0x2E:
+case 0x36:
+case 0x3E:
+  if (Mode != LongMode64Bit) {
+InstructionData->SegmentSpecified = TRUE;
+InstructionData->Segment = (*Byte >> 3) & 3;
+  }
+  break;
+
+case 0x40 ... 0x4F:
+  InstructionData->RexPrefix.Uint8 = *Byte;
+  if (*Byte & 0x08)
+

[edk2-devel] [PATCH v4 12/40] UefiCpuPkg/CpuExceptionHandler: Add support for MSR_PROT NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a MSR_PROT intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.

Add support to construct the required GHCB values to support an MSR_PROT
NAE event. Parse the instruction that generated the #VC exception to
determine whether it is RDMSR or WRMSR, setting the required register
register values in the GHCB and creating the proper SW_EXIT_INFO1 value in
the GHCB.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 90541c9a0390..25bcc34218d7 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -294,6 +294,51 @@ UnsupportedExit (
   return Status;
 }
 
+STATIC
+UINT64
+MsrExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  ExitInfo1, Status;
+
+  ExitInfo1 = 0;
+
+  switch (*(InstructionData->OpCodes + 1)) {
+  case 0x30: // WRMSR
+ExitInfo1 = 1;
+Ghcb->SaveArea.Rax = Regs->Rax;
+GhcbSetRegValid (Ghcb, GhcbRax);
+Ghcb->SaveArea.Rdx = Regs->Rdx;
+GhcbSetRegValid (Ghcb, GhcbRdx);
+/* Fallthrough */
+  case 0x32: // RDMSR
+Ghcb->SaveArea.Rcx = Regs->Rcx;
+GhcbSetRegValid (Ghcb, GhcbRcx);
+break;
+  default:
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+
+  Status = VmgExit (Ghcb, SvmExitMsr, ExitInfo1, 0);
+  if (Status) {
+return Status;
+  }
+
+  if (!ExitInfo1) {
+if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+!GhcbIsRegValid (Ghcb, GhcbRdx)) {
+  return UnsupportedExit (Ghcb, Regs, InstructionData);
+}
+Regs->Rax = Ghcb->SaveArea.Rax;
+Regs->Rdx = Ghcb->SaveArea.Rdx;
+  }
+
+  return 0;
+}
+
 #define IOIO_TYPE_STR  (1 << 2)
 #define IOIO_TYPE_IN   1
 #define IOIO_TYPE_INS  (IOIO_TYPE_IN | IOIO_TYPE_STR)
@@ -558,6 +603,10 @@ DoVcCommon (
 NaeExit = IoioExit;
 break;
 
+  case SvmExitMsr:
+NaeExit = MsrExit;
+break;
+
   default:
 NaeExit = UnsupportedExit;
   }
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53759): https://edk2.groups.io/g/devel/message/53759
Mute This Topic: https://groups.io/mt/70984934/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 13/40] UefiCpuPkg/CpuExceptionHandler: Add support for NPF NAE events (MMIO)

[Lendacky, Thomas]

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

Under SEV-ES, a NPF intercept for an NPT entry with a reserved bit set
generates a #VC exception. This condition is assumed to be an MMIO access.
VMGEXIT must be used to allow the hypervisor to handle this intercept.

Add support to construct the required GHCB values to support a NPF NAE
event for MMIO.  Parse the instruction that generated the #VC exception,
setting the required register values in the GHCB and creating the proper
SW_EXIT_INFO1, SW_EXITINFO2 and SW_SCRATCH values in the GHCB.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 305 +-
 1 file changed, 303 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 25bcc34218d7..c68aeb5d2c10 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -86,8 +86,8 @@ typedef struct {
 UINT8  Scale;
   } Sib;
 
-  UINTN  RegData;
-  UINTN  RmData;
+  INTN  RegData;
+  INTN  RmData;
 } SEV_ES_INSTRUCTION_OPCODE_EXT;
 
 typedef struct {
@@ -159,6 +159,198 @@ GhcbSetRegValid (
   Ghcb->SaveArea.ValidBitmap[RegIndex] |= (1 << RegBit);
 }
 
+STATIC
+INT64 *
+GetRegisterPointer (
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  UINT8Register
+  )
+{
+  UINT64 *Reg;
+
+  switch (Register) {
+  case 0:
+Reg = >Rax;
+break;
+  case 1:
+Reg = >Rcx;
+break;
+  case 2:
+Reg = >Rdx;
+break;
+  case 3:
+Reg = >Rbx;
+break;
+  case 4:
+Reg = >Rsp;
+break;
+  case 5:
+Reg = >Rbp;
+break;
+  case 6:
+Reg = >Rsi;
+break;
+  case 7:
+Reg = >Rdi;
+break;
+  case 8:
+Reg = >R8;
+break;
+  case 9:
+Reg = >R9;
+break;
+  case 10:
+Reg = >R10;
+break;
+  case 11:
+Reg = >R11;
+break;
+  case 12:
+Reg = >R12;
+break;
+  case 13:
+Reg = >R13;
+break;
+  case 14:
+Reg = >R14;
+break;
+  case 15:
+Reg = >R15;
+break;
+  default:
+Reg = NULL;
+  }
+  ASSERT (Reg != NULL);
+
+  return (INT64 *) Reg;
+}
+
+STATIC
+VOID
+UpdateForDisplacement (
+  SEV_ES_INSTRUCTION_DATA  *InstructionData,
+  UINTNSize
+  )
+{
+  InstructionData->DisplacementSize = Size;
+  InstructionData->Immediate += Size;
+  InstructionData->End += Size;
+}
+
+STATIC
+BOOLEAN
+IsRipRelative (
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext = >Ext;
+
+  return ((InstructionData == LongMode64Bit) &&
+  (Ext->ModRm.Mod == 0) &&
+  (Ext->ModRm.Rm == 5)  &&
+  (InstructionData->SibPresent == FALSE));
+}
+
+STATIC
+UINTN
+GetEffectiveMemoryAddress (
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext = >Ext;
+  INTN   EffectiveAddress = 0;
+
+  if (IsRipRelative (InstructionData)) {
+/* RIP-relative displacement is a 32-bit signed value */
+INT32 RipRelative = *(INT32 *) InstructionData->Displacement;
+
+UpdateForDisplacement (InstructionData, 4);
+return (UINTN) ((INTN) Regs->Rip + RipRelative);
+  }
+
+  switch (Ext->ModRm.Mod) {
+  case 1:
+UpdateForDisplacement (InstructionData, 1);
+EffectiveAddress += (INT8) (*(INT8 *) (InstructionData->Displacement));
+break;
+  case 2:
+switch (InstructionData->AddrSize) {
+case Size16Bits:
+  UpdateForDisplacement (InstructionData, 2);
+  EffectiveAddress += (INT16) (*(INT16 *) (InstructionData->Displacement));
+  break;
+default:
+  UpdateForDisplacement (InstructionData, 4);
+  EffectiveAddress += (INT32) (*(INT32 *) (InstructionData->Displacement));
+  break;
+}
+break;
+  }
+
+  if (InstructionData->SibPresent) {
+if (Ext->Sib.Index != 4) {
+  EffectiveAddress += (*GetRegisterPointer (Regs, Ext->Sib.Index) << 
Ext->Sib.Scale);
+}
+
+if ((Ext->Sib.Base != 5) || Ext->ModRm.Mod) {
+  EffectiveAddress += *GetRegisterPointer (Regs, Ext->Sib.Base);
+} else {
+  UpdateForDisplacement (InstructionData, 4);
+  EffectiveAddress += (INT32) (*(INT32 *) (InstructionData->Displacement));
+}
+  } else {
+EffectiveAddress += *GetRegisterPointer (Regs, Ext->ModRm.Rm);
+  }
+
+  return (UINTN) EffectiveAddress;
+}
+
+STATIC
+VOID
+DecodeModRm (
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_REX_PREFIX  *RexPrefix = >RexPrefix;
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext = >Ext;
+  SEV_ES_INSTRUCTION_MODRM   *ModRm = >ModRm;
+  SEV_ES_INSTRUCTION_SIB *Sib = >Sib;
+
+  InstructionData->ModRmPresent = TRUE;
+  ModRm->Uint8 = *(InstructionData->End);
+
+  InstructionData->Displacement++;
+  InstructionData->Immediate++;
+  

[edk2-devel] [PATCH v4 07/40] UefiCpuPkg: Implement library support for VMGEXIT

[Lendacky, Thomas]

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

To support issuing a VMGEXIT instruction, create a library that can be
used to perform GHCB and VMGEXIT related operations and to issue the
actual VMGEXIT instruction when using the GHCB.

Additionally, two VMGEXIT / MMIO related functions are created to support
flash emulation. Flash emulation currently is done by marking the flash
area as read-only and taking a nested page fault to perform the emulation
of the instruction. However, emulation cannot be performed because there
is no instruction decode assist support when SEV-ES is enabled. Provide
routines to initiate an MMIO request to perform actual writes to flash.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Acked-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 UefiCpuPkg/UefiCpuPkg.dec|   3 +
 UefiCpuPkg/UefiCpuPkg.dsc|   5 +
 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf |  33 
 UefiCpuPkg/Include/Library/VmgExitLib.h  | 111 +++
 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.c   | 187 +++
 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.uni |  15 ++
 6 files changed, 354 insertions(+)
 create mode 100644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 create mode 100644 UefiCpuPkg/Include/Library/VmgExitLib.h
 create mode 100644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.c
 create mode 100644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.uni

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index 005703d8a3e7..893d2d06b0f2 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -53,6 +53,9 @@ [LibraryClasses.IA32, LibraryClasses.X64]
   ##
   MpInitLib|Include/Library/MpInitLib.h
 
+  ##  @libraryclass  Provides function to support VMGEXIT processing.
+  VmgExitLib|Include/Library/VmgExitLib.h
+
 [Guids]
   gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 
0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
   gMsegSmramGuid = { 0x5802bce4, 0x, 0x4e33, { 0xa1, 0x30, 
0xeb, 0xad, 0x27, 0xf0, 0xe4, 0x39 }}
diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
index d28cb5cccb52..5ab7e423e8ab 100644
--- a/UefiCpuPkg/UefiCpuPkg.dsc
+++ b/UefiCpuPkg/UefiCpuPkg.dsc
@@ -63,6 +63,7 @@ [LibraryClasses.common.SEC]
   HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.PEIM]
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
@@ -74,6 +75,7 @@ [LibraryClasses.common.PEIM]
 [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.DXE_DRIVER]
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
@@ -81,12 +83,14 @@ [LibraryClasses.common.DXE_DRIVER]
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
   
RegisterCpuFeaturesLib|UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.DXE_SMM_DRIVER]
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.UEFI_APPLICATION]
   
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
@@ -136,6 +140,7 @@ [Components.IA32, Components.X64]
   UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
   UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf
+  UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
   UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf
   UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
   UefiCpuPkg/SecCore/SecCore.inf
diff --git a/UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf 
b/UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
new file mode 100644
index ..6acfa779e75a
--- /dev/null
+++ b/UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
@@ -0,0 +1,33 @@
+## @file
+#  VMGEXIT Support Library.
+#
+#  Copyright (c) 2019, Advanced Micro Devices, Inc. All rights reserved.
+#  SPDX-License-Identifier: 

[edk2-devel] [PATCH v4 14/40] UefiCpuPkg/CpuExceptionHandler: Add support for WBINVD NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a WBINVD intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 22 +++
 1 file changed, 22 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index c68aeb5d2c10..03003e9113fa 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -591,6 +591,24 @@ MmioExit (
   return Status;
 }
 
+STATIC
+UINT64
+WbinvdExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  Status = VmgExit (Ghcb, SvmExitWbinvd, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  return 0;
+}
+
 STATIC
 UINT64
 MsrExit (
@@ -904,6 +922,10 @@ DoVcCommon (
 NaeExit = MsrExit;
 break;
 
+  case SvmExitWbinvd:
+NaeExit = WbinvdExit;
+break;
+
   case SvmExitNpf:
 NaeExit = MmioExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53761): https://edk2.groups.io/g/devel/message/53761
Mute This Topic: https://groups.io/mt/70984937/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 17/40] UefiCpuPkg/CpuExceptionHandler: Add support for INVD NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a INVD intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 22 +++
 1 file changed, 22 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index c2bc213e602c..a47bba5ac1c1 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -856,6 +856,24 @@ IoioExit (
   return 0;
 }
 
+STATIC
+UINT64
+InvdExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  Status = VmgExit (Ghcb, SvmExitInvd, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  return 0;
+}
+
 STATIC
 UINT64
 CpuidExit (
@@ -975,6 +993,10 @@ DoVcCommon (
 NaeExit = CpuidExit;
 break;
 
+  case SvmExitInvd:
+NaeExit = InvdExit;
+break;
+
   case SvmExitIoioProt:
 NaeExit = IoioExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53764): https://edk2.groups.io/g/devel/message/53764
Mute This Topic: https://groups.io/mt/70984940/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 02/40] MdePkg: Add the MSR definition for the GHCB register

[Lendacky, Thomas]

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

For SEV-ES, the GHCB page address is stored in the GHCB MSR register
(0xc0010130). Define the register and the format used for register
during GHCB protocol negotiation.

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Include/Register/Amd/Fam17Msr.h | 31 ++
 1 file changed, 31 insertions(+)

diff --git a/MdePkg/Include/Register/Amd/Fam17Msr.h 
b/MdePkg/Include/Register/Amd/Fam17Msr.h
index 37b935dcdb30..6e8ac11bae74 100644
--- a/MdePkg/Include/Register/Amd/Fam17Msr.h
+++ b/MdePkg/Include/Register/Amd/Fam17Msr.h
@@ -17,6 +17,37 @@
 #ifndef __FAM17_MSR_H__
 #define __FAM17_MSR_H__
 
+/**
+  Secure Encrypted Virtualization - Encrypted State (SEV-ES) GHCB register
+
+**/
+#define MSR_SEV_ES_GHCB0xc0010130
+
+/**
+  MSR information returned for #MSR_SEV_ES_GHCB
+**/
+typedef union {
+  struct {
+UINT64  Function:12;
+  } GhcbInfo;
+
+  struct {
+UINT8   Reserved[3];
+UINT8   SevEncryptionBitPos;
+UINT16  SevEsProtocolMin;
+UINT16  SevEsProtocolMax;
+  } GhcbProtocol;
+
+  VOID*Ghcb;
+
+  UINT64  GhcbPhysicalAddress;
+} MSR_SEV_ES_GHCB_REGISTER;
+
+#define GHCB_INFO_SEV_INFO 1
+#define GHCB_INFO_SEV_INFO_GET 2
+#define GHCB_INFO_CPUID_REQUEST4
+#define GHCB_INFO_CPUID_RESPONSE   5
+
 /**
   Secure Encrypted Virtualization (SEV) status register
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53749): https://edk2.groups.io/g/devel/message/53749
Mute This Topic: https://groups.io/mt/70984920/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 20/40] UefiCpuPkg/CpuExceptionHandler: Add support for MONITOR/MONITORX NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a MONITOR/MONITORX intercept generates a #VC exception.
VMGEXIT must be used to allow the hypervisor to handle this intercept.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index f18fbe97e147..93341a647e48 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -591,6 +591,33 @@ MmioExit (
   return Status;
 }
 
+STATIC
+UINT64
+MonitorExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  DecodeModRm (Regs, InstructionData);
+
+  Ghcb->SaveArea.Rax = Regs->Rax;  // Identity mapped, so VA = PA
+  GhcbSetRegValid (Ghcb, GhcbRax);
+  Ghcb->SaveArea.Rcx = Regs->Rcx;
+  GhcbSetRegValid (Ghcb, GhcbRcx);
+  Ghcb->SaveArea.Rdx = Regs->Rdx;
+  GhcbSetRegValid (Ghcb, GhcbRdx);
+
+  Status = VmgExit (Ghcb, SvmExitMonitor, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  return 0;
+}
+
 STATIC
 UINT64
 WbinvdExit (
@@ -1076,6 +1103,10 @@ DoVcCommon (
 NaeExit = WbinvdExit;
 break;
 
+  case SvmExitMonitor:
+NaeExit = MonitorExit;
+break;
+
   case SvmExitNpf:
 NaeExit = MmioExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53767): https://edk2.groups.io/g/devel/message/53767
Mute This Topic: https://groups.io/mt/70984943/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 00/40] SEV-ES guest support

[Lendacky, Thomas]

This patch series provides support for running EDK2/OVMF under SEV-ES.

Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
SEV support to protect the guest register state from the hypervisor. See
"AMD64 Architecture Programmer's Manual Volume 2: System Programming",
section "15.35 Encrypted State (SEV-ES)" [1].

In order to allow a hypervisor to perform functions on behalf of a guest,
there is architectural support for notifying a guest's operating system
when certain types of VMEXITs are about to occur. This allows the guest to
selectively share information with the hypervisor to satisfy the requested
function. The notification is performed using a new exception, the VMM
Communication exception (#VC). The information is shared through the
Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
The GHCB format and the protocol for using it is documented in "SEV-ES
Guest-Hypervisor Communication Block Standardization" [2].

The main areas of the EDK2 code that are updated to support SEV-ES are
around the exception handling support and the AP boot support.

Exception support is required starting in Sec, continuing through Pei
and into Dxe in order to handle #VC exceptions that are generated.  Each
AP requires it's own GHCB page as well as a page to hold values specific
to that AP.

AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
is typically used to boot the APs. However, the hypervisor is not allowed
to update the guest registers. The GHCB document [2] talks about how SMP
booting under SEV-ES is performed.

Since the GHCB page must be a shared (unencrypted) page, the processor
must be running in long mode in order for the guest and hypervisor to
communicate with each other. As a result, SEV-ES is only supported under
the X64 architecture.

[1] https://www.amd.com/system/files/TechDocs/24593.pdf
[2] https://developer.amd.com/wp-content/resources/56421.pdf

---

These patches are based on commit:
3feea54eae33 ("CryptoPkg/BaseHashApiLib: Implement Unified Hash Calculation 
API")

Proper execution of SEV-ES relies on Bugzilla 2340 being fixed.

A version of the tree (with an extra patch to workaround Bugzilla 2340) can
be found at:
https://github.com/AMDESE/ovmf/tree/sev-es-v11

Cc: Ard Biesheuvel 
Cc: Benjamin You 
Cc: Dandan Bi 
Cc: Eric Dong 
Cc: Guo Dong 
Cc: Hao A Wu 
Cc: Jian J Wang 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Liming Gao 
Cc: Maurice Ma 
Cc: Michael D Kinney 
Cc: Ray Ni 

Changes since v3:
- Remove the need for the MP library finalization routine. The AP
  jump table address will be held by the hypervisor rather than
  communicated via the GHCB MSR. This removes some fragility around
  the UEFI to OS transition.
- Rename the SEV-ES RIP reset area to SEV-ES workarea and use it to
  communicate the SEV-ES status, so that SEC CPU exception handling is
  only established for an SEV-ES guest.
- Fix SMM build breakageAdd around QemuFlashPtrWrite().
- Fix SMM build breakage by adding VC exception support the SMM CPU
  exception handling.
- Add memory fencing around the invocation of AsmVmgExit().
- Clarify comments around the SEV-ES AP reset RIP values and usage.
- Move some PCD definitions from MdeModulePkg to UefiCpuPkg.
- Remove the 16-bit code selector definition from MdeModulePkg

Changes since v2:
- Added a way to locate the SEV-ES fixed AP RIP address for starting
  AP's to avoid updating the actual flash image (build time location
  that is identified with a GUID value).
- Create a VmgExit library to replace static inline functions.
- Move some PCDs to the appropriate packages
- Add support for writing to QEMU flash under SEV-ES
- Add additional MMIO opcode support
- Cleaned up the GHCB MSR CPUID protocol support

Changes since v1:
- Patches reworked to be more specific to the component/area being updated
  and order of definition/usage
- Created a library for VMGEXIT-related functions to replace use of inline
  functions
- Allocation method for GDT changed from AllocatePool to AllocatePages
- Early caching only enabled for SEV-ES guests
- Ensure AP loop mode set to halt loop mode for SEV-ES guests
- Reserved SEC GHCB-related memory areas when S3 is enabled

Tom Lendacky (40):
  MdePkg: Create PCDs to be used in support of SEV-ES
  MdePkg: Add the MSR definition for the GHCB register
  MdePkg: Add a structure definition for the GHCB
  MdeModulePkg/DxeIplPeim: Support GHCB pages when creating page tables
  MdePkg/BaseLib: Add support for the XGETBV instruction
  MdePkg/BaseLib: Add support for the VMGEXIT instruction
  UefiCpuPkg: Implement library support for VMGEXIT
  UefiCpuPkg/CpuExceptionHandler: Add base support for the #VC exception
  UefiCpuPkg/CpuExceptionHandler: Add support for IOIO_PROT NAE events
  UefiCpuPkg/CpuExceptionHandler: Support string IO for IOIO_PROT NAE
events
  UefiCpuPkg/CpuExceptionHandler: Add support for CPUID NAE events
  UefiCpuPkg/CpuExceptionHandler: Add support for MSR_PROT NAE events
 

[edk2-devel] [PATCH v4 08/40] UefiCpuPkg/CpuExceptionHandler: Add base support for the #VC exception

[Lendacky, Thomas]

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

Add base support to handle #VC exceptions.  This includes a stub routine
to invoke when a #VC exception occurs and special checks in the common
exception handlers to invoke the #VC exception handler routine.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Cc: Maurice Ma 
Cc: Guo Dong 
Cc: Benjamin You 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkgIa32.dsc   |  5 ++
 OvmfPkg/OvmfPkgIa32X64.dsc|  5 ++
 OvmfPkg/OvmfPkgX64.dsc|  5 ++
 UefiPayloadPkg/UefiPayloadPkgIa32.dsc |  2 +
 UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc  |  2 +
 .../DxeCpuExceptionHandlerLib.inf |  5 ++
 .../PeiCpuExceptionHandlerLib.inf |  5 ++
 .../SecPeiCpuExceptionHandlerLib.inf  |  8 +++
 .../SmmCpuExceptionHandlerLib.inf |  5 ++
 .../CpuExceptionHandlerLib/AMDSevVcCommon.h   | 26 +
 .../CpuExceptionCommon.h  |  2 +
 .../CpuExceptionCommon.c  |  2 +-
 .../Ia32/AMDSevVcCommon.c | 24 
 .../PeiDxeAMDSevVcHandler.c   | 29 ++
 .../PeiDxeSmmCpuException.c   | 16 ++
 .../SecAMDSevVcHandler.c  | 55 +++
 .../SecPeiCpuException.c  | 16 ++
 .../X64/AMDSevVcCommon.c  | 50 +
 18 files changed, 261 insertions(+), 1 deletion(-)
 create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/AMDSevVcCommon.h
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/AMDSevVcCommon.c
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeAMDSevVcHandler.c
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/SecAMDSevVcHandler.c
 create mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 4568b78cadf1..41ec761e3f17 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -236,6 +236,7 @@ [LibraryClasses.common.SEC]
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 [LibraryClasses.common.PEI_CORE]
   HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
@@ -274,6 +275,7 @@ [LibraryClasses.common.PEIM]
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
@@ -299,6 +301,7 @@ [LibraryClasses.common.DXE_CORE]
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
@@ -349,6 +352,7 @@ [LibraryClasses.common.DXE_DRIVER]
   
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 !if $(SMM_REQUIRE) == TRUE
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
 !else
@@ -392,6 +396,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 !if $(SOURCE_DEBUG_ENABLE) == TRUE
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 152b5d067116..41cc3eec3757 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -241,6 +241,7 @@ [LibraryClasses.common.SEC]
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
+  VmgExitLib|UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
 
 

[edk2-devel] [PATCH v4 03/40] MdePkg: Add a structure definition for the GHCB

[Lendacky, Thomas]

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

The GHCB is used by an SEV-ES guest for communicating between the guest
and the hypervisor. Create the GHCB definition as defined by the GHCB
protocol definition.

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Include/Register/Amd/Ghcb.h | 136 +
 1 file changed, 136 insertions(+)
 create mode 100644 MdePkg/Include/Register/Amd/Ghcb.h

diff --git a/MdePkg/Include/Register/Amd/Ghcb.h 
b/MdePkg/Include/Register/Amd/Ghcb.h
new file mode 100644
index ..efe09bac9ea0
--- /dev/null
+++ b/MdePkg/Include/Register/Amd/Ghcb.h
@@ -0,0 +1,136 @@
+/** @file
+  Guest-Hypervisor Communication Block (GHCB) Definition.
+
+  Provides data types allowing an SEV-ES guest to interact with the hypervisor
+  using the GHCB protocol.
+
+  Copyright (c) 2019, Advanced Micro Devices, Inc. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Specification Reference:
+  SEV-ES Guest-Hypervisor Communication Block Standardization
+
+**/
+
+#ifndef __GHCB_H__
+#define __GHCB_H__
+
+#include 
+#include 
+
+#define UD_EXCEPTION  6
+#define GP_EXCEPTION 13
+
+#define GHCB_VERSION_MIN 1
+#define GHCB_VERSION_MAX 1
+
+#define GHCB_STANDARD_USAGE  0
+
+typedef enum {
+  SvmExitDr7Read   = 0x27,
+  SvmExitDr7Write  = 0x37,
+  SvmExitRdtsc = 0x6E,
+  SvmExitRdpmc,
+  SvmExitCpuid = 0x72,
+  SvmExitInvd  = 0x76,
+  SvmExitIoioProt  = 0x7B,
+  SvmExitMsr,
+  SvmExitVmmCall   = 0x81,
+  SvmExitRdtscp= 0x87,
+  SvmExitWbinvd= 0x89,
+  SvmExitMonitor,
+  SvmExitMwait,
+  SvmExitNpf   = 0x400,
+
+  // VMG special exits
+  SvmExitMmioRead  = 0x8001,
+  SvmExitMmioWrite,
+  SvmExitNmiComplete,
+  SvmExitApResetHold,
+  SvmExitApJumpTable,
+
+  SvmExitUnsupported   = 0x8000,
+} SVM_EXITCODE;
+
+typedef enum {
+  GhcbCpl  = 25,
+  GhcbRflags   = 46,
+  GhcbRip,
+  GhcbRsp  = 59,
+  GhcbRax  = 63,
+  GhcbRcx  = 97,
+  GhcbRdx,
+  GhcbRbx,
+  GhcbRbp  = 101,
+  GhcbRsi,
+  GhcbRdi,
+  GhcbR8,
+  GhcbR9,
+  GhcbR10,
+  GhcbR11,
+  GhcbR12,
+  GhcbR13,
+  GhcbR14,
+  GhcbR15,
+  GhcbXCr0 = 125,
+} GHCB_REGISTER;
+
+typedef struct {
+  UINT8  Reserved1[203];
+  UINT8  Cpl;
+  UINT8  Reserved2[148];
+  UINT64 Dr7;
+  UINT8  Reserved3[144];
+  UINT64 Rax;
+  UINT8  Reserved4[264];
+  UINT64 Rcx;
+  UINT64 Rdx;
+  UINT64 Rbx;
+  UINT8  Reserved5[112];
+  UINT64 SwExitCode;
+  UINT64 SwExitInfo1;
+  UINT64 SwExitInfo2;
+  UINT64 SwScratch;
+  UINT8  Reserved6[56];
+  UINT64 XCr0;
+  UINT8  ValidBitmap[16];
+  UINT64 X87StateGpa;
+  UINT8  Reserved7[1016];
+} __attribute__ ((__packed__)) GHCB_SAVE_AREA;
+
+typedef struct {
+  GHCB_SAVE_AREA SaveArea;
+  UINT8  SharedBuffer[2032];
+  UINT8  Reserved1[10];
+  UINT16 ProtocolVersion;
+  UINT32 GhcbUsage;
+} __attribute__ ((__packed__)) __attribute__ ((aligned(SIZE_4KB))) GHCB;
+
+typedef union {
+  struct {
+UINT32  Lower32Bits;
+UINT32  Upper32Bits;
+  } Elements;
+
+  UINT64Uint64;
+} GHCB_EXIT_INFO;
+
+typedef union {
+  struct {
+UINT32  Vector:8;
+UINT32  Type:3;
+UINT32  ErrorCodeValid:1;
+UINT32  Rsvd:19;
+UINT32  Valid:1;
+UINT32  ErrorCode;
+  } Elements;
+
+  UINT64Uint64;
+} GHCB_EVENT_INJECTION;
+
+#define GHCB_EVENT_INJECTION_TYPE_INT0
+#define GHCB_EVENT_INJECTION_TYPE_NMI2
+#define GHCB_EVENT_INJECTION_TYPE_EXCEPTION  3
+#define GHCB_EVENT_INJECTION_TYPE_SOFT_INT   4
+
+#endif
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53750): https://edk2.groups.io/g/devel/message/53750
Mute This Topic: https://groups.io/mt/70984921/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 11/40] UefiCpuPkg/CpuExceptionHandler: Add support for CPUID NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a CPUID intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Add support to construct the required GHCB values to support a CPUID NAE
event. Additionally, CPUID 0x_000d requires XCR0 to be supplied in
the GHCB, so add support to issue the XGETBV instruction.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 49609c5ef22f..90541c9a0390 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -11,6 +11,8 @@
 #include 
 #include "AMDSevVcCommon.h"
 
+#define CR4_OSXSAVE (1 << 18)
+
 typedef enum {
   LongMode64Bit= 0,
   LongModeCompat32Bit,
@@ -494,6 +496,44 @@ IoioExit (
   return 0;
 }
 
+STATIC
+UINT64
+CpuidExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  Ghcb->SaveArea.Rax = Regs->Rax;
+  GhcbSetRegValid (Ghcb, GhcbRax);
+  Ghcb->SaveArea.Rcx = Regs->Rcx;
+  GhcbSetRegValid (Ghcb, GhcbRcx);
+  if (Regs->Rax == 0x000d) {
+Ghcb->SaveArea.XCr0 = (AsmReadCr4 () & CR4_OSXSAVE) ? AsmXGetBv (0) : 1;
+GhcbSetRegValid (Ghcb, GhcbXCr0);
+  }
+
+  Status = VmgExit (Ghcb, SvmExitCpuid, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+  !GhcbIsRegValid (Ghcb, GhcbRbx) ||
+  !GhcbIsRegValid (Ghcb, GhcbRcx) ||
+  !GhcbIsRegValid (Ghcb, GhcbRdx)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+  Regs->Rbx = Ghcb->SaveArea.Rbx;
+  Regs->Rcx = Ghcb->SaveArea.Rcx;
+  Regs->Rdx = Ghcb->SaveArea.Rdx;
+
+  return 0;
+}
+
 UINTN
 DoVcCommon (
   GHCB*Ghcb,
@@ -510,6 +550,10 @@ DoVcCommon (
 
   ExitCode = Regs->ExceptionData;
   switch (ExitCode) {
+  case SvmExitCpuid:
+NaeExit = CpuidExit;
+break;
+
   case SvmExitIoioProt:
 NaeExit = IoioExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53758): https://edk2.groups.io/g/devel/message/53758
Mute This Topic: https://groups.io/mt/70984933/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 10/40] UefiCpuPkg/CpuExceptionHandler: Support string IO for IOIO_PROT NAE events

[Lendacky, Thomas]

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

Add support to the #VC exception handler to handle string IO. This
requires expanding the IO instruction parsing to recognize string based
IO instructions as well as preparing an un-encrypted buffer to be used
to transfer (either to or from the guest) the string contents for the IO
operation. The SW_EXITINFO2 and SW_SCRATCH fields of the GHCB are set
appropriately for the operation. Multiple VMGEXIT invocations may be
needed to complete the string IO operation.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 78 ---
 1 file changed, 68 insertions(+), 10 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 48eb5c2358ed..49609c5ef22f 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -321,6 +321,22 @@ IoioExitInfo (
   UINT64  ExitInfo = 0;
 
   switch (*(InstructionData->OpCodes)) {
+  // INS opcodes
+  case 0x6C:
+  case 0x6D:
+ExitInfo |= IOIO_TYPE_INS;
+ExitInfo |= IOIO_SEG_ES;
+ExitInfo |= ((Regs->Rdx & 0x) << 16);
+break;
+
+  // OUTS opcodes
+  case 0x6E:
+  case 0x6F:
+ExitInfo |= IOIO_TYPE_OUTS;
+ExitInfo |= IOIO_SEG_DS;
+ExitInfo |= ((Regs->Rdx & 0x) << 16);
+break;
+
   // IN immediate opcodes
   case 0xE4:
   case 0xE5:
@@ -358,6 +374,8 @@ IoioExitInfo (
   }
 
   switch (*(InstructionData->OpCodes)) {
+  case 0x6C:
+  case 0x6E:
   case 0xE4:
   case 0xE6:
   case 0xEC:
@@ -404,7 +422,8 @@ IoioExit (
   SEV_ES_INSTRUCTION_DATA  *InstructionData
   )
 {
-  UINT64  ExitInfo1, Status;
+  UINT64   ExitInfo1, ExitInfo2, Status;
+  BOOLEAN  String;
 
   ExitInfo1 = IoioExitInfo (Regs, InstructionData);
   if (!ExitInfo1) {
@@ -421,16 +440,55 @@ IoioExit (
   Ghcb->SaveArea.Rax = Regs->Rax;
   GhcbSetRegValid (Ghcb, GhcbRax);
 
-  Status = VmgExit (Ghcb, SvmExitIoioProt, ExitInfo1, 0);
-  if (Status) {
-return Status;
-  }
-
-  if (ExitInfo1 & IOIO_TYPE_IN) {
-if (!GhcbIsRegValid (Ghcb, GhcbRax)) {
-  return UnsupportedExit (Ghcb, Regs, InstructionData);
+  String = (ExitInfo1 & IOIO_TYPE_STR) ? TRUE : FALSE;
+  if (String) {
+UINTN  IoBytes, VmgExitBytes;
+UINTN  GhcbCount, OpCount;
+
+Status = 0;
+
+IoBytes = (ExitInfo1 >> 4) & 0x7;
+GhcbCount = sizeof (Ghcb->SharedBuffer) / IoBytes;
+
+OpCount = (ExitInfo1 & IOIO_REP) ? Regs->Rcx : 1;
+while (OpCount) {
+  ExitInfo2 = MIN (OpCount, GhcbCount);
+  VmgExitBytes = ExitInfo2 * IoBytes;
+
+  if (!(ExitInfo1 & IOIO_TYPE_IN)) {
+CopyMem (Ghcb->SharedBuffer, (VOID *) Regs->Rsi, VmgExitBytes);
+Regs->Rsi += VmgExitBytes;
+  }
+
+  Ghcb->SaveArea.SwScratch = (UINT64) Ghcb->SharedBuffer;
+  Status = VmgExit (Ghcb, SvmExitIoioProt, ExitInfo1, ExitInfo2);
+  if (Status) {
+return Status;
+  }
+
+  if (ExitInfo1 & IOIO_TYPE_IN) {
+CopyMem ((VOID *) Regs->Rdi, Ghcb->SharedBuffer, VmgExitBytes);
+Regs->Rdi += VmgExitBytes;
+  }
+
+  if (ExitInfo1 & IOIO_REP) {
+Regs->Rcx -= ExitInfo2;
+  }
+
+  OpCount -= ExitInfo2;
+}
+  } else {
+Status = VmgExit (Ghcb, SvmExitIoioProt, ExitInfo1, 0);
+if (Status) {
+  return Status;
+}
+
+if (ExitInfo1 & IOIO_TYPE_IN) {
+  if (!GhcbIsRegValid (Ghcb, GhcbRax)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
 }
-Regs->Rax = Ghcb->SaveArea.Rax;
   }
 
   return 0;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53757): https://edk2.groups.io/g/devel/message/53757
Mute This Topic: https://groups.io/mt/70984931/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 06/40] MdePkg/BaseLib: Add support for the VMGEXIT instruction

[Lendacky, Thomas]

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

VMGEXIT is a new instruction used for Hypervisor/Guest communication when
running as an SEV-ES guest. A VMGEXIT will cause an automatic exit (AE)
to occur, resulting in a #VMEXIT with an exit code value of 0x403.

Provide the necessary support to execute the VMGEXIT instruction, which
is "rep; vmmcall".

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdePkg/Library/BaseLib/BaseLib.inf   |  2 ++
 MdePkg/Include/Library/BaseLib.h | 14 +
 MdePkg/Library/BaseLib/Ia32/GccInline.c  | 17 +++
 MdePkg/Library/BaseLib/X64/GccInline.c   | 17 +++
 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm | 37 
 MdePkg/Library/BaseLib/X64/VmgExit.nasm  | 32 
 6 files changed, 119 insertions(+)
 create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
 create mode 100644 MdePkg/Library/BaseLib/X64/VmgExit.nasm

diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
b/MdePkg/Library/BaseLib/BaseLib.inf
index d7a1dd017e95..62a09197b8a8 100644
--- a/MdePkg/Library/BaseLib/BaseLib.inf
+++ b/MdePkg/Library/BaseLib/BaseLib.inf
@@ -153,6 +153,7 @@ [Sources.Ia32]
   Ia32/EnableCache.c | MSFT
   Ia32/DisableCache.c | MSFT
   Ia32/XGetBv.nasm | MSFT
+  Ia32/VmgExit.nasm | MSFT
 
 
   Ia32/GccInline.c | GCC
@@ -288,6 +289,7 @@ [Sources.X64]
   X64/ReadCr0.nasm| MSFT
   X64/ReadEflags.nasm| MSFT
   X64/XGetBv.nasm | MSFT
+  X64/VmgExit.nasm | MSFT
 
 
   X64/Non-existing.c
diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index d0cbb52ed8f9..99fff8af5a3c 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -7906,6 +7906,20 @@ AsmXGetBv (
   );
 
 
+/**
+  Executes a VMGEXIT instruction (VMMCALL with a REP prefix)
+
+  Executes a VMGEXIT instruction. This function is only available on IA-32 and
+  x64.
+
+**/
+VOID
+EFIAPI
+AsmVmgExit (
+  VOID
+  );
+
+
 /**
   Patch the immediate operand of an IA32 or X64 instruction such that the byte,
   word, dword or qword operand is encoded at the end of the instruction's
diff --git a/MdePkg/Library/BaseLib/Ia32/GccInline.c 
b/MdePkg/Library/BaseLib/Ia32/GccInline.c
index 591f0bb0e097..ee8c62c79c93 100644
--- a/MdePkg/Library/BaseLib/Ia32/GccInline.c
+++ b/MdePkg/Library/BaseLib/Ia32/GccInline.c
@@ -1791,3 +1791,20 @@ AsmXGetBv (
 }
 
 
+/**
+  Executes a VMGEXIT instruction.
+
+  Executes a VMGEXIT instruction. This function is only available on IA-32 and
+  X64.
+
+**/
+VOID
+EFIAPI
+AsmVmgExit (
+  VOID
+  )
+{
+  __asm__ __volatile__ ("rep; vmmcall":::"memory");
+}
+
+
diff --git a/MdePkg/Library/BaseLib/X64/GccInline.c 
b/MdePkg/Library/BaseLib/X64/GccInline.c
index 3eed1205adb2..277974eff9ee 100644
--- a/MdePkg/Library/BaseLib/X64/GccInline.c
+++ b/MdePkg/Library/BaseLib/X64/GccInline.c
@@ -1828,3 +1828,20 @@ AsmXGetBv (
 }
 
 
+/**
+  Executes a VMGEXIT instruction.
+
+  Executes a VMGEXIT instruction. This function is only available on IA-32 and
+  X64.
+
+**/
+VOID
+EFIAPI
+AsmVmgExit (
+  VOID
+  )
+{
+  __asm__ __volatile__ ("rep; vmmcall":::"memory");
+}
+
+
diff --git a/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm 
b/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
new file mode 100644
index ..85e6260b4e2c
--- /dev/null
+++ b/MdePkg/Library/BaseLib/Ia32/VmgExit.nasm
@@ -0,0 +1,37 @@
+;--
+;
+; Copyright (c) 2019, Advanced Micro Devices, Inc. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+;   VmgExit.Asm
+;
+; Abstract:
+;
+;   AsmVmgExit function
+;
+; Notes:
+;
+;--
+
+SECTION .text
+
+;--
+; VOID
+; EFIAPI
+; AsmVmgExit (
+;   VOID
+;   );
+;--
+global ASM_PFX(AsmVmgExit)
+ASM_PFX(AsmVmgExit):
+;
+; NASM doesn't support the vmmcall instruction in 32-bit mode, so work around
+; this by temporarily switching to 64-bit mode.
+;
+BITS64
+rep vmmcall
+BITS32
+ret
+
diff --git a/MdePkg/Library/BaseLib/X64/VmgExit.nasm 
b/MdePkg/Library/BaseLib/X64/VmgExit.nasm
new file mode 100644
index ..400d0302c4a3
--- /dev/null
+++ b/MdePkg/Library/BaseLib/X64/VmgExit.nasm
@@ -0,0 +1,32 @@
+;--
+;
+; Copyright (c) 2019, Advanced Micro Devices, Inc. All rights reserved.
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+; Module Name:
+;
+;   VmgExit.Asm
+;
+; Abstract:
+;
+;   AsmVmgExit function
+;
+; Notes:
+;
+;--
+
+DEFAULT REL
+SECTION .text
+
+;--
+; VOID
+; EFIAPI
+; 

[edk2-devel] [PATCH v4 01/40] MdePkg: Create PCDs to be used in support of SEV-ES

[Lendacky, Thomas]

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

Two new fixed PCDs are needed to support SEV-ES under OVMF:
  - PcdSecGhcbBase  UINT64 value that is the base address of the GHCB
used during the SEC phase.
  - PcdSecGhcbSize  UINT64 value that is the size, in bytes, of the GHCB
area used during the SEC phase.

Three new dynamic PCDs are needed to support SEV-ES under OVMF:
  - PcdSevEsIsEnabled: BOOLEAN value used to indicate if SEV-ES is enabled
  - PcdGhcbBase:   UINT64 value that is the base address of the GHCB
   allocation.
  - PcdGhcbSize:   UINT64 value that is the size, in bytes, of the
   GHCB allocation (size is dependent on the number of
   APs).

Cc: Jian J Wang 
Cc: Hao A Wu 
Signed-off-by: Tom Lendacky 
---
 MdeModulePkg/MdeModulePkg.dec |  9 +
 UefiCpuPkg/UefiCpuPkg.dec | 14 ++
 2 files changed, 23 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index e840cebe2eae..4474c4d5bd43 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -2065,6 +2065,15 @@ [PcdsDynamic, PcdsDynamicEx]
   # @Prompt If there is any test key used by the platform.
   gEfiMdeModulePkgTokenSpaceGuid.PcdTestKeyUsed|FALSE|BOOLEAN|0x00030003
 
+  ## This dynamic PCD holds the base address of the GHCB pool allocation.
+  # @Prompt GHCB Pool Base Address
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0|UINT64|0x00030007
+
+  ## This dynamic PCD holds the total size of the GHCB pool allocation.
+  #  The amount of memory allocated for GHCBs is dependent on the number of 
APs.
+  # @Prompt GHCB Pool Size
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0|UINT64|0x00030008
+
 [PcdsDynamicEx]
   ## This dynamic PCD enables the default variable setting.
   #  Its value is the default store ID value. The default value is zero as 
Standard default.
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index a6ebdde1cfb6..005703d8a3e7 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -161,6 +161,14 @@ [PcdsFixedAtBuild]
   # @Prompt Specify the count of pre allocated SMM MP tokens per chunk.
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmMpTokenCountPerChunk|64|UINT32|0x30002002
 
+  ## The base address of the SEC GHCB page used by SEV-ES.
+  # @Prompt SEC GHCB Base Address
+  gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbBase|0|UINT32|0x30002003
+
+  ## The total size of the SEC GHCB page used by SEV-ES.
+  # @Prompt SEC GHCB Size
+  gUefiCpuPkgTokenSpaceGuid.PcdSecGhcbSize|0|UINT32|0x30002004
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## This value is the CPU Local APIC base address, which aligns the address 
on a 4-KByte boundary.
   # @Prompt Configure base address of CPU Local APIC
@@ -367,5 +375,11 @@ [PcdsDynamic, PcdsDynamicEx]
   # @ValidRange  0x8001 | 0 - 1
   gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceOutputScheme|0x0|UINT8|0x6015
 
+  ## This dynamic PCD indicates whether SEV-ES is enabled
+  #   TRUE  - SEV-ES is enabled
+  #   FALSE - SEV-ES is not enabled
+  # @Prompt SEV-ES Status
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsIsEnabled|FALSE|BOOLEAN|0x6016
+
 [UserExtensions.TianoCore."ExtraFiles"]
   UefiCpuPkgExtra.uni
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53748): https://edk2.groups.io/g/devel/message/53748
Mute This Topic: https://groups.io/mt/70984918/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 16/40] UefiCpuPkg/CpuExceptionHandler: Add support for RDPMC NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a RDPMC intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 32 +++
 1 file changed, 32 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 552fe2e1a343..c2bc213e602c 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -894,6 +894,34 @@ CpuidExit (
   return 0;
 }
 
+STATIC
+UINT64
+RdpmcExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  Ghcb->SaveArea.Rcx = Regs->Rcx;
+  GhcbSetRegValid (Ghcb, GhcbRcx);
+
+  Status = VmgExit (Ghcb, SvmExitRdpmc, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+  !GhcbIsRegValid (Ghcb, GhcbRdx)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+  Regs->Rdx = Ghcb->SaveArea.Rdx;
+
+  return 0;
+}
+
 STATIC
 UINT64
 RdtscExit (
@@ -939,6 +967,10 @@ DoVcCommon (
 NaeExit = RdtscExit;
 break;
 
+  case SvmExitRdpmc:
+NaeExit = RdpmcExit;
+break;
+
   case SvmExitCpuid:
 NaeExit = CpuidExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53763): https://edk2.groups.io/g/devel/message/53763
Mute This Topic: https://groups.io/mt/70984939/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 04/40] MdeModulePkg/DxeIplPeim: Support GHCB pages when creating page tables

[Lendacky, Thomas]

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

GHCB pages must be mapped as shared pages, so modify the process of
creating identity mapped pagetable entries so that GHCB entries are
created without the encryption bit set.

Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Dandan Bi 
Cc: Liming Gao 
Signed-off-by: Tom Lendacky 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf   |  2 +
 .../Core/DxeIplPeim/X64/VirtualMemory.h   | 12 -
 .../Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  4 +-
 .../Core/DxeIplPeim/X64/DxeLoadFunc.c | 11 -
 .../Core/DxeIplPeim/X64/VirtualMemory.c   | 49 ++-
 5 files changed, 62 insertions(+), 16 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index 98bc17fc9d1f..5e6b78e295e6 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -111,6 +111,8 @@ [Pcd.IA32,Pcd.X64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse5LevelPageTable  ## 
SOMETIMES_CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize## 
CONSUMES
 
 [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
index 2d0493f109e8..6b7c38a441d6 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
@@ -201,6 +201,8 @@ EnableExecuteDisableBit (
   @param[in, out] PageEntry2M   Pointer to 2M page entry.
   @param[in]  StackBase Stack base address.
   @param[in]  StackSize Stack size.
+  @param[in]  GhcbBase  GHCB page area base address.
+  @param[in]  GhcbSize  GHCB page area size.
 
 **/
 VOID
@@ -208,7 +210,9 @@ Split2MPageTo4K (
   IN EFI_PHYSICAL_ADDRESS   PhysicalAddress,
   IN OUT UINT64 *PageEntry2M,
   IN EFI_PHYSICAL_ADDRESS   StackBase,
-  IN UINTN  StackSize
+  IN UINTN  StackSize,
+  IN EFI_PHYSICAL_ADDRESS   GhcbBase,
+  IN UINTN  GhcbSize
   );
 
 /**
@@ -217,6 +221,8 @@ Split2MPageTo4K (
 
   @param[in] StackBase  Stack base address.
   @param[in] StackSize  Stack size.
+  @param[in] GhcbBase   GHCB page area base address.
+  @param[in] GhcbSize   GHCB page area size.
 
   @return The address of 4 level page map.
 
@@ -224,7 +230,9 @@ Split2MPageTo4K (
 UINTN
 CreateIdentityMappingPageTables (
   IN EFI_PHYSICAL_ADDRESS   StackBase,
-  IN UINTN  StackSize
+  IN UINTN  StackSize,
+  IN EFI_PHYSICAL_ADDRESS   GhcbBase,
+  IN UINTN  GhcbkSize
   );
 
 
diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index 6e8ca824d469..284b34818ca7 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -123,7 +123,7 @@ Create4GPageTablesIa32Pae (
 //
 // Need to split this 2M page that covers stack range.
 //
-Split2MPageTo4K (PhysicalAddress, (UINT64 *) PageDirectoryEntry, 
StackBase, StackSize);
+Split2MPageTo4K (PhysicalAddress, (UINT64 *) PageDirectoryEntry, 
StackBase, StackSize, 0, 0);
   } else {
 //
 // Fill in the Page Directory entries
@@ -282,7 +282,7 @@ HandOffToDxeCore (
 //
 // Create page table and save PageMapLevel4 to CR3
 //
-PageTables = CreateIdentityMappingPageTables (BaseOfStack, STACK_SIZE);
+PageTables = CreateIdentityMappingPageTables (BaseOfStack, STACK_SIZE, 0, 
0);
 
 //
 // End of PEI phase signal
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
index f465eb1d8ac4..156a477d8467 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c
@@ -35,6 +35,8 @@ HandOffToDxeCore (
   UINT32  Index;
   EFI_VECTOR_HANDOFF_INFO *VectorInfo;
   EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
+  VOID*GhcbBase;
+  UINTN   GhcbSize;
 
   //
   // Clear page 0 and mark it as allocated if NULL pointer detection is 
enabled.
@@ -81,12 +83,19 @@ HandOffToDxeCore (
   TopOfStack = (VOID *) ((UINTN) BaseOfStack + EFI_SIZE_TO_PAGES (STACK_SIZE) 
* EFI_PAGE_SIZE - CPU_STACK_ALIGNMENT);
   TopOfStack = ALIGN_POINTER (TopOfStack, CPU_STACK_ALIGNMENT);
 
+  //
+  // Get the address and 

[edk2-devel] [PATCH v4 21/40] UefiCpuPkg/CpuExceptionHandler: Add support for MWAIT/MWAITX NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a MWAIT/MWAITX intercept generates a #VC exception.
VMGEXIT must be used to allow the hypervisor to handle this intercept.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 93341a647e48..4318014ceb45 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -591,6 +591,31 @@ MmioExit (
   return Status;
 }
 
+STATIC
+UINT64
+MwaitExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  DecodeModRm (Regs, InstructionData);
+
+  Ghcb->SaveArea.Rax = Regs->Rax;
+  GhcbSetRegValid (Ghcb, GhcbRax);
+  Ghcb->SaveArea.Rcx = Regs->Rcx;
+  GhcbSetRegValid (Ghcb, GhcbRcx);
+
+  Status = VmgExit (Ghcb, SvmExitMwait, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  return 0;
+}
+
 STATIC
 UINT64
 MonitorExit (
@@ -1107,6 +1132,10 @@ DoVcCommon (
 NaeExit = MonitorExit;
 break;
 
+  case SvmExitMwait:
+NaeExit = MwaitExit;
+break;
+
   case SvmExitNpf:
 NaeExit = MmioExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53768): https://edk2.groups.io/g/devel/message/53768
Mute This Topic: https://groups.io/mt/70984944/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 22/40] UefiCpuPkg/CpuExceptionHandler: Add support for DR7 Read/Write NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
The #VC handler must provide special support to the guest for this. On
a DR7 write, the #VC handler must cache the value and issue a VMGEXIT
to notify the hypervisor of the write. However, the #VC handler must
not actually set the value of the DR7 register. On a DR7 read, the #VC
handler must return the cached value of the DR7 register to the guest.
VMGEXIT is not invoked for a DR7 register read.

To avoid exception recursion, a #VC exception will not try to read and
push the actual debug registers into the EFI_SYSTEM_CONTEXT_X64 struct
and instead push zeroes. The #VC exception handler does not make use of
the debug registers from saved context.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 68 +++
 .../X64/ExceptionHandlerAsm.nasm  | 17 +
 2 files changed, 85 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 4318014ceb45..2932e7341345 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -13,6 +13,12 @@
 
 #define CR4_OSXSAVE (1 << 18)
 
+#define DR7_RESET_VALUE 0x400
+typedef struct {
+  BOOLEAN  Dr7Cached;
+  UINT64   Dr7;
+} SEV_ES_PER_CPU_DATA;
+
 typedef enum {
   LongMode64Bit= 0,
   LongModeCompat32Bit,
@@ -1076,6 +1082,60 @@ RdtscExit (
   return 0;
 }
 
+STATIC
+UINT64
+Dr7WriteExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext = >Ext;
+  SEV_ES_PER_CPU_DATA*SevEsData = (SEV_ES_PER_CPU_DATA *) (Ghcb + 
1);
+  INTN   *Register;
+  UINT64 Status;
+
+  DecodeModRm (Regs, InstructionData);
+
+  /* MOV DRn always treats MOD == 3 no matter how encoded */
+  Register = GetRegisterPointer (Regs, Ext->ModRm.Rm);
+
+  /* Using a value of 0 for ExitInfo1 means RAX holds the value */
+  Ghcb->SaveArea.Rax = *Register;
+  GhcbSetRegValid (Ghcb, GhcbRax);
+
+  Status = VmgExit (Ghcb, SvmExitDr7Write, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  SevEsData->Dr7 = *Register;
+  SevEsData->Dr7Cached = TRUE;
+
+  return 0;
+}
+
+STATIC
+UINT64
+Dr7ReadExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext = >Ext;
+  SEV_ES_PER_CPU_DATA*SevEsData = (SEV_ES_PER_CPU_DATA *) (Ghcb + 
1);
+  INTN   *Register;
+
+  DecodeModRm (Regs, InstructionData);
+
+  /* MOV DRn always treats MOD == 3 no matter how encoded */
+  Register = GetRegisterPointer (Regs, Ext->ModRm.Rm);
+  *Register = (SevEsData->Dr7Cached) ? SevEsData->Dr7 : DR7_RESET_VALUE;
+
+  return 0;
+}
+
 UINTN
 DoVcCommon (
   GHCB*Ghcb,
@@ -1092,6 +1152,14 @@ DoVcCommon (
 
   ExitCode = Regs->ExceptionData;
   switch (ExitCode) {
+  case SvmExitDr7Read:
+NaeExit = Dr7ReadExit;
+break;
+
+  case SvmExitDr7Write:
+NaeExit = Dr7WriteExit;
+break;
+
   case SvmExitRdtsc:
 NaeExit = RdtscExit;
 break;
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
index 19198f273137..26cae56cc5cf 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
@@ -18,6 +18,8 @@
 ; CommonExceptionHandler()
 ;
 
+%define VC_EXCEPTION 29
+
 extern ASM_PFX(mErrorCodeFlag); Error code flags for exceptions
 extern ASM_PFX(mDoFarReturnFlag)  ; Do far return flag
 extern ASM_PFX(CommonExceptionHandler)
@@ -225,6 +227,9 @@ HasErrorCode:
 pushrax
 
 ;; UINT64  Dr0, Dr1, Dr2, Dr3, Dr6, Dr7;
+cmp qword [rbp + 8], VC_EXCEPTION
+je  VcDebugRegs  ; For SEV-ES (#VC) Debug registers ignored
+
 mov rax, dr7
 pushrax
 mov rax, dr6
@@ -237,7 +242,19 @@ HasErrorCode:
 pushrax
 mov rax, dr0
 pushrax
+jmp DrFinish
 
+VcDebugRegs:
+;; UINT64  Dr0, Dr1, Dr2, Dr3, Dr6, Dr7 are skipped for #VC to avoid exception 
recursion
+xor rax, rax
+pushrax
+pushrax
+pushrax
+pushrax
+pushrax
+pushrax
+
+DrFinish:
 ;; FX_SAVE_STATE_X64 FxSaveState;
 sub rsp, 512
 mov rdi, rsp
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53769): https://edk2.groups.io/g/devel/message/53769
Mute This Topic: https://groups.io/mt/70984945/21656
Group Owner: devel+ow...@edk2.groups.io

[edk2-devel] [PATCH v4 23/40] OvmfPkg/MemEncryptSevLib: Add an SEV-ES guest indicator function

[Lendacky, Thomas]

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

Create a function that can be used to determine if the VM is running
as an SEV-ES guest.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 OvmfPkg/Include/Library/MemEncryptSevLib.h| 12 +++
 .../MemEncryptSevLibInternal.c| 75 ---
 2 files changed, 60 insertions(+), 27 deletions(-)

diff --git a/OvmfPkg/Include/Library/MemEncryptSevLib.h 
b/OvmfPkg/Include/Library/MemEncryptSevLib.h
index 64dd6977b0f8..a50a0de9c870 100644
--- a/OvmfPkg/Include/Library/MemEncryptSevLib.h
+++ b/OvmfPkg/Include/Library/MemEncryptSevLib.h
@@ -13,6 +13,18 @@
 
 #include 
 
+/**
+  Returns a boolean to indicate whether SEV-ES is enabled
+
+  @retval TRUE   SEV-ES is enabled
+  @retval FALSE  SEV-ES is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsIsEnabled (
+  VOID
+  );
+
 /**
   Returns a boolean to indicate whether SEV is enabled
 
diff --git a/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c 
b/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
index 96a66e373f11..c859bb141963 100644
--- a/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
+++ b/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
@@ -20,19 +20,17 @@
 #include 
 
 STATIC BOOLEAN mSevStatus = FALSE;
+STATIC BOOLEAN mSevEsStatus = FALSE;
 STATIC BOOLEAN mSevStatusChecked = FALSE;
 
 /**
 
-  Returns a boolean to indicate whether SEV is enabled
-
-  @retval TRUE   SEV is enabled
-  @retval FALSE  SEV is not enabled
+  Reads and sets the status of SEV features
   **/
 STATIC
-BOOLEAN
+VOID
 EFIAPI
-InternalMemEncryptSevIsEnabled (
+InternalMemEncryptSevStatus (
   VOID
   )
 {
@@ -56,32 +54,55 @@ InternalMemEncryptSevIsEnabled (
   //
   Msr.Uint32 = AsmReadMsr32 (MSR_SEV_STATUS);
   if (Msr.Bits.SevBit) {
-return TRUE;
+mSevStatus = TRUE;
+  }
+
+  //
+  // Check MSR_0xC0010131 Bit 1 (Sev-Es Enabled)
+  //
+  if (Msr.Bits.SevEsBit) {
+mSevEsStatus = TRUE;
   }
 }
   }
 
-  return FALSE;
-}
-
-/**
-  Returns a boolean to indicate whether SEV is enabled
-
-  @retval TRUE   SEV is enabled
-  @retval FALSE  SEV is not enabled
-**/
-BOOLEAN
-EFIAPI
-MemEncryptSevIsEnabled (
-  VOID
-  )
-{
-  if (mSevStatusChecked) {
-return mSevStatus;
-  }
-
-  mSevStatus = InternalMemEncryptSevIsEnabled();
   mSevStatusChecked = TRUE;
+}
+
+/**
+  Returns a boolean to indicate whether SEV-ES is enabled
+
+  @retval TRUE   SEV-ES is enabled
+  @retval FALSE  SEV-ES is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevEsIsEnabled (
+  VOID
+  )
+{
+  if (!mSevStatusChecked) {
+InternalMemEncryptSevStatus();
+  }
+
+  return mSevEsStatus;
+}
+
+/**
+  Returns a boolean to indicate whether SEV is enabled
+
+  @retval TRUE   SEV is enabled
+  @retval FALSE  SEV is not enabled
+**/
+BOOLEAN
+EFIAPI
+MemEncryptSevIsEnabled (
+  VOID
+  )
+{
+  if (!mSevStatusChecked) {
+InternalMemEncryptSevStatus();
+  }
 
   return mSevStatus;
 }
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53770): https://edk2.groups.io/g/devel/message/53770
Mute This Topic: https://groups.io/mt/70984946/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 15/40] UefiCpuPkg/CpuExceptionHandler: Add support for RDTSC NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a RDTSC intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 03003e9113fa..552fe2e1a343 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -894,6 +894,31 @@ CpuidExit (
   return 0;
 }
 
+STATIC
+UINT64
+RdtscExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  Status = VmgExit (Ghcb, SvmExitRdtsc, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+  !GhcbIsRegValid (Ghcb, GhcbRdx)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+  Regs->Rdx = Ghcb->SaveArea.Rdx;
+
+  return 0;
+}
+
 UINTN
 DoVcCommon (
   GHCB*Ghcb,
@@ -910,6 +935,10 @@ DoVcCommon (
 
   ExitCode = Regs->ExceptionData;
   switch (ExitCode) {
+  case SvmExitRdtsc:
+NaeExit = RdtscExit;
+break;
+
   case SvmExitCpuid:
 NaeExit = CpuidExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53762): https://edk2.groups.io/g/devel/message/53762
Mute This Topic: https://groups.io/mt/70984938/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 19/40] UefiCpuPkg/CpuExceptionHandler: Add support for RDTSCP NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a RDTSCP intercept generates a #VC exception. VMGEXIT must be
used to allow the hypervisor to handle this intercept.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index 734c2bbeb989..f18fbe97e147 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -609,6 +609,35 @@ WbinvdExit (
   return 0;
 }
 
+STATIC
+UINT64
+RdtscpExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  DecodeModRm (Regs, InstructionData);
+
+  Status = VmgExit (Ghcb, SvmExitRdtscp, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax) ||
+  !GhcbIsRegValid (Ghcb, GhcbRcx) ||
+  !GhcbIsRegValid (Ghcb, GhcbRdx)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+  Regs->Rcx = Ghcb->SaveArea.Rcx;
+  Regs->Rdx = Ghcb->SaveArea.Rdx;
+
+  return 0;
+}
+
 STATIC
 UINT64
 VmmCallExit (
@@ -1039,6 +1068,10 @@ DoVcCommon (
 NaeExit = VmmCallExit;
 break;
 
+  case SvmExitRdtscp:
+NaeExit = RdtscpExit;
+break;
+
   case SvmExitWbinvd:
 NaeExit = WbinvdExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53766): https://edk2.groups.io/g/devel/message/53766
Mute This Topic: https://groups.io/mt/70984942/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v4 18/40] UefiCpuPkg/CpuExceptionHandler: Add support for VMMCALL NAE events

[Lendacky, Thomas]

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

Under SEV-ES, a VMMCALL intercept generates a #VC exception. VMGEXIT must
be used to allow the hypervisor to handle this intercept.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
 .../X64/AMDSevVcCommon.c  | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
index a47bba5ac1c1..734c2bbeb989 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
@@ -609,6 +609,36 @@ WbinvdExit (
   return 0;
 }
 
+STATIC
+UINT64
+VmmCallExit (
+  GHCB *Ghcb,
+  EFI_SYSTEM_CONTEXT_X64   *Regs,
+  SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  UINT64  Status;
+
+  DecodeModRm (Regs, InstructionData);
+
+  Ghcb->SaveArea.Rax = Regs->Rax;
+  GhcbSetRegValid (Ghcb, GhcbRax);
+  Ghcb->SaveArea.Cpl = (UINT8) (Regs->Cs & 0x3);
+  GhcbSetRegValid (Ghcb, GhcbCpl);
+
+  Status = VmgExit (Ghcb, SvmExitVmmCall, 0, 0);
+  if (Status) {
+return Status;
+  }
+
+  if (!GhcbIsRegValid (Ghcb, GhcbRax)) {
+return UnsupportedExit (Ghcb, Regs, InstructionData);
+  }
+  Regs->Rax = Ghcb->SaveArea.Rax;
+
+  return 0;
+}
+
 STATIC
 UINT64
 MsrExit (
@@ -1005,6 +1035,10 @@ DoVcCommon (
 NaeExit = MsrExit;
 break;
 
+  case SvmExitVmmCall:
+NaeExit = VmmCallExit;
+break;
+
   case SvmExitWbinvd:
 NaeExit = WbinvdExit;
 break;
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53765): https://edk2.groups.io/g/devel/message/53765
Mute This Topic: https://groups.io/mt/70984941/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Kevin@Insyde]

Bret,

We like the new functionality.

Our concern is our customers / we will need to modify all of the code that are 
consumers of EDKII_VARIABLE_LOCK_PROTOCOL to use the new protocols.  If you 
could review that issue we would be 100% happy.

Of course, that’s not always appropriate and we understand.

Kevin D Davis
Insyde Software

> On Feb 4, 2020, at 2:07 AM, Bret Barkelew via Groups.Io 
>  wrote:
> 
> 
> Expanding the audience beyond the RFC list….
> If no one has additional input, I’ll try to start formatting these as patches 
> later this week. Thanks!
>
> - Bret
>
> From: Bret Barkelew
> Sent: Tuesday, January 28, 2020 5:36 PM
> To: r...@edk2.groups.io
> Subject: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for 
> VariableLock Alternative
>
> All,
>
> VariablePolicy is our proposal for an expanded “VarLock-like” interface to 
> constrain and govern platform variables.
> I brought this up back in May to get initial comments on the interface and 
> implications of the interface and the approach. We implemented it in Mu over 
> the summer and it is not our defacto variable solution. It plugs in easily to 
> the existing variable infrastructure, but does want to control some of the 
> things that are currently managed by VarLock.
>
> There are also some tweaks that would be needed if this were desired to be 
> 100% optional code, but that’s no different than the current VarLock 
> implementation which has implementation code directly tied to some of the 
> common variable code.
>
> I’ve structured this RFC in two pieces:
> The Core piece represents the minimum changes needed to implement Variable 
> Policy and integrate it into Variable Services. It contains core driver code, 
> central libraries and headers, and DXE driver for the protocol interface.
> The Extras piece contains recommended code for a full-feature implementation 
> including a replacement for the VarLock protocol that enables existing code 
> to continue functioning as-is. It also contains unit and integration tests. 
> And as a bonus, it has a Rust implementation of the core business logic for 
> Variable Policy.
>
> The code can be found in the following two branches:
> https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_core
> https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra
>
> A convenient way to see all the changes in one place is to look at a 
> comparison:
> https://github.com/corthon/edk2/compare/master...corthon:personal/brbarkel/var_policy_rfc_core
> https://github.com/corthon/edk2/compare/personal/brbarkel/var_policy_rfc_core...corthon:personal/brbarkel/var_policy_rfc_extra
>
> There’s additional documentation in the PPT and DOC files in the core branch:
> https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Proposal%20Presentation.pptx
>  
> https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Whitepaper.docx
> (You’d need to download those to view.)
>
> My ultimate intention for this is to submit it as a series of patches for 
> acceptance into EDK2 as a replacement for VarLock. For now, I’m just looking 
> for initial feedback on any broad changes that might be needed to get this 
> into shape for more detailed code review on the devel list.
>
> Thanks!
>
> - Bret
>
>
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53794): https://edk2.groups.io/g/devel/message/53794
Mute This Topic: https://groups.io/mt/70968478/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] SecurityPkg: Fix incorrect return value in documentation

[Laszlo Ersek]

Hi Phil,

On 02/04/20 23:26, Philippe Mathieu-Daudé wrote:
> The DxeTpmMeasureBootHandler and DxeTpm2MeasureBootHandler handlers
> are SECURITY2_FILE_AUTHENTICATION_HANDLER prototype. This prototype
> can not return EFI_INVALID_PARAMETER.
> 
> The prototype documentation states it returns EFI_ACCESS_DENIED if:
> 
>   "The file specified by File and FileBuffer did not authenticate,
>and the platform policy dictates that the DXE Foundation may not
>use File."
> 
> Note in practice both functions return EFI_SECURITY_VIOLATION:
> 
>   "The file specified by DevicePath and FileBuffer did not
>authenticate, and the platform policy dictates that the file
>should be placed in the untrusted state. The image has been
>added to the file execution table."
> 
> Noticed while reviewing commit 6d57592740cdd0b6868baeef7929d6e6fef.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Chao Zhang 
> Signed-off-by: Philippe Mathieu-Daude 
> ---
>  .../Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c   | 2 +-
>  SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c 
> b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
> index 04b9b0d7fbf3..0c07f65c6835 100644
> --- a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
> +++ b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c
> @@ -384,7 +384,7 @@ Finish:
>and other exception operations.  The File parameter allows for possible 
> logging
>within the SAP of the driver.
>
> -  If File is NULL, then EFI_INVALID_PARAMETER is returned.
> +  If File is NULL, then EFI_ACCESS_DENIED is returned.
>
>If the file specified by File with an authentication status specified by
>AuthenticationStatus is safe for the DXE Core to use, then EFI_SUCCESS is 
> returned.

I've tried seeing where this code actually returns
EFI_INVALID_PARAMETER, but I can't find it. If File is NULL in
DxeTpm2MeasureBootHandler(), then first we seem to do:

  OrigDevicePathNode = DuplicateDevicePath (File);

which I believe will produce a NULL. Then we seem to pass this NULL
around a little bit, so I think there's a fair chance of crashing there.

I wonder if this code should be fixed, to check "File" in the first
place, and then return EFI_ACCESS_DENIED.

There are also some other places in the function that could apparently
return a wide array of error codes -- FvbProtocol->GetPhysicalAddress()
(EFI_UNSUPPORTED?), PeCoffLoaderGetImageInfo(), etc.

I do agree this patch is an improvement, however; at least it says what
*should* be returned. So with that in mind:

Acked-by: Laszlo Ersek 

Thanks
Laszlo

> diff --git a/SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c 
> b/SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c
> index 1f2eed29a1df..0dccbb66eb26 100644
> --- a/SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c
> +++ b/SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.c
> @@ -678,7 +678,7 @@ Finish:
>and other exception operations.  The File parameter allows for possible 
> logging
>within the SAP of the driver.
>
> -  If File is NULL, then EFI_INVALID_PARAMETER is returned.
> +  If File is NULL, then EFI_ACCESS_DENIED is returned.
>
>If the file specified by File with an authentication status specified by
>AuthenticationStatus is safe for the DXE Core to use, then EFI_SUCCESS is 
> returned.
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53793): https://edk2.groups.io/g/devel/message/53793
Mute This Topic: https://groups.io/mt/70984329/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Liming Gao]

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

Cc: Bob Feng 
Cc: Isaac Oram 
Signed-off-by: Liming Gao 
---
In V2, add the detail commit message.

 Silicon/Intel/Tools/FitGen/FitGen.c | 31 ---
 Silicon/Intel/Tools/FitGen/FitGen.h |  2 +-
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/Silicon/Intel/Tools/FitGen/FitGen.c 
b/Silicon/Intel/Tools/FitGen/FitGen.c
index 833610f2a0..c9dfa23a2c 100644
--- a/Silicon/Intel/Tools/FitGen/FitGen.c
+++ b/Silicon/Intel/Tools/FitGen/FitGen.c
@@ -2,7 +2,7 @@
 This utility is part of build process for IA32/X64 FD.
 It generates FIT table.
 
-Copyright (c) 2010-2019, Intel Corporation. All rights reserved.
+Copyright (c) 2010-2020, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -226,9 +226,17 @@ typedef struct {
 #define FIT_TABLE_TYPE_BIOS_DATA_AREA 13
 #define FIT_TABLE_TYPE_CSE_SECURE_BOOT16
 
+//
+// With OptionalModule Address isn't known until free space has been
+// identified and the optional module has been copied into the FLASH
+// image buffer (or initialized to be populated later by another program).
+// This is very dangerous code as it can truncate 64b pointers to
+// allocated memory buffers.  The full pointer is in Buffer for that case.
+//
 typedef struct {
   UINT32  Type;
   UINT32  Address;
+  UINT8   *Buffer; // Used by OptionalModule only
   UINT32  Size;
   UINT32  Version; // Used by OptionalModule and PortModule only
 } FIT_TABLE_CONTEXT_ENTRY;
@@ -575,9 +583,9 @@ Returns:
   UINT64  FvLength;
   EFI_GUID*TempGuid;
   UINT8   *FixPoint;
-  UINT32  Offset;
-  UINT32  FileLength;
-  UINT32  FileOccupiedSize;
+  UINTN   Offset;
+  UINTN   FileLength;
+  UINTN   FileOccupiedSize;
 
   //
   // Find the FFS file
@@ -595,7 +603,7 @@ Returns:
 InitializeFvLib (FvHeader, (UINT32)FvLength);
 
 FileHeader   = (EFI_FFS_FILE_HEADER *)((UINTN)FvHeader + 
FvHeader->HeaderLength);
-Offset   = (UINT32) (UINTN) FileHeader - (UINT32) (UINTN) FvHeader;
+Offset   = (UINTN) FileHeader - (UINTN) FvHeader;
 
 while (Offset < FvLength) {
   TempGuid = (EFI_GUID *)&(FileHeader->Name);
@@ -625,7 +633,7 @@ Returns:
 return FixPoint;
   }
   FileHeader = (EFI_FFS_FILE_HEADER *)((UINTN)FileHeader + 
FileOccupiedSize);
-  Offset = (UINT32) (UINTN) FileHeader - (UINT32) (UINTN) FvHeader;
+  Offset = (UINTN) FileHeader - (UINTN) FvHeader;
 }
 
 //
@@ -1082,7 +1090,7 @@ Returns:
 return 0;
   }
   
gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Type = 
FIT_TABLE_TYPE_MICROCODE;
-  
gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Address = 
MicrocodeBase + ((UINT32) (UINTN) MicrocodeBuffer - (UINT32) (UINTN) 
MicrocodeFileBuffer);
+  
gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Address = 
MicrocodeBase + (UINT32)((UINTN) MicrocodeBuffer - (UINTN) MicrocodeFileBuffer);
   
gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Size = 
MicrocodeSize;
   gFitTableContext.MicrocodeNumber++;
   gFitTableContext.FitEntryNumber++;
@@ -1110,7 +1118,7 @@ Returns:
   ///
   while (MicrocodeBuffer + SlotSize <= MicrocodeFileBuffer + 
MicrocodeFileSize) {
 
gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Type = 
FIT_TABLE_TYPE_MICROCODE;
-
gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Address = 
MicrocodeBase + ((UINT32) (UINTN) MicrocodeBuffer - (UINT32) (UINTN) 
MicrocodeFileBuffer);
+
gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Address = 
MicrocodeBase + (UINT32)((UINTN) MicrocodeBuffer - (UINTN) MicrocodeFileBuffer);
 gFitTableContext.MicrocodeNumber++;
 gFitTableContext.FitEntryNumber++;
 
@@ -1428,7 +1436,7 @@ Returns:
 return 0;
   }
   gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Type = 
FIT_TABLE_TYPE_MICROCODE;
-  gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Address = 
MicrocodeBase + ((UINT32) (UINTN) MicrocodeBuffer - (UINT32) (UINTN) 
MicrocodeFileBuffer);
+  gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Address = 
MicrocodeBase + (UINT32)((UINTN) MicrocodeBuffer - (UINTN) MicrocodeFileBuffer);
   gFitTableContext.Microcode[gFitTableContext.MicrocodeNumber].Size = 
MicrocodeSize;
   

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

[Bret Barkelew via Groups.Io]

Expanding the audience beyond the RFC list….
If no one has additional input, I’ll try to start formatting these as patches 
later this week. Thanks!

- Bret

From: Bret Barkelew
Sent: Tuesday, January 28, 2020 5:36 PM
To: r...@edk2.groups.io
Subject: [RFC] VariablePolicy - Protocol, Libraries, and Implementation for 
VariableLock Alternative

All,

VariablePolicy is our proposal for an expanded “VarLock-like” interface to 
constrain and govern platform variables.
I brought this up back in May to get initial comments on the interface and 
implications of the interface and the approach. We implemented it in Mu over 
the summer and it is not our defacto variable solution. It plugs in easily to 
the existing variable infrastructure, but does want to control some of the 
things that are currently managed by VarLock.

There are also some tweaks that would be needed if this were desired to be 100% 
optional code, but that’s no different than the current VarLock implementation 
which has implementation code directly tied to some of the common variable code.

I’ve structured this RFC in two pieces:

  *   The Core piece represents the minimum changes needed to implement 
Variable Policy and integrate it into Variable Services. It contains core 
driver code, central libraries and headers, and DXE driver for the protocol 
interface.
  *   The Extras piece contains recommended code for a full-feature 
implementation including a replacement for the VarLock protocol that enables 
existing code to continue functioning as-is. It also contains unit and 
integration tests. And as a bonus, it has a Rust implementation of the core 
business logic for Variable Policy.

The code can be found in the following two branches:
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_core
https://github.com/corthon/edk2/tree/personal/brbarkel/var_policy_rfc_extra

A convenient way to see all the changes in one place is to look at a comparison:
https://github.com/corthon/edk2/compare/master...corthon:personal/brbarkel/var_policy_rfc_core
https://github.com/corthon/edk2/compare/personal/brbarkel/var_policy_rfc_core...corthon:personal/brbarkel/var_policy_rfc_extra

There’s additional documentation in the PPT and DOC files in the core branch:
https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Proposal%20Presentation.pptx
 
https://github.com/corthon/edk2/blob/personal/brbarkel/var_policy_rfc_core/RFC%20VariablePolicy%20Whitepaper.docx
(You’d need to download those to view.)

My ultimate intention for this is to submit it as a series of patches for 
acceptance into EDK2 as a replacement for VarLock. For now, I’m just looking 
for initial feedback on any broad changes that might be needed to get this into 
shape for more detailed code review on the devel list.

Thanks!

- Bret



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53712): https://edk2.groups.io/g/devel/message/53712
Mute This Topic: https://groups.io/mt/70968478/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch 5/5] CryptoPkg/CryptoPkg.dsc: Add build of Crypto libraries/modules

[Wang, Jian J]

Reviewed-by: Jian J Wang 

Regards,
Jian

> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, January 30, 2020 3:01 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Lu, XiaoyuX 
> Subject: [Patch 5/5] CryptoPkg/CryptoPkg.dsc: Add build of Crypto
> libraries/modules
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2420
> 
> Based on the following package with changes to merge into
> CryptoPkg.
> 
> https://github.com/microsoft/mu_plus/tree/dev/201908/SharedCryptoPkg
> 
> Add Crypto library instances and modules that consume/produce
> the EDK II Crypto Protocols/PPIs to the CryptoPkg DSC file.
> 
> The default build of CryptoPkg performs a package verification
> build.
> 
> The CRYPTO_SERVICES define is added that supports the following
> settings.
> 
> * PACKAGE - Package verification build of all components.  Null
> versions of libraries are used to minimize build times.
> * ALL - Build PEIM, DXE, and SMM drivers.  Protocols and PPIs
> publish all services.
> * NONE- Build PEIM, DXE, and SMM drivers.  Protocols and PPIs
> publish no services.  Used to verify compiler/linker
> optimizations are working correctly.
> * MIN_PEI - Build PEIM with PPI that publishes minimum required
> services.
> * MIN_DXE_MIN_SMM - Build DXE and SMM drivers with Protocols that publish
> minimum required services.
> 
> Cc: Jian J Wang 
> Cc: Xiaoyu Lu 
> Signed-off-by: Michael D Kinney 
> ---
>  CryptoPkg/CryptoPkg.dsc | 209 +++-
>  1 file changed, 183 insertions(+), 26 deletions(-)
> 
> diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc
> index ec43c1f0a4..72324fe75f 100644
> --- a/CryptoPkg/CryptoPkg.dsc
> +++ b/CryptoPkg/CryptoPkg.dsc
> @@ -1,7 +1,8 @@
>  ## @file
>  #  Cryptographic Library Package for UEFI Security Implementation.
> +#  PEIM, DXE Driver, and SMM Driver with all crypto services enabled.
>  #
> -#  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2009 - 2020, Intel Corporation. All rights reserved.
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -21,6 +22,28 @@ [Defines]
>BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
>SKUID_IDENTIFIER   = DEFAULT
> 
> +  #
> +  # Flavor of PEI, DXE, SMM modules to build.
> +  # Must be one of ALL, NONE, MIN_PEI, MIN_DXE_MIN_SMM.
> +  # Default is ALL that is used for package build verification.
> +  #   PACKAGE - Package verification build of all components.  Null
> +  # versions of libraries are used to minimize build 
> times.
> +  #   ALL - Build PEIM, DXE, and SMM drivers.  Protocols and PPIs
> +  # publish all services.
> +  #   NONE- Build PEIM, DXE, and SMM drivers.  Protocols and PPIs
> +  # publish no services.  Used to verify compiler/linker
> +  # optimizations are working correctly.
> +  #   MIN_PEI - Build PEIM with PPI that publishes minimum required
> +  # services.
> +  #   MIN_DXE_MIN_SMM - Build DXE and SMM drivers with Protocols that
> publish
> +  # minimum required services.
> +  #
> +  DEFINE CRYPTO_SERVICES = PACKAGE
> +!if $(CRYPTO_SERVICES) IN "PACKAGE ALL NONE MIN_PEI
> MIN_DXE_MIN_SMM"
> +!else
> +  !error CRYPTO_SERVICES must be set to one of PACKAGE ALL NONE MIN_PEI
> MIN_DXE_MIN_SMM.
> +!endif
> +
> 
> #
> ###
>  #
>  # Library Class section - list of all Library Classes needed by this 
> Platform.
> @@ -29,21 +52,12 @@ [Defines]
>  [LibraryClasses]
>BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
>BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> -
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryA
> llocationLib.inf
>PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
>DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> -
> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDe
> bugPrintErrorLevelLib.inf
> -  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> -  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
> -  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
> 
> UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootS
> ervicesTableLib.inf
> -
> UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/Ue
> fiRuntimeServicesTableLib.inf
> -  UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
> 
> UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoin
> t.inf
> -
> UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiAppli
> cationEntryPoint.inf
> -
> -  

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

[Laszlo Ersek]

(+Ard)

On 02/04/20 05:54, Liming Gao wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2502
> This option is required to make GCC49 tool chain work with the high
> version GCC compiler.
> 
> Cc: Bob Feng 
> Signed-off-by: Liming Gao 
> ---
>  BaseTools/Conf/tools_def.template | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index feee2bbf16..d02424ae44 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -1974,7 +1974,7 @@ DEFINE GCC48_ARM_ASLDLINK_FLAGS  = 
> DEF(GCC_ARM_ASLDLINK_FLAGS) -Wl,--oformat
>  DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_ASLDLINK_FLAGS)
>  DEFINE GCC48_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS)
>  
> -DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS)
> +DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS) -fno-pic 
> -fno-pie
>  DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
>  DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
> common-page-size=0x40
>  DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
> -Wl,--defsym=PECOFF_HEADER_SIZE=0 DEF(GCC_DLINK2_FLAGS_COMMON) 
> -Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
> @@ -1997,7 +1997,7 @@ DEFINE GCC49_ARM_ASLDLINK_FLAGS  = 
> DEF(GCC48_ARM_ASLDLINK_FLAGS)
>  DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
>  DEFINE GCC49_ASLCC_FLAGS = DEF(GCC48_ASLCC_FLAGS)
>  
> -DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-pic 
> -fno-pie
> +DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS)
>  DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
>  DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)
>  DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
> 

- What has changed relative to commit 11d0cd23dd1b ("BaseTools/tools_def
IA32: drop -no-pie linker option for GCC49", 2018-06-18)?

- Also, if we are reverting one half of 11d0cd23dd1b (the compiler
flags), shouldn't we then revert the other half too (the linker flags)?

- The commit message says, "work with the high version GCC compiler".
What does that mean? If it is 4.9.x, with x>2, then I agree the patch is
justified (because commit 11d0cd23dd1b was apparently made for 4.9.2).
But if the phrase stands for gcc8 or so (just an example), then I don't
think the patch is a good idea; users of gcc8 can just specify the GCC5
toolchain.

Ah, indeed, I need only look at TianoCore#2502:

"GCC49 tool chain meets with the build failure when GCC7.4 compiler".

So I think this approach is wrong. Unless there is a new gcc-4.9.x
release, i.e., after gcc-4.9.2, I think we still need commit
11d0cd23dd1b in place. And, please use GCC5 for gcc-7.4 -- is there a
problem with that?

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53720): https://edk2.groups.io/g/devel/message/53720
Mute This Topic: https://groups.io/mt/70966421/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[PierreGondois]

Hello Liming and Bob,
To answer Liming's questions, I am building the DynamicTablesPkg with the patch 
with the AARCH64-DEBUG and the following configurations:
Windows - GCC- GNUmake
Windows - GCC- nmake
Windows - VS2017 - GNUmake
Windows - VS2017 - nmake
Linux   - GCC5   - GNUmake
For the record, when building with the Windows-VS2017-GNUmake configuration, 
the *_*_*_MAKE_FLAG(S) variable is set to "/nologo". As this is a nmake 
specific flag, it has to be removed when using GNUmake. Some warning flags also 
need to be slightly modified when building with VS2017.
To modify the type of make tool to use (GNUmake or nmake), I modify the 
following variable in Conf/tools_def.txt:
*_[GCC5|VS2017]_*_MAKE_PATH = [nmake|GNUmake]

I am building the ShellPkg with the patch and a small modification on how nasm 
files are added for IA32 and X64 for the following configurations:
Windows - VS2017 - GNUmake
Windows - VS2017 - nmake
Linux   - GCC- GNUmake

Unfortunately, the gcc compiler available on windows doesn't provide all the 
options of the one available on linux. For instances:
 * When building ShellPkg-DEBUG build-X64 -Windows-GCC-[nmake], the 
"-mcmodel=small" option provided is not supported.
 * When building ShellPkg-DEBUG build-IA32-Windows-GCC-[nmake], the 
"-m,elf_i386" option provided is not supported.
These issues are related to the compiler and not to the patch.

The Windows-GCC-GNUmake configuration is very important for Arm. This 
configuration was working fine until patch 
"0c3e8e9947a6c13b4327dd11b20acb95441701cf BaseTools: Enhance Basetool for 
incremental build" was merged in edk2.

Regards,
Pierre

-Original Message-
From: devel@edk2.groups.io  On Behalf Of PierreGondois 
via Groups.Io
Sent: 04 February 2020 12:01
To: devel@edk2.groups.io
Cc: Pierre Gondois ; bob.c.f...@intel.com; 
liming@intel.com; Sami Mujawar ; Pierre Gondois 
; nd 
Subject: [edk2-devel] [PATCH v2 1/1] BaseTools: Rationalise makefile generation

From: Pierre Gondois 

The GenMake.py script tests the platform environment to determine the type of 
makefile that needs to be generated. If a Windows build host is detected, the 
makefile generated is of Nmake type. Otherwise a GNUmake type is generated.

Furthermore, the ___MAKE_PATH
option in tools_def.template defines the make tool to use.
E.g.: for VS2017 this is configured to use Nmake, cf.
*_VS2017_*_MAKE_PATH = DEF(VS2017_BIN_HOST)\nmake.exe while for GCC5 it is 
setup to use GNU make.
*_GCC5_*_MAKE_PATH = DEF(GCC_HOST_PREFIX)make

This prevents using the GCC compiler toolchain on a Windows build host.

To address this issue this patch introduces 2 factors to determine the 
generated makefile output.
  1. Platform -> to determine shell commands used
 in makefile.
  2. MakeTool -> to determine the type of makefile
 that needs to be generated.

Signed-off-by: Pierre Gondois 
Signed-off-by: Sami Mujawar 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/tree/720_BaseTools_Rationalise_makefile_generation_v2

Notes:
v2:
  - Rebase on latest master [Pierre]

 BaseTools/Source/Python/AutoGen/GenMake.py | 122 ++--
 BaseTools/Source/Python/AutoGen/IncludesAutoGen.py |  34 +++---
 BaseTools/Source/Python/build/build.py |   7 +-
 3 files changed, 88 insertions(+), 75 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index 
ba199c1aa73dc46856b41c13e07e3d9770081acd..f49c765c791d57c06fcccf7059b37a018dc68ae6
 100755
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -2,6 +2,7 @@
 # Create makefile for MS nmake and GNU make  #  # Copyright (c) 2007 - 2020, 
Intel Corporation. All rights reserved.
+# Copyright (c) 2020, ARM Limited. All rights reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent  #
 
@@ -52,13 +53,6 @@ gIncludeMacroConversion = {
   "EFI_PPI_DEPENDENCY"  :   gPpiDefinition,
 }
 
-## default makefile type
-gMakeType = ""
-if sys.platform == "win32":
-gMakeType = "nmake"
-else:
-gMakeType = "gmake"
-
 
 ## BuildFile class
 #
@@ -77,6 +71,13 @@ class BuildFile(object):
 "gmake" :   "GNUmakefile"
 }
 
+# Get Makefile name.
+def getMakefileName(self):
+if not self._FileType:
+return _DEFAULT_FILE_NAME_
+else:
+return self._FILE_NAME_[self._FileType]
+
 ## Fixed header string for makefile
 _MAKEFILE_HEADER = '''#
 # DO NOT EDIT
@@ -106,7 +107,7 @@ class BuildFile(object):
 #   $(RD) remove dir command
 #
 _SHELL_CMD_ = {
-"nmake" : {
+"win32" : {
 "CP":   "copy /y",
 "MV":   "move /y",
 "RM":   "del /f /q",
@@ -114,7 +115,7 @@ class BuildFile(object):
 "RD":   "rmdir /s /q",
 },
 
-"gmake" : {
+"posix" : {
 "CP":   "cp -f",
 

Re: [edk2-devel] [PATCH V2] UefiCpuPkg RegisterCpuFeaturesLib: Match data type and format specifier

[Laszlo Ersek]

On 02/04/20 08:02, Star Zeng wrote:
> Match data type and format specifier for printing.
> 1. Type cast ProcessorNumber and FeatureIndex to UINT32
>   as %d only expects a UINT32.
> 2. Use %08x instead of %08lx for CacheControl to print Index
>   as it is UINT32 type.
> 3. Use %016lx instead of %08lx for MemoryMapped to print
>   (Index | LShiftU64 (HighIndex, 32)) as it is UINT64 type.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Star Zeng 
> ---
>  .../CpuFeaturesInitialize.c   | 24 +--
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git 
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index 0a4fcff033a3..fc96fb4372cf 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -430,8 +430,8 @@ DumpRegisterTableOnProcessor (
>DEBUG ((
>  DebugPrintErrorLevel,
>  "Processor: %04d: Index %04d, MSR  : %08x, Bit Start: %02d, Bit 
> Length: %02d, Value: %016lx\r\n",
> -ProcessorNumber,
> -FeatureIndex,
> +(UINT32) ProcessorNumber,
> +(UINT32) FeatureIndex,
>  RegisterTableEntry->Index,
>  RegisterTableEntry->ValidBitStart,
>  RegisterTableEntry->ValidBitLength,
> @@ -442,8 +442,8 @@ DumpRegisterTableOnProcessor (
>DEBUG ((
>  DebugPrintErrorLevel,
>  "Processor: %04d: Index %04d, CR   : %08x, Bit Start: %02d, Bit 
> Length: %02d, Value: %016lx\r\n",
> -ProcessorNumber,
> -FeatureIndex,
> +(UINT32) ProcessorNumber,
> +(UINT32) FeatureIndex,
>  RegisterTableEntry->Index,
>  RegisterTableEntry->ValidBitStart,
>  RegisterTableEntry->ValidBitLength,
> @@ -453,9 +453,9 @@ DumpRegisterTableOnProcessor (
>  case MemoryMapped:
>DEBUG ((
>  DebugPrintErrorLevel,
> -"Processor: %04d: Index %04d, MMIO : %08lx, Bit Start: %02d, Bit 
> Length: %02d, Value: %016lx\r\n",
> -ProcessorNumber,
> -FeatureIndex,
> +"Processor: %04d: Index %04d, MMIO : %016lx, Bit Start: %02d, Bit 
> Length: %02d, Value: %016lx\r\n",
> +(UINT32) ProcessorNumber,
> +(UINT32) FeatureIndex,
>  RegisterTableEntry->Index | LShiftU64 
> (RegisterTableEntry->HighIndex, 32),
>  RegisterTableEntry->ValidBitStart,
>  RegisterTableEntry->ValidBitLength,
> @@ -465,9 +465,9 @@ DumpRegisterTableOnProcessor (
>  case CacheControl:
>DEBUG ((
>  DebugPrintErrorLevel,
> -"Processor: %04d: Index %04d, CACHE: %08lx, Bit Start: %02d, Bit 
> Length: %02d, Value: %016lx\r\n",
> -ProcessorNumber,
> -FeatureIndex,
> +"Processor: %04d: Index %04d, CACHE: %08x, Bit Start: %02d, Bit 
> Length: %02d, Value: %016lx\r\n",
> +(UINT32) ProcessorNumber,
> +(UINT32) FeatureIndex,
>  RegisterTableEntry->Index,
>  RegisterTableEntry->ValidBitStart,
>  RegisterTableEntry->ValidBitLength,
> @@ -478,8 +478,8 @@ DumpRegisterTableOnProcessor (
>DEBUG ((
>  DebugPrintErrorLevel,
>  "Processor: %04d: Index %04d, SEMAP: %s\r\n",
> -ProcessorNumber,
> -FeatureIndex,
> +(UINT32) ProcessorNumber,
> +(UINT32) FeatureIndex,
>  mDependTypeStr[MIN ((UINT32)RegisterTableEntry->Value, 
> InvalidDepType)]
>  ));
>break;
> 

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53718): https://edk2.groups.io/g/devel/message/53718
Mute This Topic: https://groups.io/mt/70967864/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[PierreGondois]

From: Pierre Gondois 

The GenMake.py script tests the platform environment
to determine the type of makefile that needs to be
generated. If a Windows build host is detected, the
makefile generated is of Nmake type. Otherwise a
GNUmake type is generated.

Furthermore, the ___MAKE_PATH
option in tools_def.template defines the make tool
to use.
E.g.: for VS2017 this is configured to use Nmake, cf.
*_VS2017_*_MAKE_PATH = DEF(VS2017_BIN_HOST)\nmake.exe
while for GCC5 it is setup to use GNU make.
*_GCC5_*_MAKE_PATH = DEF(GCC_HOST_PREFIX)make

This prevents using the GCC compiler toolchain on a
Windows build host.

To address this issue this patch introduces 2 factors
to determine the generated makefile output.
  1. Platform -> to determine shell commands used
 in makefile.
  2. MakeTool -> to determine the type of makefile
 that needs to be generated.

Signed-off-by: Pierre Gondois 
Signed-off-by: Sami Mujawar 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/tree/720_BaseTools_Rationalise_makefile_generation_v2

Notes:
v2:
  - Rebase on latest master [Pierre]

 BaseTools/Source/Python/AutoGen/GenMake.py | 122 ++--
 BaseTools/Source/Python/AutoGen/IncludesAutoGen.py |  34 +++---
 BaseTools/Source/Python/build/build.py |   7 +-
 3 files changed, 88 insertions(+), 75 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index 
ba199c1aa73dc46856b41c13e07e3d9770081acd..f49c765c791d57c06fcccf7059b37a018dc68ae6
 100755
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -2,6 +2,7 @@
 # Create makefile for MS nmake and GNU make
 #
 # Copyright (c) 2007 - 2020, Intel Corporation. All rights reserved.
+# Copyright (c) 2020, ARM Limited. All rights reserved.
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 
@@ -52,13 +53,6 @@ gIncludeMacroConversion = {
   "EFI_PPI_DEPENDENCY"  :   gPpiDefinition,
 }
 
-## default makefile type
-gMakeType = ""
-if sys.platform == "win32":
-gMakeType = "nmake"
-else:
-gMakeType = "gmake"
-
 
 ## BuildFile class
 #
@@ -77,6 +71,13 @@ class BuildFile(object):
 "gmake" :   "GNUmakefile"
 }
 
+# Get Makefile name.
+def getMakefileName(self):
+if not self._FileType:
+return _DEFAULT_FILE_NAME_
+else:
+return self._FILE_NAME_[self._FileType]
+
 ## Fixed header string for makefile
 _MAKEFILE_HEADER = '''#
 # DO NOT EDIT
@@ -106,7 +107,7 @@ class BuildFile(object):
 #   $(RD) remove dir command
 #
 _SHELL_CMD_ = {
-"nmake" : {
+"win32" : {
 "CP":   "copy /y",
 "MV":   "move /y",
 "RM":   "del /f /q",
@@ -114,7 +115,7 @@ class BuildFile(object):
 "RD":   "rmdir /s /q",
 },
 
-"gmake" : {
+"posix" : {
 "CP":   "cp -f",
 "MV":   "mv -f",
 "RM":   "rm -f",
@@ -125,35 +126,35 @@ class BuildFile(object):
 
 ## directory separator
 _SEP_ = {
-"nmake" :   "\\",
-"gmake" :   "/"
+"win32" :   "\\",
+"posix" :   "/"
 }
 
 ## directory creation template
 _MD_TEMPLATE_ = {
-"nmake" :   'if not exist %(dir)s $(MD) %(dir)s',
-"gmake" :   "$(MD) %(dir)s"
+"win32" :   'if not exist %(dir)s $(MD) %(dir)s',
+"posix" :   "$(MD) %(dir)s"
 }
 
 ## directory removal template
 _RD_TEMPLATE_ = {
-"nmake" :   'if exist %(dir)s $(RD) %(dir)s',
-"gmake" :   "$(RD) %(dir)s"
+"win32" :   'if exist %(dir)s $(RD) %(dir)s',
+"posix" :   "$(RD) %(dir)s"
 }
 ## cp if exist
 _CP_TEMPLATE_ = {
-"nmake" :   'if exist %(Src)s $(CP) %(Src)s %(Dst)s',
-"gmake" :   "test -f %(Src)s && $(CP) %(Src)s %(Dst)s"
+"win32" :   'if exist %(Src)s $(CP) %(Src)s %(Dst)s',
+"posix" :   "test -f %(Src)s && $(CP) %(Src)s %(Dst)s"
 }
 
 _CD_TEMPLATE_ = {
-"nmake" :   'if exist %(dir)s cd %(dir)s',
-"gmake" :   "test -e %(dir)s && cd %(dir)s"
+"win32" :   'if exist %(dir)s cd %(dir)s',
+"posix" :   "test -e %(dir)s && cd %(dir)s"
 }
 
 _MAKE_TEMPLATE_ = {
-"nmake" :   'if exist %(file)s "$(MAKE)" $(MAKE_FLAGS) -f %(file)s',
-"gmake" :   'test -e %(file)s && "$(MAKE)" $(MAKE_FLAGS) -f %(file)s'
+"win32" :   'if exist %(file)s "$(MAKE)" $(MAKE_FLAGS) -f %(file)s',
+"posix" :   'test -e %(file)s && "$(MAKE)" $(MAKE_FLAGS) -f %(file)s'
 }
 
 _INCLUDE_CMD_ = {
@@ -169,22 +170,30 @@ class BuildFile(object):
 #
 def __init__(self, AutoGenObject):
 self._AutoGenObject = AutoGenObject
-self._FileType = gMakeType
 
-## Create build file
+MakePath = AutoGenObject.BuildOption.get('MAKE', {}).get('PATH')
+if 

Re: [edk2-devel] [PATCH v2 00/11] support QEMU's "SMRAM at default SMBASE" feature

[Ard Biesheuvel]

On Wed, 29 Jan 2020 at 21:44, Laszlo Ersek  wrote:
>
> Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=1512
> Repo:   https://github.com/lersek/edk2.git
> Branch: smram_at_default_smbase_bz_1512_wave_1_v2
> Supersedes: <20190924113505.27272-1-ler...@redhat.com>
>
> V1 is archived at:
> - http://mid.mail-archive.com/20190924113505.27272-1-lersek@redhat.com
> - https://edk2.groups.io/g/devel/message/47924
>
> Igor's patch set, mentioned in the v1 blurb, has been merged into QEMU
> meanwhile. The relevant QEMU commit is f404220e279c ("q35: implement
> 128K SMRAM at default SMBASE address", 2020-01-22).
>
> In v2:
> - trim the Cc list
>
> - pick up Jiewen's R-b for patches #1 through #9, from:
>   - 
> http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F7CBCB2@shsmsx102.ccr.corp.intel.com
>   - https://edk2.groups.io/g/devel/message/48166
>
> - add patch #10, and update patch #11, for satisfying Jiewen's condition
>   on his R-b.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Julien Grall 
>
> Thanks,
> Laszlo
>
> Laszlo Ersek (11):
>   OvmfPkg: introduce PcdQ35SmramAtDefaultSmbase
>   OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro
> defs
>   OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros
>   OvmfPkg/PlatformPei: factor out Q35BoardVerification()
>   OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton)
>   OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default
> SMBASE
>   OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it
> exists
>   OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default
> SMBASE
>   OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASE
>   OvmfPkg: introduce PcdCsmEnable feature flag
>   OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real)
>

For the series,

Reviewed-by: Ard Biesheuvel 


>  OvmfPkg/Include/IndustryStandard/Q35MchIch9.h   | 106 
> +++-
>  OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c   |  21 +++-
>  OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf |   4 +
>  OvmfPkg/OvmfPkg.dec |  11 ++
>  OvmfPkg/OvmfPkgIa32.dsc |   4 +
>  OvmfPkg/OvmfPkgIa32X64.dsc  |   4 +
>  OvmfPkg/OvmfPkgX64.dsc  |   4 +
>  OvmfPkg/OvmfXen.dsc |   3 +
>  OvmfPkg/PlatformPei/AmdSev.c|  24 -
>  OvmfPkg/PlatformPei/MemDetect.c |  94 
> ++---
>  OvmfPkg/PlatformPei/Platform.c  |  24 +
>  OvmfPkg/PlatformPei/Platform.h  |   7 ++
>  OvmfPkg/PlatformPei/PlatformPei.inf |   2 +
>  OvmfPkg/SmmAccess/SmmAccess2Dxe.c   |   7 ++
>  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf |   1 +
>  OvmfPkg/SmmAccess/SmmAccessPei.c|   6 ++
>  OvmfPkg/SmmAccess/SmmAccessPei.inf  |   1 +
>  OvmfPkg/SmmAccess/SmramInternal.c   |  25 +
>  OvmfPkg/SmmAccess/SmramInternal.h   |   8 ++
>  19 files changed, 285 insertions(+), 71 deletions(-)
>
> --
> 2.19.1.3.g30247aa5d201
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53795): https://edk2.groups.io/g/devel/message/53795
Mute This Topic: https://groups.io/mt/70252369/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2] UefiCpuPkg RegisterCpuFeaturesLib: Match data type and format specifier

[Dong, Eric]

Reviewed-by: Eric Dong 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Zeng, Star
Sent: Tuesday, February 4, 2020 3:02 PM
To: devel@edk2.groups.io
Cc: Zeng, Star ; Dong, Eric ; Ni, Ray 
; Laszlo Ersek 
Subject: [edk2-devel] [PATCH V2] UefiCpuPkg RegisterCpuFeaturesLib: Match data 
type and format specifier

Match data type and format specifier for printing.
1. Type cast ProcessorNumber and FeatureIndex to UINT32
  as %d only expects a UINT32.
2. Use %08x instead of %08lx for CacheControl to print Index
  as it is UINT32 type.
3. Use %016lx instead of %08lx for MemoryMapped to print
  (Index | LShiftU64 (HighIndex, 32)) as it is UINT64 type.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Star Zeng 
---
 .../CpuFeaturesInitialize.c   | 24 +--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index 0a4fcff033a3..fc96fb4372cf 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -430,8 +430,8 @@ DumpRegisterTableOnProcessor (
   DEBUG ((
 DebugPrintErrorLevel,
 "Processor: %04d: Index %04d, MSR  : %08x, Bit Start: %02d, Bit 
Length: %02d, Value: %016lx\r\n",
-ProcessorNumber,
-FeatureIndex,
+(UINT32) ProcessorNumber,
+(UINT32) FeatureIndex,
 RegisterTableEntry->Index,
 RegisterTableEntry->ValidBitStart,
 RegisterTableEntry->ValidBitLength,
@@ -442,8 +442,8 @@ DumpRegisterTableOnProcessor (
   DEBUG ((
 DebugPrintErrorLevel,
 "Processor: %04d: Index %04d, CR   : %08x, Bit Start: %02d, Bit 
Length: %02d, Value: %016lx\r\n",
-ProcessorNumber,
-FeatureIndex,
+(UINT32) ProcessorNumber,
+(UINT32) FeatureIndex,
 RegisterTableEntry->Index,
 RegisterTableEntry->ValidBitStart,
 RegisterTableEntry->ValidBitLength,
@@ -453,9 +453,9 @@ DumpRegisterTableOnProcessor (
 case MemoryMapped:
   DEBUG ((
 DebugPrintErrorLevel,
-"Processor: %04d: Index %04d, MMIO : %08lx, Bit Start: %02d, Bit 
Length: %02d, Value: %016lx\r\n",
-ProcessorNumber,
-FeatureIndex,
+"Processor: %04d: Index %04d, MMIO : %016lx, Bit Start: %02d, Bit 
Length: %02d, Value: %016lx\r\n",
+(UINT32) ProcessorNumber,
+(UINT32) FeatureIndex,
 RegisterTableEntry->Index | LShiftU64 (RegisterTableEntry->HighIndex, 
32),
 RegisterTableEntry->ValidBitStart,
 RegisterTableEntry->ValidBitLength,
@@ -465,9 +465,9 @@ DumpRegisterTableOnProcessor (
 case CacheControl:
   DEBUG ((
 DebugPrintErrorLevel,
-"Processor: %04d: Index %04d, CACHE: %08lx, Bit Start: %02d, Bit 
Length: %02d, Value: %016lx\r\n",
-ProcessorNumber,
-FeatureIndex,
+"Processor: %04d: Index %04d, CACHE: %08x, Bit Start: %02d, Bit 
Length: %02d, Value: %016lx\r\n",
+(UINT32) ProcessorNumber,
+(UINT32) FeatureIndex,
 RegisterTableEntry->Index,
 RegisterTableEntry->ValidBitStart,
 RegisterTableEntry->ValidBitLength,
@@ -478,8 +478,8 @@ DumpRegisterTableOnProcessor (
   DEBUG ((
 DebugPrintErrorLevel,
 "Processor: %04d: Index %04d, SEMAP: %s\r\n",
-ProcessorNumber,
-FeatureIndex,
+(UINT32) ProcessorNumber,
+(UINT32) FeatureIndex,
 mDependTypeStr[MIN ((UINT32)RegisterTableEntry->Value, InvalidDepType)]
 ));
   break;
-- 
2.21.0.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53803): https://edk2.groups.io/g/devel/message/53803
Mute This Topic: https://groups.io/mt/70967864/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Michael D Kinney]

Jiewen,

Thanks for pointing to the content in MdePkg.

I agree that we could include  
in BaseHashApiLib implementation and use the subset of
TPM_ALG_* define values for both the lib implementation
and the PCD description.  This will allow us to remove
the extra #defines from the HashApiLib.h class.

Mike

> -Original Message-
> From: Yao, Jiewen 
> Sent: Tuesday, February 4, 2020 2:54 PM
> To: Kinney, Michael D ;
> devel@edk2.groups.io; Sukerkar, Amol N
> 
> Cc: Wang, Jian J 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> Implement Unified Hash Calculation API
> 
> Mike
> The problem of defining a set of algo ID is that I have
> to remember the ID.
> I feel frustrated whenever I need match one ID to the
> other ID.
> 
> Currently, UEFI secure boot and TCG trusted boot are
> important feature. If we can align to one of them, it
> is easier. I believe if we have a consistent ID
> mapping, it will be much better for developer.
> 
> Current TPM20.h is defined in MdePkg (not in
> SecurityPkg) and is considered as an industry standard.
> I do not see any dependency issue.
> 
> We can define a new set - not a technical problem. I am
> just not sure why we have to. Or we can define it with
> the same value as TPM. See below list. I believe it
> will cover majority of current usage and current
> standard.
> > > > +  # 0x0004- SHA1.
> > > > +  # 0x000B- SHA256.
> > > > +  # 0x000C- SHA384.
> > > > +  # 0x000D- SHA512.
> > > > +  # 0x0012- SM3_256.
> > > > +  # 0x0027- SHA3_256.
> > > > +  # 0x0028- SHA3_384.
> > > > +  # 0x0029- SHA3_512.
> 
> 
> 
> 
> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Wednesday, February 5, 2020 12:26 AM
> > To: Yao, Jiewen ;
> devel@edk2.groups.io; Kinney,
> > Michael D ; Sukerkar,
> Amol N
> > 
> > Cc: Wang, Jian J 
> > Subject: RE: [Patch v10 2/2]
> CryptoPkg/BaseHashApiLib: Implement Unified Hash
> > Calculation API
> >
> > Jiewen,
> >
> > I think UINT8 is fine.  We can change default to 0x04
> in DEC file.
> >
> > I will let Amol comment on why MD4 and MD5 are
> included.  If
> > they are not required, then I agree they should be
> removed.
> >
> > I do not see a reason to align with TCG spec.  The
> HashApiLib
> > is a layer on top of BaseCryptLib and the use of hash
> algorithms
> > is not limited to TCG related content.  The
> BaseCryptLib
> > could potentially adopt hash algorithms that are not
> defined
> > in the TCG specification.  We also do not want
> CryptoPkg to
> > depend on the SecurityPkg.
> >
> > Thanks,
> >
> > Mike
> >
> > > -Original Message-
> > > From: Yao, Jiewen 
> > > Sent: Monday, February 3, 2020 6:54 PM
> > > To: Kinney, Michael D ;
> > > devel@edk2.groups.io
> > > Cc: Sukerkar, Amol N ;
> Wang,
> > > Jian J 
> > > Subject: RE: [Patch v10 2/2]
> CryptoPkg/BaseHashApiLib:
> > > Implement Unified Hash Calculation API
> > >
> > > Thanks Mike, to cover us during Chinese New Year
> > > holiday.
> > >
> > > I am just back from vocation. A minor comment:
> > >
> > > The PcdHashApiLibPolicy is UINT8, but the value is
> > > shown as 32bit 0x0004.
> > >
> > > There are couple of ways to enhance:
> > > 1) Define UINT8, and use 8bit style 0x04.
> > > 2) Define UINT32, and use 32bit style 0x0004.
> > > 3) Define UINT16 (match TCG definition), and use
> TCG
> > > defined value. (Tpm20.h)
> > > #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> > > #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> > > #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> > > #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> > > #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> > >
> > > MD4 and MD5 are known as insecure and deprecated. I
> > > doubt if we want to add such support. (I strong
> > > recommend NO).
> > >
> > > If we can remove MD4 and MD5, I think we can use
> #3.
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > > > -Original Message-
> > > > From: Kinney, Michael D
> 
> > > > Sent: Tuesday, February 4, 2020 7:36 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Sukerkar, Amol N ;
> > > Yao, Jiewen
> > > > ; Wang, Jian J
> > > 
> > > > Subject: [Patch v10 2/2]
> CryptoPkg/BaseHashApiLib:
> > > Implement Unified Hash
> > > > Calculation API
> > > >
> > > > From: Amol N Sukerkar 
> > > >
> > > >
> https://bugzilla.tianocore.org/show_bug.cgi?id=2151
> > > >
> > > > This commit introduces a Unified Hash API to
> > > calculate hash using a
> > > > hashing algorithm specified by the PCD,
> > > PcdHashApiLibPolicy. This library
> > > > interfaces with the various hashing API, such as,
> > > MD4, MD5, SHA1, SHA256,
> > > > SHA512 and SM3_256 implemented in BaseCryptLib.
> The
> > > user can calculate
> > > > the desired hash by setting PcdHashApiLibPolicy
> to
> > > appropriate value.
> > > >
> > > > This feature is documented in the Bugzilla,
> > > >
> https://bugzilla.tianocore.org/show_bug.cgi?id=2151.
> > > >
> > > > Cc: Jiewen Yao 
> 

[edk2-devel] [Patch v7 0/5] CryptoPkg: Add modules that produce BaseCryptLib services

[Michael D Kinney]

New in V7
* Sync with edk2/master to align with HashApiLib commits
* Fix typos and comment spelling
* Update supported archs

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

Based on the following package with changes to merge into CryptoPkg.

https://github.com/microsoft/mu_plus/tree/dev/201908/SharedCryptoPkg

* Add X509ConstructCertificateStackV() to BaseCryptLib.  This is required to
  have a VA_LIST version of X509ConstructCertificateStack() so it can be
  maped into a Protocol/PPI.
* Add EDK II Crypto Protocols/PPIs/PCDs
* Add PEIM, DXE Driver, SMM Driver that produce the EDK II Crypto Protocols/PPIs
  using the services of the BaseCryptLib and TlsLib with families of services
  and individual services enabled/disables in the Protocols/PPIs using a PCD.
* Add new BaseCryptLib library instance that calls the EDK II Crypto
  Protocols/PPIs.
* Update DSC file to build all modules/libs and provide ability to build binary
  versions of the PEIM, DXE Driver, SMM Driver with different sets of Crypto
  services enabled.

This patch series depends on the following bugs that must be resolved
before this patch series will build and pass EDK II CI.

  https://bugzilla.tianocore.org/show_bug.cgi?id=2495
  https://bugzilla.tianocore.org/show_bug.cgi?id=2496

Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Signed-off-by: Michael D Kinney 

Michael D Kinney (5):
  CryptoPkg/BaseCryptLib: Add X509ConstructCertificateStackV().
  CryptoPkg: Add EDK II Crypto Protocols/PPIs/PCDs
  CryptoPkg/Driver: Add Crypto PEIM, DXE, and SMM modules
  CryptoPkg/Library: Add BaseCryptLibOnProtocolPpi instances
  CryptoPkg/CryptoPkg.dsc: Add build of Crypto libraries/modules

 CryptoPkg/CryptoPkg.dec   |   28 +
 CryptoPkg/CryptoPkg.dsc   |  207 +-
 CryptoPkg/CryptoPkg.uni   |5 +-
 .../BaseCryptLib.h => Driver/Crypto.c}| 2139 ++-
 CryptoPkg/Driver/Crypto.uni   |   13 +
 CryptoPkg/Driver/CryptoDxe.c  |   38 +
 CryptoPkg/Driver/CryptoDxe.inf|   49 +
 CryptoPkg/Driver/CryptoPei.c  |   99 +
 CryptoPkg/Driver/CryptoPei.inf|   51 +
 CryptoPkg/Driver/CryptoSmm.c  |   41 +
 CryptoPkg/Driver/CryptoSmm.inf|   49 +
 CryptoPkg/Include/Library/BaseCryptLib.h  |   26 +
 .../Pcd/PcdCryptoServiceFamilyEnable.h|  293 +
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c |   50 +-
 .../Library/BaseCryptLib/Pk/CryptX509Null.c   |   32 +-
 .../BaseCryptLibNull/Pk/CryptX509Null.c   |   32 +-
 .../BaseCryptLibOnProtocolPpi/CryptLib.c} | 1701 +-
 .../BaseCryptLibOnProtocolPpi/CryptLib.uni|   12 +
 .../BaseCryptLibOnProtocolPpi/DxeCryptLib.c   |   68 +
 .../BaseCryptLibOnProtocolPpi/DxeCryptLib.inf |   44 +
 .../BaseCryptLibOnProtocolPpi/PeiCryptLib.c   |   57 +
 .../BaseCryptLibOnProtocolPpi/PeiCryptLib.inf |   43 +
 .../BaseCryptLibOnProtocolPpi/SmmCryptLib.c   |   79 +
 .../BaseCryptLibOnProtocolPpi/SmmCryptLib.inf |   44 +
 CryptoPkg/Private/Ppi/Crypto.h|   21 +
 .../Protocol/Crypto.h}| 5330 ++---
 CryptoPkg/Private/Protocol/SmmCrypto.h|   21 +
 27 files changed, 7860 insertions(+), 2712 deletions(-)
 copy CryptoPkg/{Include/Library/BaseCryptLib.h => Driver/Crypto.c} (61%)
 create mode 100644 CryptoPkg/Driver/Crypto.uni
 create mode 100644 CryptoPkg/Driver/CryptoDxe.c
 create mode 100644 CryptoPkg/Driver/CryptoDxe.inf
 create mode 100644 CryptoPkg/Driver/CryptoPei.c
 create mode 100644 CryptoPkg/Driver/CryptoPei.inf
 create mode 100644 CryptoPkg/Driver/CryptoSmm.c
 create mode 100644 CryptoPkg/Driver/CryptoSmm.inf
 create mode 100644 CryptoPkg/Include/Pcd/PcdCryptoServiceFamilyEnable.h
 copy CryptoPkg/{Include/Library/BaseCryptLib.h => 
Library/BaseCryptLibOnProtocolPpi/CryptLib.c} (67%)
 create mode 100644 CryptoPkg/Library/BaseCryptLibOnProtocolPpi/CryptLib.uni
 create mode 100644 CryptoPkg/Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.c
 create mode 100644 CryptoPkg/Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.inf
 create mode 100644 CryptoPkg/Library/BaseCryptLibOnProtocolPpi/PeiCryptLib.c
 create mode 100644 CryptoPkg/Library/BaseCryptLibOnProtocolPpi/PeiCryptLib.inf
 create mode 100644 CryptoPkg/Library/BaseCryptLibOnProtocolPpi/SmmCryptLib.c
 create mode 100644 CryptoPkg/Library/BaseCryptLibOnProtocolPpi/SmmCryptLib.inf
 create mode 100644 CryptoPkg/Private/Ppi/Crypto.h
 copy CryptoPkg/{Include/Library/BaseCryptLib.h => Private/Protocol/Crypto.h} 
(62%)
 create mode 100644 CryptoPkg/Private/Protocol/SmmCrypto.h

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53804): https://edk2.groups.io/g/devel/message/53804
Mute This Topic: https://groups.io/mt/70989126/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch v7 1/5] CryptoPkg/BaseCryptLib: Add X509ConstructCertificateStackV().

[Michael D Kinney]

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

Add X509ConstructCertificateStackV() to BaseCryptLib that is
identical in behavior to X509ConstructCertificateStack(), but
it takes a VA_LIST parameter for the variable argument list.

The VA_LIST form of this function is required for BaseCryptLib
functions to be wrapped in a Protocol/PPI.

Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Signed-off-by: Michael D Kinney 
Reviewed-by: Jian J Wang 
---
 CryptoPkg/Include/Library/BaseCryptLib.h  | 26 ++
 CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c | 50 +++
 .../Library/BaseCryptLib/Pk/CryptX509Null.c   | 32 +++-
 .../BaseCryptLibNull/Pk/CryptX509Null.c   | 32 +++-
 4 files changed, 128 insertions(+), 12 deletions(-)

diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h 
b/CryptoPkg/Include/Library/BaseCryptLib.h
index 8320fddc4c..5e8f2e0a10 100644
--- a/CryptoPkg/Include/Library/BaseCryptLib.h
+++ b/CryptoPkg/Include/Library/BaseCryptLib.h
@@ -2371,6 +2371,32 @@ X509ConstructCertificate (
   OUT  UINT8**SingleX509Cert
   );
 
+/**
+  Construct a X509 stack object from a list of DER-encoded certificate data.
+
+  If X509Stack is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
+
+  @param[in, out]  X509Stack  On input, pointer to an existing or NULL X509 
stack object.
+  On output, pointer to the X509 stack object with 
new
+  inserted X509 certificate.
+  @param[in]   Args   VA_LIST marker for the variable argument list.
+  A list of DER-encoded single certificate data 
followed
+  by certificate size. A NULL terminates the list. 
The
+  pairs are the arguments to 
X509ConstructCertificate().
+
+  @retval TRUEThe X509 stack construction succeeded.
+  @retval FALSE   The construction operation failed.
+  @retval FALSE   This interface is not supported.
+
+**/
+BOOLEAN
+EFIAPI
+X509ConstructCertificateStackV (
+  IN OUT  UINT8**X509Stack,
+  IN  VA_LIST  Args
+  );
+
 /**
   Construct a X509 stack object from a list of DER-encoded certificate data.
 
diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c 
b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
index 9b5579e71a..b1393a89c5 100644
--- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
+++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c
@@ -1,7 +1,7 @@
 /** @file
   X.509 Certificate Handler Wrapper Implementation over OpenSSL.
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2020, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -60,23 +60,26 @@ X509ConstructCertificate (
   Construct a X509 stack object from a list of DER-encoded certificate data.
 
   If X509Stack is NULL, then return FALSE.
+  If this interface is not supported, then return FALSE.
 
   @param[in, out]  X509Stack  On input, pointer to an existing or NULL X509 
stack object.
   On output, pointer to the X509 stack object with 
new
   inserted X509 certificate.
-  @param   ...A list of DER-encoded single certificate data 
followed
+  @param[in]   Args   VA_LIST marker for the variable argument list.
+  A list of DER-encoded single certificate data 
followed
   by certificate size. A NULL terminates the list. 
The
   pairs are the arguments to 
X509ConstructCertificate().
 
   @retval TRUEThe X509 stack construction succeeded.
   @retval FALSE   The construction operation failed.
+  @retval FALSE   This interface is not supported.
 
 **/
 BOOLEAN
 EFIAPI
-X509ConstructCertificateStack (
-  IN OUT  UINT8  **X509Stack,
-  ...
+X509ConstructCertificateStackV (
+  IN OUT  UINT8**X509Stack,
+  IN  VA_LIST  Args
   )
 {
   UINT8   *Cert;
@@ -84,7 +87,6 @@ X509ConstructCertificateStack (
   X509*X509Cert;
   STACK_OF(X509)  *CertStack;
   BOOLEAN Status;
-  VA_LIST Args;
   UINTN   Index;
 
   //
@@ -107,8 +109,6 @@ X509ConstructCertificateStack (
 }
   }
 
-  VA_START (Args, X509Stack);
-
   for (Index = 0; ; Index++) {
 //
 // If Cert is NULL, then it is the end of the list.
@@ -145,8 +145,6 @@ X509ConstructCertificateStack (
 sk_X509_push (CertStack, X509Cert);
   }
 
-  VA_END (Args);
-
   if (!Status) {
 sk_X509_pop_free (CertStack, X509_free);
   } else {
@@ -156,6 +154,38 @@ X509ConstructCertificateStack (
   return Status;
 }
 
+/**
+  Construct a X509 stack object from a list of DER-encoded certificate data.
+
+  If X509Stack is NULL, then return FALSE.
+
+  @param[in, out]  X509Stack  On input, pointer to an existing or NULL X509 
stack object.
+  

[edk2-devel] [Patch v7 5/5] CryptoPkg/CryptoPkg.dsc: Add build of Crypto libraries/modules

[Michael D Kinney]

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

Based on the following package with changes to merge into
CryptoPkg.

https://github.com/microsoft/mu_plus/tree/dev/201908/SharedCryptoPkg

Add Crypto library instances and modules that consume/produce
the EDK II Crypto Protocols/PPIs to the CryptoPkg DSC file.

The default build of CryptoPkg performs a package verification
build.

The CRYPTO_SERVICES define is added that supports the following
settings.

* PACKAGE - Package verification build of all components.  Null
versions of libraries are used to minimize build times.
* ALL - Build PEIM, DXE, and SMM drivers.  Protocols and PPIs
publish all services.
* NONE- Build PEIM, DXE, and SMM drivers.  Protocols and PPIs
publish no services.  Used to verify compiler/linker
optimizations are working correctly.
* MIN_PEI - Build PEIM with PPI that publishes minimum required
services.
* MIN_DXE_MIN_SMM - Build DXE and SMM drivers with Protocols that publish
minimum required services.

Cc: Jian J Wang 
Cc: Xiaoyu Lu 
Signed-off-by: Michael D Kinney 
Reviewed-by: Jian J Wang 
---
 CryptoPkg/CryptoPkg.dsc | 207 +++-
 1 file changed, 182 insertions(+), 25 deletions(-)

diff --git a/CryptoPkg/CryptoPkg.dsc b/CryptoPkg/CryptoPkg.dsc
index 9656a73b3c..4cb37b1349 100644
--- a/CryptoPkg/CryptoPkg.dsc
+++ b/CryptoPkg/CryptoPkg.dsc
@@ -1,5 +1,6 @@
 ## @file
 #  Cryptographic Library Package for UEFI Security Implementation.
+#  PEIM, DXE Driver, and SMM Driver with all crypto services enabled.
 #
 #  Copyright (c) 2009 - 2020, Intel Corporation. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -21,6 +22,28 @@ [Defines]
   BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
   SKUID_IDENTIFIER   = DEFAULT
 
+  #
+  # Flavor of PEI, DXE, SMM modules to build.
+  # Must be one of ALL, NONE, MIN_PEI, MIN_DXE_MIN_SMM.
+  # Default is ALL that is used for package build verification.
+  #   PACKAGE - Package verification build of all components.  Null
+  # versions of libraries are used to minimize build times.
+  #   ALL - Build PEIM, DXE, and SMM drivers.  Protocols and PPIs
+  # publish all services.
+  #   NONE- Build PEIM, DXE, and SMM drivers.  Protocols and PPIs
+  # publish no services.  Used to verify compiler/linker
+  # optimizations are working correctly.
+  #   MIN_PEI - Build PEIM with PPI that publishes minimum required
+  # services.
+  #   MIN_DXE_MIN_SMM - Build DXE and SMM drivers with Protocols that publish
+  # minimum required services.
+  #
+  DEFINE CRYPTO_SERVICES = PACKAGE
+!if $(CRYPTO_SERVICES) IN "PACKAGE ALL NONE MIN_PEI MIN_DXE_MIN_SMM"
+!else
+  !error CRYPTO_SERVICES must be set to one of PACKAGE ALL NONE MIN_PEI 
MIN_DXE_MIN_SMM.
+!endif
+
 

 #
 # Library Class section - list of all Library Classes needed by this Platform.
@@ -29,21 +52,12 @@ [Defines]
 [LibraryClasses]
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
-  
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
-  
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
-  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
-  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
-  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
   
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
-  
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
-  UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
   
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
-  
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
-
-  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
-  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.inf
+  TlsLib|CryptoPkg/Library/TlsLibNull/TlsLibNull.inf
   HashApiLib|CryptoPkg/Library/BaseHashApiLib/BaseHashApiLib.inf
 
 [LibraryClasses.ARM, LibraryClasses.AARCH64]
@@ -58,41 +72,140 @@ [LibraryClasses.ARM, LibraryClasses.AARCH64]
   # Add support for stack protector
   NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
 
+[LibraryClasses.common.PEIM]
+  PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
+  

Re: [edk2-devel] [Patch v7 0/5] CryptoPkg: Add modules that produce BaseCryptLib services

[Wang, Jian J]

For the whole patch series,

Reviewed-by: Jian J Wang 

Regards,
Jian

> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, February 05, 2020 10:59 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Lu, XiaoyuX 
> Subject: [Patch v7 0/5] CryptoPkg: Add modules that produce BaseCryptLib
> services
> 
> New in V7
> * Sync with edk2/master to align with HashApiLib commits
> * Fix typos and comment spelling
> * Update supported archs
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2420
> 
> Based on the following package with changes to merge into CryptoPkg.
> 
> https://github.com/microsoft/mu_plus/tree/dev/201908/SharedCryptoPkg
> 
> * Add X509ConstructCertificateStackV() to BaseCryptLib.  This is required to
>   have a VA_LIST version of X509ConstructCertificateStack() so it can be
>   maped into a Protocol/PPI.
> * Add EDK II Crypto Protocols/PPIs/PCDs
> * Add PEIM, DXE Driver, SMM Driver that produce the EDK II Crypto
> Protocols/PPIs
>   using the services of the BaseCryptLib and TlsLib with families of services
>   and individual services enabled/disables in the Protocols/PPIs using a PCD.
> * Add new BaseCryptLib library instance that calls the EDK II Crypto
>   Protocols/PPIs.
> * Update DSC file to build all modules/libs and provide ability to build 
> binary
>   versions of the PEIM, DXE Driver, SMM Driver with different sets of Crypto
>   services enabled.
> 
> This patch series depends on the following bugs that must be resolved
> before this patch series will build and pass EDK II CI.
> 
>   https://bugzilla.tianocore.org/show_bug.cgi?id=2495
>   https://bugzilla.tianocore.org/show_bug.cgi?id=2496
> 
> Cc: Jian J Wang 
> Cc: Xiaoyu Lu 
> Signed-off-by: Michael D Kinney 
> 
> Michael D Kinney (5):
>   CryptoPkg/BaseCryptLib: Add X509ConstructCertificateStackV().
>   CryptoPkg: Add EDK II Crypto Protocols/PPIs/PCDs
>   CryptoPkg/Driver: Add Crypto PEIM, DXE, and SMM modules
>   CryptoPkg/Library: Add BaseCryptLibOnProtocolPpi instances
>   CryptoPkg/CryptoPkg.dsc: Add build of Crypto libraries/modules
> 
>  CryptoPkg/CryptoPkg.dec   |   28 +
>  CryptoPkg/CryptoPkg.dsc   |  207 +-
>  CryptoPkg/CryptoPkg.uni   |5 +-
>  .../BaseCryptLib.h => Driver/Crypto.c}| 2139 ++-
>  CryptoPkg/Driver/Crypto.uni   |   13 +
>  CryptoPkg/Driver/CryptoDxe.c  |   38 +
>  CryptoPkg/Driver/CryptoDxe.inf|   49 +
>  CryptoPkg/Driver/CryptoPei.c  |   99 +
>  CryptoPkg/Driver/CryptoPei.inf|   51 +
>  CryptoPkg/Driver/CryptoSmm.c  |   41 +
>  CryptoPkg/Driver/CryptoSmm.inf|   49 +
>  CryptoPkg/Include/Library/BaseCryptLib.h  |   26 +
>  .../Pcd/PcdCryptoServiceFamilyEnable.h|  293 +
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c |   50 +-
>  .../Library/BaseCryptLib/Pk/CryptX509Null.c   |   32 +-
>  .../BaseCryptLibNull/Pk/CryptX509Null.c   |   32 +-
>  .../BaseCryptLibOnProtocolPpi/CryptLib.c} | 1701 +-
>  .../BaseCryptLibOnProtocolPpi/CryptLib.uni|   12 +
>  .../BaseCryptLibOnProtocolPpi/DxeCryptLib.c   |   68 +
>  .../BaseCryptLibOnProtocolPpi/DxeCryptLib.inf |   44 +
>  .../BaseCryptLibOnProtocolPpi/PeiCryptLib.c   |   57 +
>  .../BaseCryptLibOnProtocolPpi/PeiCryptLib.inf |   43 +
>  .../BaseCryptLibOnProtocolPpi/SmmCryptLib.c   |   79 +
>  .../BaseCryptLibOnProtocolPpi/SmmCryptLib.inf |   44 +
>  CryptoPkg/Private/Ppi/Crypto.h|   21 +
>  .../Protocol/Crypto.h}| 5330 ++---
>  CryptoPkg/Private/Protocol/SmmCrypto.h|   21 +
>  27 files changed, 7860 insertions(+), 2712 deletions(-)
>  copy CryptoPkg/{Include/Library/BaseCryptLib.h => Driver/Crypto.c} (61%)
>  create mode 100644 CryptoPkg/Driver/Crypto.uni
>  create mode 100644 CryptoPkg/Driver/CryptoDxe.c
>  create mode 100644 CryptoPkg/Driver/CryptoDxe.inf
>  create mode 100644 CryptoPkg/Driver/CryptoPei.c
>  create mode 100644 CryptoPkg/Driver/CryptoPei.inf
>  create mode 100644 CryptoPkg/Driver/CryptoSmm.c
>  create mode 100644 CryptoPkg/Driver/CryptoSmm.inf
>  create mode 100644 CryptoPkg/Include/Pcd/PcdCryptoServiceFamilyEnable.h
>  copy CryptoPkg/{Include/Library/BaseCryptLib.h =>
> Library/BaseCryptLibOnProtocolPpi/CryptLib.c} (67%)
>  create mode 100644
> CryptoPkg/Library/BaseCryptLibOnProtocolPpi/CryptLib.uni
>  create mode 100644
> CryptoPkg/Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.c
>  create mode 100644
> CryptoPkg/Library/BaseCryptLibOnProtocolPpi/DxeCryptLib.inf
>  create mode 100644
> CryptoPkg/Library/BaseCryptLibOnProtocolPpi/PeiCryptLib.c
>  create mode 100644
> CryptoPkg/Library/BaseCryptLibOnProtocolPpi/PeiCryptLib.inf
>  create mode 100644
> CryptoPkg/Library/BaseCryptLibOnProtocolPpi/SmmCryptLib.c
>  create mode 100644
> CryptoPkg/Library/BaseCryptLibOnProtocolPpi/SmmCryptLib.inf
>  create mode 100644 CryptoPkg/Private/Ppi/Crypto.h
>  copy 

Re: [edk2-devel] [PATCH 1/4] MdeModulePkg/SdMmcPciHcDxe: Enhance driver traces

[Wu, Hao A]

Hello Mateusz,

Try to provide some feedbacks before I can test the patch.

Some inline comments below:


> -Original Message-
> From: Albecki, Mateusz
> Sent: Monday, February 03, 2020 10:19 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas; Gao, Zhichao; Gao, Liming
> Subject: [PATCH 1/4] MdeModulePkg/SdMmcPciHcDxe: Enhance driver
> traces
> 
> To allow for easier debug of failing commands we
> have added a capability to print TRB and command
> packet when we start execution of the TRB(on
> DEBUG_VERBOSE level) and when the TRB failed to
> execute correctly(on DEBUG_ERROR level). Additionally
> we will also print error interrupt status and interrupt
> status register on failed SD command.
> 
> Cc: Hao A Wu 
> Cc: Marcin Wojtas 
> Cc: Zhichao Gao 
> Cc: Liming Gao 
> 
> Signed-off-by: Mateusz Albecki 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 87
> 
>  1 file changed, 87 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index b05c818462..959645bf26 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1643,6 +1643,82 @@ BuildAdmaDescTable (
>return EFI_SUCCESS;
>  }
> 
> +/**
> +  Prints the contents of the command packet to the debug port.
> +
> +  @param[in] DebugLevel  Debug level at which the packet should be
> printed.
> +  @param[in] Packet  Pointer to packet to print.
> +**/
> +VOID
> +SdMmcPrintPacket (
> +  IN UINT32   DebugLevel,
> +  IN EFI_SD_MMC_PASS_THRU_COMMAND_PACKET  *Packet
> +  )
> +{
> +  if (Packet == NULL) {
> +return;
> +  }
> +
> +  DEBUG ((DebugLevel, "Printing
> EFI_SD_MMC_PASS_THRU_COMMAND_PACKET\n"));
> +  if (Packet->SdMmcCmdBlk != NULL) {
> +DEBUG ((DebugLevel, "Command index: %d, argument: %X\n", Packet-
> >SdMmcCmdBlk->CommandIndex, Packet->SdMmcCmdBlk-
> >CommandArgument));
> +DEBUG ((DebugLevel, "Command type: %d, response type: %d\n",
> Packet->SdMmcCmdBlk->CommandType, Packet->SdMmcCmdBlk-
> >ResponseType));
> +  }
> +  if (Packet->SdMmcStatusBlk != NULL) {
> +DEBUG ((DebugLevel, "Response 0: %X, 1: %X, 2: %X, 3: %X\n",
> +   Packet->SdMmcStatusBlk->Resp0,
> +   Packet->SdMmcStatusBlk->Resp1,
> +   Packet->SdMmcStatusBlk->Resp2,
> +   Packet->SdMmcStatusBlk->Resp3
> +   ));
> +  }
> +  DEBUG ((DebugLevel, "Timeout: %d\n", Packet->Timeout));


Please update to use %ld for UINT64 here.


> +  DEBUG ((DebugLevel, "InDataBuffer: %X\n", Packet->InDataBuffer));
> +  DEBUG ((DebugLevel, "OutDataBuffer: %X\n", Packet->OutDataBuffer));


Please update to use %p for InDataBuffer/OutDataBuffer (VOID *).


> +  DEBUG ((DebugLevel, "InTransferLength: %d\n", Packet-
> >InTransferLength));
> +  DEBUG ((DebugLevel, "OutTransferLength: %d\n", Packet-
> >OutTransferLength));
> +  DEBUG ((DebugLevel, "TransactionStatus: %r\n", Packet-
> >TransactionStatus));
> +}
> +
> +/**
> +  Prints the contents of the TRB to the debug port.
> +
> +  @param[in] DebugLevel  Debug level at which the TRB should be printed.
> +  @param[in] Trb Pointer to the TRB structure.
> +**/
> +VOID
> +SdMmcPrintTrb (
> +  IN UINT32 DebugLevel,
> +  IN SD_MMC_HC_TRB  *Trb
> +  )
> +{
> +  if (Trb == NULL) {
> +return;
> +  }
> +
> +  DEBUG ((DebugLevel, "Printing SD_MMC_HC_TRB\n"));
> +  DEBUG ((DebugLevel, "Slot: %d\n", Trb->Slot));
> +  DEBUG ((DebugLevel, "BlockSize: %d\n", Trb->BlockSize));
> +  DEBUG ((DebugLevel, "Data: %X\n", Trb->Data));


Please update to use %p for Trb->Data (VOID *).


> +  DEBUG ((DebugLevel, "DataLen: %d\n", Trb->DataLen));
> +  DEBUG ((DebugLevel, "Read: %d\n", Trb->Read));
> +  DEBUG ((DebugLevel, "DataPhy: %X\n", Trb->DataPhy));


Please update to use %lX for Trb->DataPhy (EFI_PHYSICAL_ADDRESS).


> +  DEBUG ((DebugLevel, "DataMap: %X\n", Trb->DataMap));


Please update to use %p for Trb->DataMap (VOID *).


> +  DEBUG ((DebugLevel, "Mode: %d\n", Trb->Mode));
> +  DEBUG ((DebugLevel, "AdmaLengthMode: %d\n", Trb-
> >AdmaLengthMode));
> +  DEBUG ((DebugLevel, "Event: %d\n", Trb->Event));


Please update to use %p for Trb->Event (EFI_EVENT).


> +  DEBUG ((DebugLevel, "Started: %d\n", Trb->Started));
> +  DEBUG ((DebugLevel, "Timeout: %d\n", Trb->Timeout));


Please update to use %ld for Trb->Timeout (UINT64).


> +  DEBUG ((DebugLevel, "Retries: %d\n", Trb->Retries));
> +  DEBUG ((DebugLevel, "Adma32Desc: %X\n", Trb->Adma32Desc));
> +  DEBUG ((DebugLevel, "Adma64V3Desc: %X\n", Trb->Adma64V3Desc));
> +  DEBUG ((DebugLevel, "Adma64V4Desc: %X\n", Trb->Adma64V4Desc));
> +  DEBUG ((DebugLevel, "AdmaMap: %X\n", Trb->AdmaMap));


Please update to use %p for:
Trb->Adma32Desc
Trb->Adma64V3Desc
Trb->Adma64V4Desc
Trb->AdmaMap
(pointers)

Best Regards,
Hao Wu

> +  DEBUG 

Re: [edk2-devel] [PATCH 4/4] MdeModulePkg/SdMmcPciHcDxe: Fix PIO transfer mode

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Albecki, Mateusz
> Sent: Monday, February 03, 2020 10:19 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas; Gao, Zhichao; Gao, Liming
> Subject: [edk2-devel] [PATCH 4/4] MdeModulePkg/SdMmcPciHcDxe: Fix PIO
> transfer mode
> 
> Current driver does not support PIO transfer mode for
> commands other then tuning. This change adds the code
> to transfer PIO data.


Hello Mateusz,

Try to provide some feedbacks before I can test the patch.

One test request, is it possible for you to test the asynchronous transfer for
the PIO mode?

A possible method can be using an UEFI application to locate the BlockIO 2
protocol from a specific SD or eMMC device (which forced to PIO transfer mode).
And test with the WriteBlocksEx() & ReadBlocksEx() services to see if the RW
is successful.

Also, one more inline comment below:


> 
> Cc: Hao A Wu 
> Cc: Marcin Wojtas 
> Cc: Zhichao Gao 
> Cc: Liming Gao 
> 
> Signed-off-by: Mateusz Albecki 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   3 +
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 113
> +
>  2 files changed, 95 insertions(+), 21 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 15b7d12596..fd89306fab 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -157,6 +157,9 @@ typedef struct {
>UINT64  Timeout;
>UINT32  Retries;
> 
> +  BOOLEAN PioModeTransferCompleted;
> +  UINT32  PioBlockIndex;
> +
>SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
>SD_MMC_HC_ADMA_64_V3_DESC_LINE  *Adma64V3Desc;
>SD_MMC_HC_ADMA_64_V4_DESC_LINE  *Adma64V4Desc;
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 480a1664ea..43703974f7 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1711,6 +1711,8 @@ SdMmcPrintTrb (
>DEBUG ((DebugLevel, "CommandComplete: %d\n", Trb-
> >CommandComplete));
>DEBUG ((DebugLevel, "Timeout: %d\n", Trb->Timeout));
>DEBUG ((DebugLevel, "Retries: %d\n", Trb->Retries));
> +  DEBUG ((DebugLevel, "PioModeTransferCompleted: %d\n", Trb-
> >PioModeTransferCompleted));
> +  DEBUG ((DebugLevel, "PioBlockIndex: %d\n", Trb->PioBlockIndex));
>DEBUG ((DebugLevel, "Adma32Desc: %X\n", Trb->Adma32Desc));
>DEBUG ((DebugLevel, "Adma64V3Desc: %X\n", Trb->Adma64V3Desc));
>DEBUG ((DebugLevel, "Adma64V4Desc: %X\n", Trb->Adma64V4Desc));
> @@ -1762,6 +1764,8 @@ SdMmcCreateTrb (
>Trb->CommandComplete = FALSE;
>Trb->Timeout   = Packet->Timeout;
>Trb->Retries   = SD_MMC_TRB_RETRIES;
> +  Trb->PioModeTransferCompleted = FALSE;
> +  Trb->PioBlockIndex = 0;
>Trb->Private   = Private;
> 
>if ((Packet->InTransferLength != 0) && (Packet->InDataBuffer != NULL)) {
> @@ -2447,6 +2451,85 @@ SdMmcCheckCommandComplete (
>return EFI_NOT_READY;
>  }
> 
> +/**
> +  Transfers data from card using PIO method.
> +
> +  @param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA
> instance.
> +  @param[in] TrbThe pointer to the SD_MMC_HC_TRB instance.
> +  @param[in] IntStatus  Snapshot of the normal interrupt status register.
> +
> +  @retval EFI_SUCCESS   PIO transfer completed successfully.
> +  @retval EFI_NOT_READY PIO transfer completion still pending.
> +  @retval OthersPIO transfer failed to complete.
> +**/
> +EFI_STATUS
> +SdMmcTransferDataWithPio (
> +  IN SD_MMC_HC_PRIVATE_DATA  *Private,
> +  IN SD_MMC_HC_TRB   *Trb,
> +  IN UINT16  IntStatus
> +  )
> +{
> +  EFI_STATUS  Status;
> +  UINT16  Data16;
> +  UINT32  BlockCount;
> +
> +  BlockCount = (Trb->DataLen / Trb->BlockSize);
> +  if (Trb->DataLen % Trb->BlockSize != 0) {
> +BlockCount += 1;
> +  }
> +
> +  if (Trb->PioBlockIndex >= BlockCount) {
> +return EFI_SUCCESS;
> +  }
> +
> +  if (Trb->Read) {
> +if ((IntStatus & BIT5) == 0) {
> +  return EFI_NOT_READY;
> +}
> +Data16 = BIT5;
> +SdMmcHcRwMmio (Private->PciIo, Trb->Slot,
> SD_MMC_HC_NOR_INT_STS, FALSE, sizeof (Data16), );
> +
> +Status = Private->PciIo->Mem.Read (
> +   Private->PciIo,
> +   EfiPciIoWidthFifoUint8,
> +   Trb->Slot,
> +   SD_MMC_HC_BUF_DAT_PORT,
> +   Trb->BlockSize,
> +   (VOID*)((UINT8*)Trb->Data + (Trb->BlockSize * Trb-
> >PioBlockIndex))
> +   );


The read (write) process will be:

1. Wait for the Buffer Read (Write) Ready to set;
2. Clear the Buffer Read (Write) Ready bit;
3. Access the Buffer Data Port register 'Trb->BlockSize' 

Re: [edk2-devel] [PATCH 2/4] MdeModulePkg/SdMmcPciHcDxe: Read response on command completion

[Wu, Hao A]

One question below:


> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Albecki, Mateusz
> Sent: Monday, February 03, 2020 10:19 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas; Gao, Zhichao; Gao, Liming
> Subject: [edk2-devel] [PATCH 2/4] MdeModulePkg/SdMmcPciHcDxe: Read
> response on command completion
> 
> SdMmcPciHcDxe driver used to read response only after
> command and data transfer completed. According to SDHCI
> specification response data is ready after the command
> complete status is set by the host controller. Getting
> the response data early will help debugging the cases
> when command completed but data transfer timed out.
> 
> Cc: Hao A Wu 
> Cc: Marcin Wojtas 
> Cc: Zhichao Gao 
> Cc: Liming Gao 
> 
> Signed-off-by: Mateusz Albecki 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   1 +
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 201
> +++--
>  2 files changed, 144 insertions(+), 58 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 5bc3577ba2..15b7d12596 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -153,6 +153,7 @@ typedef struct {
> 
>EFI_EVENT   Event;
>BOOLEAN Started;
> +  BOOLEAN CommandComplete;
>UINT64  Timeout;
>UINT32  Retries;
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 959645bf26..3dfaae8542 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1708,6 +1708,7 @@ SdMmcPrintTrb (
>DEBUG ((DebugLevel, "AdmaLengthMode: %d\n", Trb->AdmaLengthMode));
>DEBUG ((DebugLevel, "Event: %d\n", Trb->Event));
>DEBUG ((DebugLevel, "Started: %d\n", Trb->Started));
> +  DEBUG ((DebugLevel, "CommandComplete: %d\n", Trb-
> >CommandComplete));
>DEBUG ((DebugLevel, "Timeout: %d\n", Trb->Timeout));
>DEBUG ((DebugLevel, "Retries: %d\n", Trb->Retries));
>DEBUG ((DebugLevel, "Adma32Desc: %X\n", Trb->Adma32Desc));
> @@ -1758,6 +1759,7 @@ SdMmcCreateTrb (
>Trb->Packet= Packet;
>Trb->Event = Event;
>Trb->Started   = FALSE;
> +  Trb->CommandComplete = FALSE;
>Trb->Timeout   = Packet->Timeout;
>Trb->Retries   = SD_MMC_TRB_RETRIES;
>Trb->Private   = Private;
> @@ -2352,6 +2354,99 @@ SdMmcCheckAndRecoverErrors (
>return ErrorStatus;
>  }
> 
> +/**
> +  Reads the response data into the TRB buffer.
> +  This function assumes that caller made sure that
> +  command has completed.
> +
> +  @param[in] Private  A pointer to the SD_MMC_HC_PRIVATE_DATA
> instance.
> +  @param[in] Trb  The pointer to the SD_MMC_HC_TRB instance.
> +
> +  @retval EFI_SUCCESS  Response read successfully.
> +  @retval Others   Failed to get response.
> +**/
> +EFI_STATUS
> +SdMmcGetResponse (
> +  IN SD_MMC_HC_PRIVATE_DATA  *Private,
> +  IN SD_MMC_HC_TRB   *Trb
> +  )
> +{
> +  EFI_SD_MMC_PASS_THRU_COMMAND_PACKET  *Packet;
> +  UINT8Index;
> +  UINT32   Response[4];
> +  EFI_STATUS   Status;
> +
> +  Packet = Trb->Packet;
> +
> +  if (Packet->SdMmcCmdBlk->CommandType == SdMmcCommandTypeBc) {
> +return EFI_SUCCESS;
> +  }
> +
> +  for (Index = 0; Index < 4; Index++) {
> +Status = SdMmcHcRwMmio (
> +   Private->PciIo,
> +   Trb->Slot,
> +   SD_MMC_HC_RESPONSE + Index * 4,
> +   TRUE,
> +   sizeof (UINT32),
> +   [Index]
> +   );
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +}
> +  CopyMem (Packet->SdMmcStatusBlk, Response, sizeof (Response));
> +
> +  return EFI_SUCCESS;
> +}
> +
> +/**
> +  Checks if the command completed. If the command
> +  completed it gets the response and records the
> +  command completion in the TRB.
> +
> +  @param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA
> instance.
> +  @param[in] TrbThe pointer to the SD_MMC_HC_TRB instance.
> +  @param[in] IntStatus  Snapshot of the normal interrupt status register.
> +
> +  @retval EFI_SUCCESS   Command completed successfully.
> +  @retval EFI_NOT_READY Command completion still pending.
> +  @retval OthersCommand failed to complete.
> +**/
> +EFI_STATUS
> +SdMmcCheckCommandComplete (
> +  IN SD_MMC_HC_PRIVATE_DATA  *Private,
> +  IN SD_MMC_HC_TRB   *Trb,
> +  IN UINT16  IntStatus
> +  )
> +{
> +  UINT16  Data16;
> +  EFI_STATUS  Status;
> +
> +  if ((IntStatus & BIT0) != 0) {
> +Data16 = BIT0;
> +Status = SdMmcHcRwMmio (
> +   

Re: [edk2-devel] [PATCH 3/4] MdeModulePkg/SdMmcPciHcDxe: Refactor data transfer completion

[Wu, Hao A]

Just a similar question to PATCH 2/4 below:


> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Albecki, Mateusz
> Sent: Monday, February 03, 2020 10:19 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas; Gao, Zhichao; Gao, Liming
> Subject: [edk2-devel] [PATCH 3/4] MdeModulePkg/SdMmcPciHcDxe:
> Refactor data transfer completion
> 
> This patch refactors the way in which the driver will check
> the data transfer completion. Data transfer related
> functionalities have been moved to separate function.
> 
> Cc: Hao A Wu 
> Cc: Marcin Wojtas 
> Cc: Zhichao Gao 
> Cc: Liming Gao 
> 
> Signed-off-by: Mateusz Albecki 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 181
> ++-
>  1 file changed, 112 insertions(+), 69 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 3dfaae8542..480a1664ea 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -2447,6 +2447,112 @@ SdMmcCheckCommandComplete (
>return EFI_NOT_READY;
>  }
> 
> +/**
> +  Update the SDMA address on the SDMA buffer boundary interrupt.
> +
> +  @param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA
> instance.
> +  @param[in] TrbThe pointer to the SD_MMC_HC_TRB instance.
> +
> +  @retval EFI_SUCCESS  Updated SDMA buffer address.
> +  @retval Others   Failed to update SDMA buffer address.
> +**/
> +EFI_STATUS
> +SdMmcUpdateSdmaAddress (
> +  IN SD_MMC_HC_PRIVATE_DATA  *Private,
> +  IN SD_MMC_HC_TRB   *Trb
> +  )
> +{
> +  UINT64  SdmaAddr;
> +  EFI_STATUS  Status;
> +
> +  SdmaAddr = SD_MMC_SDMA_ROUND_UP ((UINTN)Trb->DataPhy,
> SD_MMC_SDMA_BOUNDARY);
> +
> +  if (Private->ControllerVersion[Trb->Slot] >= SD_MMC_HC_CTRL_VER_400)
> {
> +Status = SdMmcHcRwMmio (
> +   Private->PciIo,
> +   Trb->Slot,
> +   SD_MMC_HC_ADMA_SYS_ADDR,
> +   FALSE,
> +   sizeof (UINT64),
> +   
> +   );
> +  } else {
> +Status = SdMmcHcRwMmio (
> +   Private->PciIo,
> +   Trb->Slot,
> +   SD_MMC_HC_SDMA_ADDR,
> +   FALSE,
> +   sizeof (UINT32),
> +   
> +   );
> +  }
> +
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  Trb->DataPhy = (UINT64)(UINTN)SdmaAddr;
> +  return EFI_SUCCESS;
> +}
> +
> +/**
> +  Checks if the data transfer completed and performs any actions
> +  neccessary to continue the data transfer such as SDMA system
> +  address fixup or PIO data transfer.
> +
> +  @param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA
> instance.
> +  @param[in] TrbThe pointer to the SD_MMC_HC_TRB instance.
> +  @param[in] IntStatus  Snapshot of the normal interrupt status register.
> +
> +  @retval EFI_SUCCESS   Data transfer completed successfully.
> +  @retval EFI_NOT_READY Data transfer completion still pending.
> +  @retval OthersData transfer failed to complete.
> +**/
> +EFI_STATUS
> +SdMmcCheckDataTransfer (
> +  IN SD_MMC_HC_PRIVATE_DATA  *Private,
> +  IN SD_MMC_HC_TRB   *Trb,
> +  IN UINT16  IntStatus
> +  )
> +{
> +  UINT16  Data16;
> +  EFI_STATUS  Status;
> +
> +  if ((IntStatus & BIT1) != 0) {
> +Data16 = BIT1;
> +Status = SdMmcHcRwMmio (
> +   Private->PciIo,
> +   Trb->Slot,
> +   SD_MMC_HC_NOR_INT_STS,
> +   FALSE,
> +   sizeof (Data16),
> +   
> +   );


Cleaning the Transfer Complete (BIT1) right after checking it is more aligned
with the spec, right?

Best Regards,
Hao Wu


> +return Status;
> +  }
> +
> +  if ((Trb->Mode == SdMmcSdmaMode) && ((IntStatus & BIT3) != 0)) {
> +Data16 = BIT3;
> +Status = SdMmcHcRwMmio (
> +   Private->PciIo,
> +   Trb->Slot,
> +   SD_MMC_HC_NOR_INT_STS,
> +   FALSE,
> +   sizeof (Data16),
> +   
> +   );
> +if (EFI_ERROR (Status)) {
> +  return Status;
> +}
> +Status = SdMmcUpdateSdmaAddress (Private, Trb);
> +if (EFI_ERROR (Status)) {
> +  return Status;
> +}
> +  }
> +
> +  return EFI_NOT_READY;
> +}
> +
>  /**
>Check the TRB execution result.
> 
> @@ -2467,7 +2573,6 @@ SdMmcCheckTrbResult (
>EFI_STATUS  Status;
>EFI_SD_MMC_PASS_THRU_COMMAND_PACKET *Packet;
>UINT16  IntStatus;
> -  UINT64  SdmaAddr;
>UINT32  PioLength;
> 
>Packet  = Trb->Packet;
> @@ -2530,80 +2635,18 @@ SdMmcCheckTrbResult (
>  Status = SdMmcCheckCommandComplete (Private, Trb, IntStatus);
>  if (EFI_ERROR (Status)) {
>goto Done;
> -} else {
> -  //
> 

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

[Yao, Jiewen]

Thank you Mike.

> -Original Message-
> From: Kinney, Michael D 
> Sent: Wednesday, February 5, 2020 9:04 AM
> To: Yao, Jiewen ; devel@edk2.groups.io; Sukerkar,
> Amol N ; Kinney, Michael D
> 
> Cc: Wang, Jian J 
> Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib: Implement Unified Hash
> Calculation API
> 
> Jiewen,
> 
> Thanks for pointing to the content in MdePkg.
> 
> I agree that we could include 
> in BaseHashApiLib implementation and use the subset of
> TPM_ALG_* define values for both the lib implementation
> and the PCD description.  This will allow us to remove
> the extra #defines from the HashApiLib.h class.
> 
> Mike
> 
> > -Original Message-
> > From: Yao, Jiewen 
> > Sent: Tuesday, February 4, 2020 2:54 PM
> > To: Kinney, Michael D ;
> > devel@edk2.groups.io; Sukerkar, Amol N
> > 
> > Cc: Wang, Jian J 
> > Subject: RE: [Patch v10 2/2] CryptoPkg/BaseHashApiLib:
> > Implement Unified Hash Calculation API
> >
> > Mike
> > The problem of defining a set of algo ID is that I have
> > to remember the ID.
> > I feel frustrated whenever I need match one ID to the
> > other ID.
> >
> > Currently, UEFI secure boot and TCG trusted boot are
> > important feature. If we can align to one of them, it
> > is easier. I believe if we have a consistent ID
> > mapping, it will be much better for developer.
> >
> > Current TPM20.h is defined in MdePkg (not in
> > SecurityPkg) and is considered as an industry standard.
> > I do not see any dependency issue.
> >
> > We can define a new set - not a technical problem. I am
> > just not sure why we have to. Or we can define it with
> > the same value as TPM. See below list. I believe it
> > will cover majority of current usage and current
> > standard.
> > > > > +  # 0x0004- SHA1.
> > > > > +  # 0x000B- SHA256.
> > > > > +  # 0x000C- SHA384.
> > > > > +  # 0x000D- SHA512.
> > > > > +  # 0x0012- SM3_256.
> > > > > +  # 0x0027- SHA3_256.
> > > > > +  # 0x0028- SHA3_384.
> > > > > +  # 0x0029- SHA3_512.
> >
> >
> >
> >
> > > -Original Message-
> > > From: Kinney, Michael D 
> > > Sent: Wednesday, February 5, 2020 12:26 AM
> > > To: Yao, Jiewen ;
> > devel@edk2.groups.io; Kinney,
> > > Michael D ; Sukerkar,
> > Amol N
> > > 
> > > Cc: Wang, Jian J 
> > > Subject: RE: [Patch v10 2/2]
> > CryptoPkg/BaseHashApiLib: Implement Unified Hash
> > > Calculation API
> > >
> > > Jiewen,
> > >
> > > I think UINT8 is fine.  We can change default to 0x04
> > in DEC file.
> > >
> > > I will let Amol comment on why MD4 and MD5 are
> > included.  If
> > > they are not required, then I agree they should be
> > removed.
> > >
> > > I do not see a reason to align with TCG spec.  The
> > HashApiLib
> > > is a layer on top of BaseCryptLib and the use of hash
> > algorithms
> > > is not limited to TCG related content.  The
> > BaseCryptLib
> > > could potentially adopt hash algorithms that are not
> > defined
> > > in the TCG specification.  We also do not want
> > CryptoPkg to
> > > depend on the SecurityPkg.
> > >
> > > Thanks,
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: Yao, Jiewen 
> > > > Sent: Monday, February 3, 2020 6:54 PM
> > > > To: Kinney, Michael D ;
> > > > devel@edk2.groups.io
> > > > Cc: Sukerkar, Amol N ;
> > Wang,
> > > > Jian J 
> > > > Subject: RE: [Patch v10 2/2]
> > CryptoPkg/BaseHashApiLib:
> > > > Implement Unified Hash Calculation API
> > > >
> > > > Thanks Mike, to cover us during Chinese New Year
> > > > holiday.
> > > >
> > > > I am just back from vocation. A minor comment:
> > > >
> > > > The PcdHashApiLibPolicy is UINT8, but the value is
> > > > shown as 32bit 0x0004.
> > > >
> > > > There are couple of ways to enhance:
> > > > 1) Define UINT8, and use 8bit style 0x04.
> > > > 2) Define UINT32, and use 32bit style 0x0004.
> > > > 3) Define UINT16 (match TCG definition), and use
> > TCG
> > > > defined value. (Tpm20.h)
> > > > #define TPM_ALG_SHA1   (TPM_ALG_ID)(0x0004)
> > > > #define TPM_ALG_SHA256 (TPM_ALG_ID)(0x000B)
> > > > #define TPM_ALG_SHA384 (TPM_ALG_ID)(0x000C)
> > > > #define TPM_ALG_SHA512 (TPM_ALG_ID)(0x000D)
> > > > #define TPM_ALG_SM3_256(TPM_ALG_ID)(0x0012)
> > > >
> > > > MD4 and MD5 are known as insecure and deprecated. I
> > > > doubt if we want to add such support. (I strong
> > > > recommend NO).
> > > >
> > > > If we can remove MD4 and MD5, I think we can use
> > #3.
> > > >
> > > > Thank you
> > > > Yao Jiewen
> > > >
> > > > > -Original Message-
> > > > > From: Kinney, Michael D
> > 
> > > > > Sent: Tuesday, February 4, 2020 7:36 AM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Sukerkar, Amol N ;
> > > > Yao, Jiewen
> > > > > ; Wang, Jian J
> > > > 
> > > > > Subject: [Patch v10 2/2]
> > CryptoPkg/BaseHashApiLib:
> > > > Implement Unified Hash
> > > > > Calculation API
> > > > >
> > > > > From: Amol N Sukerkar 
> > > > >
> > > > >
> > 

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

[PierreGondois]

Hello Liming,

>  I think below three configurations are common. With this patch, they can 
> work fine, right?
[1] Windows - GCC- GNUmake
[2] Windows - VS2017 - nmake
[3] Linux   - GCC5   - GNUmake

I tested the following setups:
  * On AARCH64 - DEBUG build - [ShellPkg], configurations [1], [2] and [3] are 
working well.
  * On [IA32|X64] - DEBUG build - [ShellPkg], configurations [2] and [3] are 
working well.
  * On [IA32|X64] - DEBUG build - [ShellPkg], configuration [1]  fails because 
of unsupported compiler options from mingw-gcc. These compiler issues are not 
related with the patch. This configuration could not work before this patch and 
making this configuration works is beyond the scope of this patch.

> And, do you mean Windows - GCC - GNUmake is still blocked by the change 
> "0c3e8e9947a6c13b4327dd11b20acb95441701cf BaseTools: Enhance Basetool for 
> incremental build"?
We are mainly using the configuration [1] to build edk2 for AARCH64. We believe 
the change introduced by 0c3e8e9947a6c13b4327dd11b20acb95441701cf made our 
build stop working. This patch would allow it to work again.

Regards,
Pierre

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Liming Gao via 
Groups.Io
Sent: 04 February 2020 13:50
To: devel@edk2.groups.io; Pierre Gondois 
Cc: Feng, Bob C ; Sami Mujawar ; nd 

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

Pierre:
  I think below three configurations are common. With this patch, they can work 
fine, right? And, do you mean Windows - GCC- GNUmake is still blocked by 
the change "0c3e8e9947a6c13b4327dd11b20acb95441701cf BaseTools: Enhance 
Basetool for incremental build"?

> Windows - GCC- GNUmake
> Windows - VS2017 - nmake
> Linux   - GCC5   - GNUmake

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of 
> PierreGondois
> Sent: Tuesday, February 4, 2020 8:03 PM
> To: devel@edk2.groups.io; Pierre Gondois 
> Cc: Feng, Bob C ; Gao, Liming 
> ; Sami Mujawar ; nd 
> 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] BaseTools: Rationalise 
> makefile generation
> 
> Hello Liming and Bob,
> To answer Liming's questions, I am building the DynamicTablesPkg with 
> the patch with the AARCH64-DEBUG and the following
> configurations:
> Windows - GCC- GNUmake
> Windows - GCC- nmake
> Windows - VS2017 - GNUmake
> Windows - VS2017 - nmake
> Linux   - GCC5   - GNUmake
> For the record, when building with the Windows-VS2017-GNUmake configuration, 
> the *_*_*_MAKE_FLAG(S) variable is set to "/nologo".
> As this is a nmake specific flag, it has to be removed when using 
> GNUmake. Some warning flags also need to be slightly modified when building 
> with VS2017.
> To modify the type of make tool to use (GNUmake or nmake), I modify the 
> following variable in Conf/tools_def.txt:
> *_[GCC5|VS2017]_*_MAKE_PATH = [nmake|GNUmake]
> 
> I am building the ShellPkg with the patch and a small modification on 
> how nasm files are added for IA32 and X64 for the following
> configurations:
> Windows - VS2017 - GNUmake
> Windows - VS2017 - nmake
> Linux   - GCC- GNUmake
> 
> Unfortunately, the gcc compiler available on windows doesn't provide all the 
> options of the one available on linux. For instances:
>  * When building ShellPkg-DEBUG build-X64 -Windows-GCC-[nmake], the 
> "-mcmodel=small" option provided is not supported.
>  * When building ShellPkg-DEBUG build-IA32-Windows-GCC-[nmake], the 
> "-m,elf_i386" option provided is not supported.
> These issues are related to the compiler and not to the patch.
> 
> The Windows-GCC-GNUmake configuration is very important for Arm. This 
> configuration was working fine until patch 
> "0c3e8e9947a6c13b4327dd11b20acb95441701cf BaseTools: Enhance Basetool for 
> incremental build" was merged in edk2.
> 
> Regards,
> Pierre
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of 
> PierreGondois via Groups.Io
> Sent: 04 February 2020 12:01
> To: devel@edk2.groups.io
> Cc: Pierre Gondois ; bob.c.f...@intel.com; 
> liming@intel.com; Sami Mujawar ; Pierre 
> Gondois ; nd 
> Subject: [edk2-devel] [PATCH v2 1/1] BaseTools: Rationalise makefile 
> generation
> 
> From: Pierre Gondois 
> 
> The GenMake.py script tests the platform environment to determine the 
> type of makefile that needs to be generated. If a Windows build host is 
> detected, the makefile generated is of Nmake type. Otherwise a GNUmake type 
> is generated.
> 
> Furthermore, the ___MAKE_PATH
> option in tools_def.template defines the make tool to use.
> E.g.: for VS2017 this is configured to use Nmake, cf.
> *_VS2017_*_MAKE_PATH = DEF(VS2017_BIN_HOST)\nmake.exe while for GCC5 it is 
> setup to use GNU make.
> *_GCC5_*_MAKE_PATH = DEF(GCC_HOST_PREFIX)make
> 
> This prevents using the GCC compiler toolchain on a Windows build host.
> 
> To address this issue this patch introduces 2 factors to determine the 
> generated makefile output.
>   1. Platform -> to 

Re: [edk2-devel] [Patch] CryptoPkg/BaseCryptLibNull: Add missing HkdfSha256ExtractAndExpand()

[Wang, Jian J]

The copyright year of file CryptHkdfNull.c was not updated. With it addressed,

Reviewed-by: Jian J Wang 

Regards,
Jian

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael D
> Kinney
> Sent: Thursday, January 30, 2020 8:17 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J ; Lu, XiaoyuX 
> Subject: [edk2-devel] [Patch] CryptoPkg/BaseCryptLibNull: Add missing
> HkdfSha256ExtractAndExpand()
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2493
> 
> The BaseCryptLib was expanded to add the HkdfSha256ExtractAndExpand()
> service in the following commit:
> 
> https://github.com/tianocore/edk2/commit/4b1b7c1913092d73d689d8086dcfa
> 579c0217dc8
> 
> When BaseCryptLibNull was added in the commit below, this new
> service was not included.
> 
> https://github.com/tianocore/edk2/commit/d95de082da01f4a4cb3ebf87e1597
> 2a12d0f8d53
> 
> Cc: Jian J Wang 
> Cc: Xiaoyu Lu 
> Signed-off-by: Michael D Kinney 
> ---
>  .../BaseCryptLibNull/BaseCryptLibNull.inf |  3 +-
>  .../BaseCryptLibNull/Kdf/CryptHkdfNull.c  | 43 +++
>  2 files changed, 45 insertions(+), 1 deletion(-)
>  create mode 100644 CryptoPkg/Library/BaseCryptLibNull/Kdf/CryptHkdfNull.c
> 
> diff --git a/CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.inf
> b/CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.inf
> index 1e4807968a..8f53b0dfd0 100644
> --- a/CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.inf
> +++ b/CryptoPkg/Library/BaseCryptLibNull/BaseCryptLibNull.inf
> @@ -6,7 +6,7 @@
>  #  This external input must be validated carefully to avoid security issues 
> such as
>  #  buffer overflow or integer overflow.
>  #
> -#  Copyright (c) 2009 - 2019, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2009 - 2020, Intel Corporation. All rights reserved.
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -37,6 +37,7 @@ [Sources]
>Hmac/CryptHmacMd5Null.c
>Hmac/CryptHmacSha1Null.c
>Hmac/CryptHmacSha256Null.c
> +  Kdf/CryptHkdfNull.c
>Cipher/CryptAesNull.c
>Cipher/CryptTdesNull.c
>Cipher/CryptArc4Null.c
> diff --git a/CryptoPkg/Library/BaseCryptLibNull/Kdf/CryptHkdfNull.c
> b/CryptoPkg/Library/BaseCryptLibNull/Kdf/CryptHkdfNull.c
> new file mode 100644
> index 00..19d795a4cc
> --- /dev/null
> +++ b/CryptoPkg/Library/BaseCryptLibNull/Kdf/CryptHkdfNull.c
> @@ -0,0 +1,43 @@
> +/** @file
> +  HMAC-SHA256 KDF Wrapper Implementation which does not provide real
> capabilities.
> +
> +Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#include 
> +#include 
> +
> +/**
> +  Derive key data using HMAC-SHA256 based KDF.
> +
> +  @param[in]   Key  Pointer to the user-supplied key.
> +  @param[in]   KeySize  Key size in bytes.
> +  @param[in]   Salt Pointer to the salt(non-secret) value.
> +  @param[in]   SaltSize Salt size in bytes.
> +  @param[in]   Info Pointer to the application specific info.
> +  @param[in]   InfoSize Info size in bytes.
> +  @param[out]  Out  Pointer to buffer to receive hkdf value.
> +  @param[in]   OutSize  Size of hkdf bytes to generate.
> +
> +  @retval TRUE   Hkdf generated successfully.
> +  @retval FALSE  Hkdf generation failed.
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +HkdfSha256ExtractAndExpand (
> +  IN   CONST UINT8  *Key,
> +  IN   UINTNKeySize,
> +  IN   CONST UINT8  *Salt,
> +  IN   UINTNSaltSize,
> +  IN   CONST UINT8  *Info,
> +  IN   UINTNInfoSize,
> +  OUT  UINT8*Out,
> +  IN   UINTNOutSize
> +  )
> +{
> +  ASSERT (FALSE);
> +  return FALSE;
> +}
> --
> 2.21.0.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53727): https://edk2.groups.io/g/devel/message/53727
Mute This Topic: https://groups.io/mt/70261270/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Liming Gao]

Pierre:
  I think below three configurations are common. With this patch, they can work 
fine, right? And, do you mean Windows - GCC- GNUmake is still blocked by 
the change "0c3e8e9947a6c13b4327dd11b20acb95441701cf BaseTools: Enhance 
Basetool for incremental build"?

> Windows - GCC- GNUmake
> Windows - VS2017 - nmake
> Linux   - GCC5   - GNUmake

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of PierreGondois
> Sent: Tuesday, February 4, 2020 8:03 PM
> To: devel@edk2.groups.io; Pierre Gondois 
> Cc: Feng, Bob C ; Gao, Liming ; 
> Sami Mujawar ; nd
> 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] BaseTools: Rationalise makefile 
> generation
> 
> Hello Liming and Bob,
> To answer Liming's questions, I am building the DynamicTablesPkg with the 
> patch with the AARCH64-DEBUG and the following
> configurations:
> Windows - GCC- GNUmake
> Windows - GCC- nmake
> Windows - VS2017 - GNUmake
> Windows - VS2017 - nmake
> Linux   - GCC5   - GNUmake
> For the record, when building with the Windows-VS2017-GNUmake configuration, 
> the *_*_*_MAKE_FLAG(S) variable is set to "/nologo".
> As this is a nmake specific flag, it has to be removed when using GNUmake. 
> Some warning flags also need to be slightly modified when
> building with VS2017.
> To modify the type of make tool to use (GNUmake or nmake), I modify the 
> following variable in Conf/tools_def.txt:
> *_[GCC5|VS2017]_*_MAKE_PATH = [nmake|GNUmake]
> 
> I am building the ShellPkg with the patch and a small modification on how 
> nasm files are added for IA32 and X64 for the following
> configurations:
> Windows - VS2017 - GNUmake
> Windows - VS2017 - nmake
> Linux   - GCC- GNUmake
> 
> Unfortunately, the gcc compiler available on windows doesn't provide all the 
> options of the one available on linux. For instances:
>  * When building ShellPkg-DEBUG build-X64 -Windows-GCC-[nmake], the 
> "-mcmodel=small" option provided is not supported.
>  * When building ShellPkg-DEBUG build-IA32-Windows-GCC-[nmake], the 
> "-m,elf_i386" option provided is not supported.
> These issues are related to the compiler and not to the patch.
> 
> The Windows-GCC-GNUmake configuration is very important for Arm. This 
> configuration was working fine until patch
> "0c3e8e9947a6c13b4327dd11b20acb95441701cf BaseTools: Enhance Basetool for 
> incremental build" was merged in edk2.
> 
> Regards,
> Pierre
> 
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of PierreGondois 
> via Groups.Io
> Sent: 04 February 2020 12:01
> To: devel@edk2.groups.io
> Cc: Pierre Gondois ; bob.c.f...@intel.com; 
> liming@intel.com; Sami Mujawar
> ; Pierre Gondois ; nd 
> 
> Subject: [edk2-devel] [PATCH v2 1/1] BaseTools: Rationalise makefile 
> generation
> 
> From: Pierre Gondois 
> 
> The GenMake.py script tests the platform environment to determine the type of 
> makefile that needs to be generated. If a Windows build
> host is detected, the makefile generated is of Nmake type. Otherwise a 
> GNUmake type is generated.
> 
> Furthermore, the ___MAKE_PATH
> option in tools_def.template defines the make tool to use.
> E.g.: for VS2017 this is configured to use Nmake, cf.
> *_VS2017_*_MAKE_PATH = DEF(VS2017_BIN_HOST)\nmake.exe while for GCC5 it is 
> setup to use GNU make.
> *_GCC5_*_MAKE_PATH = DEF(GCC_HOST_PREFIX)make
> 
> This prevents using the GCC compiler toolchain on a Windows build host.
> 
> To address this issue this patch introduces 2 factors to determine the 
> generated makefile output.
>   1. Platform -> to determine shell commands used
>  in makefile.
>   2. MakeTool -> to determine the type of makefile
>  that needs to be generated.
> 
> Signed-off-by: Pierre Gondois 
> Signed-off-by: Sami Mujawar 
> ---
> 
> The changes can be seen at 
> https://github.com/PierreARM/edk2/tree/720_BaseTools_Rationalise_makefile_generation_v2
> 
> Notes:
> v2:
>   - Rebase on latest master [Pierre]
> 
>  BaseTools/Source/Python/AutoGen/GenMake.py | 122 ++--
>  BaseTools/Source/Python/AutoGen/IncludesAutoGen.py |  34 +++---
>  BaseTools/Source/Python/build/build.py |   7 +-
>  3 files changed, 88 insertions(+), 75 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
> b/BaseTools/Source/Python/AutoGen/GenMake.py
> index 
> ba199c1aa73dc46856b41c13e07e3d9770081acd..f49c765c791d57c06fcccf7059b37a018dc68ae6
>  100755
> --- a/BaseTools/Source/Python/AutoGen/GenMake.py
> +++ b/BaseTools/Source/Python/AutoGen/GenMake.py
> @@ -2,6 +2,7 @@
>  # Create makefile for MS nmake and GNU make  #  # Copyright (c) 2007 - 2020, 
> Intel Corporation. All rights reserved.
> +# Copyright (c) 2020, ARM Limited. All rights reserved.
>  # SPDX-License-Identifier: BSD-2-Clause-Patent  #
> 
> @@ -52,13 +53,6 @@ gIncludeMacroConversion = {
>"EFI_PPI_DEPENDENCY"  :   gPpiDefinition,
>  }
> 
> -## default makefile type
> -gMakeType = ""
> -if 

Re: [edk2-devel] [PATCH v2 1/1] BaseTools: Build ASL files before C files

[Liming Gao]

Pierre:
  I see you use ':' to describe the dependency between the different source 
file. This is makefile syntax for the dependency. If one file depends on more 
than one files, other files will list after this file with the separator space 
' '. So, I think the example should be like below.

> [Sources]
>   FileName1.X
>   FileName2.Y : FileName1.X
>   FileName3.Z : FileName1.X  FileName3.Y

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of PierreGondois
> Sent: Thursday, January 23, 2020 1:33 AM
> To: Pierre Gondois ; devel@edk2.groups.io
> Cc: ard.biesheu...@linaro.org; Feng, Bob C ; Gao, 
> Liming ; Sami Mujawar
> ; nd 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] BaseTools: Build ASL files before C 
> files
> 
> Hello everyone,
> Do you have any input on the patch?
> 
> Regards,
> Pierre
> 
> -Original Message-
> From: PierreGondois 
> Sent: 14 January 2020 18:46
> To: devel@edk2.groups.io
> Cc: Pierre Gondois ; ard.biesheu...@linaro.org; 
> bob.c.f...@intel.com; liming@intel.com; Sami
> Mujawar ; nd 
> Subject: [PATCH v2 1/1] BaseTools: Build ASL files before C files
> 
> From: Pierre Gondois 
> 
> The dependencies for C files are satisfied by the build system.
> However, there are use cases where source files with different languages are 
> inter-dependent. The EDKII build framework currently
> doesn't have options to specify such dependencies.
> E.g. It may be necessary to specify the build order between
>  ASL files and C files. The use case being that the AML
>  blob generated by compiling the ASL files is loaded and
>  parsed by some C code.
> 
> This patch allows to describe dependencies between files listed in the 
> '[Sources]' section of '.inf' files. The list of source files to build
> prior are colon separated (':'), e.g.:
> [Sources]
>   FileName1.X
>   FileName2.Y : FileName1.X
>   FileName3.Z : FileName1.X : FileName3.Z
> 
> In the example above:
>   * FileName1.X will be built prior to FileName2.Y.
>   * FileName1.X and FileName2.Y will be built prior to
> FileName3.Z.
> 
> This does not affect the file specific build options, which are pipe 
> separated, e.g.:
>   FileName2.Y | GCC : FileName1.X
> 
> The list of colon separated files must be part of the module, i.e. they must 
> be present in the [Sources] section.
> 
> Their file extension must be described in the 
> BaseTools/Conf/build_rule.template file, and generate an output file, i.e. 
> have a non-
> empty '' section.
> 
> Declaring a dependency in the [Sources] sections leads to the creation of 
> makefile rules between these files in the build. The makefile
> rule is between the generated files.
> E.g.:
>   FileName1.X generates FileName1.objx
>   FileName2.Y generates FileName2.objy
>   Then
> FileName2.Y : FileName1.X
>   will create the following makefile rule:
> FileName2.objy : FileName1.objx
> 
> INF Specification updates:
> s3.2.1, "Common Definitions":
>::= ":"
>  ::=   
> 
> s2.5, "[Sources] Section":
>   To describe a build order dependency between source
>   files, specify the source files to build prior by
>   listing them, colon separated.
>::=  [] []*
>::=  [FileNameDependency]
> 
> Signed-off-by: Pierre Gondois 
> ---
> 
> The changes can be seen at 
> https://github.com/PierreARM/edk2/tree/676_build_asl_first_v2
> 
> Notes:
> v2:
>   - Enable file dependencies in .if files [Pierre]
> 
>  BaseTools/Source/Python/AutoGen/BuildEngine.py  |  6 
>  BaseTools/Source/Python/AutoGen/GenMake.py  |  7 +
>  BaseTools/Source/Python/AutoGen/ModuleAutoGen.py| 17 +++
>  BaseTools/Source/Python/Common/DataType.py  |  3 +-
>  BaseTools/Source/Python/Common/Misc.py  |  3 ++
>  BaseTools/Source/Python/Workspace/InfBuildData.py   | 32 ++--
>  BaseTools/Source/Python/Workspace/MetaFileParser.py | 18 +--
>  7 files changed, 81 insertions(+), 5 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/BuildEngine.py 
> b/BaseTools/Source/Python/AutoGen/BuildEngine.py
> index 
> d602414ca41f37155c9c6d00eec54ea3918840c3..687617756619a5b547f18c99c4773842a8328ae8
>  100644
> --- a/BaseTools/Source/Python/AutoGen/BuildEngine.py
> +++ b/BaseTools/Source/Python/AutoGen/BuildEngine.py
> @@ -2,6 +2,8 @@
>  # The engine for building files
>  #
>  # Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2020, ARM Limited. All rights reserved. #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent  #
> 
> @@ -53,6 +55,7 @@ class TargetDescBlock(object):
>  self.Outputs = Outputs
>  self.Commands = Commands
>  self.Dependencies = Dependencies
> +self.SourceFileDependencies = None
>  if self.Outputs:
>  self.Target = self.Outputs[0]
>  else:
> @@ -277,6 +280,9 @@ class FileBuildRule:
>  TargetDesc.GenListFile = self.GenListFile
>  

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

[Liming Gao]

Laszlo:

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, February 4, 2020 8:02 PM
> To: devel@edk2.groups.io; Gao, Liming 
> Cc: Feng, Bob C ; Ard Biesheuvel 
> 
> Subject: Re: [edk2-devel] [Patch] BaseTools tools_def.template: Add back 
> -fno-pie option in GCC49 tool chain
> 
> (+Ard)
> 
> On 02/04/20 05:54, Liming Gao wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2502
> > This option is required to make GCC49 tool chain work with the high
> > version GCC compiler.
> >
> > Cc: Bob Feng 
> > Signed-off-by: Liming Gao 
> > ---
> >  BaseTools/Conf/tools_def.template | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/BaseTools/Conf/tools_def.template 
> > b/BaseTools/Conf/tools_def.template
> > index feee2bbf16..d02424ae44 100755
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -1974,7 +1974,7 @@ DEFINE GCC48_ARM_ASLDLINK_FLAGS  = 
> > DEF(GCC_ARM_ASLDLINK_FLAGS) -Wl,--oformat
> >  DEFINE GCC48_AARCH64_ASLDLINK_FLAGS  = DEF(GCC_AARCH64_ASLDLINK_FLAGS)
> >  DEFINE GCC48_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS)
> >
> > -DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS)
> > +DEFINE GCC49_IA32_CC_FLAGS   = DEF(GCC48_IA32_CC_FLAGS) -fno-pic 
> > -fno-pie
> >  DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
> >  DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections 
> > -z common-page-size=0x40
> >  DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
> > -Wl,--defsym=PECOFF_HEADER_SIZE=0
> DEF(GCC_DLINK2_FLAGS_COMMON) -Wl,--entry,ReferenceAcpiTable -u 
> ReferenceAcpiTable
> > @@ -1997,7 +1997,7 @@ DEFINE GCC49_ARM_ASLDLINK_FLAGS  = 
> > DEF(GCC48_ARM_ASLDLINK_FLAGS)
> >  DEFINE GCC49_AARCH64_ASLDLINK_FLAGS  = DEF(GCC48_AARCH64_ASLDLINK_FLAGS)
> >  DEFINE GCC49_ASLCC_FLAGS = DEF(GCC48_ASLCC_FLAGS)
> >
> > -DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-pic 
> > -fno-pie
> > +DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS)
> >  DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS)
> >  DEFINE GCC5_IA32_X64_DLINK_COMMON= DEF(GCC49_IA32_X64_DLINK_COMMON)
> >  DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS  = DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
> >
> 
> - What has changed relative to commit 11d0cd23dd1b ("BaseTools/tools_def
> IA32: drop -no-pie linker option for GCC49", 2018-06-18)?
> 
> - Also, if we are reverting one half of 11d0cd23dd1b (the compiler
> flags), shouldn't we then revert the other half too (the linker flags)?

Yes. Half change is revert. CC_FLAGS is added back. DLINK flag is not,
because GCC4.9 doesn't know the link option -no-pie. But, GCC 4.9 accepts the 
CC option -fno-pie.
I verify this change. CC flags -fno-pie can resolve the build failure with 
GCC7.4. I also see -fno-pie option 
Is in GCC ARM and AARCH64 arch. So, I think this change is enough. 

> 
> - The commit message says, "work with the high version GCC compiler".
> What does that mean? If it is 4.9.x, with x>2, then I agree the patch is
> justified (because commit 11d0cd23dd1b was apparently made for 4.9.2).
> But if the phrase stands for gcc8 or so (just an example), then I don't
> think the patch is a good idea; users of gcc8 can just specify the GCC5
> toolchain.
> 
> Ah, indeed, I need only look at TianoCore#2502:
> 
> "GCC49 tool chain meets with the build failure when GCC7.4 compiler".
> 
> So I think this approach is wrong. Unless there is a new gcc-4.9.x
> release, i.e., after gcc-4.9.2, I think we still need commit
> 11d0cd23dd1b in place. And, please use GCC5 for gcc-7.4 -- is there a
> problem with that?

By design, GCC49 can work with the high version GCC compiler like GCC5. 
GCC49 is the tool chain without LTO enable. GCC5 is the tool chain with LTO. 
So, they are for two different GCC setting. They should both support 
high version GCC compiler. GCC49 supported GCC compiler version is from GCC 4.9.
GCC5 supported GCC compiler version is from GCC 5.0. I know GCC49 or GCC5 tool 
chain 
name brings a little confuse. I will add more detail info in tools_def.txt for 
them. 

Thanks
Liming
> 
> Thanks
> Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53722): https://edk2.groups.io/g/devel/message/53722
Mute This Topic: https://groups.io/mt/70966421/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Dong, Eric]

Reviewed-by: Eric Dong 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Wu, Hao A
Sent: Monday, February 3, 2020 8:35 AM
To: devel@edk2.groups.io
Cc: Wu, Hao A ; Dong, Eric ; Ni, Ray 
; Laszlo Ersek ; Fu, Siyuan 
; Kinney, Michael D 
Subject: [edk2-devel] [PATCH v1] UefiCpuPkg/MpInitLib: Always get CPUID & 
PlatformID in MicrocodeDetect()

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

Commit fd30b00707 updated the logic in function MicrocodeDetect() that will 
directly use the CPUID and PlatformID information from the 'CpuData'
field in the CPU_MP_DATA structure, instead of collecting these information for 
each processor via AsmCpuid() and AsmReadMsr64() calls respectively.

At that moment, this approach worked fine for APs. Since:
a) When the APs are waken up for the 1st time (1st MpInitLibInitialize()
   entry at PEI phase), the function InitializeApData() will be called for
   each AP and the CPUID and PlatformID information will be collected.

b) During the 2nd entry of MpInitLibInitialize() at DXE phase, when the
   APs are waken up again, the function InitializeApData() will not be
   called, which means the CPUID and PlatformID information will not be
   collected. However, the below logics in MicrocodeDetect() function:

  CurrentRevision = GetCurrentMicrocodeSignature ();
  IsBspCallIn = (ProcessorNumber == (UINTN)CpuMpData->BspNumber) ? TRUE : 
FALSE;
  if (CurrentRevision != 0 && !IsBspCallIn) {
//
// Skip loading microcode if it has been loaded successfully
//
return;
  }

   will ensure that the microcode detection and application will be
   skipped due to the fact that such process has already been done in the
   PEI phase.

But after commit 396e791059, which removes the above skip loading logic, the 
CPUID and PlatformID information on APs will be used upon the 2nd entry of the 
MpInitLibInitialize(). But since the CPUID and PlatformID information has not 
been collected, it will bring issue to the microcode detection process.

This commit will update the logic in MicrocodeDetect() back to always 
collecting the CPUID and PlatformID information explicitly.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Siyuan Fu 
Cc: Michael D Kinney 
Signed-off-by: Hao A Wu 
---
 UefiCpuPkg/Library/MpInitLib/Microcode.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c 
b/UefiCpuPkg/Library/MpInitLib/Microcode.c
index b6675b9a60..67e214d463 100644
--- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
+++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
@@ -93,6 +93,7 @@ MicrocodeDetect (
   UINT32  InCompleteCheckSum32;
   BOOLEAN CorrectMicrocode;
   VOID*MicrocodeData;
+  MSR_IA32_PLATFORM_ID_REGISTER   PlatformIdMsr;
   UINT32  ThreadId;
   BOOLEAN IsBspCallIn;
 
@@ -115,8 +116,18 @@ MicrocodeDetect (
   }
 
   ExtendedTableLength = 0;
-  Eax.Uint32 = CpuMpData->CpuData[ProcessorNumber].ProcessorSignature;
-  PlatformId = CpuMpData->CpuData[ProcessorNumber].PlatformId;
+  //
+  // Here data of CPUID leafs have not been collected into context 
+ buffer, so  // GetProcessorCpuid() cannot be used here to retrieve CPUID data.
+  //
+  AsmCpuid (CPUID_VERSION_INFO, , NULL, NULL, NULL);
+
+  //
+  // The index of platform information resides in bits 50:52 of MSR 
+ IA32_PLATFORM_ID  //
+  PlatformIdMsr.Uint64 = AsmReadMsr64 (MSR_IA32_PLATFORM_ID);
+ PlatformId = (UINT8) PlatformIdMsr.Bits.PlatformId;
+
 
   //
   // Check whether AP has same processor with BSP.
--
2.12.0.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#53723): https://edk2.groups.io/g/devel/message/53723
Mute This Topic: https://groups.io/mt/70934372/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-