Re: [edk2] [PATCH 03/26] Vlv2TbltDevicePkg: assume GCC48 or later

[Sun, Zailiang]

Reviewed-by: Zailiang Sun 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, January 3, 2019 10:48 AM
> To: edk2-devel-01 
> Cc: Sun, Zailiang ; Qian, Yi 
> Subject: [PATCH 03/26] Vlv2TbltDevicePkg: assume GCC48 or later
> 
> We're about to remove BaseTools support for GCC44..GCC47. Bump the
> assumption about the minimum gcc version to GCC48 in
> "Vlv2TbltDevicePkg/bld_vlv.sh".
> 
> No GCC44..GCC47 references remain under Vlv2TbltDevicePkg after this
> patch.
> 
> Cc: Zailiang Sun 
> Cc: Yi Qian 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> Untested.
> 
>  Vlv2TbltDevicePkg/bld_vlv.sh | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/Vlv2TbltDevicePkg/bld_vlv.sh b/Vlv2TbltDevicePkg/bld_vlv.sh
> index 538b3ef9d730..51d3acacb48b 100755
> --- a/Vlv2TbltDevicePkg/bld_vlv.sh
> +++ b/Vlv2TbltDevicePkg/bld_vlv.sh
> @@ -179,23 +179,11 @@ sed -i '/^MAX_CONCURRENT_THREAD_NUMBER/d'
> Conf/target.txt
> 
>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>  case $gcc_version in
> -4.5.*)
> -  TARGET_TOOLS=GCC45
> -  ;;
> -4.6.*)
> -  TARGET_TOOLS=GCC46
> -  ;;
> -4.7.*)
> -  TARGET_TOOLS=GCC47
> -  ;;
> -4.8.*)
> -  TARGET_TOOLS=GCC48
> -  ;;
>  4.9.*|4.1[0-9].*|5.*.*|6.*.*)
>TARGET_TOOLS=GCC49
>;;
>  *)
> -  TARGET_TOOLS=GCC44
> +  TARGET_TOOLS=GCC48
>;;
>  esac
> 
> --
> 2.19.1.3.g30247aa5d201
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

[Feng, Bob C]

Reviewed-by: Bob Feng  

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Friday, January 4, 2019 2:28 AM
To: edk2-devel@lists.01.org
Cc: Ard Biesheuvel ; Laszlo Ersek 
; Leif Lindholm ; Kinney, Michael 
D ; Gao, Liming ; Wang, Jian 
J ; Wu, Hao A ; Jagadeesh Ujja 
; Achin Gupta ; Thomas 
Panakamattam Abraham ; Sami Mujawar 
; Feng, Bob C 
Subject: [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

The standalone MM core is executed in place, and resides in a separate 
execution context which may be space constrained.
Since code and data may be mapped with different attributes for security 
reasons, the PE/COFF binary could have a section alignment of 4 KB.

This means that any relocation data is not only useless, but it will also take 
up 4 KB of valuable space.

So add support for the RELOCS_STRIPPED attribute on FFS files of this type, so 
that we can get rid of the .reloc section altogether.
Combined with the FIXED attribute (which enables an optimization in GenFfs that 
strips redundant padding) and a TE type binary, this gets rid of all the 
needless padding around the standalone MM core binary.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Jagadeesh Ujja 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 BaseTools/Source/Python/GenFds/EfiSection.py  | 2 +-
 BaseTools/Source/Python/GenFds/FdfParser.py   | 2 +-
 BaseTools/Source/Python/GenFds/FfsInfStatement.py | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
b/BaseTools/Source/Python/GenFds/EfiSection.py
index f8573b5c7d1b..0be176ec8ae1 100644
--- a/BaseTools/Source/Python/GenFds/EfiSection.py
+++ b/BaseTools/Source/Python/GenFds/EfiSection.py
@@ -68,7 +68,7 @@ class EfiSection (EfiSectionClassObject):
 StringData = FfsInf.__ExtendMacro__(self.StringData)
 ModuleNameStr = FfsInf.__ExtendMacro__('$(MODULE_NAME)')
 NoStrip = True
-if FfsInf.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM) and SectionType in (BINARY_FILE_TYPE_TE, 
BINARY_FILE_TYPE_PE32):
+if FfsInf.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM, SUP_MODULE_MM_CORE_STANDALONE) and SectionType in 
(BINARY_FILE_TYPE_TE, BINARY_FILE_TYPE_PE32):
 if FfsInf.KeepReloc is not None:
 NoStrip = FfsInf.KeepReloc
 elif FfsInf.KeepRelocFromRule is not None:
diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
b/BaseTools/Source/Python/GenFds/FdfParser.py
index e000228d2f6c..de0b166030e7 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -2589,7 +2589,7 @@ class FdfParser:
 #
 @staticmethod
 def _FileCouldHaveRelocFlag (FileType):
-if FileType in {SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, SUP_MODULE_PEIM, 
'PEI_DXE_COMBO'}:
+if FileType in {SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, SUP_MODULE_PEIM, 
SUP_MODULE_MM_CORE_STANDALONE, 'PEI_DXE_COMBO'}:
 return True
 else:
 return False
diff --git a/BaseTools/Source/Python/GenFds/FfsInfStatement.py 
b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
index c1073c96e9aa..d4c61c074963 100644
--- a/BaseTools/Source/Python/GenFds/FfsInfStatement.py
+++ b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
@@ -901,7 +901,7 @@ class FfsInfStatement(FfsInfStatementClassObject):
 #   @retval string   File name of the generated section file
 #
 def __GenComplexFileSection__(self, Rule, FvChildAddr, FvParentAddr, 
IsMakefile = False):
-if self.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM):
+if self.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM, SUP_MODULE_MM_CORE_STANDALONE):
 if Rule.KeepReloc is not None:
 self.KeepRelocFromRule = Rule.KeepReloc
 SectFiles = []
--
2.17.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failure

[Wang, Jian J]

Reviewed-by: Jian J Wang 

> -Original Message-
> From: Wu, Hao A
> Sent: Friday, January 04, 2019 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Bi, Dandan ;
> Wang, Jian J ; Ni, Ray 
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT
> build failure
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425
> 
> This commit will resolve the VS2015 IA32 NOOPT build failure within
> SdMmcPciHcDxe.
> 
> More specifically, this commit will use BaseLib API RShiftU64() to perform
> right-shift operations for UINT64 type operators.
> 
> Cc: Dandan Bi 
> Cc: Jian J Wang 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 6086720fa1..5aec8c6992 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1505,7 +1505,7 @@ BuildAdmaDescTable (
>  Trb->Adma32Desc[Index].Valid = 1;
>  Trb->Adma32Desc[Index].Act   = 2;
>  if (DataLength26) {
> -  Trb->Adma32Desc[Index].UpperLength = (UINT16)(Remaining >> 16);
> +  Trb->Adma32Desc[Index].UpperLength = (UINT16)RShiftU64 (Remaining,
> 16);
>  }
>  Trb->Adma32Desc[Index].LowerLength = (UINT16)(Remaining &
> MAX_UINT16);
>  Trb->Adma32Desc[Index].Address = (UINT32)Address;
> @@ -1524,11 +1524,11 @@ BuildAdmaDescTable (
>  Trb->Adma64Desc[Index].Valid = 1;
>  Trb->Adma64Desc[Index].Act   = 2;
>  if (DataLength26) {
> -  Trb->Adma64Desc[Index].UpperLength  = (UINT16)(Remaining >> 16);
> +  Trb->Adma64Desc[Index].UpperLength  = (UINT16)RShiftU64 (Remaining,
> 16);
>  }
>  Trb->Adma64Desc[Index].LowerLength  = (UINT16)(Remaining &
> MAX_UINT16);
>  Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
> -Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
> +Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64 (Address, 
> 32);
>  break;
>} else {
>  Trb->Adma64Desc[Index].Valid = 1;
> @@ -1538,7 +1538,7 @@ BuildAdmaDescTable (
>  }
>  Trb->Adma64Desc[Index].LowerLength  = 0;
>  Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
> -Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
> +Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64 (Address, 
> 32);
>}
>  }
> 
> --
> 2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failure

[Bi, Dandan]

Reviewed-by: Bi Dandan 

Thanks,
Dandan
> -Original Message-
> From: Wu, Hao A
> Sent: Friday, January 4, 2019 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Bi, Dandan ;
> Wang, Jian J ; Ni, Ray 
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT
> build failure
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425
> 
> This commit will resolve the VS2015 IA32 NOOPT build failure within
> SdMmcPciHcDxe.
> 
> More specifically, this commit will use BaseLib API RShiftU64() to perform
> right-shift operations for UINT64 type operators.
> 
> Cc: Dandan Bi 
> Cc: Jian J Wang 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 6086720fa1..5aec8c6992 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1505,7 +1505,7 @@ BuildAdmaDescTable (
>  Trb->Adma32Desc[Index].Valid = 1;
>  Trb->Adma32Desc[Index].Act   = 2;
>  if (DataLength26) {
> -  Trb->Adma32Desc[Index].UpperLength = (UINT16)(Remaining >> 16);
> +  Trb->Adma32Desc[Index].UpperLength = (UINT16)RShiftU64
> + (Remaining, 16);
>  }
>  Trb->Adma32Desc[Index].LowerLength = (UINT16)(Remaining &
> MAX_UINT16);
>  Trb->Adma32Desc[Index].Address = (UINT32)Address; @@ -1524,11
> +1524,11 @@ BuildAdmaDescTable (
>  Trb->Adma64Desc[Index].Valid = 1;
>  Trb->Adma64Desc[Index].Act   = 2;
>  if (DataLength26) {
> -  Trb->Adma64Desc[Index].UpperLength  = (UINT16)(Remaining >> 16);
> +  Trb->Adma64Desc[Index].UpperLength  = (UINT16)RShiftU64
> + (Remaining, 16);
>  }
>  Trb->Adma64Desc[Index].LowerLength  = (UINT16)(Remaining &
> MAX_UINT16);
>  Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
> -Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
> +Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64
> + (Address, 32);
>  break;
>} else {
>  Trb->Adma64Desc[Index].Valid = 1; @@ -1538,7 +1538,7 @@
> BuildAdmaDescTable (
>  }
>  Trb->Adma64Desc[Index].LowerLength  = 0;
>  Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
> -Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
> +Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64
> + (Address, 32);
>}
>  }
> 
> --
> 2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update

[Gao, Liming]

Laszlo:
  This issue has been fixed in edk2 master. I just cherry pick those fixes from 
edk2 master to my Python3 branch (https://github.com/lgao4/edk2/tree/Python3). 

Thanks
Liming
>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Monday, December 31, 2018 8:16 AM
>To: Gao, Liming ; Gary Lin 
>Cc: edk2-devel@lists.01.org; Kinney, Michael D 
>Subject: Re: [edk2] [RFC] Edk2 BaseTools Python3 Migration Update
>
>On 12/29/18 07:07, Gao, Liming wrote:
>> Lin:
>>Thanks for your verification.  This issue has been fixed in the
>>latest version of https://github.com/lgao4/edk2/tree/Python3. Could
>>you try again?
>
>At commit 4614985ec223 ("BaseTools:The binary data type is incorrect",
>2018-12-29):
>
>
>(1) I tried to build OVMF as follows (using
>python-2.7.5-69.el7_5.x86_64):
>
>  build \
>-a IA32 \
>-p OvmfPkg/OvmfPkgIa32.dsc \
>-D SMM_REQUIRE \
>-D SECURE_BOOT_ENABLE \
>-D TLS_ENABLE \
>-D NETWORK_IP6_ENABLE \
>-t GCC48 \
>-n 4 \
>--report-file=/tmp/build.ovmf.32.report \
>--log=/tmp/build.ovmf.32.log \
>-b NOOPT \
>-D HTTP_BOOT_ENABLE \
>--cmd-len=65536 \
>--hash \
>--genfds-multi-thread
>
>This produced messages like:
>
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/FVMAIN_COMPACT.Fv.txt(...):
>warning: Fail to read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/PEIFV.Fv.txt(...): warning: Fail to
>read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/DXEFV.Fv.txt(...): warning: Fail to
>read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/SECFV.Fv.txt(...): warning: Fail to
>read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/FVMAIN_COMPACT.Fv.txt(...):
>warning: Fail to read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/PEIFV.Fv.txt(...): warning: Fail to
>read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/DXEFV.Fv.txt(...): warning: Fail to
>read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/SECFV.Fv.txt(...): warning: Fail to
>read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/PEIFV.Fv.txt(...): warning: Fail to
>read report file
>> BuildReport.py...
>> .../Build/OvmfIa32/NOOPT_GCC48/FV/DXEFV.Fv.txt(...): warning: Fail to
>read report file
>
>near the end of the build.
>
>
>(2) After I removed the "--report-file" switch, the warnings
>disappeared.
>
>However, neither of the expected output files
>
>- Build/OvmfIa32/NOOPT_GCC48/FV/OVMF.fd
>- Build/OvmfIa32/NOOPT_GCC48/FV/OVMF_CODE.fd
>
>existed. To be more precise, none of "OVMF.fd" and "OVMF_CODE.fd"
>existed anywhere in the "Build" directory.
>
>Judged from the build log, it seemed that at least some *.efi modules
>were compiled and linked, but FVs and FDs were not built. The following
>sections of the log were missing:
>
>> Fd File Name:OVMF_VARS
>(.../Build/OvmfIa32/NOOPT_GCC48/FV/OVMF_VARS.fd)
>>
>> Generate Region at Offset 0x0
>>Region Size = 0x4
>>Region Name = DATA
>>
>> Generate Region at Offset 0x4
>>Region Size = 0x1000
>>Region Name = None
>>
>> Generate Region at Offset 0x41000
>>Region Size = 0x1000
>>Region Name = DATA
>>
>> Generate Region at Offset 0x42000
>>Region Size = 0x42000
>>Region Name = None
>>
>> Fd File Name:MEMFD (.../Build/OvmfIa32/NOOPT_GCC48/FV/MEMFD.fd)
>>
>> Generate Region at Offset 0x0
>>Region Size = 0x6000
>>Region Name = None
>>
>> Generate Region at Offset 0x6000
>>Region Size = 0x1000
>>Region Name = None
>>
>> Generate Region at Offset 0x7000
>>Region Size = 0x1000
>>Region Name = None
>> Padding region starting from offset 0x8000, with size 0x8000
>>
>> Generate Region at Offset 0x8000
>>Region Size = 0x8000
>>Region Name = None
>>
>> Generate Region at Offset 0x1
>>Region Size = 0x1
>>Region Name = None
>>
>> Generate Region at Offset 0x2
>>Region Size = 0xE
>>Region Name = FV
>>
>> Generating PEIFV FV
>>
>> Generate Region at Offset 0x10
>>Region Size = 0xB0
>>Region Name = FV
>>
>> Generating DXEFV FV
>>
>> Fd File Name:OVMF (.../Build/OvmfIa32/NOOPT_GCC48/FV/OVMF.fd)
>>
>> Generate Region at Offset 0x0
>>Region Size = 0x4
>>Region Name = DATA
>>
>> Generate Region at Offset 0x4
>>Region Size = 0x1000
>>Region Name = None
>>
>> Generate Region at Offset 0x41000
>>Region Size = 0x1000
>>Region Name = DATA
>>
>> Generate Region at Offset 0x42000
>>Region Size = 0x42000
>>Region Name = None
>>
>> Generate Region at Offset 0x84000
>>Region Size = 0x348000
>>Region Name = FV
>>
>> Generating FVMAIN_COMPACT FV
>>
>> Generate Region at Offset 0x3CC000
>>Region Size = 0x34000
>>Region Name = FV
>>
>> Generating SECFV FV
>>
>> Fd File Name:OVMF_CODE
>(.../Build/OvmfIa32/NOOPT_GCC48/FV/OVMF_CODE.fd)
>>
>> Generate Region at Offset 0x0
>>Region 

[edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failure

[Hao Wu]

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

This commit will resolve the VS2015 IA32 NOOPT build failure within
SdMmcPciHcDxe.

More specifically, this commit will use BaseLib API RShiftU64() to perform
right-shift operations for UINT64 type operators.

Cc: Dandan Bi 
Cc: Jian J Wang 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
index 6086720fa1..5aec8c6992 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
@@ -1505,7 +1505,7 @@ BuildAdmaDescTable (
 Trb->Adma32Desc[Index].Valid = 1;
 Trb->Adma32Desc[Index].Act   = 2;
 if (DataLength26) {
-  Trb->Adma32Desc[Index].UpperLength = (UINT16)(Remaining >> 16);
+  Trb->Adma32Desc[Index].UpperLength = (UINT16)RShiftU64 (Remaining, 
16);
 }
 Trb->Adma32Desc[Index].LowerLength = (UINT16)(Remaining & MAX_UINT16);
 Trb->Adma32Desc[Index].Address = (UINT32)Address;
@@ -1524,11 +1524,11 @@ BuildAdmaDescTable (
 Trb->Adma64Desc[Index].Valid = 1;
 Trb->Adma64Desc[Index].Act   = 2;
 if (DataLength26) {
-  Trb->Adma64Desc[Index].UpperLength  = (UINT16)(Remaining >> 16);
+  Trb->Adma64Desc[Index].UpperLength  = (UINT16)RShiftU64 (Remaining, 
16);
 }
 Trb->Adma64Desc[Index].LowerLength  = (UINT16)(Remaining & MAX_UINT16);
 Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
-Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
+Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64 (Address, 32);
 break;
   } else {
 Trb->Adma64Desc[Index].Valid = 1;
@@ -1538,7 +1538,7 @@ BuildAdmaDescTable (
 }
 Trb->Adma64Desc[Index].LowerLength  = 0;
 Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
-Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
+Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64 (Address, 32);
   }
 }
 
-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Correct PcdArray value assigment statement

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>BobCF
>Sent: Saturday, December 29, 2018 4:43 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [edk2] [Patch] BaseTools: Correct PcdArray value assigment
>statement
>
>https://bugzilla.tianocore.org/show_bug.cgi?id=1410
>BaseTools should not generate C structure array initial value
>if the value is not specified with CODE style.
>
>This patch is going to remove the incorrect initial value statement
>and correct the Pcd Array value assignment statement.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Bob Feng 
>Cc: Liming Gao 
>---
> .../Python/Workspace/BuildClassObject.py  |   1 -
> .../Source/Python/Workspace/DscBuildData.py   | 117 +++---
> 2 files changed, 73 insertions(+), 45 deletions(-)
>
>diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py
>b/BaseTools/Source/Python/Workspace/BuildClassObject.py
>index 52b3369561..73920c5153 100644
>--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
>+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
>@@ -99,11 +99,10 @@ class PcdClassObject(object):
> for demesionattr in self.DefaultValues:
> deme = ArrayIndex.findall(demesionattr)
> for i in range(len(deme)-1):
> if int(deme[i].lstrip("[").rstrip("]").strip()) > 
> int(self._Capacity[i]):
> print "error"
>-self._Capacity = [str(int(d) + 1) for d in self._Capacity]
> return self._Capacity
> @property
> def DatumType(self):
> return self._DatumType
>
>diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
>b/BaseTools/Source/Python/Workspace/DscBuildData.py
>index 7f6e966b5f..7e82e8e934 100644
>--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
>+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
>@@ -1738,21 +1738,26 @@ class DscBuildData(PlatformBuildClassObject):
>
> def GenerateSizeFunction(self, Pcd):
> CApp = "// Default Value in Dec \n"
> CApp = CApp + "void Cal_%s_%s_Size(UINT32 *Size){\n" %
>(Pcd.TokenSpaceGuidCName, Pcd.TokenCName)
> if Pcd.IsArray():
>-if (len(Pcd.Capacity) == 1 and Pcd.Capacity[0] != '0') or
>(len(Pcd.Capacity) >1 and reduce(lambda x,y:int(x)*int(y), Pcd.Capacity)) > 0:
>-CApp += "  *Size = (sizeof (%s) * (%s) > *Size) ? sizeof (%s) 
>* (%s):
>*Size; \n" % (Pcd.BaseDatumType,
>"*".join(Pcd.Capacity),Pcd.BaseDatumType, "*".join(Pcd.Capacity))
>-if "{CODE(" in Pcd.DefaultValueFromDec:
>-CApp += "  *Size = (sizeof (%s_%s_INIT_Value) > *Size ? sizeof
>(%s_%s_INIT_Value) : *Size);\n" %
>(Pcd.TokenSpaceGuidCName,Pcd.TokenCName,Pcd.TokenSpaceGuidCName,
>Pcd.TokenCName)
>-for skuname in Pcd.SkuInfoList:
>-skuobj = Pcd.SkuInfoList[skuname]
>-if skuobj.VariableName:
>-for defaultstore in skuobj.DefaultStoreDict:
>-CApp += "  *Size = (sizeof (%s_%s_%s_%s_Value) > 
>*Size ? sizeof
>(%s_%s_%s_%s_Value) : *Size);\n" %
>(Pcd.TokenSpaceGuidCName,Pcd.TokenCName,skuname,defaultstore,Pcd.T
>okenSpaceGuidCName,Pcd.TokenCName,skuname,defaultstore)
>-else:
>-CApp += "  *Size = (sizeof (%s_%s_%s_%s_Value) > *Size ? 
>sizeof
>(%s_%s_%s_%s_Value) : *Size);\n" %
>(Pcd.TokenSpaceGuidCName,Pcd.TokenCName,skuname,TAB_DEFAULT_STO
>RES_DEFAULT,Pcd.TokenSpaceGuidCName,Pcd.TokenCName,skuname,TAB_
>DEFAULT_STORES_DEFAULT)
>+if Pcd.Type in PCD_DYNAMIC_TYPE_SET |
>PCD_DYNAMIC_EX_TYPE_SET:
>+for skuname in Pcd.SkuInfoList:
>+skuobj = Pcd.SkuInfoList[skuname]
>+if skuobj.VariableName:
>+for defaultstore in skuobj.DefaultStoreDict:
>+pcddef =
>self.GetPcdDscRawDefaultValue(Pcd,skuname,defaultstore)
>+if pcddef and "{CODE(" in pcddef:
>+CApp += "  *Size = (sizeof 
>(%s_%s_%s_%s_Value) > *Size ?
>sizeof (%s_%s_%s_%s_Value) : *Size);\n" %
>(Pcd.TokenSpaceGuidCName,Pcd.TokenCName,skuname,defaultstore,Pcd.T
>okenSpaceGuidCName,Pcd.TokenCName,skuname,defaultstore)
>+else:
>+pcddef =
>self.GetPcdDscRawDefaultValue(Pcd,skuname,TAB_DEFAULT_STORES_DEFA
>ULT)
>+if pcddef and "{CODE(" in pcddef:
>+CApp += "  *Size = (sizeof (%s_%s_%s_%s_Value) > 
>*Size ?
>sizeof (%s_%s_%s_%s_Value) : *Size);\n" %
>(Pcd.TokenSpaceGuidCName,Pcd.TokenCName,skuname,TAB_DEFAULT_STO
>RES_DEFAULT,Pcd.TokenSpaceGuidCName,Pcd.TokenCName,skuname,TAB_
>DEFAULT_STORES_DEFAULT)
>+else:
>+pcddef =
>self.GetPcdDscRawDefaultValue(Pcd,TAB_DEFAULT,TAB_DEFAULT_STORES_
>DEFAULT)
>+if pcddef and "{CODE(" in 

Re: [edk2] Uninstalling Invalid Protocol Interfaces

[Ashish Singhal]

Hi Mike,

Call to UninstallMultipleProtocolInterfaces at 
https://github.com/tianocore/edk2/blob/master/NetworkPkg/IScsiDxe/IScsiDriver.c#L1864
 fails because the component name interface may not be installed depending on 
the state of PCD.

Thanks
Ashish

From: Kinney, Michael D 
Sent: Thursday, January 3, 2019 5:09 PM
To: Ashish Singhal ; edk2-devel@lists.01.org; Kinney, 
Michael D 
Cc: Gao, Liming ; Fu, Siyuan ; Wu, 
Jiaxin 
Subject: RE: Uninstalling Invalid Protocol Interfaces

Hi Ashish,

Can you provide a pointer to the UninstallMultipleProtocolInterfaces() call 
that is causing this failure?

I agree that the UefiLib could provide additional services to simplify the 
implementation of the unload handlers.  Matching the UefiLib APIs that install 
the Uefi Driver Model protocol would be useful, so the driver entry point and 
the driver unload functions can use matching APIs.

Mike

From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
Sent: Thursday, January 3, 2019 3:39 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>; Fu, Siyuan 
mailto:siyuan...@intel.com>>; Wu, Jiaxin 
mailto:jiaxin...@intel.com>>
Subject: Uninstalling Invalid Protocol Interfaces

Hello,

As part of moving from MdeModulePkg implementation of IScsiDxe to the 
implementation in NetworkPkg, I started hitting exception in the driver loaded 
after IScsiDxe if IScsiDxe's installation fails for some reason. Upon 
debugging, I found out that calls to UninstallMultipleProtocolInterfaces as 
part of Error 2 as well Error 1 fail while trying to uninstall component name 
protocol-interface pair and return error code EFI_INVALID_PARAMETER. As per 
UninstallMultipleProtocolInterfaces's documentation, if uninstallation of any 
of the input protocol-interface pair fails, it will reinstall any just 
uninstalled protocol and return EFI_INVALID_PARAMETER which causes the cleanup 
of this driver corrupt leading to failure in next driver getting loaded. The 
reason of failure in UninstallMultipleProtocolInterfaces is because the driver 
uses EfiLibInstallDriverBindingComponentName2 to install interfaces which may 
not install component name interfaces depending on the value of PCDs 
PcdComponentNameDi
 sable and PcdComponentName2Disable. I have the following proposals to get 
around this issue.


  1.  Instead of calling UninstallMultipleProtocolInterfaces once and list all 
protocol-interface pairs, do it sequentially for every pair so that the once 
which was installed correctly, gets uninstalled instead of getting reinstalled 
because of a failure uninstalling another pair. This would however make us not 
really use use UninstallMultipleProtocolInterfaces API to its full caliber.
  2.  In UEFILib, add a function EfiLibUninstallDriverBindingComponentName2 for 
uninstalling protocol interfaces taking into consideration the state of PCDs 
PcdComponentNameDisable and PcdComponentName2Disable.
  3.  In UEFILib, add uninstall functions for all corresponding install APIs to 
get coverage for all scenarios.

I would certainly prefer option 2 or 3 as they seem to be more correct and 
would provide a for all drivers which may hit the issue. I am happy to make the 
code changes as needed and suggested by the maintainers.

Thanks
Ashish

This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Uninstalling Invalid Protocol Interfaces

[Kinney, Michael D]

Hi Ashish,

Can you provide a pointer to the UninstallMultipleProtocolInterfaces() call 
that is causing this failure?

I agree that the UefiLib could provide additional services to simplify the 
implementation of the unload handlers.  Matching the UefiLib APIs that install 
the Uefi Driver Model protocol would be useful, so the driver entry point and 
the driver unload functions can use matching APIs.

Mike

From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
Sent: Thursday, January 3, 2019 3:39 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming 
; Fu, Siyuan ; Wu, Jiaxin 

Subject: Uninstalling Invalid Protocol Interfaces

Hello,

As part of moving from MdeModulePkg implementation of IScsiDxe to the 
implementation in NetworkPkg, I started hitting exception in the driver loaded 
after IScsiDxe if IScsiDxe's installation fails for some reason. Upon 
debugging, I found out that calls to UninstallMultipleProtocolInterfaces as 
part of Error 2 as well Error 1 fail while trying to uninstall component name 
protocol-interface pair and return error code EFI_INVALID_PARAMETER. As per 
UninstallMultipleProtocolInterfaces's documentation, if uninstallation of any 
of the input protocol-interface pair fails, it will reinstall any just 
uninstalled protocol and return EFI_INVALID_PARAMETER which causes the cleanup 
of this driver corrupt leading to failure in next driver getting loaded. The 
reason of failure in UninstallMultipleProtocolInterfaces is because the driver 
uses EfiLibInstallDriverBindingComponentName2 to install interfaces which may 
not install component name interfaces depending on the value of PCDs 
PcdComponentNameDi
 sable and PcdComponentName2Disable. I have the following proposals to get 
around this issue.


  1.  Instead of calling UninstallMultipleProtocolInterfaces once and list all 
protocol-interface pairs, do it sequentially for every pair so that the once 
which was installed correctly, gets uninstalled instead of getting reinstalled 
because of a failure uninstalling another pair. This would however make us not 
really use use UninstallMultipleProtocolInterfaces API to its full caliber.
  2.  In UEFILib, add a function EfiLibUninstallDriverBindingComponentName2 for 
uninstalling protocol interfaces taking into consideration the state of PCDs 
PcdComponentNameDisable and PcdComponentName2Disable.
  3.  In UEFILib, add uninstall functions for all corresponding install APIs to 
get coverage for all scenarios.

I would certainly prefer option 2 or 3 as they seem to be more correct and 
would provide a for all drivers which may hit the issue. I am happy to make the 
code changes as needed and suggested by the maintainers.

Thanks
Ashish

This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply email and destroy all copies of the original 
message.

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Uninstalling Invalid Protocol Interfaces

[Ashish Singhal]

Hello,

As part of moving from MdeModulePkg implementation of IScsiDxe to the 
implementation in NetworkPkg, I started hitting exception in the driver loaded 
after IScsiDxe if IScsiDxe's installation fails for some reason. Upon 
debugging, I found out that calls to UninstallMultipleProtocolInterfaces as 
part of Error 2 as well Error 1 fail while trying to uninstall component name 
protocol-interface pair and return error code EFI_INVALID_PARAMETER. As per 
UninstallMultipleProtocolInterfaces's documentation, if uninstallation of any 
of the input protocol-interface pair fails, it will reinstall any just 
uninstalled protocol and return EFI_INVALID_PARAMETER which causes the cleanup 
of this driver corrupt leading to failure in next driver getting loaded. The 
reason of failure in UninstallMultipleProtocolInterfaces is because the driver 
uses EfiLibInstallDriverBindingComponentName2 to install interfaces which may 
not install component name interfaces depending on the value of PCDs 
PcdComponentNameDi
 sable and PcdComponentName2Disable. I have the following proposals to get 
around this issue.


  1.  Instead of calling UninstallMultipleProtocolInterfaces once and list all 
protocol-interface pairs, do it sequentially for every pair so that the once 
which was installed correctly, gets uninstalled instead of getting reinstalled 
because of a failure uninstalling another pair. This would however make us not 
really use use UninstallMultipleProtocolInterfaces API to its full caliber.
  2.  In UEFILib, add a function EfiLibUninstallDriverBindingComponentName2 for 
uninstalling protocol interfaces taking into consideration the state of PCDs 
PcdComponentNameDisable and PcdComponentName2Disable.
  3.  In UEFILib, add uninstall functions for all corresponding install APIs to 
get coverage for all scenarios.

I would certainly prefer option 2 or 3 as they seem to be more correct and 
would provide a for all drivers which may hit the issue. I am happy to make the 
code changes as needed and suggested by the maintainers.

Thanks
Ashish

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce][RFC] Collaboration Software: Microsoft Teams

[Jeremiah Cox via edk2-devel]

On the topic of Microsoft Teams, it has a free option, limited to 300 users.  
More than 300 users requires an enterprise license, starting at $8/user/month.  
There is a steep discount for some types of non-profits, but I don't know if we 
would qualify.

More details on the offering here:  
https://products.office.com/en-us/microsoft-teams/free

Highlights:
* Unlimited chat messages and search.
* Built-in audio and video calling for individuals, groups, and full team 
meetups.
* 10 GB of team file storage plus additional 2 GB per person for personal 
storage.
* Integrated, real-time content creation with Office Online apps, including 
built-in Word, Excel, PowerPoint, and OneNote.
* Unlimited app integrations with 140+ business apps to choose from-including 
Adobe, * Evernote, and Trello.
* Ability to communicate and collaborate with anyone inside or outside your 
organization, backed by Microsoft's secure, global infrastructure.

If this sounds like a viable option to the community, please email me and I'll 
add you as a guest on our Project Mu Teams channel for evaluation purposes.

Thanks,
Jeremiah

-Original Message-
From: edk2-devel  On Behalf Of stephano
Sent: Friday, November 16, 2018 8:59 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [edk2-announce][RFC] Collaboration Software

We are looking to augment our current communication methods (mailing list / 
IRC) with a modern solution for group collaboration. The goal is to allow folks 
to communicate effectively without interrupting the current patch review 
system, as well as enabling any future systems with more robust options.

Specific features we are looking for include attachments (currently blocked by 
the list), robust logging, modern chat, and integration with tools like bug 
trackers and source repositories (APIs, or better yet, pre-rolled plugins).

Our current contenders are Google Groups and Groups.io. This RFC is in hopes of 
finding other options to evaluate.

Cheers,
Stephano
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fmailman%2Flistinfo%2Fedk2-develdata=02%7C01%7Cjerecox%40microsoft.com%7Ccced1ed304fa4bb2912508d64be60e56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636779848794152121sdata=i3HtNOPFa010PWb2qSe4TKnTpsTwzPbQzN3S48uG9Po%3Dreserved=0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 00/26] remove the GCC44 through GCC47 toolchains

[Jordan Justen]

On 2019-01-02 18:47:50, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: drop_gcc44_gcc47_tiano1377
> 
> (0) This series is meant as an alternative to
> 
>   [edk2] [Patch 0/5] Remove unused tool chains in tools_def.template
>   20181224150107.28624-1-liming.gao@intel.com">http://mid.mail-archive.com/20181224150107.28624-1-liming.gao@intel.com

I'm taking Liming's patchset as an indication that Intel is okay with
removing the older GCC toolchains.

Based on that, the series is
Reviewed-by: Jordan Justen 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Ard Biesheuvel]

On Thu, 3 Jan 2019 at 19:28, Ard Biesheuvel  wrote:
>
> This series proposed an alternative approach to the series sent out by
> Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the
> special PCD, as well as some other if() conditionals.
>

That would be

[0] https://lists.01.org/pipermail/edk2-devel/2019-January/034542.html

Also, I seem to have included a BaseTools/ patch in error. Apologies
for the sloppiness.


> The primary difference is that this series defines and implements
> MmServicesTableLib in such a way that the traditional SMM drivers
> can use it as well. This is appropriate, considering that the PI
> spec has rebranded traditional SMM as one implementation of the generic
> MM framework.
>
> Patch #1 is based on Jagadeesh's patch, and introduces the MmServicesTableLib
> library class, but for all SMM flavours, not only for standalone MM.
>
> Patch #2 implements MmServicesTableLib for traditional SMM implementations.
>
> Patch #3 refactors FaultTolerantWriteDxe so that the parts of the SMM
> driver that invoke boot services are separated from the core SMM pieces.
>
> Patch #4 implements FaultTolerantWriteSmm for the standalone MM environment.
>
> Patches #5 and #6 do the same, respectively, for the variable runtime driver.
>
> This approach minimizes the delta, and thus the maintenance burden, between
> the traditional SMM and standalone MM drivers, while not resorting to runtime
> checks or other conditionals in the code to implement logic that should be
> decided at build time.
>
> Note that this series only covers part of the work contributed by Jagadeesh.
> This series focuses on the MdePkg and MdeModulePkg changes that affect shared
> code.
>
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Jagadeesh Ujja 
> Cc: Achin Gupta 
> Cc: Thomas Panakamattam Abraham 
> Cc: Sami Mujawar 
>
> Ard Biesheuvel (5):
>   MdePkg: implement MmServicesTableLib based on traditional SMM
>   MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses
>   MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version
>   MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses
>   MdeModulePkg/VariableRuntimeDxe: implement standalone MM version
>
> Jagadeesh Ujja (1):
>   MdePkg/Include: add MmServicesTableLib header file
>
>  MdeModulePkg/MdeModulePkg.dsc |   1 +
>  .../FaultTolerantWrite.h  |  22 ++-
>  .../FaultTolerantWriteDxe.c   |  31 
>  .../FaultTolerantWriteSmm.c   |  54 +++
>  .../FaultTolerantWriteSmm.inf |   5 +-
>  .../FaultTolerantWriteSmmCommon.h |  31 
>  .../FaultTolerantWriteSmmDxe.c|   1 +
>  .../FaultTolerantWriteStandaloneMm.c  |  70 +
>  .../FaultTolerantWriteStandaloneMm.inf|  90 
>  .../FaultTolerantWriteTraditionalMm.c |  94 
>  .../UpdateWorkingBlock.c  |  10 +-
>  .../Variable/RuntimeDxe/TcgMorLockSmm.c   |  18 +--
>  .../Universal/Variable/RuntimeDxe/Variable.h  |  50 +++
>  .../Variable/RuntimeDxe/VariableSmm.c |  59 +++-
>  .../Variable/RuntimeDxe/VariableSmm.inf   |   5 +-
>  .../RuntimeDxe/VariableStandaloneMm.c |  69 +
>  .../RuntimeDxe/VariableStandaloneMm.inf   | 135 ++
>  .../RuntimeDxe/VariableTraditionalMm.c| 114 +++
>  MdePkg/Include/Library/MmServicesTableLib.h   |  25 
>  .../MmServicesTableLib/MmServicesTableLib.c   |  63 
>  .../MmServicesTableLib/MmServicesTableLib.inf |  45 ++
>  .../MmServicesTableLib/MmServicesTableLib.uni |  22 +++
>  MdePkg/MdePkg.dec |   4 +
>  MdePkg/MdePkg.dsc |   1 +
>  24 files changed, 916 insertions(+), 103 deletions(-)
>  create mode 100644 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
>  create mode 100644 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
>  create mode 100644 
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c
>  create mode 100644 
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
>  create mode 100644 
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
>  create mode 100644 
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableTraditionalMm.c
>  create mode 100644 MdePkg/Include/Library/MmServicesTableLib.h
>  create mode 100644 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
>  create mode 100644 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
>  create mode 100644 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni
>
> --
> 2.17.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 6/6] MdeModulePkg/VariableRuntimeDxe: implement standalone MM version

[Ard Biesheuvel]

Reuse most of the existing code to implement a variable runtime
driver that will be able to execute in the context of standalone
MM.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c   |  69 
++
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf | 135 

 2 files changed, 204 insertions(+)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
new file mode 100644
index ..fbc99467c057
--- /dev/null
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
@@ -0,0 +1,69 @@
+/** @file
+
+  Parts of the SMM/MM implementation that are specific to standalone MM
+
+Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved. 
+Copyright (c) 2018, Linaro, Ltd. All rights reserved. 
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "Variable.h"
+
+BOOLEAN
+VariableSmmIsBufferOutsideSmmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64Length
+  )
+{
+  return TRUE;
+}
+
+/**
+  Notify the system that the SMM variable driver is ready
+**/
+VOID
+VariableNotifySmmReady (
+  VOID
+  )
+{
+}
+
+/**
+  Notify the system that the SMM variable write driver is ready
+**/
+VOID
+VariableNotifySmmWriteReady (
+  VOID
+  )
+{
+}
+
+EFI_STATUS
+EFIAPI
+VariableServiceInitialize (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_MM_SYSTEM_TABLE  *MmSystemTable
+  )
+{
+  return MmVariableServiceInitialize ();
+}
+
+/**
+  Whether the TCG or TCG2 protocols are installed in the UEFI protocol 
database.
+  This information is used by the MorLock code to infer whether an existing
+  MOR variable is legitimate or not.
+**/
+BOOLEAN
+VariableHaveTcgProtocols (
+  VOID
+  )
+{
+  return FALSE;
+}
diff --git 
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
new file mode 100644
index ..54d647af914c
--- /dev/null
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
@@ -0,0 +1,135 @@
+## @file
+#  Provides SMM variable service.
+#
+#  This module installs SMM variable protocol into SMM protocol database,
+#  which can be used by SMM driver, and installs SMM variable protocol
+#  into BS protocol database, which can be used to notify the SMM Runtime
+#  Dxe driver that the SMM variable service is ready.
+#  This module should be used with SMM Runtime DXE module together. The
+#  SMM Runtime DXE module would install variable arch protocol and variable
+#  write arch protocol based on SMM variable module.
+#
+#  Caution: This module requires additional review when modified.
+#  This driver will have external input - variable data and communicate buffer 
in SMM mode.
+#  This external input must be validated carefully to avoid security issues 
such as
+#  buffer overflow or integer overflow.
+#The whole SMM authentication variable design relies on the integrity of 
flash part and SMM.
+#  which is assumed to be protected by platform.  All variable code and 
metadata in flash/SMM Memory
+#  may not be modified without authorization. If platform fails to protect 
these resources,
+#  the authentication service provided in this driver will be broken, and the 
behavior is undefined.
+#
+# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution. The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = VariableStandaloneMm
+  FILE_GUID  = 7ee2c0c1-c21a-4113-a53a-66824a95696f
+  MODULE_TYPE= MM_STANDALONE
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x00010032
+  ENTRY_POINT= VariableServiceInitialize
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = AARCH64
+#
+
+
+[Sources]
+  Reclaim.c
+  Variable.c
+  VariableSmm.c
+  VariableStandaloneMm.c
+  VarCheck.c
+  Variable.h
+  

[edk2] [PATCH 3/6] MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses

[Ard Biesheuvel]

In preparation of providing a standalone MM based FTW driver, move
the existing SMM driver to the new MM services table, and factor out
some pieces that are specific to the traditional driver, mainly
related to the use of UEFI boot services, which are not accessible
to standalone MM drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/MdeModulePkg.dsc  
|  1 +
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h  
| 22 -
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c   
| 31 +++
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c   
| 54 +--
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf 
|  5 +-
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h 
| 31 +++
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.c
|  1 +
 MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c 
| 94 
 MdeModulePkg/Universal/FaultTolerantWriteDxe/UpdateWorkingBlock.c  
| 10 +--
 9 files changed, 205 insertions(+), 44 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 5d042be3a862..ef3c144ed524 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -153,6 +153,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf
   
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
   
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
+  MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
   SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
 
diff --git a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
index 844cf3bee04d..8d146264b129 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWrite.h
@@ -31,7 +31,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
 #include 
 
 //
@@ -766,4 +765,25 @@ WriteWorkSpaceData (
   IN UINT8  *Buffer
   );
 
+/**
+  Internal implementation of CRC32. Depending on the execution context
+  (traditional SMM or DXE vs standalone MM), this function is implemented
+  via a call to the CalculateCrc32 () boot service, or via a library
+  call.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC is 
to be computed.
+  @param[in]  Length   The number of bytes in the buffer Data.
+
+  @retval Crc32The 32-bit CRC was computed for the data buffer.
+
+**/
+UINT32
+FtwCalculateCrc32 (
+  IN  VOID *Buffer,
+  IN  UINTNLength
+  );
+
 #endif
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
index 094e40f9d86c..24e507104bbe 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c
@@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 **/
 
+#include 
 #include "FaultTolerantWrite.h"
 EFI_EVENT mFvbRegistration = NULL;
 
@@ -250,3 +251,33 @@ FaultTolerantWriteInitialize (
 
   return EFI_SUCCESS;
 }
+
+/**
+  Internal implementation of CRC32. Depending on the execution context
+  (traditional SMM or DXE vs standalone MM), this function is implemented
+  via a call to the CalculateCrc32 () boot service, or via a library
+  call.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 32-bit CRC is 
to be computed.
+  @param[in]  Length   The number of bytes in the buffer Data.
+
+  @retval Crc32The 32-bit CRC was computed for the data buffer.
+
+**/
+UINT32
+FtwCalculateCrc32 (
+  IN  VOID *Buffer,
+  IN  UINTNLength
+  )
+{
+  EFI_STATUSStatus;
+  UINT32ReturnValue;
+
+  Status = gBS->CalculateCrc32 (Buffer, Length, );
+  ASSERT_EFI_ERROR (Status);
+
+  return ReturnValue;
+}
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c
index 

[edk2] [PATCH 5/6] MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses

[Ard Biesheuvel]

In preparation of providing a standalone MM based variable runtime
driver, move the existing SMM driver to the new MM services table,
and factor out some pieces that are specific to the traditional
driver, mainly related to the use of UEFI boot services, which are
not accessible to standalone MM drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c |  18 +---
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h  |  50 
+
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c   |  59 
--
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf |   5 +-
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableTraditionalMm.c | 114 

 5 files changed, 187 insertions(+), 59 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
index 28aa2893c6f8..009d96c3a65e 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
@@ -21,7 +21,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
 #include "Variable.h"
 
 typedef struct {
@@ -419,8 +418,6 @@ MorLockInitAtEndOfDxe (
 {
   UINTN  MorSize;
   EFI_STATUS MorStatus;
-  EFI_STATUS TcgStatus;
-  VOID   *TcgInterface;
 
   if (!mMorLockInitializationRequired) {
 //
@@ -458,20 +455,7 @@ MorLockInitAtEndOfDxe (
 // can be deduced from the absence of the TCG / TCG2 protocols, as edk2's
 // MOR implementation depends on (one of) those protocols.
 //
-TcgStatus = gBS->LocateProtocol (
-   ,
-   NULL, // Registration
-   
-   );
-if (EFI_ERROR (TcgStatus)) {
-  TcgStatus = gBS->LocateProtocol (
- ,
- NULL,   // Registration
- 
- );
-}
-
-if (!EFI_ERROR (TcgStatus)) {
+if (VariableHaveTcgProtocols ()) {
   //
   // The MOR variable originates from the platform firmware; set the MOR
   // Control Lock variable to report the locking capability to the OS.
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
index 938eb5de61fa..11822575ac4d 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
@@ -924,4 +924,54 @@ VariableExLibAtRuntime (
   VOID
   );
 
+/**
+  Notify the system that the SMM variable driver is ready
+**/
+VOID
+VariableNotifySmmReady (
+  VOID
+  );
+
+/**
+  Notify the system that the SMM variable write driver is ready
+**/
+VOID
+VariableNotifySmmWriteReady (
+  VOID
+  );
+
+/**
+  Variable service MM driver entry point
+**/
+EFI_STATUS
+EFIAPI
+MmVariableServiceInitialize (
+  VOID
+  );
+
+/**
+  This function check if the buffer is valid per processor architecture and 
not overlap with SMRAM.
+
+  @param Buffer  The buffer start address to be checked.
+  @param Length  The buffer length to be checked.
+
+  @retval TRUE  This buffer is valid per processor architecture and not 
overlap with SMRAM.
+  @retval FALSE This buffer is not valid per processor architecture or overlap 
with SMRAM.
+**/
+BOOLEAN
+VariableSmmIsBufferOutsideSmmValid (
+  IN EFI_PHYSICAL_ADDRESS  Buffer,
+  IN UINT64Length
+  );
+
+/**
+  Whether the TCG or TCG2 protocols are installed in the UEFI protocol 
database.
+  This information is used by the MorLock code to infer whether an existing
+  MOR variable is legitimate or not.
+**/
+BOOLEAN
+VariableHaveTcgProtocols (
+  VOID
+  );
+
 #endif
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
index 8c53f84ff6e8..7245587052df 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
@@ -15,6 +15,7 @@
   SmmVariableGetStatistics() should also do validation based on its own 
knowledge.
 
 Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2018, Linaro, Ltd. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -28,18 +29,15 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
-#include 
-#include 
+#include 
 
 #include 
 #include "Variable.h"
 
 extern VARIABLE_INFO_ENTRY   *gVariableInfo;
-EFI_HANDLE 

[edk2] [PATCH 0/6] implement standalone MM versions of the variable runtime drivers

[Ard Biesheuvel]

This series proposed an alternative approach to the series sent out by
Jagadeesh [0]. In particular, it gets rid of the InMm() calls and the
special PCD, as well as some other if() conditionals.

The primary difference is that this series defines and implements
MmServicesTableLib in such a way that the traditional SMM drivers
can use it as well. This is appropriate, considering that the PI
spec has rebranded traditional SMM as one implementation of the generic
MM framework.

Patch #1 is based on Jagadeesh's patch, and introduces the MmServicesTableLib
library class, but for all SMM flavours, not only for standalone MM.

Patch #2 implements MmServicesTableLib for traditional SMM implementations.

Patch #3 refactors FaultTolerantWriteDxe so that the parts of the SMM
driver that invoke boot services are separated from the core SMM pieces.

Patch #4 implements FaultTolerantWriteSmm for the standalone MM environment.

Patches #5 and #6 do the same, respectively, for the variable runtime driver.

This approach minimizes the delta, and thus the maintenance burden, between
the traditional SMM and standalone MM drivers, while not resorting to runtime
checks or other conditionals in the code to implement logic that should be
decided at build time.

Note that this series only covers part of the work contributed by Jagadeesh.
This series focuses on the MdePkg and MdeModulePkg changes that affect shared
code.

Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Jagadeesh Ujja 
Cc: Achin Gupta 
Cc: Thomas Panakamattam Abraham 
Cc: Sami Mujawar 

Ard Biesheuvel (5):
  MdePkg: implement MmServicesTableLib based on traditional SMM
  MdeModulePkg/FaultTolerantWriteDxe: factor out boot service accesses
  MdeModulePkg/FaultTolerantWriteDxe: implement standalone MM version
  MdeModulePkg/VariableRuntimeDxe: factor out boot service accesses
  MdeModulePkg/VariableRuntimeDxe: implement standalone MM version

Jagadeesh Ujja (1):
  MdePkg/Include: add MmServicesTableLib header file

 MdeModulePkg/MdeModulePkg.dsc |   1 +
 .../FaultTolerantWrite.h  |  22 ++-
 .../FaultTolerantWriteDxe.c   |  31 
 .../FaultTolerantWriteSmm.c   |  54 +++
 .../FaultTolerantWriteSmm.inf |   5 +-
 .../FaultTolerantWriteSmmCommon.h |  31 
 .../FaultTolerantWriteSmmDxe.c|   1 +
 .../FaultTolerantWriteStandaloneMm.c  |  70 +
 .../FaultTolerantWriteStandaloneMm.inf|  90 
 .../FaultTolerantWriteTraditionalMm.c |  94 
 .../UpdateWorkingBlock.c  |  10 +-
 .../Variable/RuntimeDxe/TcgMorLockSmm.c   |  18 +--
 .../Universal/Variable/RuntimeDxe/Variable.h  |  50 +++
 .../Variable/RuntimeDxe/VariableSmm.c |  59 +++-
 .../Variable/RuntimeDxe/VariableSmm.inf   |   5 +-
 .../RuntimeDxe/VariableStandaloneMm.c |  69 +
 .../RuntimeDxe/VariableStandaloneMm.inf   | 135 ++
 .../RuntimeDxe/VariableTraditionalMm.c| 114 +++
 MdePkg/Include/Library/MmServicesTableLib.h   |  25 
 .../MmServicesTableLib/MmServicesTableLib.c   |  63 
 .../MmServicesTableLib/MmServicesTableLib.inf |  45 ++
 .../MmServicesTableLib/MmServicesTableLib.uni |  22 +++
 MdePkg/MdePkg.dec |   4 +
 MdePkg/MdePkg.dsc |   1 +
 24 files changed, 916 insertions(+), 103 deletions(-)
 create mode 100644 
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
 create mode 100644 
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.inf
 create mode 100644 
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c
 create mode 100644 
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
 create mode 100644 
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
 create mode 100644 
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableTraditionalMm.c
 create mode 100644 MdePkg/Include/Library/MmServicesTableLib.h
 create mode 100644 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.c
 create mode 100644 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
 create mode 100644 MdePkg/Library/MmServicesTableLib/MmServicesTableLib.uni

-- 
2.17.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/6] MdePkg/Include: add MmServicesTableLib header file

[Ard Biesheuvel]

From: Jagadeesh Ujja 

SMM has been rebranded as MM, and can be implemented in traditional
mode or standalone mode, using the same prototype for the services
table. Expose this table via MmServicesTableLib, permitting the
respective implementations to expose a traditional or standalone
version.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jagadeesh Ujja 
Signed-off-by: Ard Biesheuvel 
---
 MdePkg/Include/Library/MmServicesTableLib.h | 25 
 MdePkg/MdePkg.dec   |  4 
 2 files changed, 29 insertions(+)

diff --git a/MdePkg/Include/Library/MmServicesTableLib.h 
b/MdePkg/Include/Library/MmServicesTableLib.h
new file mode 100644
index ..12bd01e98641
--- /dev/null
+++ b/MdePkg/Include/Library/MmServicesTableLib.h
@@ -0,0 +1,25 @@
+/** @file
+  Provides a service to retrieve a pointer to the Standalone MM Services Table.
+  Only available to Standalone MM module types.
+
+Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MM_SERVICES_TABLE_LIB_H__
+#define __MM_SERVICES_TABLE_LIB_H__
+
+#include 
+
+extern EFI_MM_SYSTEM_TABLE *gMmst;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 712bd46dd3d3..a7383b6daafb 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -243,6 +243,10 @@ [LibraryClasses]
   ##
   SafeIntLib|Include/Library/SafeIntLib.h
 
+  ## @libraryclass Provides a service to retrieve a pointer to the Standalone 
MM Services Table.
+  #Only available to MM_STANDALONE, SMM/DXE Combined and SMM 
module types.
+  MmServicesTableLib|Include/Library/MmServicesTableLib.h
+
 [LibraryClasses.IA32, LibraryClasses.X64]
   ##  @libraryclass  Abstracts both S/W SMI generation and detection.
   ##
-- 
2.17.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

[Ard Biesheuvel]

The standalone MM core is executed in place, and resides in a
separate execution context which may be space constrained.
Since code and data may be mapped with different attributes for
security reasons, the PE/COFF binary could have a section
alignment of 4 KB.

This means that any relocation data is not only useless, but it
will also take up 4 KB of valuable space.

So add support for the RELOCS_STRIPPED attribute on FFS files of
this type, so that we can get rid of the .reloc section altogether.
Combined with the FIXED attribute (which enables an optimization
in GenFfs that strips redundant padding) and a TE type binary, this
gets rid of all the needless padding around the standalone MM core
binary.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Jagadeesh Ujja 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 BaseTools/Source/Python/GenFds/EfiSection.py  | 2 +-
 BaseTools/Source/Python/GenFds/FdfParser.py   | 2 +-
 BaseTools/Source/Python/GenFds/FfsInfStatement.py | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
b/BaseTools/Source/Python/GenFds/EfiSection.py
index f8573b5c7d1b..0be176ec8ae1 100644
--- a/BaseTools/Source/Python/GenFds/EfiSection.py
+++ b/BaseTools/Source/Python/GenFds/EfiSection.py
@@ -68,7 +68,7 @@ class EfiSection (EfiSectionClassObject):
 StringData = FfsInf.__ExtendMacro__(self.StringData)
 ModuleNameStr = FfsInf.__ExtendMacro__('$(MODULE_NAME)')
 NoStrip = True
-if FfsInf.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM) and SectionType in (BINARY_FILE_TYPE_TE, 
BINARY_FILE_TYPE_PE32):
+if FfsInf.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM, SUP_MODULE_MM_CORE_STANDALONE) and SectionType in 
(BINARY_FILE_TYPE_TE, BINARY_FILE_TYPE_PE32):
 if FfsInf.KeepReloc is not None:
 NoStrip = FfsInf.KeepReloc
 elif FfsInf.KeepRelocFromRule is not None:
diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
b/BaseTools/Source/Python/GenFds/FdfParser.py
index e000228d2f6c..de0b166030e7 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -2589,7 +2589,7 @@ class FdfParser:
 #
 @staticmethod
 def _FileCouldHaveRelocFlag (FileType):
-if FileType in {SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, SUP_MODULE_PEIM, 
'PEI_DXE_COMBO'}:
+if FileType in {SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, SUP_MODULE_PEIM, 
SUP_MODULE_MM_CORE_STANDALONE, 'PEI_DXE_COMBO'}:
 return True
 else:
 return False
diff --git a/BaseTools/Source/Python/GenFds/FfsInfStatement.py 
b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
index c1073c96e9aa..d4c61c074963 100644
--- a/BaseTools/Source/Python/GenFds/FfsInfStatement.py
+++ b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
@@ -901,7 +901,7 @@ class FfsInfStatement(FfsInfStatementClassObject):
 #   @retval string   File name of the generated section file
 #
 def __GenComplexFileSection__(self, Rule, FvChildAddr, FvParentAddr, 
IsMakefile = False):
-if self.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM):
+if self.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM, SUP_MODULE_MM_CORE_STANDALONE):
 if Rule.KeepReloc is not None:
 self.KeepRelocFromRule = Rule.KeepReloc
 SectFiles = []
-- 
2.17.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library

[Laszlo Ersek]

On 01/03/19 12:03, Ard Biesheuvel wrote:
> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  wrote:
>>
>> Some of the existing DXE drivers can be refactored to execute within
>> the Standalone MM execution environment as well. Allow such drivers to
>> get access to the Standalone MM services tables.
>>
>> Add a mechanism to determine the execution mode is required.
>> i.e, in MM or non-MM
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Jagadeesh Ujja 
>> ---
>>  MdePkg/Include/Library/StandaloneMmServicesTableLib.h   
>>  | 43 
>>  MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c  
>>  | 39 ++
>>  
>> MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf 
>> | 36 
>>  MdePkg/MdePkg.dec   
>>  |  4 ++
>>  4 files changed, 122 insertions(+)
>>
> 
> OK, so since the PI spec only refers to MM mode now, this library
> class should be
> 
> MmServicesTableLib|Include/Library/MmServicesTableLib.h
> 
> with an implementation in MdeModulePkg that exposes the deprecated SMM
> system table as the MM system table.
> 
> In StandaloneMmPkg, we can add an implementation that exposes the
> standalone MM system table.
> 
> (They are binary compatible, so it is just a matter of casting one
> pointer to the other)
> 
> With this in place, we can go ahead and update FaultTolerantWrite and
> Variable SMM driver to switch from SmmServicesTableLib to
> MmServicesTableLib. This will require existing x86 platforms to define
> a new library class resolution for MmServicesTableLib, referring to
> the implementation in MdeModulePkg. This is unfortunate, but it is an
> unavoidable consequence of the PI spec changes.

It shouldn't be too intrusive or hard to review, I expect.

> 
> Remaining question is what to do with InSmm() ...

I'm lacking the context on this; on the other hand, I can refer back to
at least one earlier discussion -- there had been multiple -- of the
discrepancy between the PI spec and the edk2 code. See:

- bullet (9) in
,
- and
.

Not sure how that can be applied to Arm.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Thursday, January 03, 2019 4:13 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [edk2] [PATCH] BaseTools/GenFds: permit stripped
> MM_CORE_STANDALONE binaries
> 
> The standalone MM core is executed in place, and resides in a
> separate execution context which may be space constrained.
> Since code and data may be mapped with different attributes for
> security reasons, the PE/COFF binary could have a section
> alignment of 4 KB.
> 
> This means that any relocation data is not only useless, but it
> will also take up 4 KB of valuable space.
> 
> So add support for the RELOCS_STRIPPED attribute on FFS files of
> this type, so that we can get rid of the .reloc section altogether.
> Combined with the FIXED attribute (which enables an optimization
> in GenFfs that strips redundant padding) and a TE type binary, this
> gets rid of all the needless padding around the standalone MM core
> binary.
> 
> Cc: Bob Feng 
> Cc: Liming Gao 
> Cc: Jagadeesh Ujja 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  BaseTools/Source/Python/GenFds/EfiSection.py  | 2 +-
>  BaseTools/Source/Python/GenFds/FdfParser.py   | 2 +-
>  BaseTools/Source/Python/GenFds/FfsInfStatement.py | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py
> b/BaseTools/Source/Python/GenFds/EfiSection.py
> index f8573b5c7d1b..0be176ec8ae1 100644
> --- a/BaseTools/Source/Python/GenFds/EfiSection.py
> +++ b/BaseTools/Source/Python/GenFds/EfiSection.py
> @@ -68,7 +68,7 @@ class EfiSection (EfiSectionClassObject):
>  StringData = FfsInf.__ExtendMacro__(self.StringData)
>  ModuleNameStr = FfsInf.__ExtendMacro__('$(MODULE_NAME)')
>  NoStrip = True
> -if FfsInf.ModuleType in (SUP_MODULE_SEC,
> SUP_MODULE_PEI_CORE, SUP_MODULE_PEIM) and SectionType in
> (BINARY_FILE_TYPE_TE, BINARY_FILE_TYPE_PE32):
> +if FfsInf.ModuleType in (SUP_MODULE_SEC,
> SUP_MODULE_PEI_CORE, SUP_MODULE_PEIM,
> SUP_MODULE_MM_CORE_STANDALONE) and SectionType in
> (BINARY_FILE_TYPE_TE, BINARY_FILE_TYPE_PE32):
>  if FfsInf.KeepReloc is not None:
>  NoStrip = FfsInf.KeepReloc
>  elif FfsInf.KeepRelocFromRule is not None:
> diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py
> b/BaseTools/Source/Python/GenFds/FdfParser.py
> index e000228d2f6c..de0b166030e7 100644
> --- a/BaseTools/Source/Python/GenFds/FdfParser.py
> +++ b/BaseTools/Source/Python/GenFds/FdfParser.py
> @@ -2589,7 +2589,7 @@ class FdfParser:
>  #
>  @staticmethod
>  def _FileCouldHaveRelocFlag (FileType):
> -if FileType in {SUP_MODULE_SEC, SUP_MODULE_PEI_CORE,
> SUP_MODULE_PEIM, 'PEI_DXE_COMBO'}:
> +if FileType in {SUP_MODULE_SEC, SUP_MODULE_PEI_CORE,
> SUP_MODULE_PEIM, SUP_MODULE_MM_CORE_STANDALONE,
> 'PEI_DXE_COMBO'}:
>  return True
>  else:
>  return False
> diff --git a/BaseTools/Source/Python/GenFds/FfsInfStatement.py
> b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
> index c1073c96e9aa..d4c61c074963 100644
> --- a/BaseTools/Source/Python/GenFds/FfsInfStatement.py
> +++ b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
> @@ -901,7 +901,7 @@ class FfsInfStatement(FfsInfStatementClassObject):
>  #   @retval string   File name of the generated section file
>  #
>  def __GenComplexFileSection__(self, Rule, FvChildAddr, FvParentAddr,
> IsMakefile = False):
> -if self.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE,
> SUP_MODULE_PEIM):
> +if self.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE,
> SUP_MODULE_PEIM, SUP_MODULE_MM_CORE_STANDALONE):
>  if Rule.KeepReloc is not None:
>  self.KeepRelocFromRule = Rule.KeepReloc
>  SectFiles = []
> --
> 2.17.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on GCC v4.4"

[Marvin Häuser]

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, January 3, 2019 3:48 AM
> To: edk2-devel-01 
> Cc: Ard Biesheuvel ; Liming Gao
> ; Marvin Haeuser ;
> Michael D Kinney 
> Subject: [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on
> GCC v4.4"
> 
> This reverts commit 357cec385d4f ("MdePkg: avoid __builtin_unreachable()
> on GCC v4.4", 2016-07-21).
> 
> We've removed BaseTools support for GCC44..GCC47, therefore we need
> not catch the GCC44 corner case for __builtin_unreachable().
> 
> No GCC44..GCC47 references remain under MdePkg after this patch.
> 
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Cc: Marvin Haeuser 

Reviewed-by: Marvin Haeuser 

> Cc: Michael D Kinney 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> I build-tested this change by building ArmVirtQemu with the GCC5
> toolchain (gcc-6.1.1), and OVMF with the GCC48 toolchain (gcc-4.8.5).
> 
> Namely, the PeiCore() function
> [MdeModulePkg/Core/Pei/PeiMain/PeiMain.c]
> and the DxeMain() function
> [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c]
> use UNREACHABLE().
> 
>  MdePkg/Include/Base.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h index
> bc877d8125a5..d6b04baeaf8b 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -112,11 +112,10 @@ VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE,
> 4);  // warnings.
>  //
>  #ifndef UNREACHABLE
> -  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)
> +  #ifdef __GNUC__
>  ///
>  /// Signal compilers and analyzers that this call is not reachable.  It 
> is
>  /// up to the compiler to remove any code past that point.
> -/// Not implemented by GCC 4.4 or earlier.
>  ///
>  #define UNREACHABLE()  __builtin_unreachable ()
>#elif defined (__has_feature)
> --
> 2.19.1.3.g30247aa5d201

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools/GenFds: permit stripped MM_CORE_STANDALONE binaries

[Ard Biesheuvel]

The standalone MM core is executed in place, and resides in a
separate execution context which may be space constrained.
Since code and data may be mapped with different attributes for
security reasons, the PE/COFF binary could have a section
alignment of 4 KB.

This means that any relocation data is not only useless, but it
will also take up 4 KB of valuable space.

So add support for the RELOCS_STRIPPED attribute on FFS files of
this type, so that we can get rid of the .reloc section altogether.
Combined with the FIXED attribute (which enables an optimization
in GenFfs that strips redundant padding) and a TE type binary, this
gets rid of all the needless padding around the standalone MM core
binary.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Jagadeesh Ujja 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 BaseTools/Source/Python/GenFds/EfiSection.py  | 2 +-
 BaseTools/Source/Python/GenFds/FdfParser.py   | 2 +-
 BaseTools/Source/Python/GenFds/FfsInfStatement.py | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
b/BaseTools/Source/Python/GenFds/EfiSection.py
index f8573b5c7d1b..0be176ec8ae1 100644
--- a/BaseTools/Source/Python/GenFds/EfiSection.py
+++ b/BaseTools/Source/Python/GenFds/EfiSection.py
@@ -68,7 +68,7 @@ class EfiSection (EfiSectionClassObject):
 StringData = FfsInf.__ExtendMacro__(self.StringData)
 ModuleNameStr = FfsInf.__ExtendMacro__('$(MODULE_NAME)')
 NoStrip = True
-if FfsInf.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM) and SectionType in (BINARY_FILE_TYPE_TE, 
BINARY_FILE_TYPE_PE32):
+if FfsInf.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM, SUP_MODULE_MM_CORE_STANDALONE) and SectionType in 
(BINARY_FILE_TYPE_TE, BINARY_FILE_TYPE_PE32):
 if FfsInf.KeepReloc is not None:
 NoStrip = FfsInf.KeepReloc
 elif FfsInf.KeepRelocFromRule is not None:
diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
b/BaseTools/Source/Python/GenFds/FdfParser.py
index e000228d2f6c..de0b166030e7 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -2589,7 +2589,7 @@ class FdfParser:
 #
 @staticmethod
 def _FileCouldHaveRelocFlag (FileType):
-if FileType in {SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, SUP_MODULE_PEIM, 
'PEI_DXE_COMBO'}:
+if FileType in {SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, SUP_MODULE_PEIM, 
SUP_MODULE_MM_CORE_STANDALONE, 'PEI_DXE_COMBO'}:
 return True
 else:
 return False
diff --git a/BaseTools/Source/Python/GenFds/FfsInfStatement.py 
b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
index c1073c96e9aa..d4c61c074963 100644
--- a/BaseTools/Source/Python/GenFds/FfsInfStatement.py
+++ b/BaseTools/Source/Python/GenFds/FfsInfStatement.py
@@ -901,7 +901,7 @@ class FfsInfStatement(FfsInfStatementClassObject):
 #   @retval string   File name of the generated section file
 #
 def __GenComplexFileSection__(self, Rule, FvChildAddr, FvParentAddr, 
IsMakefile = False):
-if self.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM):
+if self.ModuleType in (SUP_MODULE_SEC, SUP_MODULE_PEI_CORE, 
SUP_MODULE_PEIM, SUP_MODULE_MM_CORE_STANDALONE):
 if Rule.KeepReloc is not None:
 self.KeepRelocFromRule = Rule.KeepReloc
 SectFiles = []
-- 
2.17.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library

[Ard Biesheuvel]

On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  wrote:
>
> Some of the existing DXE drivers can be refactored to execute within
> the Standalone MM execution environment as well. Allow such drivers to
> get access to the Standalone MM services tables.
>
> Add a mechanism to determine the execution mode is required.
> i.e, in MM or non-MM
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja 
> ---
>  MdePkg/Include/Library/StandaloneMmServicesTableLib.h
> | 43 
>  MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c   
> | 39 ++
>  MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf 
> | 36 
>  MdePkg/MdePkg.dec
> |  4 ++
>  4 files changed, 122 insertions(+)
>

OK, so since the PI spec only refers to MM mode now, this library
class should be

MmServicesTableLib|Include/Library/MmServicesTableLib.h

with an implementation in MdeModulePkg that exposes the deprecated SMM
system table as the MM system table.

In StandaloneMmPkg, we can add an implementation that exposes the
standalone MM system table.

(They are binary compatible, so it is just a matter of casting one
pointer to the other)

With this in place, we can go ahead and update FaultTolerantWrite and
Variable SMM driver to switch from SmmServicesTableLib to
MmServicesTableLib. This will require existing x86 platforms to define
a new library class resolution for MmServicesTableLib, referring to
the implementation in MdeModulePkg. This is unfortunate, but it is an
unavoidable consequence of the PI spec changes.

Remaining question is what to do with InSmm() ...


> diff --git a/MdePkg/Include/Library/StandaloneMmServicesTableLib.h 
> b/MdePkg/Include/Library/StandaloneMmServicesTableLib.h
> new file mode 100644
> index 000..3a27ac4
> --- /dev/null
> +++ b/MdePkg/Include/Library/StandaloneMmServicesTableLib.h
> @@ -0,0 +1,43 @@
> +/** @file
> +  Provides a service to retrieve a pointer to the Standalone MM Services 
> Table.
> +  Provides a InMm implementation for RUNTIME DXE drivers
> +
> +Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __MM_SERVICES_TABLE_LIB_H__
> +#define __MM_SERVICES_TABLE_LIB_H__
> +
> +#include 
> +#include 
> +
> +extern EFI_MM_SYSTEM_TABLE *gMmst;
> +
> +/**
> +  This function allows the caller to determine if the driver is executing in
> +  Standalone Management Mode(SMM).
> +
> +  This function returns TRUE if the driver is executing in SMM and FALSE if 
> the
> +  driver is not executing in SMM.
> +
> +  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
> +  @retval  FALSE The driver is not executing in Standalone Management Mode 
> (SMM).
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +InMm (
> +  VOID
> +  );
> +
> +#endif
> diff --git 
> a/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c 
> b/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
> new file mode 100644
> index 000..6f37cd8
> --- /dev/null
> +++ 
> b/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
> @@ -0,0 +1,39 @@
> +/** @file
> +  Standalone MM Services Table Library.
> +
> +  Copyright (c) 2018, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +
> +EFI_MM_SYSTEM_TABLE *gMmst = NULL;
> +
> +/**
> +  This function allows the caller to determine if the driver is executing in
> +  Standalone Management Mode(SMM).
> +
> +  This function returns TRUE if the driver is executing in SMM and FALSE if 
> the
> +  driver is not executing in SMM.
> +
> +  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
> +  @retval  FALSE The driver is not executing in Standalone Management Mode 
> (SMM).
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +InMm (
> +  VOID
> +  )
> +{
> +  return FALSE;
> +}
> diff --git 
> 

Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable from Standalone MM

[Ard Biesheuvel]

On Thu, 3 Jan 2019 at 10:52, Ard Biesheuvel  wrote:
>
> On Thu, 3 Jan 2019 at 08:43, Jagadeesh Ujja  wrote:
> >
> > hi Ard
> >
> > On Wed, Jan 2, 2019 at 10:45 PM Ard Biesheuvel
> >  wrote:
> > >
> > > On Thu, 20 Dec 2018 at 15:23, Gao, Liming  wrote:
> > > >
> > > > Jagadeesh:
> > > >   MdeModulePkg Variable service/Fault tolerant/Nor Flash driver depends 
> > > > on StandaloneMmServicesTableLib library class header file. This header 
> > > > file is added into MdePkg. It has two interfaces. One is global gMmst, 
> > > > another is function InMm(). So, there is no dependency issue here.
> > > > And, MdePkg adds one StandaloneMmServicesTableLib library INF with 
> > > > empty implementation, this library is just for build. It sets 
> > > > gMmst=NULL, and always return FASLE in InMm(). This library can be used 
> > > > in MdeModulePkg.dsc to make Variable driver pass build. There is also 
> > > > no dependency issue here. Last, Platform DSC file will refer to the 
> > > > real StandaloneMmServicesTableLib library INF from StandaloneMmPkg.
> > > >
> > >
> > > I think we should avoid the need for InMm() altogether for standalone
> > > MM. It will always return TRUE for standalone MM modules, and it will
> > > always return FALSE for other modules, so the distinction should be
> > > made at build time.
> > >
> > > This means that we need to refactor the SMM 'server' modules and/or
> > > libraries so that any code they cannot share (like boot services
> > > invocations) are only included in the classic SMM versions.
> > >
> > > I have pushed my own prototype code here:
> > > https://github.com/ardbiesheuvel/edk2/commits/standalone-mm
> > >
> > > There is some overlap with Jagadeesh's work. I will work with him
> > > directly to resolve this before posting any new revisions.
> > >
> > InMm()”  and “PcdStandaloneMmVariableEnabled” are defined to reuse the
> > existing code as much as possible.
> > Initially I have done separate copy of the file to avoid “if..else”
> > but had a comment about “duplicating code primarily due to the
> > maintenance overhead”
> >
>
> We shouldn't rely on runtime functions and PCDs to make build time decision.
>
> Lots of the SMM code can be refactored. As Jian suggested, we could
> introduce a helper library with implementations for the MM protocol
> handling and memory allocation routines exposed via the system table,
> so that the users can invoke the abstract library.
>

Actually, looking at the PI spec, it seems that SMM is deprecated, and
so we should port these drivers to the new MM system table entirely.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 00/13] Extend secure variable service to be usable from Standalone MM

[Ard Biesheuvel]

On Thu, 3 Jan 2019 at 08:43, Jagadeesh Ujja  wrote:
>
> hi Ard
>
> On Wed, Jan 2, 2019 at 10:45 PM Ard Biesheuvel
>  wrote:
> >
> > On Thu, 20 Dec 2018 at 15:23, Gao, Liming  wrote:
> > >
> > > Jagadeesh:
> > >   MdeModulePkg Variable service/Fault tolerant/Nor Flash driver depends 
> > > on StandaloneMmServicesTableLib library class header file. This header 
> > > file is added into MdePkg. It has two interfaces. One is global gMmst, 
> > > another is function InMm(). So, there is no dependency issue here.
> > > And, MdePkg adds one StandaloneMmServicesTableLib library INF with empty 
> > > implementation, this library is just for build. It sets gMmst=NULL, and 
> > > always return FASLE in InMm(). This library can be used in 
> > > MdeModulePkg.dsc to make Variable driver pass build. There is also no 
> > > dependency issue here. Last, Platform DSC file will refer to the real 
> > > StandaloneMmServicesTableLib library INF from StandaloneMmPkg.
> > >
> >
> > I think we should avoid the need for InMm() altogether for standalone
> > MM. It will always return TRUE for standalone MM modules, and it will
> > always return FALSE for other modules, so the distinction should be
> > made at build time.
> >
> > This means that we need to refactor the SMM 'server' modules and/or
> > libraries so that any code they cannot share (like boot services
> > invocations) are only included in the classic SMM versions.
> >
> > I have pushed my own prototype code here:
> > https://github.com/ardbiesheuvel/edk2/commits/standalone-mm
> >
> > There is some overlap with Jagadeesh's work. I will work with him
> > directly to resolve this before posting any new revisions.
> >
> InMm()”  and “PcdStandaloneMmVariableEnabled” are defined to reuse the
> existing code as much as possible.
> Initially I have done separate copy of the file to avoid “if..else”
> but had a comment about “duplicating code primarily due to the
> maintenance overhead”
>

We shouldn't rely on runtime functions and PCDs to make build time decision.

Lots of the SMM code can be refactored. As Jian suggested, we could
introduce a helper library with implementations for the MM protocol
handling and memory allocation routines exposed via the system table,
so that the users can invoke the abstract library.

As for the various boot services calls: these just have to be factored
out or replaced.
- gBS->CalculcateCrc32 () in the FTW driver can just be replaced with
the version from BaseLib (but only for the standalone MM version)
- MorLockInitAtEndOfDxe() in the variable driver attempts to locate
some TCG protocols to infer whether the variable may have been set by
platform firmware, this code just needs to be dropped in the
standalone MM version
- the ArmPkg NOR flash driver needs some refactoring in any case,
since all the block I/O and disk I/O routines can be dropped for
standalone MM.

So of course, we have to take the maintenance burden into account, and
so we have to refactor carefully so that we share as much code as
possible. But relying on InMm() and PCDs is not acceptable.

> So we are using “InMm()” and “PcdStandaloneMmVariableEnabled” PCD flag
> and trying to use the same code as much as possible.
>
> The patchset “Extend secure variable service to be usable from
> Standalone MM” as POC was submitted as RFC patches on “October 31,
> 2018”.
> Subsequent comments are fixed and we had 7 version of the patch set
> under review.
>

I'm not sure why you are bringing this up, but it is irrelevant. This
is important stuff that touches a lot of different packages, so if it
takes 20 revisions, so be it.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 26/26] Revert "MdePkg: avoid __builtin_unreachable() on GCC v4.4"

[Ard Biesheuvel]

On Thu, 3 Jan 2019 at 03:49, Laszlo Ersek  wrote:
>
> This reverts commit 357cec385d4f ("MdePkg: avoid __builtin_unreachable()
> on GCC v4.4", 2016-07-21).
>
> We've removed BaseTools support for GCC44..GCC47, therefore we need not
> catch the GCC44 corner case for __builtin_unreachable().
>
> No GCC44..GCC47 references remain under MdePkg after this patch.
>
> Cc: Ard Biesheuvel 
> Cc: Liming Gao 
> Cc: Marvin Haeuser 
> Cc: Michael D Kinney 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>
> Notes:
> I build-tested this change by building ArmVirtQemu with the GCC5
> toolchain (gcc-6.1.1), and OVMF with the GCC48 toolchain (gcc-4.8.5).
>
> Namely, the PeiCore() function [MdeModulePkg/Core/Pei/PeiMain/PeiMain.c]
> and the DxeMain() function [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c]
> use UNREACHABLE().
>
>  MdePkg/Include/Base.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h
> index bc877d8125a5..d6b04baeaf8b 100644
> --- a/MdePkg/Include/Base.h
> +++ b/MdePkg/Include/Base.h
> @@ -112,11 +112,10 @@ VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE, 4);
>  // warnings.
>  //
>  #ifndef UNREACHABLE
> -  #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)
> +  #ifdef __GNUC__
>  ///
>  /// Signal compilers and analyzers that this call is not reachable.  It 
> is
>  /// up to the compiler to remove any code past that point.
> -/// Not implemented by GCC 4.4 or earlier.
>  ///
>  #define UNREACHABLE()  __builtin_unreachable ()
>#elif defined (__has_feature)
> --
> 2.19.1.3.g30247aa5d201
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 24/26] ArmPkg/ArmSoftFloatLib: drop build flags specific to GCC46/GCC47

[Ard Biesheuvel]

On Thu, 3 Jan 2019 at 03:49, Laszlo Ersek  wrote:
>
> We've removed BaseTools support for GCC44..GCC47. Drop
> ArmPkg/ArmSoftFloatLib build flags that are specific to any of those gcc
> versions. (See also commit 01627dba0911, "ArmPkg/ArmSoftfloatLib: restrict
> -fno-tree-vrp option to GCC46 and GCC47", 2015-12-15).
>
> No GCC44..GCC47 references remain under ArmPkg after this patch.
>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>
> Notes:
> Build-tested with a 32-bit ArmVirtQemu build, with -D
> SECURE_BOOT_ENABLE, using the GCC5 toolchain. Such a build consumes
> ArmSoftFloatLib via OpensslLib.
>
>  ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf 
> b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> index 3c76381b25dc..9c4cd62b3dd9 100644
> --- a/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> +++ b/ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> @@ -49,6 +49,4 @@ [Packages]
>
>  [BuildOptions]
>GCC:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC -Wno-enum-compare -fno-lto
> -  *_GCC46_*_CC_FLAGS = -fno-tree-vrp
> -  *_GCC47_*_CC_FLAGS = -fno-tree-vrp
>RVCT:*_*_*_CC_FLAGS = -DSOFTFLOAT_FOR_GCC
> --
> 2.19.1.3.g30247aa5d201
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 02/26] OvmfPkg: require GCC48 or later

[Ard Biesheuvel]

On Thu, 3 Jan 2019 at 03:48, Laszlo Ersek  wrote:
>
> We're about to remove BaseTools support for GCC44..GCC47. Reject those gcc
> versions cleanly in "OvmfPkg/build.sh". In "OvmfPkg/README", upgrade any
> mentions of the same gcc versions to GCC48.
>
> No GCC44..GCC47 references remain under OvmfPkg after this patch.
>
> Cc: Anthony Perard 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>
> Notes:
> I tested that, after this patch, "build.sh" successfully builds OvmfPkg
> with GCC48. I did no runtime tests, nor did I test the rejection path
> with any of gcc-4.4 through gcc-4.7.
>
>  OvmfPkg/README   |  6 +++---
>  OvmfPkg/build.sh | 16 ++--
>  2 files changed, 5 insertions(+), 17 deletions(-)
>
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index 7415419d2dd7..68ce0750af19 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -115,8 +115,8 @@ $ OvmfPkg/build.sh -a X64 qemu
>  And to run a 64-bit UEFI bootable ISO image:
>  $ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso
>
> -To build a 32-bit OVMF without debug messages using GCC 4.5:
> -$ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC45
> +To build a 32-bit OVMF without debug messages using GCC 4.8:
> +$ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC48
>
>  === SMM support ===
>
> @@ -406,7 +406,7 @@ volume image.
>
>  If you build with the UNIXGCC toolchain, then debugging will be disabled
>  due to larger image sizes being produced by the UNIXGCC toolchain. The
> -first choice recommendation is to use GCC44 or newer instead.
> +first choice recommendation is to use GCC48 or newer instead.
>
>  If you must use UNIXGCC, then you can override the build options for
>  particular libraries and modules in the .dsc to re-enable debugging
> diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh
> index 682155202564..6821742e7acd 100755
> --- a/OvmfPkg/build.sh
> +++ b/OvmfPkg/build.sh
> @@ -83,22 +83,10 @@ case `uname` in
>Linux*)
>  gcc_version=$(gcc -v 2>&1 | tail -1 | awk '{print $3}')
>  case $gcc_version in
> -  [1-3].*|4.[0-3].*)
> -echo OvmfPkg requires GCC4.4 or later
> +  [1-3].*|4.[0-7].*)
> +echo OvmfPkg requires GCC4.8 or later
>  exit 1
>  ;;
> -  4.4.*)
> -TARGET_TOOLS=GCC44
> -;;
> -  4.5.*)
> -TARGET_TOOLS=GCC45
> -;;
> -  4.6.*)
> -TARGET_TOOLS=GCC46
> -;;
> -  4.7.*)
> -TARGET_TOOLS=GCC47
> -;;
>4.8.*)
>  TARGET_TOOLS=GCC48
>  ;;
> --
> 2.19.1.3.g30247aa5d201
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel