[edk2] [PATCH] UefiCpuPkg/FeaturesLib: Fix Haswell CPU hang with 50% throttling

[Ruiyu Ni]

Today's implementation only assumes SandyBridge CPU supports
Extended On-Demand Clock Modulation Duty Cycle.
Actually it is supported when CPUID.06h.EAX[5] == 1.

When platform requests 50% throttling, it causes value 1000b
set to the low-4 bits of IA32_CLOCK_MODULATION.
But the wrong code sets 1000b to bits[1-3] which causes assertion.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
Cc: Eric Dong 
---
 .../Library/CpuCommonFeaturesLib/ClockModulation.c | 52 ++
 1 file changed, 23 insertions(+), 29 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ClockModulation.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ClockModulation.c
index 56e53561e9..84d59de78f 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ClockModulation.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ClockModulation.c
@@ -1,7 +1,7 @@
 /** @file
   Clock Modulation feature.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2018, 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
@@ -67,40 +67,34 @@ ClockModulationInitialize (
   IN BOOLEAN   State
   )
 {
-  if (IS_SANDY_BRIDGE_PROCESSOR (CpuInfo->DisplayFamily, 
CpuInfo->DisplayModel)) {
-CPU_REGISTER_TABLE_WRITE_FIELD (
-  ProcessorNumber,
-  Msr,
-  MSR_SANDY_BRIDGE_IA32_CLOCK_MODULATION,
-  MSR_SANDY_BRIDGE_IA32_CLOCK_MODULATION_REGISTER,
-  Bits.OnDemandClockModulationDutyCycle,
-  PcdGet8 (PcdCpuClockModulationDutyCycle)
-  );
-CPU_REGISTER_TABLE_WRITE_FIELD (
-  ProcessorNumber,
-  Msr,
-  MSR_SANDY_BRIDGE_IA32_CLOCK_MODULATION,
-  MSR_SANDY_BRIDGE_IA32_CLOCK_MODULATION_REGISTER,
-  Bits.OnDemandClockModulationEnable,
-  (State) ? 1 : 0
-  );
-  } else {
-CPU_REGISTER_TABLE_WRITE_FIELD (
-  ProcessorNumber,
-  Msr,
-  MSR_IA32_CLOCK_MODULATION,
-  MSR_IA32_CLOCK_MODULATION_REGISTER,
-  Bits.OnDemandClockModulationDutyCycle,
-  PcdGet8 (PcdCpuClockModulationDutyCycle)
-  );
+  CPUID_THERMAL_POWER_MANAGEMENT_EAX   ThermalPowerManagementEax;
+  AsmCpuid (CPUID_THERMAL_POWER_MANAGEMENT, , 
NULL, NULL, NULL);
+
+  CPU_REGISTER_TABLE_WRITE_FIELD (
+ProcessorNumber,
+Msr,
+MSR_IA32_CLOCK_MODULATION,
+MSR_IA32_CLOCK_MODULATION_REGISTER,
+Bits.OnDemandClockModulationDutyCycle,
+PcdGet8 (PcdCpuClockModulationDutyCycle) >> 1
+);
+  if (ThermalPowerManagementEax.Bits.ECMD == 1) {
 CPU_REGISTER_TABLE_WRITE_FIELD (
   ProcessorNumber,
   Msr,
   MSR_IA32_CLOCK_MODULATION,
   MSR_IA32_CLOCK_MODULATION_REGISTER,
-  Bits.OnDemandClockModulationEnable,
-  (State) ? 1 : 0
+  Bits.ExtendedOnDemandClockModulationDutyCycle,
+  PcdGet8 (PcdCpuClockModulationDutyCycle) & BIT0
   );
   }
+  CPU_REGISTER_TABLE_WRITE_FIELD (
+ProcessorNumber,
+Msr,
+MSR_IA32_CLOCK_MODULATION,
+MSR_IA32_CLOCK_MODULATION_REGISTER,
+Bits.OnDemandClockModulationEnable,
+(State) ? 1 : 0
+);
   return RETURN_SUCCESS;
 }
-- 
2.16.1.windows.1

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

[edk2] [PATCH] BaseTools: Fix COMPRESS alignment incorrect issue

[Feng, YunhuaX]

Doesn't generate the correct alignment for the leaf section
in the compression section.
Below FFS rule doesn't work as the expectation.

[Rule.Common.PEIM.PE32]
  FILE PEIM = $(NAMED_GUID) {
PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
COMPRESS {
  PE32   PE32  Align=Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
  UI STRING="$(MODULE_NAME)" Optional
  VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
}
  }

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/GenFds/CompressSection.py | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/BaseTools/Source/Python/GenFds/CompressSection.py 
b/BaseTools/Source/Python/GenFds/CompressSection.py
index 64ad275d83..98532ed8e6 100644
--- a/BaseTools/Source/Python/GenFds/CompressSection.py
+++ b/BaseTools/Source/Python/GenFds/CompressSection.py
@@ -59,18 +59,32 @@ class CompressSection (CompressSectionClassObject) :
 self.CompType = FfsInf.__ExtendMacro__(self.CompType)
 self.Alignment = FfsInf.__ExtendMacro__(self.Alignment)
 
 SectFiles = tuple()
 Index = 0
+MaxAlign = None
 for Sect in self.SectionList:
 Index = Index + 1
 SecIndex = '%s.%d' %(SecNum, Index)
 ReturnSectList, AlignValue = Sect.GenSection(OutputPath, 
ModuleName, SecIndex, KeyStringList, FfsInf, Dict, IsMakefile=IsMakefile)
+if AlignValue != None:
+if MaxAlign == None:
+MaxAlign = AlignValue
+if GenFdsGlobalVariable.GetAlignment (AlignValue) > 
GenFdsGlobalVariable.GetAlignment (MaxAlign):
+MaxAlign = AlignValue
 if ReturnSectList != []:
+if AlignValue == None:
+AlignValue = "1"
 for FileData in ReturnSectList:
 SectFiles += (FileData,)
 
+if MaxAlign != None:
+if self.Alignment == None:
+self.Alignment = MaxAlign
+else:
+if GenFdsGlobalVariable.GetAlignment (MaxAlign) > 
GenFdsGlobalVariable.GetAlignment (self.Alignment):
+self.Alignment = MaxAlign
 
 OutputFile = OutputPath + \
  os.sep + \
  ModuleName + \
  'SEC'  + \
-- 
2.12.2.windows.2

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

[edk2] [Patch] BaseTools: Fixed Build failed issue.

[BobCF]

If the PCD is not used in DSC file and user set
that PCD value from Command line, build will fail.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 1da4f03ab8..6e3cd0f3f1 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -896,11 +896,12 @@ class DscBuildData(PlatformBuildClassObject):
 else:
 pcdobj = self._Pcds.get((pcd[1],pcd[0]))
 if pcdobj:
 pcdset.append((pcd[0],pcd[1], pcdobj.DefaultValue))
 else:
-pcdset.append((pcd[0],pcd[1],pcd[3]))
+pcdvalue = pcd[3] if len(pcd) == 4 else pcd[2]
+pcdset.append((pcd[0],pcd[1],pcdvalue))
 GlobalData.BuildOptionPcd = pcdset
 def GetFieldValueFromComm(self,ValueStr,TokenSpaceGuidCName, TokenCName, 
FieldName):
 PredictedFieldType = "VOID*"
 if ValueStr.startswith('L'):
 if not ValueStr[1]:
@@ -2163,14 +2164,18 @@ class DscBuildData(PlatformBuildClassObject):
 
 
 for pcd in Pcds.values():
 SkuInfoObj = pcd.SkuInfoList.values()[0]
 pcdDecObject = self._DecPcds[pcd.TokenCName, 
pcd.TokenSpaceGuidCName]
+pcd.DatumType = pcdDecObject.DatumType
 # Only fix the value while no value provided in DSC file.
 for sku in pcd.SkuInfoList.values():
 if (sku.HiiDefaultValue == "" or sku.HiiDefaultValue == None):
 sku.HiiDefaultValue = pcdDecObject.DefaultValue
+for default_store in sku.DefaultStoreDict:
+
sku.DefaultStoreDict[default_store]=pcdDecObject.DefaultValue
+pcd.DefaultValue = pcdDecObject.DefaultValue
 if 'DEFAULT' not in pcd.SkuInfoList.keys() and 'COMMON' not in 
pcd.SkuInfoList.keys():
 valuefromDec = pcdDecObject.DefaultValue
 SkuInfo = SkuInfoClass('DEFAULT', '0', 
SkuInfoObj.VariableName, SkuInfoObj.VariableGuid, SkuInfoObj.VariableOffset, 
valuefromDec,VariableAttribute=SkuInfoObj.VariableAttribute,DefaultStore={DefaultStore:valuefromDec})
 pcd.SkuInfoList['DEFAULT'] = SkuInfo
 elif 'DEFAULT' not in pcd.SkuInfoList.keys() and 'COMMON' in 
pcd.SkuInfoList.keys():
-- 
2.14.3.windows.1

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

Re: [edk2] [PATCH edk2/MdePkg v2] MdePkg ACPI: Add some macros for PPTT

[Zeng, Star]

Reviewed-by: Star Zeng 


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Tuesday, February 6, 2018 2:42 PM
To: leif.lindh...@linaro.org; linaro-u...@lists.linaro.org; 
edk2-devel@lists.01.org; graeme.greg...@linaro.org
Cc: huangmin...@huawei.com; ard.biesheu...@linaro.org; john.ga...@huawei.com; 
zhangjinso...@huawei.com; Heyi Guo ; 
wanghuiqi...@huawei.com; guoh...@huawei.com; wai...@126.com; 
mengfanr...@huawei.com; huangda...@hisilicon.com
Subject: [edk2] [PATCH edk2/MdePkg v2] MdePkg ACPI: Add some macros for PPTT

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang 
Signed-off-by: Heyi Guo 
---
 MdePkg/Include/IndustryStandard/Acpi62.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h 
b/MdePkg/Include/IndustryStandard/Acpi62.h
index 2904d34..730365b 100644
--- a/MdePkg/Include/IndustryStandard/Acpi62.h
+++ b/MdePkg/Include/IndustryStandard/Acpi62.h
@@ -2557,6 +2557,12 @@ typedef struct {
 } EFI_ACPI_6_2_PPTT_STRUCTURE_HEADER;
 
 ///
+/// For PPTT struct processor flags
+///
+#define EFI_ACPI_6_2_PPTT_PROCESSOR_ID_INVALID 0x0
+#define EFI_ACPI_6_2_PPTT_PROCESSOR_ID_VALID   0x1
+
+///
 /// Processor hierarchy node structure flags  ///  typedef struct { @@ -2593,6 
+2599,18 @@ typedef struct {  } EFI_ACPI_6_2_PPTT_STRUCTURE_CACHE_FLAGS;
 
 ///
+/// For cache attributes
+///
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_WRITE   0x1
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ_WRITE  0x2
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_DATA0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_INSTRUCTION 0x1
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_UNIFIED 0x2
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_THROUGH 0x1
+
+///
 /// Cache Type Structure cache attributes  ///  typedef struct {
--
1.9.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

[edk2] [Patch V2] BaseTools: not specified value of MAX_CONCURRENT_THREAD_NUMBER

[Yonghong Zhu]

V2: add info that when value set to 1 means disable multiple thread.

when MAX_CONCURRENT_THREAD_NUMBER is not specified, tool will
automatically detect number of processor threads.

Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=775
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Conf/target.template | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/BaseTools/Conf/target.template b/BaseTools/Conf/target.template
index 787fc64..5ff0c19 100644
--- a/BaseTools/Conf/target.template
+++ b/BaseTools/Conf/target.template
@@ -1,7 +1,7 @@
 #
-#  Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2018, 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
@@ -57,14 +57,17 @@ TOOL_CHAIN_CONF   = Conf/tools_def.txt
 #  TAGNAME   List  Optional   Specify the name(s) of the 
tools_def.txt TagName to use.
 # If not specified, all applicable 
TagName tools will be
 # used for the build.  The list 
uses space character separation.
 TOOL_CHAIN_TAG= MYTOOLS
 
-# MAX_CONCURRENT_THREAD_NUMBER  NUMBER  Optional  The number of concurrent 
threads. Recommend to set this
-# value to one more than the 
number of your compurter
-# cores or CPUs. Less than 2 
means disable multithread build.
-MAX_CONCURRENT_THREAD_NUMBER = 1
+# MAX_CONCURRENT_THREAD_NUMBER  NUMBER  Optional  The number of concurrent 
threads. If not specified or set
+# to zero, tool automatically 
detect number of processor
+# threads. Recommend to set 
this value to one less than the
+# number of your computer 
cores or CPUs. When value set to 1,
+# means disable multithread 
build. Not specify the default
+# value in this file.
+# MAX_CONCURRENT_THREAD_NUMBER = 1
 
 
 # BUILD_RULE_CONF  Filename Optional  Specify the file name to use for the 
build rules that are followed
 # when generating Makefiles. If not 
specified, the file: 
 # WORKSPACE/Conf/build_rule.txt will be 
used
-- 
2.6.1.windows.1

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

Re: [edk2] [Patch] MdeModulePkg: Don't build VarCheckUefiLib and DxeCore for EBC arch

[Zeng, Star]

Liming,

I am aware the purpose of the change.
And I do not want VarCheckUefiLib and VariableRuntimeDxe to be separated.
So I prefer to move VariableRuntimeDxe.

With that handled, Reviewed-by: Star Zeng 


Thanks,
Star
-Original Message-
From: Gao, Liming 
Sent: Tuesday, February 6, 2018 3:00 PM
To: Zeng, Star ; edk2-devel@lists.01.org
Subject: RE: [edk2] [Patch] MdeModulePkg: Don't build VarCheckUefiLib and 
DxeCore for EBC arch

Star:
  I don't know why only VariableRuntimeDxe and EmuVariableRuntimeDxe are in 
[Components.IA32, Components.X64, Components.Ebc]. This patch is not to build 
VarCheckUefiLib and DxeCore for EBC arch. It doesn't touch others. For your 
comments, I can change VariableRuntimeDxe not build for EBC. 

Thanks
Liming
>-Original Message-
>From: Zeng, Star
>Sent: Tuesday, February 06, 2018 2:53 PM
>To: Gao, Liming ; edk2-devel@lists.01.org
>Cc: Zeng, Star 
>Subject: RE: [edk2] [Patch] MdeModulePkg: Don't build VarCheckUefiLib 
>and DxeCore for EBC arch
>
>Liming,
>
>Moving VarCheckUefiLib to be separated with VariableRuntimeDxe is 
>strange to me.
>It is not just for build, and also to demonstrate how is the library 
>linked with VariableRuntimeDxe.
>And why only VariableRuntimeDxe and EmuVariableRuntimeDxe are put in 
>[Components.IA32, Components.X64, Components.Ebc], but not others, for 
>example RegularExpressionDxe and RamDiskDxe, etc?
>
>If feasible, I prefer to move VariableRuntimeDxe (include its linking 
>libraries) and EmuVariableRuntimeDxe to [Components.IA32, 
>Components.X64, Components.IPF, Components.AARCH64].
>
>
>Thanks,
>Star
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>Liming Gao
>Sent: Tuesday, January 30, 2018 1:33 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] MdeModulePkg: Don't build VarCheckUefiLib and 
>DxeCore for EBC arch
>
>EBC build failure is caused by d7a09cb86a0416c099fa3a9e0fbe2c8f399b28de.
>It changes MAX_UINTN and MAX_ADDRESS definition as below.
>VarCheckUefiLib and DxeCore uses MAX_UINTN and MAX_ADDRESS in the 
>global data initialization.
>New style has >> operator, and not supported by EBC compiler.
>The fix is not to build VarCheckUefiLib and DxeCore for EBC arch.
>
>#define MAX_UINTN  ((UINTN) ~0)
>==>
>#define MAX_UINTN  ((UINTN)(~0ULL >> (64 - sizeof (INTN) * 8)))
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Liming Gao 
>---
> MdeModulePkg/MdeModulePkg.dsc | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
>diff --git a/MdeModulePkg/MdeModulePkg.dsc 
>b/MdeModulePkg/MdeModulePkg.dsc index dd7e9d5..f4062fa 100644
>--- a/MdeModulePkg/MdeModulePkg.dsc
>+++ b/MdeModulePkg/MdeModulePkg.dsc
>@@ -267,10 +267,6 @@
>   MdeModulePkg/Bus/Isa/Ps2MouseDxe/Ps2MouseDxe.inf
>
>MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePci
>DeviceDxe.inf
>
>-  MdeModulePkg/Core/Dxe/DxeMain.inf {
>-
>-
>NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32G
>uidedSectionExtractLib.inf
>-  }
>   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>   MdeModulePkg/Core/Pei/PeiMain.inf
>   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>@@ -314,7 +310,6 @@
>
>MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.
>inf
>   MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
>   MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
>-  MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>   MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLib.inf
>   MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
>   MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.inf
>@@ -439,10 +434,16 @@
>   MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf
>   MdeModulePkg/Universal/EbcDxe/EbcDebuggerConfig.inf
>
>+[Components.IA32, Components.X64, Components.IPF, Components.ARM, 
>+Components.AARCH64]
>+  MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>+  MdeModulePkg/Core/Dxe/DxeMain.inf {
>+
>+
>+NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32
>Guide
>+dSectionExtractLib.inf
>+  }
>+
> [Components.IA32, Components.X64, Components.Ebc]
>   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
> 
>-  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>   NULL|MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLib.inf
>   NULL|MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
>   }
>--
>2.8.0.windows.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

[edk2] [Patch V2] Build spec: Add description about auto detect thread number

[Yonghong Zhu]

V2: add info that when value set to 1 means disable multiple thread.

Add description about enable auto detect thread number when
MAX_CONCURRENT_THREAD_NUMBER is not specified.

Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=775
Cc: Liming Gao 
Cc: Michael Kinney 
Cc: Kevin W Shaw 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 5_meta-data_file_specifications/53_target_txt_file.md | 7 ---
 appendix_d_buildexe_command/d4_usage.md   | 3 +--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/5_meta-data_file_specifications/53_target_txt_file.md 
b/5_meta-data_file_specifications/53_target_txt_file.md
index ff8c2ec..8fe77eb 100644
--- a/5_meta-data_file_specifications/53_target_txt_file.md
+++ b/5_meta-data_file_specifications/53_target_txt_file.md
@@ -116,13 +116,14 @@ Specify the name of the `tools_def.txt` tool chain tag 
name to use. If not
 specified in this file and it is not specified using the `-t` option on the
 command-line, then the build will break.
 
 **_Integer_**
 
-The number of concurrent threads. The default, if not specified or set to zero,
-is 2 Recommend setting this value to one more than the number of computer cores
-or CPUs of the development workstation.
+The number of concurrent threads. If not specified or set to zero, tool
+automatically detect number of processor threads. Recommend setting this
+value to one less than the number of computer cores or CPUs of the development
+workstation. When value set to 1, means disable multithread build.
 
 **_BuildRulesFile_**
 
 Specify the file name to use for the build rules that are followed when
 generating Makefiles. If not specified, the file:
diff --git a/appendix_d_buildexe_command/d4_usage.md 
b/appendix_d_buildexe_command/d4_usage.md
index 57d2656..c9777ef 100644
--- a/appendix_d_buildexe_command/d4_usage.md
+++ b/appendix_d_buildexe_command/d4_usage.md
@@ -60,12 +60,11 @@ Options:
   -x SKUID, --sku-id=SKUID
 Using this name of SKU ID to build the platform,
 overriding SKUID_IDENTIFIER in DSC file.
   -n THREADNUMBER   Build the platform using multi-threaded compiler. The
 value overrides target.txt's
-MAX_CONCURRENT_THREAD_NUMBER. Less than 2 will disable
-multi-thread builds.
+MAX_CONCURRENT_THREAD_NUMBER.
   -f FDFFILE, --fdf=FDFFILE
 The name of the FDF file to use, which overrides the
 setting in the DSC file.
   -r ROMIMAGE, --rom-image=ROMIMAGE
 The name of FD to be generated. The name must be from
-- 
2.6.1.windows.1

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

Re: [edk2] [PATCH] MdeModulePkg/PiSmmCore: add API parameter check

[Zeng, Star]

Reviewed-by: Star Zeng 


Thanks,
Star
-Original Message-
From: Wang, Jian J 
Sent: Tuesday, February 6, 2018 1:14 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric 
Subject: [PATCH] MdeModulePkg/PiSmmCore: add API parameter check

The Heap Guard feature wrapped SmmInternalFreePagesEx with 
SmmInternalFreePagesExWithGuard but didn't add necessary parameter check. This 
patch fixes this situation.

Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/PiSmmCore/HeapGuard.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c 
b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
index 063a330b18..c5ffb26342 100644
--- a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
+++ b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
@@ -1205,6 +1205,10 @@ SmmInternalFreePagesExWithGuard (
   EFI_PHYSICAL_ADDRESSMemoryToFree;
   UINTN   PagesToFree;
 
+  if (((Memory & EFI_PAGE_MASK) != 0) || (Memory == 0) || (NumberOfPages == 
0)) {
+return EFI_INVALID_PARAMETER;
+  }
+
   MemoryToFree  = Memory;
   PagesToFree   = NumberOfPages;
 
--
2.14.1.windows.1

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

Re: [edk2] [Patch] MdeModulePkg: Don't build VarCheckUefiLib and DxeCore for EBC arch

[Gao, Liming]

Star:
  I don't know why only VariableRuntimeDxe and EmuVariableRuntimeDxe are in 
[Components.IA32, Components.X64, Components.Ebc]. This patch is not to build 
VarCheckUefiLib and DxeCore for EBC arch. It doesn't touch others. For your 
comments, I can change VariableRuntimeDxe not build for EBC. 

Thanks
Liming
>-Original Message-
>From: Zeng, Star
>Sent: Tuesday, February 06, 2018 2:53 PM
>To: Gao, Liming ; edk2-devel@lists.01.org
>Cc: Zeng, Star 
>Subject: RE: [edk2] [Patch] MdeModulePkg: Don't build VarCheckUefiLib and
>DxeCore for EBC arch
>
>Liming,
>
>Moving VarCheckUefiLib to be separated with VariableRuntimeDxe is strange
>to me.
>It is not just for build, and also to demonstrate how is the library linked 
>with
>VariableRuntimeDxe.
>And why only VariableRuntimeDxe and EmuVariableRuntimeDxe are put in
>[Components.IA32, Components.X64, Components.Ebc], but not others, for
>example RegularExpressionDxe and RamDiskDxe, etc?
>
>If feasible, I prefer to move VariableRuntimeDxe (include its linking 
>libraries)
>and EmuVariableRuntimeDxe to [Components.IA32, Components.X64,
>Components.IPF, Components.AARCH64].
>
>
>Thanks,
>Star
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Liming Gao
>Sent: Tuesday, January 30, 2018 1:33 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] MdeModulePkg: Don't build VarCheckUefiLib and
>DxeCore for EBC arch
>
>EBC build failure is caused by d7a09cb86a0416c099fa3a9e0fbe2c8f399b28de.
>It changes MAX_UINTN and MAX_ADDRESS definition as below.
>VarCheckUefiLib and DxeCore uses MAX_UINTN and MAX_ADDRESS in the
>global data initialization.
>New style has >> operator, and not supported by EBC compiler.
>The fix is not to build VarCheckUefiLib and DxeCore for EBC arch.
>
>#define MAX_UINTN  ((UINTN) ~0)
>==>
>#define MAX_UINTN  ((UINTN)(~0ULL >> (64 - sizeof (INTN) * 8)))
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Liming Gao 
>---
> MdeModulePkg/MdeModulePkg.dsc | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
>diff --git a/MdeModulePkg/MdeModulePkg.dsc
>b/MdeModulePkg/MdeModulePkg.dsc index dd7e9d5..f4062fa 100644
>--- a/MdeModulePkg/MdeModulePkg.dsc
>+++ b/MdeModulePkg/MdeModulePkg.dsc
>@@ -267,10 +267,6 @@
>   MdeModulePkg/Bus/Isa/Ps2MouseDxe/Ps2MouseDxe.inf
>
>MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePci
>DeviceDxe.inf
>
>-  MdeModulePkg/Core/Dxe/DxeMain.inf {
>-
>-
>NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32G
>uidedSectionExtractLib.inf
>-  }
>   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
>   MdeModulePkg/Core/Pei/PeiMain.inf
>   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
>@@ -314,7 +310,6 @@
>
>MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.
>inf
>   MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
>   MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
>-  MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>   MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLib.inf
>   MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
>   MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.inf
>@@ -439,10 +434,16 @@
>   MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf
>   MdeModulePkg/Universal/EbcDxe/EbcDebuggerConfig.inf
>
>+[Components.IA32, Components.X64, Components.IPF, Components.ARM,
>+Components.AARCH64]
>+  MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>+  MdeModulePkg/Core/Dxe/DxeMain.inf {
>+
>+
>+NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32
>Guide
>+dSectionExtractLib.inf
>+  }
>+
> [Components.IA32, Components.X64, Components.Ebc]
>   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
> 
>-  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
>   NULL|MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLib.inf
>   NULL|MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
>   }
>--
>2.8.0.windows.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] MdeModulePkg: Don't build VarCheckUefiLib and DxeCore for EBC arch

[Zeng, Star]

Liming,

Moving VarCheckUefiLib to be separated with VariableRuntimeDxe is strange to me.
It is not just for build, and also to demonstrate how is the library linked 
with VariableRuntimeDxe.
And why only VariableRuntimeDxe and EmuVariableRuntimeDxe are put in 
[Components.IA32, Components.X64, Components.Ebc], but not others, for example 
RegularExpressionDxe and RamDiskDxe, etc?

If feasible, I prefer to move VariableRuntimeDxe (include its linking 
libraries) and EmuVariableRuntimeDxe to [Components.IA32, Components.X64, 
Components.IPF, Components.AARCH64].


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Tuesday, January 30, 2018 1:33 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] MdeModulePkg: Don't build VarCheckUefiLib and DxeCore 
for EBC arch

EBC build failure is caused by d7a09cb86a0416c099fa3a9e0fbe2c8f399b28de.
It changes MAX_UINTN and MAX_ADDRESS definition as below. VarCheckUefiLib and 
DxeCore uses MAX_UINTN and MAX_ADDRESS in the global data initialization.
New style has >> operator, and not supported by EBC compiler.
The fix is not to build VarCheckUefiLib and DxeCore for EBC arch.

#define MAX_UINTN  ((UINTN) ~0)
==>
#define MAX_UINTN  ((UINTN)(~0ULL >> (64 - sizeof (INTN) * 8)))

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
---
 MdeModulePkg/MdeModulePkg.dsc | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc 
index dd7e9d5..f4062fa 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -267,10 +267,6 @@
   MdeModulePkg/Bus/Isa/Ps2MouseDxe/Ps2MouseDxe.inf
   
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
-  MdeModulePkg/Core/Dxe/DxeMain.inf {
-
-  
NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
-  }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
   MdeModulePkg/Core/Pei/PeiMain.inf
   MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
@@ -314,7 +310,6 @@
   MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
   MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
-  MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLib.inf
   MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
   MdeModulePkg/Library/PlatformVarCleanupLib/PlatformVarCleanupLib.inf
@@ -439,10 +434,16 @@
   MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf
   MdeModulePkg/Universal/EbcDxe/EbcDebuggerConfig.inf
 
+[Components.IA32, Components.X64, Components.IPF, Components.ARM, 
+Components.AARCH64]
+  MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  MdeModulePkg/Core/Dxe/DxeMain.inf {
+
+  
+NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32Guide
+dSectionExtractLib.inf
+  }
+
 [Components.IA32, Components.X64, Components.Ebc]
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 
-  NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   NULL|MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiLib.inf
   NULL|MdeModulePkg/Library/VarCheckPcdLib/VarCheckPcdLib.inf
   }
--
2.8.0.windows.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

[edk2] [PATCH edk2/MdePkg v2] MdePkg ACPI: Add some macros for PPTT

[Heyi Guo]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang 
Signed-off-by: Heyi Guo 
---
 MdePkg/Include/IndustryStandard/Acpi62.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h 
b/MdePkg/Include/IndustryStandard/Acpi62.h
index 2904d34..730365b 100644
--- a/MdePkg/Include/IndustryStandard/Acpi62.h
+++ b/MdePkg/Include/IndustryStandard/Acpi62.h
@@ -2557,6 +2557,12 @@ typedef struct {
 } EFI_ACPI_6_2_PPTT_STRUCTURE_HEADER;
 
 ///
+/// For PPTT struct processor flags
+///
+#define EFI_ACPI_6_2_PPTT_PROCESSOR_ID_INVALID 0x0
+#define EFI_ACPI_6_2_PPTT_PROCESSOR_ID_VALID   0x1
+
+///
 /// Processor hierarchy node structure flags
 ///
 typedef struct {
@@ -2593,6 +2599,18 @@ typedef struct {
 } EFI_ACPI_6_2_PPTT_STRUCTURE_CACHE_FLAGS;
 
 ///
+/// For cache attributes
+///
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_WRITE   0x1
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ_WRITE  0x2
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_DATA0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_INSTRUCTION 0x1
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_UNIFIED 0x2
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_THROUGH 0x1
+
+///
 /// Cache Type Structure cache attributes
 ///
 typedef struct {
-- 
1.9.1

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

[edk2] [PATCH edk2/MdePkg v2] Add some macros for PPTT

[Heyi Guo]

Add some macros to Acpi62.h for PPTT as ACPI 6.2 Spec.


Heyi Guo (1):
  MdePkg ACPI: Add some macros for PPTT

 MdePkg/Include/IndustryStandard/Acpi62.h | 18 ++
 1 file changed, 18 insertions(+)

-- 
1.9.1

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

Re: [edk2] [PATCH edk2/MdePkg v1] MdePkg ACPI: Add some macros for PPTT

[Zeng, Star]

I mean

+#define EFI_ACPI_6_2_PPTT_PROCESSOR_ID_INVALID0x0
+#define EFI_ACPI_6_2_PPTT_PROCESSOR_ID_VALID  0x1


Thanks,
Star
-Original Message-
From: Huangming (Mark) [mailto:huangmin...@huawei.com] 
Sent: Tuesday, February 6, 2018 2:12 PM
To: Zeng, Star ; Heyi Guo ; 
leif.lindh...@linaro.org; linaro-u...@lists.linaro.org; 
edk2-devel@lists.01.org; graeme.greg...@linaro.org
Cc: ard.biesheu...@linaro.org; Gao, Liming ; 
mengfanr...@huawei.com; guoh...@huawei.com; zhangjinso...@huawei.com; Kinney, 
Michael D ; wai...@126.com; 
wanghuiqi...@huawei.com; huangda...@hisilicon.com
Subject: Re: [edk2] [PATCH edk2/MdePkg v1] MdePkg ACPI: Add some macros for PPTT



On 2018/2/6 12:16, Zeng, Star wrote:
> How about using EFI_ACPI_6_2_PPTT_PROCESSOR_ID_XXX to be more specific?
> 

like this?
EFI_ACPI_6_2_PPTT_PROCESSOR_ID_PHYSICAL_PACKAGE 0x01
EFI_ACPI_6_2_PPTT_PROCESSOR_ID_ACPI_PROCESSOR   0x01

> Others are good to me.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Heyi Guo
> Sent: Friday, February 2, 2018 11:30 AM
> To: leif.lindh...@linaro.org; linaro-u...@lists.linaro.org; 
> edk2-devel@lists.01.org; graeme.greg...@linaro.org
> Cc: huangmin...@huawei.com; ard.biesheu...@linaro.org; Gao, Liming 
> ; mengfanr...@huawei.com; guoh...@huawei.com; 
> Heyi Guo ; zhangjinso...@huawei.com; Kinney, 
> Michael D ; wai...@126.com; 
> wanghuiqi...@huawei.com; huangda...@hisilicon.com
> Subject: [edk2] [PATCH edk2/MdePkg v1] MdePkg ACPI: Add some macros 
> for PPTT
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> Signed-off-by: Heyi Guo 
> ---
>  MdePkg/Include/IndustryStandard/Acpi62.h | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h 
> b/MdePkg/Include/IndustryStandard/Acpi62.h
> index 2904d34..30faba9 100644
> --- a/MdePkg/Include/IndustryStandard/Acpi62.h
> +++ b/MdePkg/Include/IndustryStandard/Acpi62.h
> @@ -2557,6 +2557,12 @@ typedef struct {  } 
> EFI_ACPI_6_2_PPTT_STRUCTURE_HEADER;
>  
>  ///
> +/// Value for valid fields in PPTT struct ///
> +#define EFI_ACPI_6_2_PPTT_INVALID0x0
> +#define EFI_ACPI_6_2_PPTT_VALID  0x1
> +
> +///
>  /// Processor hierarchy node structure flags  ///  typedef struct { 
> @@ -2593,6 +2599,18 @@ typedef struct {  } 
> EFI_ACPI_6_2_PPTT_STRUCTURE_CACHE_FLAGS;
>  
>  ///
> +/// For cache attributes
> +///
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_WRITE   0x1
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ_WRITE  0x2
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_DATA0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_INSTRUCTION 0x1
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_UNIFIED 0x2
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_THROUGH 0x1
> +
> +///
>  /// Cache Type Structure cache attributes  ///  typedef struct {
> 

--
Best Regards,

Ming

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

Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: fix infinite loop issue in SMM profile

[Yao, Jiewen]

Hi
May I know how "3" is calculated?

+  RestorePageNumber = 3;

Thank you
Yao Jiewen


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J
> Wang
> Sent: Tuesday, February 6, 2018 11:02 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Yao, Jiewen ; Laszlo
> Ersek ; Dong, Eric 
> Subject: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: fix infinite loop issue in
> SMM profile
> 
> The infinite loop is caused by the memory instruction, such as
> "rep mov", operating on memory block crossing boundary of NON-PRESENT
> pages. Because the address triggering page fault set in CR2 will be in
> the first page, SmmProfilePFHandler() will only change the first page
> into PRESENT. The page following will be still in NON-PRESENT status.
> 
> Since SmmProfilePFHandler() will setup single-step trap for the
> instruction causing #PF, when the handler returns back to the
> instruction and re-execute it, both #DB and #PF will be triggered
> because the instruction wants to access both first and second page
> but only first page is PRESENT.
> 
> Normally #DB exception will be handled first and its handler will
> change first page back to NON-PRESENT status. Then #PF is handled
> and its handler will change first page to PRESENT status again and
> setup another single-step for the instruction triggering #PF. Then
> the whole system falls into an infinite loop and the memory operation
> will never move on.
> 
> This patch fix above situation by always changing 3 pages to PRESENT
> status instead of just 1 page. Those 3 pages include the page before
> and after the page causing #PF because memory operation instruction
> may have direction flag (DF) set or cleared.
> 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Ruiyu Ni 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> index 9588eaf029..8cdfc82a92 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
> @@ -1302,6 +1302,8 @@ SmmProfilePFHandler (
>  {
>UINT64*PageTable;
>UINT64PFAddress;
> +  UINT64RestoreAddress;
> +  UINTN RestorePageNumber;
>UINTN CpuIndex;
>UINTN Index;
>UINT64InstructionAddress;
> @@ -1331,10 +1333,22 @@ SmmProfilePFHandler (
>PFAddress = AsmReadCr2 ();
>CpuIndex  = GetCpuIndex ();
> 
> -  if (PFAddress <= 0x) {
> -RestorePageTableBelow4G (PageTable, PFAddress, CpuIndex, ErrorCode);
> -  } else {
> -RestorePageTableAbove4G (PageTable, PFAddress, CpuIndex, ErrorCode,
> );
> +  //
> +  // Memory operation cross pages, like "rep mov" instruction, will cause
> +  // infinite loop between this and Debug Trap handler. Since the direction
> +  // of memory operation is unknown, the pages before and after current page
> +  // should be taken into account as well.
> +  //
> +  RestorePageNumber = 3;
> +  RestoreAddress = PFAddress - EFI_PAGE_SIZE;
> +  while (RestorePageNumber > 0) {
> +if (RestoreAddress <= 0x) {
> +  RestorePageTableBelow4G (PageTable, RestoreAddress, CpuIndex,
> ErrorCode);
> +} else {
> +  RestorePageTableAbove4G (PageTable, RestoreAddress, CpuIndex,
> ErrorCode, );
> +}
> +RestoreAddress += EFI_PAGE_SIZE;
> +RestorePageNumber--;
>}
> 
>if (!IsValidPFAddress) {
> --
> 2.14.1.windows.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 edk2/MdePkg v1] MdePkg ACPI: Add some macros for PPTT

[Huangming (Mark)]

On 2018/2/6 12:16, Zeng, Star wrote:
> How about using EFI_ACPI_6_2_PPTT_PROCESSOR_ID_XXX to be more specific?
> 

like this?
EFI_ACPI_6_2_PPTT_PROCESSOR_ID_PHYSICAL_PACKAGE 0x01
EFI_ACPI_6_2_PPTT_PROCESSOR_ID_ACPI_PROCESSOR   0x01

> Others are good to me.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi 
> Guo
> Sent: Friday, February 2, 2018 11:30 AM
> To: leif.lindh...@linaro.org; linaro-u...@lists.linaro.org; 
> edk2-devel@lists.01.org; graeme.greg...@linaro.org
> Cc: huangmin...@huawei.com; ard.biesheu...@linaro.org; Gao, Liming 
> ; mengfanr...@huawei.com; guoh...@huawei.com; Heyi Guo 
> ; zhangjinso...@huawei.com; Kinney, Michael D 
> ; wai...@126.com; wanghuiqi...@huawei.com; 
> huangda...@hisilicon.com
> Subject: [edk2] [PATCH edk2/MdePkg v1] MdePkg ACPI: Add some macros for PPTT
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> Signed-off-by: Heyi Guo 
> ---
>  MdePkg/Include/IndustryStandard/Acpi62.h | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h 
> b/MdePkg/Include/IndustryStandard/Acpi62.h
> index 2904d34..30faba9 100644
> --- a/MdePkg/Include/IndustryStandard/Acpi62.h
> +++ b/MdePkg/Include/IndustryStandard/Acpi62.h
> @@ -2557,6 +2557,12 @@ typedef struct {
>  } EFI_ACPI_6_2_PPTT_STRUCTURE_HEADER;
>  
>  ///
> +/// Value for valid fields in PPTT struct
> +///
> +#define EFI_ACPI_6_2_PPTT_INVALID0x0
> +#define EFI_ACPI_6_2_PPTT_VALID  0x1
> +
> +///
>  /// Processor hierarchy node structure flags
>  ///
>  typedef struct {
> @@ -2593,6 +2599,18 @@ typedef struct {
>  } EFI_ACPI_6_2_PPTT_STRUCTURE_CACHE_FLAGS;
>  
>  ///
> +/// For cache attributes
> +///
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_WRITE   0x1
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ_WRITE  0x2
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_DATA0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_INSTRUCTION 0x1
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_UNIFIED 0x2
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_THROUGH 0x1
> +
> +///
>  /// Cache Type Structure cache attributes
>  ///
>  typedef struct {
> 

-- 
Best Regards,

Ming

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

Re: [edk2] [Patch] SecurityPkg: Don't build AuthVariableLib for EBC arch

[Zhang, Chao B]

Reviewed-by: Chao Zhang 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Tuesday, January 30, 2018 1:34 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] SecurityPkg: Don't build AuthVariableLib for EBC arch

EBC build failure is caused by d7a09cb86a0416c099fa3a9e0fbe2c8f399b28de.
It changes MAX_UINTN definition as below. AuthVariableLib uses MAX_UINTN in the 
global data initialization. New style has >> operator, and not supported by EBC 
compiler. The fix is not to build AuthVariableLib for EBC.

#define MAX_UINTN  ((UINTN) ~0)
==>
#define MAX_UINTN  ((UINTN)(~0ULL >> (64 - sizeof (INTN) * 8)))

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
---
 SecurityPkg/SecurityPkg.dsc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc index 
43ac0b1..65a2fe3 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -215,6 +215,7 @@
   SecurityPkg/Library/FmpAuthenticationLibPkcs7/FmpAuthenticationLibPkcs7.inf
   
SecurityPkg/Library/FmpAuthenticationLibRsa2048Sha256/FmpAuthenticationLibRsa2048Sha256.inf
 
+[Components.IA32, Components.X64, Components.IPF, Components.ARM, 
+Components.AARCH64]
   SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
 
 [Components.IA32, Components.X64, Components.IPF]
--
2.8.0.windows.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] BaseTools: enhance error check for DatumType format

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Friday, February 02, 2018 4:24 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: enhance error check for DatumType format
>
>Add a check for DatumType format, eg: VOID *, original Tool will crash
>but no detail error message which cause confusion to user.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/Workspace/DecBuildData.py | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
>diff --git a/BaseTools/Source/Python/Workspace/DecBuildData.py
>b/BaseTools/Source/Python/Workspace/DecBuildData.py
>index 2fd3820..2266b0b 100644
>--- a/BaseTools/Source/Python/Workspace/DecBuildData.py
>+++ b/BaseTools/Source/Python/Workspace/DecBuildData.py
>@@ -1,9 +1,9 @@
> ## @file
> # This file is used to create a database used by build tool
> #
>-# Copyright (c) 2008 - 2017, Intel Corporation. All rights reserved.
>+# Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> # (C) Copyright 2016 Hewlett Packard Enterprise Development LP
> # 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
>@@ -421,10 +421,15 @@ class DecBuildData(PackageBuildClassObject):
> Setting,LineNo = PcdDict[self._Arch, PcdCName, TokenSpaceGuid]
> if Setting == None:
> continue
>
> DefaultValue, DatumType, TokenNumber = AnalyzePcdData(Setting)
>+if DatumType not in [TAB_UINT8, TAB_UINT16, TAB_UINT32,
>TAB_UINT64, TAB_VOID, "BOOLEAN"]:
>+StructPattern = re.compile(r'[_a-zA-Z][0-9A-Za-z_]*$')
>+if StructPattern.match(DatumType) == None:
>+EdkLogger.error('build', FORMAT_INVALID, "DatumType only
>support BOOLEAN, UINT8, UINT16, UINT32, UINT64, VOID* or a valid struct
>name.", File=self.MetaFile, Line=LineNo)
>+
> validateranges, validlists, expressions =
>self._RawData.GetValidExpression(TokenSpaceGuid, PcdCName)
> PcdObj = PcdClassObject(
> PcdCName,
> TokenSpaceGuid,
> self._PCD_TYPE_STRING_[Type],
>--
>2.6.1.windows.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

[edk2] [PATCH] MdeModulePkg/PiSmmCore: add API parameter check

[Jian J Wang]

The Heap Guard feature wrapped SmmInternalFreePagesEx with
SmmInternalFreePagesExWithGuard but didn't add necessary
parameter check. This patch fixes this situation.

Cc: Star Zeng 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/PiSmmCore/HeapGuard.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c 
b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
index 063a330b18..c5ffb26342 100644
--- a/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
+++ b/MdeModulePkg/Core/PiSmmCore/HeapGuard.c
@@ -1205,6 +1205,10 @@ SmmInternalFreePagesExWithGuard (
   EFI_PHYSICAL_ADDRESSMemoryToFree;
   UINTN   PagesToFree;
 
+  if (((Memory & EFI_PAGE_MASK) != 0) || (Memory == 0) || (NumberOfPages == 
0)) {
+return EFI_INVALID_PARAMETER;
+  }
+
   MemoryToFree  = Memory;
   PagesToFree   = NumberOfPages;
 
-- 
2.14.1.windows.1

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

Re: [edk2] [EDK2] How to use compiler intrinsic function, such as :mmintrin.h

[Andrew Fish]

Technically speaking the compiler generates the code for the intrinsics but the 
compiler specific include files generally don't just work as they are built to 
included in the context of that compilers C lib. 

I've had some luck using intrinsics from clang, but you have to:
1) Make your own version of the intrinsic header porting it to the edk2 type 
system, or use portable types.
  a) You also need to realized the intrinsics are compiler specific. Generally 
there is the VC++ and GCC flavors of intrinsics.
  b) The intrinsics can also be CPU architecture specific. 
2) You can override compiler flags at a driver or library level via the 
[BuildOptions]section: 
https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.inf
3) You need to realize the edk2 is not doing the setup for you. So you have to 
do the CPU ID checks, or turn on the modes required for some things to be 
valid. Don't cause exceptions as there is no code to handle it. Etc. 

Thanks,

Andrew Fish


> On Feb 5, 2018, at 8:57 PM, Tiger Liu(BJ-RD)  wrote:
> 
> Hi, Liming:
> Thanks for your reply.
> I tried to compile a UEFI shell application.
> And this app would call functions provided in mmintrin.h
> 
> So, I met this trouble.
> 
> Thanks
> 
> Best wishes,
> -邮件原件-
> 发件人: Gao, Liming [mailto:liming@intel.com ]
> 发送时间: 2018年2月6日 12:39
> 收件人: Tiger Liu(BJ-RD) >; 
> edk2-devel@lists.01.org 
> 主题: RE: [edk2] [EDK2] How to use compiler intrinsic function, such as 
> :mmintrin.h
> 
> Tiger:
>  Yes. EDK2 doesn't support the intrinsic function. Because edk2 compiled EFI 
> image run in target machine instead of OS, they can't link VS system 
> libraries.
> 
>  And, EDK2 doesn't support to specify the include path in BuildOptions. If 
> you want to use EDK2 build system to compile EXE file that run in OS, such as 
> SecMain, you can compile it with system header file and library. The system 
> header file include path is set in ENV include. If you type set include, you 
> will se its value.
> 
> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Tiger Liu(BJ-RD)
>> Sent: Monday, February 05, 2018 5:06 PM
>> To: edk2-devel@lists.01.org
>> Subject: Re: [edk2] [EDK2] How to use compiler intrinsic function, such
>> as :mmintrin.h
>> 
>> Hi, experts:
>> I have a question about how to direct compiler to search dedicated
>> include directory.
>> Such as:
>> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include
>> 
>> I tried to tell  compiler through “/I” parameter.
>> “/I C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include”
>> 
>> But failed.
>> 
>> Best wishes,
>> 发件人: Tiger Liu(BJ-RD)
>> 发送时间: 2018年2月2日 19:08
>> 收件人: edk2-devel@lists.01.org
>> 主题: [EDK2] How to use compiler intrinsic function, such as :mmintrin.h
>> 
>> Hi, experts:
>> I have a question about using compiler’s intrinsic function.
>> It seems EDKII’s compiler option doesn’t support using intrinsic function.
>> 
>> Such as:
>> mmintrin.h  MMX
>> xmmintrin.hSSE
>> emmintrin.h   SSE2
>> pmmintrin.h   SSE3
>> tmmintrin.hSSSE3
>> intrin.h SSE4A
>> smmintrin.h   SSE4.1
>> nmmintrin.h   SSE4.2
>> mm3dnow.h  3DNOW
>> 
>> Thanks
>> 
>> Best wishes,
>> 
>> 
>> 保密声明：
>> 本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其
>> 内容做任何未经授权的查阅、使用、复制或转发。
>> CONFIDENTIAL NOTE:
>> This email contains confidential or legally privileged information and
>> is for the sole use of its intended recipient. Any unauthorized review,
>> use, copying or forwarding of this email or the content of this email is 
>> strictly prohibited.
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> 
> 保密声明：
> 本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for 
> the sole use of its intended recipient. Any unauthorized review, use, copying 
> or forwarding of this email or the content of this email is strictly 
> prohibited.
> ___
> 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] [EDK2] How to use compiler intrinsic function, such as :mmintrin.h

[Tiger Liu(BJ-RD)]

Hi, Liming:
Thanks for your reply.
I tried to compile a UEFI shell application.
And this app would call functions provided in mmintrin.h

So, I met this trouble.

Thanks

Best wishes,
-邮件原件-
发件人: Gao, Liming [mailto:liming@intel.com]
发送时间: 2018年2月6日 12:39
收件人: Tiger Liu(BJ-RD) ; edk2-devel@lists.01.org
主题: RE: [edk2] [EDK2] How to use compiler intrinsic function, such as 
:mmintrin.h

Tiger:
  Yes. EDK2 doesn't support the intrinsic function. Because edk2 compiled EFI 
image run in target machine instead of OS, they can't link VS system libraries.

  And, EDK2 doesn't support to specify the include path in BuildOptions. If you 
want to use EDK2 build system to compile EXE file that run in OS, such as 
SecMain, you can compile it with system header file and library. The system 
header file include path is set in ENV include. If you type set include, you 
will se its value.

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Tiger Liu(BJ-RD)
>Sent: Monday, February 05, 2018 5:06 PM
>To: edk2-devel@lists.01.org
>Subject: Re: [edk2] [EDK2] How to use compiler intrinsic function, such
>as :mmintrin.h
>
>Hi, experts:
>I have a question about how to direct compiler to search dedicated
>include directory.
>Such as:
>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include
>
>I tried to tell  compiler through “/I” parameter.
>“/I C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include”
>
>But failed.
>
>Best wishes,
>发件人: Tiger Liu(BJ-RD)
>发送时间: 2018年2月2日 19:08
>收件人: edk2-devel@lists.01.org
>主题: [EDK2] How to use compiler intrinsic function, such as :mmintrin.h
>
>Hi, experts:
>I have a question about using compiler’s intrinsic function.
>It seems EDKII’s compiler option doesn’t support using intrinsic function.
>
>Such as:
>mmintrin.h  MMX
>xmmintrin.hSSE
>emmintrin.h   SSE2
>pmmintrin.h   SSE3
>tmmintrin.hSSSE3
>intrin.h SSE4A
>smmintrin.h   SSE4.1
>nmmintrin.h   SSE4.2
>mm3dnow.h  3DNOW
>
>Thanks
>
>Best wishes,
>
>
>保密声明：
>本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其
>内容做任何未经授权的查阅、使用、复制或转发。
>CONFIDENTIAL NOTE:
>This email contains confidential or legally privileged information and
>is for the sole use of its intended recipient. Any unauthorized review,
>use, copying or forwarding of this email or the content of this email is 
>strictly prohibited.
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel


保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [EDK2] How to use compiler intrinsic function, such as :mmintrin.h

[Gao, Liming]

Tiger:
  Yes. EDK2 doesn't support the intrinsic function. Because edk2 compiled EFI 
image run in target machine instead of OS, they can't link VS system libraries. 

  And, EDK2 doesn't support to specify the include path in BuildOptions. If you 
want to use EDK2 build system to compile EXE file that run in OS, such as 
SecMain, you can compile it with system header file and library. The system 
header file include path is set in ENV include. If you type set include, you 
will se its value. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Tiger Liu(BJ-RD)
>Sent: Monday, February 05, 2018 5:06 PM
>To: edk2-devel@lists.01.org
>Subject: Re: [edk2] [EDK2] How to use compiler intrinsic function, such
>as :mmintrin.h
>
>Hi, experts:
>I have a question about how to direct compiler to search dedicated include
>directory.
>Such as:
>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include
>
>I tried to tell  compiler through “/I” parameter.
>“/I C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include”
>
>But failed.
>
>Best wishes,
>发件人: Tiger Liu(BJ-RD)
>发送时间: 2018年2月2日 19:08
>收件人: edk2-devel@lists.01.org
>主题: [EDK2] How to use compiler intrinsic function, such as :mmintrin.h
>
>Hi, experts:
>I have a question about using compiler’s intrinsic function.
>It seems EDKII’s compiler option doesn’t support using intrinsic function.
>
>Such as:
>mmintrin.h  MMX
>xmmintrin.hSSE
>emmintrin.h   SSE2
>pmmintrin.h   SSE3
>tmmintrin.hSSSE3
>intrin.h SSE4A
>smmintrin.h   SSE4.1
>nmmintrin.h   SSE4.2
>mm3dnow.h  3DNOW
>
>Thanks
>
>Best wishes,
>
>
>保密声明：
>本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其
>内容做任何未经授权的查阅、使用、复制或转发。
>CONFIDENTIAL NOTE:
>This email contains confidential or legally privileged information and is for 
>the
>sole use of its intended recipient. Any unauthorized review, use, copying or
>forwarding of this email or the content of this email is strictly prohibited.
>___
>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] BaseTools: not specified value of MAX_CONCURRENT_THREAD_NUMBER

[Gao, Liming]

Yonghong:
  Please add the description for this behavior in target.template. 

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Monday, February 05, 2018 2:15 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch] BaseTools: not specified value of
>MAX_CONCURRENT_THREAD_NUMBER
>
>when MAX_CONCURRENT_THREAD_NUMBER is not specified, tool will
>automatically detect number of processor threads.
>
>Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=775
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Conf/target.template | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
>diff --git a/BaseTools/Conf/target.template
>b/BaseTools/Conf/target.template
>index 787fc64..d4b929d 100644
>--- a/BaseTools/Conf/target.template
>+++ b/BaseTools/Conf/target.template
>@@ -1,7 +1,7 @@
> #
>-#  Copyright (c) 2006 - 2011, Intel Corporation. All rights reserved.
>+#  Copyright (c) 2006 - 2018, 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
>@@ -57,14 +57,15 @@ TOOL_CHAIN_CONF   = Conf/tools_def.txt
> #  TAGNAME   List  Optional   Specify the name(s) of the 
> tools_def.txt
>TagName to use.
> # If not specified, all 
> applicable TagName tools will be
> # used for the build.  The list 
> uses space character
>separation.
> TOOL_CHAIN_TAG= MYTOOLS
>
>-# MAX_CONCURRENT_THREAD_NUMBER  NUMBER  Optional  The number
>of concurrent threads. Recommend to set this
>-# value to one more than the 
>number of your
>compurter
>-# cores or CPUs. Less than 2 
>means disable
>multithread build.
>-MAX_CONCURRENT_THREAD_NUMBER = 1
>+# MAX_CONCURRENT_THREAD_NUMBER  NUMBER  Optional  The number
>of concurrent threads. The default, if not
>+# specified or set to zero, 
>tool automatically detect
>number
>+# of processor threads. 
>Recommend to set this value
>to one
>+# more than the number of 
>your compurter cores or
>CPUs.
>+# MAX_CONCURRENT_THREAD_NUMBER = 1
>
>
> # BUILD_RULE_CONF  Filename Optional  Specify the file name to use for the
>build rules that are followed
> # when generating Makefiles. If not 
> specified, the file:
> # WORKSPACE/Conf/build_rule.txt will be 
> used
>--
>2.6.1.windows.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 edk2/MdePkg v1] MdePkg ACPI: Add some macros for PPTT

[Zeng, Star]

How about using EFI_ACPI_6_2_PPTT_PROCESSOR_ID_XXX to be more specific?

Others are good to me.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Friday, February 2, 2018 11:30 AM
To: leif.lindh...@linaro.org; linaro-u...@lists.linaro.org; 
edk2-devel@lists.01.org; graeme.greg...@linaro.org
Cc: huangmin...@huawei.com; ard.biesheu...@linaro.org; Gao, Liming 
; mengfanr...@huawei.com; guoh...@huawei.com; Heyi Guo 
; zhangjinso...@huawei.com; Kinney, Michael D 
; wai...@126.com; wanghuiqi...@huawei.com; 
huangda...@hisilicon.com
Subject: [edk2] [PATCH edk2/MdePkg v1] MdePkg ACPI: Add some macros for PPTT

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang 
Signed-off-by: Heyi Guo 
---
 MdePkg/Include/IndustryStandard/Acpi62.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h 
b/MdePkg/Include/IndustryStandard/Acpi62.h
index 2904d34..30faba9 100644
--- a/MdePkg/Include/IndustryStandard/Acpi62.h
+++ b/MdePkg/Include/IndustryStandard/Acpi62.h
@@ -2557,6 +2557,12 @@ typedef struct {
 } EFI_ACPI_6_2_PPTT_STRUCTURE_HEADER;
 
 ///
+/// Value for valid fields in PPTT struct
+///
+#define EFI_ACPI_6_2_PPTT_INVALID0x0
+#define EFI_ACPI_6_2_PPTT_VALID  0x1
+
+///
 /// Processor hierarchy node structure flags
 ///
 typedef struct {
@@ -2593,6 +2599,18 @@ typedef struct {
 } EFI_ACPI_6_2_PPTT_STRUCTURE_CACHE_FLAGS;
 
 ///
+/// For cache attributes
+///
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_WRITE   0x1
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ_WRITE  0x2
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_DATA0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_INSTRUCTION 0x1
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_UNIFIED 0x2
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK0x0
+#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_THROUGH 0x1
+
+///
 /// Cache Type Structure cache attributes
 ///
 typedef struct {
-- 
1.9.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 edk2/MdePkg v1] MdePkg ACPI: Add some macros for PPTT

[Huangming (Mark)]

Any comments for this patch?

On 2018/2/2 11:30, Heyi Guo wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> Signed-off-by: Heyi Guo 
> ---
>  MdePkg/Include/IndustryStandard/Acpi62.h | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h 
> b/MdePkg/Include/IndustryStandard/Acpi62.h
> index 2904d34..30faba9 100644
> --- a/MdePkg/Include/IndustryStandard/Acpi62.h
> +++ b/MdePkg/Include/IndustryStandard/Acpi62.h
> @@ -2557,6 +2557,12 @@ typedef struct {
>  } EFI_ACPI_6_2_PPTT_STRUCTURE_HEADER;
>  
>  ///
> +/// Value for valid fields in PPTT struct
> +///
> +#define EFI_ACPI_6_2_PPTT_INVALID0x0
> +#define EFI_ACPI_6_2_PPTT_VALID  0x1
> +
> +///
>  /// Processor hierarchy node structure flags
>  ///
>  typedef struct {
> @@ -2593,6 +2599,18 @@ typedef struct {
>  } EFI_ACPI_6_2_PPTT_STRUCTURE_CACHE_FLAGS;
>  
>  ///
> +/// For cache attributes
> +///
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_WRITE   0x1
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_ALLOCATION_READ_WRITE  0x2
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_DATA0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_INSTRUCTION 0x1
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_CACHE_TYPE_UNIFIED 0x2
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK0x0
> +#define EFI_ACPI_6_2_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_THROUGH 0x1
> +
> +///
>  /// Cache Type Structure cache attributes
>  ///
>  typedef struct {
> 

-- 
Best Regards,

Ming

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

Re: [edk2] [PATCH] SecurityPkg: Support PP version lower than 1.3

[Zhang, Chao B]

Qin & Jiewen
 Tks for your comments , I will follow up to update the patch.

-Original Message-
From: Yao, Jiewen 
Sent: Tuesday, February 6, 2018 10:33 AM
To: Long, Qin ; Zhang, Chao B ; 
edk2-devel@lists.01.org
Subject: RE: [PATCH] SecurityPkg: Support PP version lower than 1.3

Yeah. I suggest we just use sizeof() for the fixed string.


> -Original Message-
> From: Long, Qin
> Sent: Tuesday, February 6, 2018 10:30 AM
> To: Zhang, Chao B ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: RE: [PATCH] SecurityPkg: Support PP version lower than 1.3
> 
> Could you update the AsciiStrLen usage with safe version, or direct 
> "sizeof()"?
> Others looks good to me.
> 
> Reviewed-by: Long Qin 
> 
> 
> Best Regards & Thanks,
> LONG, Qin
> 
> -Original Message-
> From: Zhang, Chao B
> Sent: Monday, February 5, 2018 10:32 AM
> To: edk2-devel@lists.01.org
> Cc: Long, Qin ; Yao, Jiewen 
> ; Zhang, Chao B 
> Subject: [PATCH] SecurityPkg: Support PP version lower than 1.3
> 
> TCG PP 1.2 & PP 1.3 spec defined different Opcodes.
> Update code to support both.
> 
> Cc: Long Qin 
> Cc: Yao Jiewen 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chao Zhang 
> ---
>  .../SmmTcg2PhysicalPresenceLib.c   | 31
> +-
>  .../SmmTcg2PhysicalPresenceLib.inf |  7 +++--
>  2 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git
> a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresen
> ce
> Lib.c
> b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresen
> ce
> Lib.c
> index 6061453..ffade10 100644
> ---
> a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresen
> ce
> Lib.c
> +++ b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPr
> +++ es
> +++ enceLib.c
> @@ -10,7 +10,7 @@
>Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction() and
> Tcg2PhysicalPresenceLibGetUserConfirmationStatusFunction()
>will receive untrusted input and do validation.
> 
> -Copyright (c) 2015 - 2017, Intel Corporation. All rights 
> reserved.
> +Copyright (c) 2015 - 2018, 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 @@
> -27,12 +27,16 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, 
> EITHER EXPRESS OR IMPLIED.
> 
>  #include 
> 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> 
> +#define PP_INF_VERSION_1_2"1.2"
> +
>  EFI_SMM_VARIABLE_PROTOCOL  *mTcg2PpSmmVariable;
> +BOOLEANmIsTcg2PPVerLowerThan_1_3 = FALSE;
> 
>  /**
>The handler for TPM physical presence function:
> @@ -337,11 +341,22 @@
> Tcg2PhysicalPresenceLibGetUserConfirmationStatusFunction (
>break;
> 
>  default:
> -  if (OperationRequest <
> TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) {
> -//
> -// TCG PP spec defined operations that are reserved or
> un-implemented
> -//
> -return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
> +  if (mIsTcg2PPVerLowerThan_1_3 == FALSE) {
> +if (OperationRequest <
> TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) {
> +  //
> +  // TCG2 PP1.3 spec defined operations that are reserved or
> un-implemented
> +  //
> +  return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
> +}
> +  } else {
> +   //
> +   // TCG PP lower than 1.3. (1.0, 1.1, 1.2)
> +   //
> +   if (OperationRequest <=
> TCG2_PHYSICAL_PRESENCE_NO_ACTION_MAX) {
> + RequestConfirmed = TRUE;
> +   } else if (OperationRequest <
> TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) {
> + return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
> +   }
>}
>break;
>}
> @@ -377,6 +392,10 @@ Tcg2PhysicalPresenceLibConstructor (  {
>EFI_STATUS  Status;
> 
> +  if (AsciiStrnCmp(PP_INF_VERSION_1_2, (CHAR8
> *)PcdGetPtr(PcdTcgPhysicalPresenceInterfaceVer),
> AsciiStrLen(PP_INF_VERSION_1_2)) <=0) {
> +mIsTcg2PPVerLowerThan_1_3 = TRUE;  }
> +
>//
>// Locate SmmVariableProtocol.
>//
> diff --git
> a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresen
> ce
> Lib.inf
> b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresen
> ce
> Lib.inf
> index 5fa84b1..8367097 100644
> ---
> a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresen
> ce
> Lib.inf
> +++ b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPr
> +++ es
> +++ enceLib.inf
> @@ -7,7 +7,7 @@
>  #  This driver will have external 

Re: [edk2] [PATCH v2] BaseTools/Conf: disable DTC legacy phandle format

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>Sent: Monday, February 05, 2018 9:59 PM
>To: Laszlo Ersek 
>Cc: edk2-devel@lists.01.org; Gao, Liming ; Zhu,
>Yonghong 
>Subject: Re: [PATCH v2] BaseTools/Conf: disable DTC legacy phandle format
>
>On 1 February 2018 at 16:53, Laszlo Ersek  wrote:
>> On 02/01/18 12:15, Ard Biesheuvel wrote:
>>> By default, the device tree compiler emits phandle properties twice:
>>> one called 'phandle' and another called 'linux,phandle'. Given that
>>> Linux was updated in early 2010 [0] to accept the former (which is
>>> what is specified in the ePAPR and device tree specifications), there
>>> is no point in emitting both when compiling device trees for UEFI
>>> platforms.
>>>
>>> [0] 04b954a673dd02f585a2769c4945a43880faa989
>>> "of/flattree: Make the kernel accept ePAPR style phandle information"
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>>  BaseTools/Conf/build_rule.template | 2 +-
>>>  BaseTools/Conf/tools_def.template  | 1 +
>>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/BaseTools/Conf/build_rule.template
>b/BaseTools/Conf/build_rule.template
>>> index 3e6aa8ff0f34..a5e471eb3c10 100755
>>> --- a/BaseTools/Conf/build_rule.template
>>> +++ b/BaseTools/Conf/build_rule.template
>>> @@ -250,7 +250,7 @@
>>>
>>>  
>>>  "$(PP)" $(DTCPP_FLAGS) $(INC) ${src} > ${d_path}(+)${s_base}.i
>>> -"$(DTC)" -I dts -O dtb -o ${dst} ${d_path}(+)${s_base}.i
>>> +"$(DTC)" $(DTC_FLAGS) -I dts -O dtb -o ${dst} 
>>> ${d_path}(+)${s_base}.i
>>>
>>>  [Visual-Form-Representation-File]
>>>  
>>> diff --git a/BaseTools/Conf/tools_def.template
>b/BaseTools/Conf/tools_def.template
>>> index 482ef263c274..99ad271471d9 100755
>>> --- a/BaseTools/Conf/tools_def.template
>>> +++ b/BaseTools/Conf/tools_def.template
>>> @@ -4467,6 +4467,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS=
>/NOLOGO /NODEFAULTLIB /LTCG /DLL /OPT:REF
>>>  DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = --add-gnu-
>debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
>>>  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
>>>  NOOPT_*_*_OBJCOPY_ADDDEBUGFLAG = --add-gnu-
>debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
>>> +*_*_*_DTC_FLAGS= -H epapr
>>>
>>>  DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-builtin 
>>> -fno-
>strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h -fno-
>common
>>>  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 -
>malign-double -freorder-blocks -freorder-blocks-and-partition -O2 -mno-
>stack-arg-probe
>>>
>>
>> Reviewed-by: Laszlo Ersek 
>
>Thank you.
>
>Liming, any comments?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: fix infinite loop issue in SMM profile

[Jian J Wang]

The infinite loop is caused by the memory instruction, such as
"rep mov", operating on memory block crossing boundary of NON-PRESENT
pages. Because the address triggering page fault set in CR2 will be in
the first page, SmmProfilePFHandler() will only change the first page
into PRESENT. The page following will be still in NON-PRESENT status.

Since SmmProfilePFHandler() will setup single-step trap for the
instruction causing #PF, when the handler returns back to the
instruction and re-execute it, both #DB and #PF will be triggered
because the instruction wants to access both first and second page
but only first page is PRESENT.

Normally #DB exception will be handled first and its handler will
change first page back to NON-PRESENT status. Then #PF is handled
and its handler will change first page to PRESENT status again and
setup another single-step for the instruction triggering #PF. Then
the whole system falls into an infinite loop and the memory operation
will never move on.

This patch fix above situation by always changing 3 pages to PRESENT
status instead of just 1 page. Those 3 pages include the page before
and after the page causing #PF because memory operation instruction
may have direction flag (DF) set or cleared.

Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Ruiyu Ni 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index 9588eaf029..8cdfc82a92 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -1302,6 +1302,8 @@ SmmProfilePFHandler (
 {
   UINT64*PageTable;
   UINT64PFAddress;
+  UINT64RestoreAddress;
+  UINTN RestorePageNumber;
   UINTN CpuIndex;
   UINTN Index;
   UINT64InstructionAddress;
@@ -1331,10 +1333,22 @@ SmmProfilePFHandler (
   PFAddress = AsmReadCr2 ();
   CpuIndex  = GetCpuIndex ();
 
-  if (PFAddress <= 0x) {
-RestorePageTableBelow4G (PageTable, PFAddress, CpuIndex, ErrorCode);
-  } else {
-RestorePageTableAbove4G (PageTable, PFAddress, CpuIndex, ErrorCode, 
);
+  //
+  // Memory operation cross pages, like "rep mov" instruction, will cause
+  // infinite loop between this and Debug Trap handler. Since the direction
+  // of memory operation is unknown, the pages before and after current page
+  // should be taken into account as well.
+  //
+  RestorePageNumber = 3;
+  RestoreAddress = PFAddress - EFI_PAGE_SIZE;
+  while (RestorePageNumber > 0) {
+if (RestoreAddress <= 0x) {
+  RestorePageTableBelow4G (PageTable, RestoreAddress, CpuIndex, ErrorCode);
+} else {
+  RestorePageTableAbove4G (PageTable, RestoreAddress, CpuIndex, ErrorCode, 
);
+}
+RestoreAddress += EFI_PAGE_SIZE;
+RestorePageNumber--;
   }
 
   if (!IsValidPFAddress) {
-- 
2.14.1.windows.1

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

Re: [edk2] [PATCH 04/10] MdeModulePkg/ResetSystemRuntimeDxe: Add platform filter and handler

[Ni, Ruiyu]

On 2/2/2018 9:46 PM, Laszlo Ersek wrote:

On 02/02/18 07:45, Ruiyu Ni wrote:

From: Michael D Kinney 

Add support for platform specific reset filters and platform
specific reset handlers to ResetSystem().  A filter may modify
the reset type and reset data and call ResetSystem() with the
modified parameters.  A handler performs the reset action.

The support for platform specific filters and platform specific
handlers is based on the Reset Notification feature added to the
UEFI 2.7 Specification.

Platform specific reset filters are processed first so the final
reset type and reset data can be determined.  In the DXE Phase
The UEFI Reset Notifications are processed second so all UEFI
Drivers that have registered for a Reset Notification can perform
any required clean up actions.  The platform specific reset
handlers are processed third.  If there are no registered
platform specific reset handlers or none of them reset the
platform, then the default reset action based on the
ResetSystemLib is performed.

In the PEI Phase, filters are handlers are registered through
the folloiwng 2 PPIs that are based on
EFI_RESET_NOTIFICATION_PROTOCOL.
* gEdkiiPlatformSpecificResetFilterPpiGuid
* gEdkiiPlatformSpecificResetFilterPpiGuid


The second entry should be "gEdkiiPlatformSpecificResetHandlerPpiGuid".



In the DXE Phase, filters are handlers are registered through
the folloiwng 2 Protocols that are based on
EFI_RESET_NOTIFICATION_PROTOCOL.
* gEdkiiPlatformSpecificResetFilterProtocolGuid
* gEdkiiPlatformSpecificResetFilterProtocolGuid


The second entry should be "gEdkiiPlatformSpecificResetHandlerProtocolGuid".

[...]

Thanks
Laszlo



Thanks. I will change the commit message when checking in.

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

Re: [edk2] Why does EDK2 disable time checks on certificates?

[Long, Qin]

The OS can update the certificates by correct SetVariable() call with 
authenticated payload (following UEFI secure boot / authenticated variable 
definitions. Refer to the section 8.2  "Variable Services" and chapter 31 
"Secure Boot and Driver Signing" for more details). 
I am not sure if current OS will enforce any periodical update. Currently, UEFI 
is just distributing the revocation list file to address possible security 
risks (http://www.uefi.org/revocationlistfile). 


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bryan 
Rosario
Sent: Tuesday, February 6, 2018 10:17 AM
To: Zhang, Chao B 
Cc: edk2-devel@lists.01.org; Alain Gefflaut ; Long, Qin 

Subject: Re: [edk2] Why does EDK2 disable time checks on certificates?

Thanks for the info.

Another question: if I enable time checks in my local copy of EDK2 (or if there 
is another UEFI implementation with time checks enabled), do operating systems 
generally update their certificates periodically to avoid them expiring?
In particular, I'm wondering about bootloaders that are signed for secure boot. 
I've seen expiration times on the attached certificates and I'm wondering if 
the bootloader will be periodically updated, or if operating systems will just 
expect that the firmware doesn't actually enforce the expiration time.

On Mon, Feb 5, 2018 at 5:45 PM, Zhang, Chao B 
wrote:

> Bryan:
>You can reference EFI_CERT_X509_SHA256,  EFI_CERT_X509_SHA384,
> EFI_CERT_X509_SHA512 data structure definition in UEFI spec.
>   Now they are only supported in DBX.  Revocation time here is defined 
> by user instead of directly from Validity of X059 Certificate in order 
> to address the issue mentioned below.
>
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Long, Qin
> Sent: Tuesday, February 6, 2018 8:55 AM
> To: Bryan Rosario ; edk2-devel@lists.01.org
> Subject: Re: [edk2] Why does EDK2 disable time checks on certificates?
>
> It's EDK2-only.
> The current pre-boot environment have no trusted timer synchronization 
> service. And it's very likely the system time is not the real-time 
> (esp under dev environment). So the certificate time expiration 
> checking was bypassed to avoid any boot break.
>
> Against the corresponding certificate revocation case, the UEFI 
> introduced the DBX database (forbidden list) to address this.
>
>
> Best Regards & Thanks,
> LONG, Qin
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Bryan Rosario
> Sent: Tuesday, February 6, 2018 5:52 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Why does EDK2 disable time checks on certificates?
>
> See here ("Currently certificate time expiration checking is ignored."):
> https://github.com/tianocore/tianocore.github.io/wiki/How-
> to-Enable-Security
> .
>
> Is this behavior part of the UEFI specification or is it EDK2-only? 
> And what's the reasoning for it?
>
> Thanks,
> Bryan
> ___
> 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
>
___
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] BaseTools: Fix flexible PCD DEVICE_PATH parse issue

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Feng, YunhuaX 
Sent: Tuesday, February 06, 2018 10:20 AM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong ; Gao, Liming 
Subject: [PATCH] BaseTools: Fix flexible PCD DEVICE_PATH parse issue

When the format of DEVICE_PATH have string, like as:
{DEVICE_PATH("BBS(1,"AB",0)")} have string "AB", will get the wrong value.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/Common/Misc.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index b34cb4c3be..08523e4669 100644
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -1597,11 +1597,12 @@ def ParseFieldValue (Value):
 RetSize += Size
 for I in range(Size):
 Value = (Value << 8) | ((ItemValue >> 8 * I) & 0xff)
 return Value, RetSize
 if Value.startswith('DEVICE_PATH(') and Value.endswith(')'):
-Value = Value.split('"')[1]
+Value = Value.replace("DEVICE_PATH(", '').rstrip(')')
+Value = Value.strip().strip('"')
 return ParseDevPathValue(Value)
 if Value.lower().startswith('0x'):
 Value = int(Value, 16)
 if Value == 0:
 return 0, 1
--
2.12.2.windows.2

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

Re: [edk2] setting the TLS cipher list for HTTPS booting

[Wu, Jiaxin]

Leaving the variable up to the platform setting is good to me. 

Mike,

If you have no comments, we will follow the variable solution. 

Thanks,
Jiaxin

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, February 5, 2018 6:47 PM
> To: Wu, Jiaxin ; Kinney, Michael D
> ; Fu, Siyuan ; Ye, Ting
> ; Li, Ruth ; Long, Qin
> ; Yao, Jiewen ; Hsiung, Harry L
> 
> Cc: edk2-devel-01 
> Subject: Re: setting the TLS cipher list for HTTPS booting
> 
> On 02/05/18 04:33, Wu, Jiaxin wrote:
> > Hi Laszlo,
> >
> > In recent days, we received the comment from Kinney about the PCD
> > usage in UEFI driver.  Kinney doesn't recommend us to use the *dynamic
> > PCD* in *soft-loading* UEFI driver even though it's not prohibited.
> >
> > So, we want to confirm with you whether this is the urgent request
> > need us to support it ASAP or it's in low priority.
> >
> > If you need us support the feature ASAP, we can use the  private
> > variable solution as we discussed before since there is no security
> > issue and the size requirement is not big.
> >
> > If not urgency, we might consider whether need to define a platform to
> > driver configuration protocol or not. You know it will take a long
> > time to scandalize one protocol for platform HTTPS configuration in
> > the future UEFI spec.
> 
> The variable approach sounds good to me, but with a small twist:
> 
> Could we please leave it up to the platform whether the private variable
> is non-volatile versus volatile? Because platform X might want to
> configure the cipher suite list once, permanently, while platform Y
> might want to configure the cipher suite list dynamically on each boot.
> For platform Y, spending any flash space (and flash writing time) on the
> variable is superfluous.
> 
> For QEMU / OVMF specifically, I would prefer a volatile, boot-time only
> variable. After setting this variable, I think OVMF platform code should
> even lock it down with the edk2 variable lock protocol. In effect this
> would behave like a "read only" PCD -- no flash impact at all.
> 
> As long as HttpDxe only calls gRT->GetVariable() (or equivalent wrappers
> from UefiLib) on the new variable, the variable's attributes should not
> matter; they can be left to the platform.
> 
> Thanks!
> Laszlo
> 
> 
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Thursday, January 25, 2018 8:42 PM
> >> To: Wu, Jiaxin ; Fu, Siyuan ;
> Ye,
> >> Ting ; Long, Qin ; Yao, Jiewen
> >> ; Hsiung, Harry L 
> >> Cc: edk2-devel-01 
> >> Subject: Re: setting the TLS cipher list for HTTPS booting
> >>
> >> On 01/25/18 05:52, Wu, Jiaxin wrote:
> >>> Hi Laszlo,
> >>>
> >>> The HttpDxe driver needs to install the Driver Binding Protocol so as
> >>> to check if a specific controller is supported by HttpDxe. HttpDxe
> >>> can only be started if the TcpServiceBindingProtocol existed. So, it
> >>> has to follow the UEFI Driver Model.
> >>>
> >>> For the PCD usage, I think it should be fine to cover the
> >>> configuration of UEFI Drivers through the PCD settings. The
> >>> requirement of *.inf needs to include the PcdLib and the section of
> >>> [Pcd]. We already have the similar pattern for this usage, for
> >>> example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in
> >>> MdeModulePkg. Besides, there are some advantages by using PCD
> >>> compared to the variable. First, PCD is one kind of interface that
> >>> more formal than a private variable, the setting by PCD is more
> >>> acceptable by the consumer. Secondly, from a *security* standpoint,
> >>> variable can be dumped easily from the flash region. Here, even
> >>> though it's no security impact towards the cipher list storage
> >>> because it will be public shared to remote server, but we need to
> >>> think and *align* with other configurations for TLS in HTTPS level.
> >>> For example, in the future, we might support the HTTPS mutual
> >>> authentication, than the host PrivateKey/Password
> >>> (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable
> >>> due to its confidentiality, while PCD is good choice. At that time,
> >>> we will also provide the PCD for EfiTlsConfigDataTypeCACertificate,
> >>> which is currently setting by the variable (TlsCaCertificate), so as
> >>> to align all the configuration setting on one line, which can reduce
> >>> the complexity of platform usage. Finally, we can also save the
> >>> variable space.
> >>>
> >>> From the above, the dynamic PCD is a solution I still preferred.
> >>
> >> OK, it works for me. Thanks!
> >> Laszlo

___

Re: [edk2] [PATCH] IntelSiliconPkg PlatformVTdSampleDxe: State it is only for dev/debug

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, February 6, 2018 10:14 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen ;
> Kinney, Michael D 
> Subject: [PATCH] IntelSiliconPkg PlatformVTdSampleDxe: State it is only for
> dev/debug
> 
> Cc: Jiewen Yao 
> Cc: Michael Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  .../Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c  |
> 5 -
>  .../Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf|
> 5 -
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git
> a/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c
> b/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.
> c
> index e522db069a43..3b141d978fdc 100644
> ---
> a/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c
> +++
> b/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.
> c
> @@ -1,7 +1,10 @@
>  /** @file
>Platform VTd Sample driver.
> 
> -  Copyright (c) 2017, Intel Corporation. All rights reserved.
> +  Note: This module should only be used for dev/debug purposes.
> +It MUST never be used for production builds.
> +
> +  Copyright (c) 2017 - 2018, 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
> diff --git
> a/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.i
> nf
> b/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.i
> nf
> index 9895bc201174..0200b932d829 100644
> ---
> a/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.i
> nf
> +++
> b/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.i
> nf
> @@ -1,7 +1,10 @@
>  ## @file
>  # Platform VTd Sample driver.
>  #
> -# Copyright (c) 2017, Intel Corporation. All rights reserved.
> +# Note: This module should only be used for dev/debug purposes.
> +#   It MUST never be used for production builds.
> +#
> +# Copyright (c) 2017 - 2018, 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
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH] SecurityPkg: Support PP version lower than 1.3

[Yao, Jiewen]

Yeah. I suggest we just use sizeof() for the fixed string.


> -Original Message-
> From: Long, Qin
> Sent: Tuesday, February 6, 2018 10:30 AM
> To: Zhang, Chao B ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: RE: [PATCH] SecurityPkg: Support PP version lower than 1.3
> 
> Could you update the AsciiStrLen usage with safe version, or direct 
> "sizeof()"?
> Others looks good to me.
> 
> Reviewed-by: Long Qin 
> 
> 
> Best Regards & Thanks,
> LONG, Qin
> 
> -Original Message-
> From: Zhang, Chao B
> Sent: Monday, February 5, 2018 10:32 AM
> To: edk2-devel@lists.01.org
> Cc: Long, Qin ; Yao, Jiewen ;
> Zhang, Chao B 
> Subject: [PATCH] SecurityPkg: Support PP version lower than 1.3
> 
> TCG PP 1.2 & PP 1.3 spec defined different Opcodes.
> Update code to support both.
> 
> Cc: Long Qin 
> Cc: Yao Jiewen 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chao Zhang 
> ---
>  .../SmmTcg2PhysicalPresenceLib.c   | 31
> +-
>  .../SmmTcg2PhysicalPresenceLib.inf |  7 +++--
>  2 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git
> a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresence
> Lib.c
> b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresence
> Lib.c
> index 6061453..ffade10 100644
> ---
> a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresence
> Lib.c
> +++ b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPres
> +++ enceLib.c
> @@ -10,7 +10,7 @@
>Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction() and
> Tcg2PhysicalPresenceLibGetUserConfirmationStatusFunction()
>will receive untrusted input and do validation.
> 
> -Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2015 - 2018, 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 
> @@
> -27,12 +27,16 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> 
>  #include 
> 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> 
> +#define PP_INF_VERSION_1_2"1.2"
> +
>  EFI_SMM_VARIABLE_PROTOCOL  *mTcg2PpSmmVariable;
> +BOOLEANmIsTcg2PPVerLowerThan_1_3 = FALSE;
> 
>  /**
>The handler for TPM physical presence function:
> @@ -337,11 +341,22 @@
> Tcg2PhysicalPresenceLibGetUserConfirmationStatusFunction (
>break;
> 
>  default:
> -  if (OperationRequest <
> TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) {
> -//
> -// TCG PP spec defined operations that are reserved or
> un-implemented
> -//
> -return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
> +  if (mIsTcg2PPVerLowerThan_1_3 == FALSE) {
> +if (OperationRequest <
> TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) {
> +  //
> +  // TCG2 PP1.3 spec defined operations that are reserved or
> un-implemented
> +  //
> +  return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
> +}
> +  } else {
> +   //
> +   // TCG PP lower than 1.3. (1.0, 1.1, 1.2)
> +   //
> +   if (OperationRequest <=
> TCG2_PHYSICAL_PRESENCE_NO_ACTION_MAX) {
> + RequestConfirmed = TRUE;
> +   } else if (OperationRequest <
> TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) {
> + return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
> +   }
>}
>break;
>}
> @@ -377,6 +392,10 @@ Tcg2PhysicalPresenceLibConstructor (  {
>EFI_STATUS  Status;
> 
> +  if (AsciiStrnCmp(PP_INF_VERSION_1_2, (CHAR8
> *)PcdGetPtr(PcdTcgPhysicalPresenceInterfaceVer),
> AsciiStrLen(PP_INF_VERSION_1_2)) <=0) {
> +mIsTcg2PPVerLowerThan_1_3 = TRUE;
> +  }
> +
>//
>// Locate SmmVariableProtocol.
>//
> diff --git
> a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresence
> Lib.inf
> b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresence
> Lib.inf
> index 5fa84b1..8367097 100644
> ---
> a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresence
> Lib.inf
> +++ b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPres
> +++ enceLib.inf
> @@ -7,7 +7,7 @@
>  #  This driver will have external input - variable.
>  #  This external input must be validated carefully to avoid security issue.
>  #
> -# Copyright (c) 2015, Intel Corporation. All rights reserved.
> +# Copyright (c) 2015 - 2018, Intel Corporation. All rights
> +reserved.
>  # This program and the accompanying materials  # are licensed and made
> available under the terms and conditions of the BSD 

Re: [edk2] [PATCH] SecurityPkg: Support PP version lower than 1.3

[Long, Qin]

Could you update the AsciiStrLen usage with safe version, or direct "sizeof()"? 
Others looks good to me.

Reviewed-by: Long Qin 


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: Zhang, Chao B 
Sent: Monday, February 5, 2018 10:32 AM
To: edk2-devel@lists.01.org
Cc: Long, Qin ; Yao, Jiewen ; Zhang, 
Chao B 
Subject: [PATCH] SecurityPkg: Support PP version lower than 1.3

TCG PP 1.2 & PP 1.3 spec defined different Opcodes.
Update code to support both.

Cc: Long Qin 
Cc: Yao Jiewen 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chao Zhang 
---
 .../SmmTcg2PhysicalPresenceLib.c   | 31 +-
 .../SmmTcg2PhysicalPresenceLib.inf |  7 +++--
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git 
a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c 
b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c
index 6061453..ffade10 100644
--- 
a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.c
+++ b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPres
+++ enceLib.c
@@ -10,7 +10,7 @@
   Tcg2PhysicalPresenceLibSubmitRequestToPreOSFunction() and 
Tcg2PhysicalPresenceLibGetUserConfirmationStatusFunction()
   will receive untrusted input and do validation.
 
-Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, 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 @@ -27,12 +27,16 @@ 
WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+#define PP_INF_VERSION_1_2"1.2"
+
 EFI_SMM_VARIABLE_PROTOCOL  *mTcg2PpSmmVariable;
+BOOLEANmIsTcg2PPVerLowerThan_1_3 = FALSE;
 
 /**
   The handler for TPM physical presence function:
@@ -337,11 +341,22 @@ Tcg2PhysicalPresenceLibGetUserConfirmationStatusFunction (
   break;
 
 default:
-  if (OperationRequest < TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) 
{
-//
-// TCG PP spec defined operations that are reserved or un-implemented
-//
-return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
+  if (mIsTcg2PPVerLowerThan_1_3 == FALSE) {
+if (OperationRequest < 
TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) {
+  //
+  // TCG2 PP1.3 spec defined operations that are reserved or 
un-implemented
+  //
+  return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
+}
+  } else {
+   //
+   // TCG PP lower than 1.3. (1.0, 1.1, 1.2)
+   //
+   if (OperationRequest <= TCG2_PHYSICAL_PRESENCE_NO_ACTION_MAX) {
+ RequestConfirmed = TRUE;
+   } else if (OperationRequest < 
TCG2_PHYSICAL_PRESENCE_VENDOR_SPECIFIC_OPERATION) {
+ return TCG_PP_GET_USER_CONFIRMATION_NOT_IMPLEMENTED;
+   }
   }
   break;
   }
@@ -377,6 +392,10 @@ Tcg2PhysicalPresenceLibConstructor (  {
   EFI_STATUS  Status;
 
+  if (AsciiStrnCmp(PP_INF_VERSION_1_2, (CHAR8 
*)PcdGetPtr(PcdTcgPhysicalPresenceInterfaceVer), 
AsciiStrLen(PP_INF_VERSION_1_2)) <=0) {
+mIsTcg2PPVerLowerThan_1_3 = TRUE;
+  }
+
   //
   // Locate SmmVariableProtocol.
   //
diff --git 
a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.inf 
b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.inf
index 5fa84b1..8367097 100644
--- 
a/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPresenceLib.inf
+++ b/SecurityPkg/Library/SmmTcg2PhysicalPresenceLib/SmmTcg2PhysicalPres
+++ enceLib.inf
@@ -7,7 +7,7 @@
 #  This driver will have external input - variable.
 #  This external input must be validated carefully to avoid security issue.
 #
-# Copyright (c) 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2015 - 2018, 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 @@ 
-52,6 +52,9 @@
   ## SOMETIMES_CONSUMES ## Variable:L"PhysicalPresence"
   ## SOMETIMES_CONSUMES ## Variable:L"PhysicalPresenceFlags"
   gEfiTcg2PhysicalPresenceGuid
-  
+
+[Pcd]
+  gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer  ## 
+CONSUMES
+
 [Depex]
   gEfiSmmVariableProtocolGuid
\ No newline at end of file
--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org

[edk2] [PATCH] BaseTools: Fix flexible PCD DEVICE_PATH parse issue

[Feng, YunhuaX]

When the format of DEVICE_PATH have string, like as:
{DEVICE_PATH("BBS(1,"AB",0)")} have string "AB", will
get the wrong value.

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/Common/Misc.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index b34cb4c3be..08523e4669 100644
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -1597,11 +1597,12 @@ def ParseFieldValue (Value):
 RetSize += Size
 for I in range(Size):
 Value = (Value << 8) | ((ItemValue >> 8 * I) & 0xff)
 return Value, RetSize
 if Value.startswith('DEVICE_PATH(') and Value.endswith(')'):
-Value = Value.split('"')[1]
+Value = Value.replace("DEVICE_PATH(", '').rstrip(')')
+Value = Value.strip().strip('"')
 return ParseDevPathValue(Value)
 if Value.lower().startswith('0x'):
 Value = int(Value, 16)
 if Value == 0:
 return 0, 1
-- 
2.12.2.windows.2

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

Re: [edk2] Why does EDK2 disable time checks on certificates?

[Bryan Rosario]

Thanks for the info.

Another question: if I enable time checks in my local copy of EDK2 (or if
there is another UEFI implementation with time checks enabled), do
operating systems generally update their certificates periodically to avoid
them expiring?
In particular, I'm wondering about bootloaders that are signed for secure
boot. I've seen expiration times on the attached certificates and I'm
wondering if the bootloader will be periodically updated, or if operating
systems will just expect that the firmware doesn't actually enforce the
expiration time.

On Mon, Feb 5, 2018 at 5:45 PM, Zhang, Chao B 
wrote:

> Bryan:
>You can reference EFI_CERT_X509_SHA256,  EFI_CERT_X509_SHA384,
> EFI_CERT_X509_SHA512 data structure definition in UEFI spec.
>   Now they are only supported in DBX.  Revocation time here is defined by
> user instead of directly from Validity of X059 Certificate in order to
> address the issue mentioned below.
>
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Long, Qin
> Sent: Tuesday, February 6, 2018 8:55 AM
> To: Bryan Rosario ; edk2-devel@lists.01.org
> Subject: Re: [edk2] Why does EDK2 disable time checks on certificates?
>
> It's EDK2-only.
> The current pre-boot environment have no trusted timer synchronization
> service. And it's very likely the system time is not the real-time (esp
> under dev environment). So the certificate time expiration checking was
> bypassed to avoid any boot break.
>
> Against the corresponding certificate revocation case, the UEFI introduced
> the DBX database (forbidden list) to address this.
>
>
> Best Regards & Thanks,
> LONG, Qin
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Bryan Rosario
> Sent: Tuesday, February 6, 2018 5:52 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Why does EDK2 disable time checks on certificates?
>
> See here ("Currently certificate time expiration checking is ignored."):
> https://github.com/tianocore/tianocore.github.io/wiki/How-
> to-Enable-Security
> .
>
> Is this behavior part of the UEFI specification or is it EDK2-only? And
> what's the reasoning for it?
>
> Thanks,
> Bryan
> ___
> 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
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] IntelSiliconPkg PlatformVTdSampleDxe: State it is only for dev/debug

[Star Zeng]

Cc: Jiewen Yao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 .../Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c  | 5 -
 .../Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf| 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git 
a/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c 
b/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c
index e522db069a43..3b141d978fdc 100644
--- a/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c
+++ b/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c
@@ -1,7 +1,10 @@
 /** @file
   Platform VTd Sample driver.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Note: This module should only be used for dev/debug purposes.
+It MUST never be used for production builds.
+
+  Copyright (c) 2017 - 2018, 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
diff --git 
a/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf 
b/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf
index 9895bc201174..0200b932d829 100644
--- a/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf
+++ b/IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf
@@ -1,7 +1,10 @@
 ## @file
 # Platform VTd Sample driver.
 #
-# Copyright (c) 2017, Intel Corporation. All rights reserved.
+# Note: This module should only be used for dev/debug purposes.
+#   It MUST never be used for production builds.
+#
+# Copyright (c) 2017 - 2018, 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
-- 
2.7.0.windows.1

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

Re: [edk2] Why the DEBUG can't output the full string?

[krishnaLee]

Hi Laszlo Ersek and Andrew Fish,
I had change all the MACRO in MdePkg + MdeModulePkg  like this  "#define 
MAX_DEBUG_MESSAGE_LENGTH 0x1000",and it has no function;
I had also change follow MACRO value from 200 to 1000:
//
D:\edk2-vUDK2017\MdeModulePkg\Include\Guid\StatusCodeDataTypeDebug.h
///
/// The maximum size of an EFI_DEBUG_INFO structure.
///
#define EFI_STATUS_CODE_DATA_MAX_SIZE 1000
//


I had clean and rebuild the project Nt32Pkg and follow test.
then the debug char's length is extended ok,This behave looks strange...


//test code:
EFI_STATUS
EFIAPI
UefiMain (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
CHAR16 
buffer[]=L"-A0-11-aa-bb-cc-dd-ee-ff-gg\
--B0-11-aa-bb-cc-dd-ee-ff-gg";
CHAR16 
buffer2[]=L"-C0-11-aa-bb-cc-dd-ee-ff-gg\
--D0-11-aa-bb-cc-dd-ee-ff-gg-";


DEBUG ((EFI_D_INFO,"size-of-buffer:%d\n",sizeof(buffer)));
DEBUG ((EFI_D_INFO,"%s",buffer));
DEBUG ((EFI_D_INFO,"\r\n"));


DEBUG ((EFI_D_INFO,"%s",buffer2));
DEBUG ((EFI_D_INFO,"\r\n"));


return EFI_SUCCESS;
}
//test code end;




I don't know if it is a bug,nevertheless,it worked as I expect.
thank you.
by krishna.





















At 2018-02-02 10:07:14, "krishnaLee"  wrote:

Hi Andrew Fish,
I didn't know the internal buffer is limited, I just think the Hii 
  will be a formatted string,I want to understarnd how it worked 
so I print it,I find the result is not  as I expected...
I had calculate the first DEBUG string length,it is 199 chars limited.then I  
search the MdePkg+MdeModulePkg for the define "MAX_DEBUG_MESSAGE_LENGTH",and 
modify them all to"#define MAX_DEBUG_MESSAGE_LENGTH 0x200",
rebuild Nt32Pkg,run my test,but the result is same,it is still 199 chars 
limited.


thanks.














At 2018-02-02 03:21:06, "Andrew Fish"  wrote:




On Feb 1, 2018, at 8:23 AM, Laszlo Ersek  wrote:


On 02/01/18 10:47, krishnaLee wrote:
Hi,
For example,the follow code:
//-code-start
ConfigRequestHdr = HiiConstructConfigHdr (, VariableName, 
PrivateData1->DriverHandle[0]);
Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
ConfigRequest = AllocateZeroPool (Size);
ASSERT (ConfigRequest != NULL);
AllocatedRequest = TRUE;
UnicodeSPrint (ConfigRequest, Size, L"%s=0=%016LX", 
ConfigRequestHdr, (UINT64)BufferSize);
FreePool (ConfigRequestHdr);
//-code-end


I add a debug message at the end of code:
DEBUG((EFI_D_INFO,"construct-ConfigRequest:%s",ConfigRequest));
DEBUG((EFI_D_INFO,"\r\n"));


and the output will be:
construct-ConfigRequest:GUID=db3b005aa15068459170ebd49e16c47c=00420044004d0079004900660072004e00560044006100740061=01041400db3b005aa15068459170ebd49e16c47c7fff0400=0=00


If I add another debug message at the end of code:
DEBUG((EFI_D_INFO,"construct-ConfigRequest:"));
for(UINTN i=0;i

Re: [edk2] Why does EDK2 disable time checks on certificates?

[Zhang, Chao B]

Bryan:
   You can reference EFI_CERT_X509_SHA256,  EFI_CERT_X509_SHA384, 
EFI_CERT_X509_SHA512 data structure definition in UEFI spec.
  Now they are only supported in DBX.  Revocation time here is defined by user 
instead of directly from Validity of X059 Certificate in order to address the 
issue mentioned below.


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Long, Qin
Sent: Tuesday, February 6, 2018 8:55 AM
To: Bryan Rosario ; edk2-devel@lists.01.org
Subject: Re: [edk2] Why does EDK2 disable time checks on certificates?

It's EDK2-only. 
The current pre-boot environment have no trusted timer synchronization service. 
And it's very likely the system time is not the real-time (esp under dev 
environment). So the certificate time expiration checking was bypassed to avoid 
any boot break. 

Against the corresponding certificate revocation case, the UEFI introduced the 
DBX database (forbidden list) to address this. 


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bryan 
Rosario
Sent: Tuesday, February 6, 2018 5:52 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Why does EDK2 disable time checks on certificates?

See here ("Currently certificate time expiration checking is ignored."):
https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security
.

Is this behavior part of the UEFI specification or is it EDK2-only? And what's 
the reasoning for it?

Thanks,
Bryan
___
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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Guo Heyi]

On Mon, Feb 05, 2018 at 10:11:30AM +0100, Ard Biesheuvel wrote:
> On 5 February 2018 at 09:06, Ni, Ruiyu  wrote:
> > On 2/3/2018 2:00 PM, Ni, Ruiyu wrote:
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >>> Sent: Friday, February 2, 2018 4:22 PM
> >>> To: Ni, Ruiyu 
> >>> Cc: Guo Heyi ,Dong Wei ; Dong,
> >>> Eric ; edk2-devel@lists.01.org; linaro-uefi  >>> u...@lists.linaro.org>; Kinney, Michael D ;
> >>> Zeng,
> >>> Star 
> >>> Subject: Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support for
> >>> address translation
> >>>
> >>> On 2 February 2018 at 00:34, Ni, Ruiyu  wrote:
> 
> 
> 
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Friday, February 2, 2018 1:23 AM
> > To: Ni, Ruiyu 
> > Cc: Guo Heyi ,Dong Wei ;
> >>>
> >>> Dong,
> >
> > Eric ; edk2-devel@lists.01.org; linaro-uefi
> > ; Kinney, Michael D
> > ; Zeng, Star 
> > Subject: Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support
> > for address translation
> >
> > On 1 February 2018 at 05:03, Ni, Ruiyu  wrote:
> >>
> >> On 1/29/2018 4:50 PM, Guo Heyi wrote:
> >>>
> >>>
> >>> Sorry for the late; I caught cold and didn't work for several days
> >>> last week :( Please see my comments below:
> >>>
> >>>
> >>> On Mon, Jan 22, 2018 at 11:36:14AM +0800, Ni, Ruiyu wrote:
> 
> 
>  On 1/18/2018 9:26 AM, Guo Heyi wrote:
> >
> >
> > On Wed, Jan 17, 2018 at 02:08:06PM +, Ard Biesheuvel wrote:
> >>
> >>
> >> On 15 January 2018 at 14:46, Heyi Guo  wrote:
> >>>
> >>>
> >>> This is the draft patch for the discussion posted in
> >>> edk2-devel mailing list:
> >>> https://lists.01.org/pipermail/edk2-devel/2017-December/019289
> >>> .ht
> >>> ml
> >>>
> >>> As discussed in the mailing list, we'd like to add support for
> >>> PCI address translation which is necessary for some non-x86
> >>> platforms. I also want to minimize the changes to the generic
> >>> host bridge driver and platform PciHostBridgeLib
> >>> implemetations, so additional two interfaces are added to
> >>> expose translation information of the platform. To be generic,
> >>> I add translation for each type of IO or memory resources.
> >>>
> >>> The patch is still a RFC, so I only passed the build for
> >>> qemu64 and the function has not been tested yet.
> >>>
> >>> Please let me know your comments about it.
> >>>
> >>> Thanks.
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement 1.1
> >>> Signed-off-by: Heyi Guo 
> >>> Cc: Ruiyu Ni 
> >>> Cc: Ard Biesheuvel 
> >>> Cc: Star Zeng 
> >>> Cc: Eric Dong 
> >>> ---
> >>>.../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c  |  19 
> >>>.../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  53
> >>> ---
> >>>.../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h   |   8 +-
> >>>.../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 101
> >>> ++---
> >>>MdeModulePkg/Include/Library/PciHostBridgeLib.h|  36
> >>>
> >>> 
> >>>
> >>>5 files changed, 192 insertions(+), 25 deletions(-)
> >>>
> >>> diff --git
> >>> a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> >>> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> >>> index 5b9c887..0c8371a 100644
> >>> ---
> >>> a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> >>> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.
> >>> +++ c
> >>> @@ -360,6 +360,16 @@ PciHostBridgeGetRootBridges (
> >>>  return 
> >>>}
> >>>
> >>> +PCI_ROOT_BRIDGE_TRANSLATION * EFIAPI
> >>> +PciHostBridgeGetTranslations (
> >>> +  UINTN *Count
> >>> +  )
> >>> +{
> >>> +  *Count = 0;
> >>> +  return NULL;
> >>> +}
> >>> +
> >>>/**
> >>>  Free the root bridge instances array returned from
> >>>  PciHostBridgeGetRootBridges().
> >>> @@ -377,6 +387,15 @@ 

Re: [edk2] [PATCH] BaseTools: Report error GUID format if incorrectly

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Feng, YunhuaX 
Sent: Monday, February 05, 2018 11:43 AM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong ; Gao, Liming 
Subject: [PATCH] BaseTools: Report error GUID format if incorrectly

Flexible GUID format support like these:
1. { GUID("11E13869-1896-4A07-8B21-D8B23DD2A2B4") } 2. { GUID({ 0x11e13869, 
0x1896, 0x4a07,{
0x8b, 0x21, 0xd8, 0xb2, 0x3d, 0xd2, 0xa2, 0xb4 } }) } 3. { 
GUID(gEfiBlockIoProtocolGuid) }

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng 
---
 BaseTools/Source/Python/Common/Misc.py | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/BaseTools/Source/Python/Common/Misc.py 
b/BaseTools/Source/Python/Common/Misc.py
index b8c2ce1ddc..5a0bcd9bf7 100644
--- a/BaseTools/Source/Python/Common/Misc.py
+++ b/BaseTools/Source/Python/Common/Misc.py
@@ -1535,16 +1535,10 @@ def ParseFieldValue (Value):
 if Value.startswith('GUID') and Value.endswith(')'):
 Value = Value.split('(', 1)[1][:-1].strip()
 if Value[0] == '{' and Value[-1] == '}':
-Value = Value[1:-1].strip()
-Value = Value.split('{', 1)
-Value = ['%02x' % int(Item, 16) for Item in (Value[0] + 
Value[1][:-1]).split(',')]
-if len(Value[0]) != 8:
-Value[0] = '%08X' % int(Value[0], 16)
-if len(Value[1]) != 4:
-Value[1] = '%04X' % int(Value[1], 16)
-if len(Value[2]) != 4:
-Value[2] = '%04X' % int(Value[2], 16)
-Value = '-'.join(Value[0:3]) + '-' + ''.join(Value[3:5]) + '-' + 
''.join(Value[5:11])
+TmpValue = GuidStructureStringToGuidString(Value)
+if len(TmpValue) == 0:
+raise BadExpression("Invalid GUID value string %s" % Value)
+Value = TmpValue
 if Value[0] == '"' and Value[-1] == '"':
 Value = Value[1:-1]
 try:
--
2.12.2.windows.2

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

Re: [edk2] Why does EDK2 disable time checks on certificates?

[Long, Qin]

It's EDK2-only. 
The current pre-boot environment have no trusted timer synchronization service. 
And it's very likely the system time is not the real-time (esp under dev 
environment). So the certificate time expiration checking was bypassed to avoid 
any boot break. 

Against the corresponding certificate revocation case, the UEFI introduced the 
DBX database (forbidden list) to address this. 


Best Regards & Thanks,
LONG, Qin

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bryan 
Rosario
Sent: Tuesday, February 6, 2018 5:52 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Why does EDK2 disable time checks on certificates?

See here ("Currently certificate time expiration checking is ignored."):
https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security
.

Is this behavior part of the UEFI specification or is it EDK2-only? And what's 
the reasoning for it?

Thanks,
Bryan
___
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

[edk2] Why does EDK2 disable time checks on certificates?

[Bryan Rosario]

See here ("Currently certificate time expiration checking is ignored."):
https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security
.

Is this behavior part of the UEFI specification or is it EDK2-only? And
what's the reasoning for it?

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

Re: [edk2] change keys in a ..._VARS.fd file programmatically (SecureBoot enabled)

[Richard W.M. Jones]

On Mon, Feb 05, 2018 at 07:06:11PM +0100, Laszlo Ersek wrote:
> Hi,
> 
> On 02/05/18 15:14, Dmitry Mityugov wrote:
> > Hi,
> > 
> > Could you please let me know if it possible to automate changing keys in a
> > ..._VARS.fd when SecureBoot is enabled? I understand that I can go into the
> > UEFI shell and change them there manually, but I'm looking for a way to
> > add/replace/delete them from my program before a KVM VM is started.
> > 
> > I've found an email in this list with a similar question,
> > https://lists.01.org/pipermail/edk2-devel/2017-August/012995.html , but I'm
> > not sure if the answer is still valid, or if any new possibilities have
> > arosen since then.
> 
> My (still valid) answer is here:
> 
> http://mid.mail-archive.com/550860A1.9030904@redhat.com
> 
> and here:
> 
> http://mid.mail-archive.com/56461E2D.1090601@redhat.com
> 
> and here:
> 
> http://mid.mail-archive.com/a1eedec9-f1c2-049d-8bb4-b094c9626f8e@redhat.com
> 
> > There are also some home-made editors for the vars, like
> > http://git.annexia.org/?p=virt-efivars.git;a=summary . Should I go this way
> > in my adventure?
> 
> I'm unsure how frequently Rich maintains this project (I'm CC'ing him),
> but the approach in this project is generally workable, because it
> modifies the variable store *from within* the guest (the "appliance" in
> libguestfs lingo), using the UEFI runtime variable services.

I don't really maintain it, but subject to the license the
original questioner is free to try and make something of it.

Rich.

> Summary:
> - if you try to modify the variable store file from the host side, with
>   a custom utility that is independent of edk2, that's a bad idea.
> - Whereas, if you modify the variable store from within the guest, via
>   the UEFI variable services (calling them from the UEFI shell, or from
>   the guest operating system / a privileged guest OS process), that's a
>   good idea. (This is what "virt-efivars" does.)
> 
> Thanks,
> Laszlo

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 00/14] rid PiSmmCpuDxeSmm of DB-encoded instructions

[Laszlo Ersek]

On 02/05/18 19:22, Kinney, Michael D wrote:
> Laszlo,
> 
> Let's see if we can close on the timeline for 
> the .S/.asm RFC this week.
> 
> I am concerned about making them UINT8 from C code
> because future maintainer may think that the patch 
> value type is UINT8.
> 
> Labels in assembly that are defined to be a function
> that is callable from C code does not have a storage
> type.  Why can't we make these labels the same way?

To my understanding, the labels in the NASM source code for functions
and variables look the same; the actual declaration only comes from the
C code.

(Assuming we declare a NASM label as a function in the C source, nothing
in the toolchain enforces an actual match between caller and callee; it
is possible to call the function (from C) through a declaration that
doesn't match the actual assembly implementation. IOW it's up to us to
avoid such bugs.)

If I understand correctly, you are suggesting that we take a label from
the NASM source that stands right after an instruction to patch, and we
declare it as a function in the C source. (With what prototype though?
The label does not actually introduce a function definition in the
assembly code; it would make no sense to call it.) Then, for the
patching, I presume your suggestion is to convert the address of the
function to UINTN, perform the subtraction, etc. Something like:

  typedef VOID (X86_ASSEMBLY_LABEL) (VOID);

(This is not a pointer-to-function type, but a function type.)

A declaration using the typedef would be

  extern X86_ASSEMBLY_LABEL gPatchCr3;

(This declares an extern function, not a pointer to a function.)

The patching function would take a pointer to a function:

  VOID
  EFIAPI
  PatchInstructionX86 (
OUT X86_ASSEMBLY_LABEL *InstructionEnd,
IN  UINT64 PatchValue,
IN  UINTN  ValueSize
);

and the implementation would have to do e.g.

  WriteUnaligned32 (
(UINT32 *)(UINTN)InstructionEnd - 1,
(UINT32)PatchValue
);

It would be called like

  PatchInstructionX86 (, Value, 4);


But, what does this buy us in comparison to just:

  typedef UINT8 X86_ASSEMBLY_LABEL;

?

If you worry that a future maintainer misunderstands the UINT8, then we
can as well hide the UINT8 behind a typedef; X86_ASSEMBLY_LABEL doesn't
have to be a function type for the hiding. (Conversely, when using a
function type as underlying type, I worry that a future maintainer might
be tempted to call them :) )

Thanks,
Laszlo

>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Monday, February 5, 2018 2:28 AM
>> To: Kinney, Michael D ; edk2-
>> devel-01 
>> Cc: Ard Biesheuvel ; Dong,
>> Eric ; Yao, Jiewen
>> ; Leif Lindholm
>> ; Gao, Liming
>> ; Ni, Ruiyu 
>> Subject: Re: [PATCH 00/14] rid PiSmmCpuDxeSmm of DB-
>> encoded instructions
>>
>> On 02/03/18 01:45, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> Thanks for all the work on this series and the very
>>> detailed commit messages.
>>>
>>> Liming's email on removing the .S and .asm files is an
>>> RFC.  We need to see this RFC approved before we can
>>> commit changes to remove .S and .asm files.  This
>> should
>>> be a separate activity.
>>
>> Sure, I can drop that patch, but then the PiSmmCpuDxeSmm
>> changes in the
>> other patches will divert the NASM files from the .S and
>> .asm files. Is
>> that (temporary) non-uniformity better than removing the
>> .S and .asm files?
>>
>>> One odd thing I see in this series is that the
>> instruction
>>> patch label in the .nasm file is just a label and does
>> not
>>> have any storage associated with it.
>>
>> No, this is not correct; the storage that is associated
>> with each of
>> these "patch labels" is the one byte (UINT8) directly
>> following the
>> label -- whatever that byte might be. It is generally
>> part of a totally
>> unrelated instruction.
>>
>> In case we had to patch an immediate operand that
>> happened to comprise
>> the very last byte(s) of a NASM source file, *then* we'd
>> have to add one
>> dummy DB at the end, just so there was something that the
>> label directly
>> refered to.
>>
>> This is why UINT8 is a good type here, because it
>> requires us to add the
>> least amount of padding.
>>
>>> But in the C code
>>> the type UINT8 is used with the label which implies
>> some
>>> storage.  Can we make the globals in C code be a
>> pointer
>>> (maybe VOID *) instead of UINT8?
>>
>> I don't think so. For building the addresses, we rely on
>> the linker, and
>> the linker needs definitions (allocations) of objects.
>> Your above
>> observation is correct (i.e. that storage is required),
>> my addition to
>> that is that storage is *already* allocated (one UINT8
>> per patch label /
>> symbol).
>>
>> Thanks!
>> Laszlo

Re: [edk2] [PATCH 00/14] rid PiSmmCpuDxeSmm of DB-encoded instructions

[Kinney, Michael D]

Laszlo,

Let's see if we can close on the timeline for 
the .S/.asm RFC this week.

I am concerned about making them UINT8 from C code
because future maintainer may think that the patch 
value type is UINT8.

Labels in assembly that are defined to be a function
that is callable from C code does not have a storage
type.  Why can't we make these labels the same way?

Mike

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, February 5, 2018 2:28 AM
> To: Kinney, Michael D ; edk2-
> devel-01 
> Cc: Ard Biesheuvel ; Dong,
> Eric ; Yao, Jiewen
> ; Leif Lindholm
> ; Gao, Liming
> ; Ni, Ruiyu 
> Subject: Re: [PATCH 00/14] rid PiSmmCpuDxeSmm of DB-
> encoded instructions
> 
> On 02/03/18 01:45, Kinney, Michael D wrote:
> > Laszlo,
> >
> > Thanks for all the work on this series and the very
> > detailed commit messages.
> >
> > Liming's email on removing the .S and .asm files is an
> > RFC.  We need to see this RFC approved before we can
> > commit changes to remove .S and .asm files.  This
> should
> > be a separate activity.
> 
> Sure, I can drop that patch, but then the PiSmmCpuDxeSmm
> changes in the
> other patches will divert the NASM files from the .S and
> .asm files. Is
> that (temporary) non-uniformity better than removing the
> .S and .asm files?
> 
> > One odd thing I see in this series is that the
> instruction
> > patch label in the .nasm file is just a label and does
> not
> > have any storage associated with it.
> 
> No, this is not correct; the storage that is associated
> with each of
> these "patch labels" is the one byte (UINT8) directly
> following the
> label -- whatever that byte might be. It is generally
> part of a totally
> unrelated instruction.
> 
> In case we had to patch an immediate operand that
> happened to comprise
> the very last byte(s) of a NASM source file, *then* we'd
> have to add one
> dummy DB at the end, just so there was something that the
> label directly
> refered to.
> 
> This is why UINT8 is a good type here, because it
> requires us to add the
> least amount of padding.
> 
> > But in the C code
> > the type UINT8 is used with the label which implies
> some
> > storage.  Can we make the globals in C code be a
> pointer
> > (maybe VOID *) instead of UINT8?
> 
> I don't think so. For building the addresses, we rely on
> the linker, and
> the linker needs definitions (allocations) of objects.
> Your above
> observation is correct (i.e. that storage is required),
> my addition to
> that is that storage is *already* allocated (one UINT8
> per patch label /
> symbol).
> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] change keys in a ..._VARS.fd file programmatically (SecureBoot enabled)

[Laszlo Ersek]

Hi,

On 02/05/18 15:14, Dmitry Mityugov wrote:
> Hi,
> 
> Could you please let me know if it possible to automate changing keys in a
> ..._VARS.fd when SecureBoot is enabled? I understand that I can go into the
> UEFI shell and change them there manually, but I'm looking for a way to
> add/replace/delete them from my program before a KVM VM is started.
> 
> I've found an email in this list with a similar question,
> https://lists.01.org/pipermail/edk2-devel/2017-August/012995.html , but I'm
> not sure if the answer is still valid, or if any new possibilities have
> arosen since then.

My (still valid) answer is here:

http://mid.mail-archive.com/550860A1.9030904@redhat.com

and here:

http://mid.mail-archive.com/56461E2D.1090601@redhat.com

and here:

http://mid.mail-archive.com/a1eedec9-f1c2-049d-8bb4-b094c9626f8e@redhat.com

> There are also some home-made editors for the vars, like
> http://git.annexia.org/?p=virt-efivars.git;a=summary . Should I go this way
> in my adventure?

I'm unsure how frequently Rich maintains this project (I'm CC'ing him),
but the approach in this project is generally workable, because it
modifies the variable store *from within* the guest (the "appliance" in
libguestfs lingo), using the UEFI runtime variable services.

Summary:
- if you try to modify the variable store file from the host side, with
  a custom utility that is independent of edk2, that's a bad idea.
- Whereas, if you modify the variable store from within the guest, via
  the UEFI variable services (calling them from the UEFI shell, or from
  the guest operating system / a privileged guest OS process), that's a
  good idea. (This is what "virt-efivars" does.)

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

Re: [edk2] [PATCH] ShellPkg/map: Fix out-of-bound read when "map fsn"

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Sunday, February 04, 2018 9:50 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Wang, Jian J
> 
> Subject: [PATCH] ShellPkg/map: Fix out-of-bound read when "map fsn"
> Importance: High
> 
> The below code reads additional one CHAR16 when copying
> content from Specific to NewSpecific.
> NewSpecific = AllocateCopyPool(
> StrSize(Specific) + sizeof(CHAR16), Specific
> );
> 
> The patch fixes this issue.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> Cc: Jian J Wang 
> ---
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Map.c | 18 --
> 
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Map.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Map.c
> index 3f5925f507..9166ca2205 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Map.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Map.c
> @@ -1,7 +1,7 @@
>  /** @file
>Main file for map shell level 2 command.
> 
> -  Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
>(C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
>(C) Copyright 2016 Hewlett Packard Enterprise Development LP
> 
> @@ -220,19 +220,25 @@ MappingListHasType(
>IN CONST BOOLEANConsist
>)
>  {
> -  CHAR16 *NewSpecific;
> -  RETURN_STATUS  Status;
> +  CHAR16  *NewSpecific;
> +  RETURN_STATUS   Status;
> +  UINTN   Length;
> 
>//
>// specific has priority
>//
>if (Specific != NULL) {
> -NewSpecific = AllocateCopyPool(StrSize(Specific) + sizeof(CHAR16),
> Specific);
> +Length  = StrLen (Specific);
> +//
> +// Allocate enough buffer for Specific and potential ":"
> +//
> +NewSpecific = AllocatePool ((Length + 2) * sizeof(CHAR16));
>  if (NewSpecific == NULL){
>return FALSE;
>  }
> -if (NewSpecific[StrLen(NewSpecific)-1] != L':') {
> -  Status = StrnCatS(NewSpecific, (StrSize(Specific) +
> sizeof(CHAR16))/sizeof(CHAR16), L":", StrLen(L":"));
> +StrCpyS (NewSpecific, Length + 2, Specific);
> +if (Specific[Length - 1] != L':') {
> +  Status = StrnCatS(NewSpecific, Length + 2, L":", StrLen(L":"));
>if (EFI_ERROR (Status)) {
>  FreePool(NewSpecific);
>  return FALSE;
> --
> 2.16.1.windows.1

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

Re: [edk2] [PATCH] ShellPkg/for: Fix potential null pointer deference

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Sunday, February 04, 2018 11:54 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben 
> Subject: [PATCH] ShellPkg/for: Fix potential null pointer deference
> Importance: High
> 
> When "FOR %a %a IN A B C" is executed,
> CurrentScriptFile->CurrentCommand->Data is NULL.
> But the code assumes it's not NULL and tries to
> deference it.
> 
> The patch fixes this issue.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/Library/UefiShellLevel1CommandsLib/For.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c
> b/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c
> index 3db4bb58d3..9824977149 100644
> --- a/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c
> +++ b/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c
> @@ -2,7 +2,7 @@
>Main file for endfor and for shell level 1 functions.
> 
>(C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> -  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2018, 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
> @@ -624,7 +624,9 @@ ShellCommandRunFor (
>if (CurrentScriptFile != NULL && CurrentScriptFile->CurrentCommand !=
> NULL) {
>  Info = (SHELL_FOR_INFO*)CurrentScriptFile->CurrentCommand->Data;
>  if (CurrentScriptFile->CurrentCommand->Reset) {
> -  Info->CurrentValue  = (CHAR16*)Info->Set;
> +  if (Info != NULL) {
> +Info->CurrentValue = (CHAR16*)Info->Set;
> +  }
>FirstPass = TRUE;
>CurrentScriptFile->CurrentCommand->Reset = FALSE;
>  }
> --
> 2.16.1.windows.1

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

[edk2] change keys in a ..._VARS.fd file programmatically (SecureBoot enabled)

[Dmitry Mityugov]

Hi,

Could you please let me know if it possible to automate changing keys in a
..._VARS.fd when SecureBoot is enabled? I understand that I can go into the
UEFI shell and change them there manually, but I'm looking for a way to
add/replace/delete them from my program before a KVM VM is started.

I've found an email in this list with a similar question,
https://lists.01.org/pipermail/edk2-devel/2017-August/012995.html , but I'm
not sure if the answer is still valid, or if any new possibilities have
arosen since then.

There are also some home-made editors for the vars, like
http://git.annexia.org/?p=virt-efivars.git;a=summary . Should I go this way
in my adventure?

Thank you in advance for any insight on this subject

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

Re: [edk2] [PATCH v2] BaseTools/Conf: disable DTC legacy phandle format

[Ard Biesheuvel]

On 1 February 2018 at 16:53, Laszlo Ersek  wrote:
> On 02/01/18 12:15, Ard Biesheuvel wrote:
>> By default, the device tree compiler emits phandle properties twice:
>> one called 'phandle' and another called 'linux,phandle'. Given that
>> Linux was updated in early 2010 [0] to accept the former (which is
>> what is specified in the ePAPR and device tree specifications), there
>> is no point in emitting both when compiling device trees for UEFI
>> platforms.
>>
>> [0] 04b954a673dd02f585a2769c4945a43880faa989
>> "of/flattree: Make the kernel accept ePAPR style phandle information"
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  BaseTools/Conf/build_rule.template | 2 +-
>>  BaseTools/Conf/tools_def.template  | 1 +
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/BaseTools/Conf/build_rule.template 
>> b/BaseTools/Conf/build_rule.template
>> index 3e6aa8ff0f34..a5e471eb3c10 100755
>> --- a/BaseTools/Conf/build_rule.template
>> +++ b/BaseTools/Conf/build_rule.template
>> @@ -250,7 +250,7 @@
>>
>>  
>>  "$(PP)" $(DTCPP_FLAGS) $(INC) ${src} > ${d_path}(+)${s_base}.i
>> -"$(DTC)" -I dts -O dtb -o ${dst} ${d_path}(+)${s_base}.i
>> +"$(DTC)" $(DTC_FLAGS) -I dts -O dtb -o ${dst} 
>> ${d_path}(+)${s_base}.i
>>
>>  [Visual-Form-Representation-File]
>>  
>> diff --git a/BaseTools/Conf/tools_def.template 
>> b/BaseTools/Conf/tools_def.template
>> index 482ef263c274..99ad271471d9 100755
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -4467,6 +4467,7 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO 
>> /NODEFAULTLIB /LTCG /DLL /OPT:REF
>>  DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
>> --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
>>  RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =
>>  NOOPT_*_*_OBJCOPY_ADDDEBUGFLAG = 
>> --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug
>> +*_*_*_DTC_FLAGS= -H epapr
>>
>>  DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-builtin 
>> -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include AutoGen.h 
>> -fno-common
>>  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
>> -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
>> -mno-stack-arg-probe
>>
>
> Reviewed-by: Laszlo Ersek 

Thank you.

Liming, any comments?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] setting the TLS cipher list for HTTPS booting

[Laszlo Ersek]

On 02/05/18 04:33, Wu, Jiaxin wrote:
> Hi Laszlo,
>
> In recent days, we received the comment from Kinney about the PCD
> usage in UEFI driver.  Kinney doesn't recommend us to use the *dynamic
> PCD* in *soft-loading* UEFI driver even though it's not prohibited.
>
> So, we want to confirm with you whether this is the urgent request
> need us to support it ASAP or it's in low priority.
>
> If you need us support the feature ASAP, we can use the  private
> variable solution as we discussed before since there is no security
> issue and the size requirement is not big.
>
> If not urgency, we might consider whether need to define a platform to
> driver configuration protocol or not. You know it will take a long
> time to scandalize one protocol for platform HTTPS configuration in
> the future UEFI spec.

The variable approach sounds good to me, but with a small twist:

Could we please leave it up to the platform whether the private variable
is non-volatile versus volatile? Because platform X might want to
configure the cipher suite list once, permanently, while platform Y
might want to configure the cipher suite list dynamically on each boot.
For platform Y, spending any flash space (and flash writing time) on the
variable is superfluous.

For QEMU / OVMF specifically, I would prefer a volatile, boot-time only
variable. After setting this variable, I think OVMF platform code should
even lock it down with the edk2 variable lock protocol. In effect this
would behave like a "read only" PCD -- no flash impact at all.

As long as HttpDxe only calls gRT->GetVariable() (or equivalent wrappers
from UefiLib) on the new variable, the variable's attributes should not
matter; they can be left to the platform.

Thanks!
Laszlo


>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, January 25, 2018 8:42 PM
>> To: Wu, Jiaxin ; Fu, Siyuan ; Ye,
>> Ting ; Long, Qin ; Yao, Jiewen
>> ; Hsiung, Harry L 
>> Cc: edk2-devel-01 
>> Subject: Re: setting the TLS cipher list for HTTPS booting
>>
>> On 01/25/18 05:52, Wu, Jiaxin wrote:
>>> Hi Laszlo,
>>>
>>> The HttpDxe driver needs to install the Driver Binding Protocol so as
>>> to check if a specific controller is supported by HttpDxe. HttpDxe
>>> can only be started if the TcpServiceBindingProtocol existed. So, it
>>> has to follow the UEFI Driver Model.
>>>
>>> For the PCD usage, I think it should be fine to cover the
>>> configuration of UEFI Drivers through the PCD settings. The
>>> requirement of *.inf needs to include the PcdLib and the section of
>>> [Pcd]. We already have the similar pattern for this usage, for
>>> example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in
>>> MdeModulePkg. Besides, there are some advantages by using PCD
>>> compared to the variable. First, PCD is one kind of interface that
>>> more formal than a private variable, the setting by PCD is more
>>> acceptable by the consumer. Secondly, from a *security* standpoint,
>>> variable can be dumped easily from the flash region. Here, even
>>> though it's no security impact towards the cipher list storage
>>> because it will be public shared to remote server, but we need to
>>> think and *align* with other configurations for TLS in HTTPS level.
>>> For example, in the future, we might support the HTTPS mutual
>>> authentication, than the host PrivateKey/Password
>>> (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable
>>> due to its confidentiality, while PCD is good choice. At that time,
>>> we will also provide the PCD for EfiTlsConfigDataTypeCACertificate,
>>> which is currently setting by the variable (TlsCaCertificate), so as
>>> to align all the configuration setting on one line, which can reduce
>>> the complexity of platform usage. Finally, we can also save the
>>> variable space.
>>>
>>> From the above, the dynamic PCD is a solution I still preferred.
>>
>> OK, it works for me. Thanks!
>> Laszlo

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

Re: [edk2] [PATCH 00/14] rid PiSmmCpuDxeSmm of DB-encoded instructions

[Laszlo Ersek]

On 02/03/18 01:45, Kinney, Michael D wrote:
> Laszlo,
> 
> Thanks for all the work on this series and the very
> detailed commit messages.
> 
> Liming's email on removing the .S and .asm files is an
> RFC.  We need to see this RFC approved before we can
> commit changes to remove .S and .asm files.  This should
> be a separate activity.

Sure, I can drop that patch, but then the PiSmmCpuDxeSmm changes in the
other patches will divert the NASM files from the .S and .asm files. Is
that (temporary) non-uniformity better than removing the .S and .asm files?

> One odd thing I see in this series is that the instruction
> patch label in the .nasm file is just a label and does not
> have any storage associated with it.

No, this is not correct; the storage that is associated with each of
these "patch labels" is the one byte (UINT8) directly following the
label -- whatever that byte might be. It is generally part of a totally
unrelated instruction.

In case we had to patch an immediate operand that happened to comprise
the very last byte(s) of a NASM source file, *then* we'd have to add one
dummy DB at the end, just so there was something that the label directly
refered to.

This is why UINT8 is a good type here, because it requires us to add the
least amount of padding.

> But in the C code
> the type UINT8 is used with the label which implies some
> storage.  Can we make the globals in C code be a pointer
> (maybe VOID *) instead of UINT8?

I don't think so. For building the addresses, we rely on the linker, and
the linker needs definitions (allocations) of objects. Your above
observation is correct (i.e. that storage is required), my addition to
that is that storage is *already* allocated (one UINT8 per patch label /
symbol).

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

Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Ard Biesheuvel]

On 5 February 2018 at 09:06, Ni, Ruiyu  wrote:
> On 2/3/2018 2:00 PM, Ni, Ruiyu wrote:
>>
>>
>>
>>> -Original Message-
>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>>> Sent: Friday, February 2, 2018 4:22 PM
>>> To: Ni, Ruiyu 
>>> Cc: Guo Heyi ,Dong Wei ; Dong,
>>> Eric ; edk2-devel@lists.01.org; linaro-uefi >> u...@lists.linaro.org>; Kinney, Michael D ;
>>> Zeng,
>>> Star 
>>> Subject: Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support for
>>> address translation
>>>
>>> On 2 February 2018 at 00:34, Ni, Ruiyu  wrote:



> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, February 2, 2018 1:23 AM
> To: Ni, Ruiyu 
> Cc: Guo Heyi ,Dong Wei ;
>>>
>>> Dong,
>
> Eric ; edk2-devel@lists.01.org; linaro-uefi
> ; Kinney, Michael D
> ; Zeng, Star 
> Subject: Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support
> for address translation
>
> On 1 February 2018 at 05:03, Ni, Ruiyu  wrote:
>>
>> On 1/29/2018 4:50 PM, Guo Heyi wrote:
>>>
>>>
>>> Sorry for the late; I caught cold and didn't work for several days
>>> last week :( Please see my comments below:
>>>
>>>
>>> On Mon, Jan 22, 2018 at 11:36:14AM +0800, Ni, Ruiyu wrote:


 On 1/18/2018 9:26 AM, Guo Heyi wrote:
>
>
> On Wed, Jan 17, 2018 at 02:08:06PM +, Ard Biesheuvel wrote:
>>
>>
>> On 15 January 2018 at 14:46, Heyi Guo  wrote:
>>>
>>>
>>> This is the draft patch for the discussion posted in
>>> edk2-devel mailing list:
>>> https://lists.01.org/pipermail/edk2-devel/2017-December/019289
>>> .ht
>>> ml
>>>
>>> As discussed in the mailing list, we'd like to add support for
>>> PCI address translation which is necessary for some non-x86
>>> platforms. I also want to minimize the changes to the generic
>>> host bridge driver and platform PciHostBridgeLib
>>> implemetations, so additional two interfaces are added to
>>> expose translation information of the platform. To be generic,
>>> I add translation for each type of IO or memory resources.
>>>
>>> The patch is still a RFC, so I only passed the build for
>>> qemu64 and the function has not been tested yet.
>>>
>>> Please let me know your comments about it.
>>>
>>> Thanks.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Heyi Guo 
>>> Cc: Ruiyu Ni 
>>> Cc: Ard Biesheuvel 
>>> Cc: Star Zeng 
>>> Cc: Eric Dong 
>>> ---
>>>.../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c  |  19 
>>>.../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  53
>>> ---
>>>.../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h   |   8 +-
>>>.../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 101
>>> ++---
>>>MdeModulePkg/Include/Library/PciHostBridgeLib.h|  36
>>>
>>> 
>>>
>>>5 files changed, 192 insertions(+), 25 deletions(-)
>>>
>>> diff --git
>>> a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
>>> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
>>> index 5b9c887..0c8371a 100644
>>> ---
>>> a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
>>> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.
>>> +++ c
>>> @@ -360,6 +360,16 @@ PciHostBridgeGetRootBridges (
>>>  return 
>>>}
>>>
>>> +PCI_ROOT_BRIDGE_TRANSLATION * EFIAPI
>>> +PciHostBridgeGetTranslations (
>>> +  UINTN *Count
>>> +  )
>>> +{
>>> +  *Count = 0;
>>> +  return NULL;
>>> +}
>>> +
>>>/**
>>>  Free the root bridge instances array returned from
>>>  PciHostBridgeGetRootBridges().
>>> @@ -377,6 +387,15 @@ PciHostBridgeFreeRootBridges (
>>>  ASSERT (Count == 1);
>>>}
>>>
>>> +VOID
>>> +EFIAPI
>>> +PciHostBridgeFreeTranslations (
>>> +  PCI_ROOT_BRIDGE_TRANSLATION *Translations,
>>> +  UINTN   Count
>>> +  )

Re: [edk2] [EDK2] How to use compiler intrinsic function, such as :mmintrin.h

[Tiger Liu(BJ-RD)]

Hi, experts:
I have a question about how to direct compiler to search dedicated include 
directory.
Such as:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include

I tried to tell  compiler through “/I” parameter.
“/I C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include”

But failed.

Best wishes,
发件人: Tiger Liu(BJ-RD)
发送时间: 2018年2月2日 19:08
收件人: edk2-devel@lists.01.org
主题: [EDK2] How to use compiler intrinsic function, such as :mmintrin.h

Hi, experts:
I have a question about using compiler’s intrinsic function.
It seems EDKII’s compiler option doesn’t support using intrinsic function.

Such as:
mmintrin.h  MMX
xmmintrin.hSSE
emmintrin.h   SSE2
pmmintrin.h   SSE3
tmmintrin.hSSSE3
intrin.h SSE4A
smmintrin.h   SSE4.1
nmmintrin.h   SSE4.2
mm3dnow.h  3DNOW

Thanks

Best wishes,


保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] MdePkg/SafeString: Fix potential out-of-bound memory access

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Ni, Ruiyu
> Sent: Monday, February 5, 2018 1:26 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Gao, Liming ;
> Wang, Jian J 
> Subject: [PATCH v2] MdePkg/SafeString: Fix potential out-of-bound memory
> access
> 
> Today's implementation of [Ascii]StrnCpyS/[Ascii]StrnCatS calls
> StrnLenS () to get the length of source string but supplies the
> destination buffer size as max size.
> It's a bug that may cause out-of-bound memory access.
> For example:
>   StrnCpyS (Dest[10], 10, "hello", 6)
>   -> StrnLenS ("hello", 10) //< cause out-of bound memory access
> 
> In a pool guard enabled environment, when using shell to edit an
> existing file which contains empty line, the page fault is met.
> 
> The patch fixes the four library functions to avoid such
> out-of-bound memory access.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Jian J Wang 
> ---
>  MdePkg/Library/BaseLib/SafeString.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseLib/SafeString.c
> b/MdePkg/Library/BaseLib/SafeString.c
> index 68c33e9b7b..29310889ca 100644
> --- a/MdePkg/Library/BaseLib/SafeString.c
> +++ b/MdePkg/Library/BaseLib/SafeString.c
> @@ -1,7 +1,7 @@
>  /** @file
>Safe String functions.
> 
> -  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
> +  Copyright (c) 2014 - 2018, 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
> @@ -342,7 +342,7 @@ StrnCpyS (
>//
>// 4. If Length is not less than DestMax, then DestMax shall be greater 
> than
> StrnLenS(Source, DestMax).
>//
> -  SourceLen = StrnLenS (Source, DestMax);
> +  SourceLen = StrnLenS (Source, MIN (DestMax, Length));
>if (Length >= DestMax) {
>  SAFE_STRING_CONSTRAINT_CHECK ((DestMax > SourceLen),
> RETURN_BUFFER_TOO_SMALL);
>}
> @@ -361,7 +361,7 @@ StrnCpyS (
>// pointed to by Destination. If no null character was copied from Source,
> then Destination[Length] is set to a null
>// character.
>//
> -  while ((*Source != 0) && (SourceLen > 0)) {
> +  while ((SourceLen > 0) && (*Source != 0)) {
>  *(Destination++) = *(Source++);
>  SourceLen--;
>}
> @@ -551,7 +551,7 @@ StrnCatS (
>//
>// 5. If Length is not less than CopyLen, then CopyLen shall be greater 
> than
> StrnLenS(Source, CopyLen).
>//
> -  SourceLen = StrnLenS (Source, CopyLen);
> +  SourceLen = StrnLenS (Source, MIN (CopyLen, Length));
>if (Length >= CopyLen) {
>  SAFE_STRING_CONSTRAINT_CHECK ((CopyLen > SourceLen),
> RETURN_BUFFER_TOO_SMALL);
>}
> @@ -572,7 +572,7 @@ StrnCatS (
>// a null character.
>//
>Destination = Destination + DestLen;
> -  while ((*Source != 0) && (SourceLen > 0)) {
> +  while ((SourceLen > 0) && (*Source != 0)) {
>  *(Destination++) = *(Source++);
>  SourceLen--;
>}
> @@ -1916,7 +1916,7 @@ AsciiStrnCpyS (
>//
>// 4. If Length is not less than DestMax, then DestMax shall be greater 
> than
> AsciiStrnLenS(Source, DestMax).
>//
> -  SourceLen = AsciiStrnLenS (Source, DestMax);
> +  SourceLen = AsciiStrnLenS (Source, MIN (DestMax, Length));
>if (Length >= DestMax) {
>  SAFE_STRING_CONSTRAINT_CHECK ((DestMax > SourceLen),
> RETURN_BUFFER_TOO_SMALL);
>}
> @@ -1935,7 +1935,7 @@ AsciiStrnCpyS (
>// pointed to by Destination. If no null character was copied from Source,
> then Destination[Length] is set to a null
>// character.
>//
> -  while ((*Source != 0) && (SourceLen > 0)) {
> +  while ((SourceLen > 0) && (*Source != 0)) {
>  *(Destination++) = *(Source++);
>  SourceLen--;
>}
> @@ -2115,7 +2115,7 @@ AsciiStrnCatS (
>//
>// 5. If Length is not less than CopyLen, then CopyLen shall be greater 
> than
> AsciiStrnLenS(Source, CopyLen).
>//
> -  SourceLen = AsciiStrnLenS (Source, CopyLen);
> +  SourceLen = AsciiStrnLenS (Source, MIN (CopyLen, Length));
>if (Length >= CopyLen) {
>  SAFE_STRING_CONSTRAINT_CHECK ((CopyLen > SourceLen),
> RETURN_BUFFER_TOO_SMALL);
>}
> @@ -2136,7 +2136,7 @@ AsciiStrnCatS (
>// a null character.
>//
>Destination = Destination + DestLen;
> -  while ((*Source != 0) && (SourceLen > 0)) {
> +  while ((SourceLen > 0) && (*Source != 0)) {
>  *(Destination++) = *(Source++);
>  SourceLen--;
>}
> --
> 2.16.1.windows.1

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

[edk2] [edk2-non-osi][PATCH 2/2] Platform/Hisilicon/HiKey960: add mcu firmware

[Haojian Zhuang]

The MCU is used to control multiple core power state and
scale core frequency in Hisilicon Hi3660 SoC. The firmware
of MCU is lpm3.img.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Haojian Zhuang 
---
 Platform/Hisilicon/HiKey960/lpm3.img | Bin 0 -> 217344 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 Platform/Hisilicon/HiKey960/lpm3.img

diff --git a/Platform/Hisilicon/HiKey960/lpm3.img 
b/Platform/Hisilicon/HiKey960/lpm3.img
new file mode 100644
index 
..bd0243bfa386e324a5274c1b327ed0772e644677
GIT binary patch
literal 217344
zcmeFa3wTu3xj(%2Wv&^>Boi<#Ig!n!eBH9T$LoGm*QpAj
zPIdOaPBs5%r&@UYivjbFF9s|-(`2TB=1WufR8v@3lqL#ASz<~3j{4K}&-Mu{(xsJh
ziL_tdE=A-wrL;z-er01x!~VwY4Uxt-8@?E@Z)Y}qF_5;s1iy~$+wq{ml(=k+e-K
z*Wy3Z80BBbNCyd%wseI59^uOq;Z%g5M)>y=VJ*I0BOT-2fBiqdn2N`_iSn6d4{%P>oLXrQ@B*Wxsho3aCH2`Mx
zJj9#Zi1PMm$0f6uD8K1Y+fv0`(I_e{c0Nn2jv2RT@rxSC>+qSozNO|7C*ll<>(ZDd
zv2Lfx2sW1%e@7z%{4SeYi~kOOwWC_mJZgs_kS(Xjgu8OX)iI$qTgsG4{wQiTlRU55
zHcPxGz~%Ge6!GpAIdaMcZ~v_|jI$HvJ)?PKA@-=?js09OMTwAzeQF|>aaPBypy6?C
zZGdrR$}yLqc)eQu5$#)nOj%I2d2KCTMetI*Il$YZt*j*TGr~qUaodp|t?~Bkl
zgDX>Xx9=1kMq@cIwG~8l@Pq8k=#5(*b
zQsTd~g)6L93|zIs@!SR0X%bkJ?-VmdSLM(6X|gdEot~!@8Q->2Gcz8X}FoleM6etMoa2KNx$lW>0v;B>z8E^my0@2~xeM}JPn33}XdJ8h_}oOapkLeFC4_$@Eit-W|JBmxNLmu@Szqhv;oNHMT~NJ+@7V
zg@Uv+Zx1I3N{EmGTR4PKnCY+4+w+UDYG7u|$7EOR;q=o327+x^usvW3=h
zWUMUU?XUb^rhL6>_6RYrXVtQdFmWTj2<4K5KU9?IXPj@8q6acP0TV6>q!HbaO
ziUn)o$BYnK$@;DS)C1Yldum9a@rf`v>phJa#>qoUYsL!nHrVu*Q8}lyEE~I4r`M&}
zSz1Es;V)s8deD~X@=o-pXYAOv9Mj5klxA=L`@UwM@w~VH7p`U>>S3?zB2m`m?Jp=<
zlkNBUOE~AXQM=$$@k=W3m0O32JF3=kYk*k9KBv3Uc{FIY5-(Wo_7sg
zGn?nNVH~{#APBSWEb(YLnU@hpZR?4PVAfkB+5P(5qt8W5O|FY^(l`XkKJK84j=
z^utPr%qaqw+DraE(>5@S(YtR
z3G($ArltOH##f~1mgSgPWPN6>q2=2~^D%Frg*CiRDL?vid1+v2xx-84-KNJ4kGudJ
zZ%nC4g!}cd5R<

[edk2] [edk2-non-osi][PATCH 1/2] Platform/Hisilicon/HiKey: add mcuimage

[Haojian Zhuang]

The MCU of Hisilicon 6220 SoC is used to control multiple cores
power states, and scale core frequency. mcuimage.bin is the
firmware of MCU.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Haojian Zhuang 
---
 Platform/Hisilicon/HiKey/mcuimage.bin | Bin 0 -> 146688 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 Platform/Hisilicon/HiKey/mcuimage.bin

diff --git a/Platform/Hisilicon/HiKey/mcuimage.bin 
b/Platform/Hisilicon/HiKey/mcuimage.bin
new file mode 100644
index 
..dcaa78651351b16bd27677aab13f50feec369565
GIT binary patch
literal 146688
zcmeFadwf*Y)i=J+Ws*rUA(IO*xd0~_E`fjq0yPM(21WXXLXl*TdQa@kdetolJ*52_Gx{SSoBc>sV5>h!76(~6ju0O3
zuDLAX`#e)Mlt=?0mobcgXLxakmP0m43|NK#9slAxdKkO0ybU&
zCtd+3T>%pOcLhBD3fOc7oO%VEb_JY%1)OmOJmCtMI8dh76Y|853E7V4
z89XoJX~T2nzk;6-@`i?g72iF0=Dc?8`R}ZQW#!BBmKQ8uQh3uX%dN#XXYz#e)8?Ly
zH(EZKr@aXif{ognM00*>A2RT!bmdw+JKh}N+;BWyh#wyxqC?QNf7di{O#|07a7_c(
zG;mD=*EDcV1J^WgO#}Z^G{Cd!ykU@I)p-L+(cokao~*%U4W6gLc^X`#!G#*UN`qHw
z@LCP7)ZqIyc#8)8JYS-mAe48vL9FAJX6>8vLpTzplY2HTWY9{!oL@Y48^s+^fMp
z4gQ}}!sJO#|07a1{-3et1d!LHr{G4-Xj62z-?o*HG6qa7_c(H1J=cfq5+K5q0R&
z=l_v^*^VT2tZ32Rq+FP%^4cgnNy;HQeNqd)T@egY6=d||=+WWBf?Y
z%i6nFdzWi`S7~qZMo6yzN7QyrjB6UWrh#i3xTb+?8n~u`YZ|zwfomGLrh#i3xTb+?
z8n~u`{~tAw-KqI2UJJcDwYTM@25WE2n;NXWEq~Tv?Y&5gcU*ff(&8Q0-ZM4)VeLIr
z!yne(SNbmq6XMTnZ@SM>$eQhZB&+k`tJ$09LQ|wPtVuW!wt=u-6r;dy8
zyox?w%`~lvG1rsg;uBP#`3Hmgu`mBuJhVA8~kfb4}RL;V*|4^St
z7MM0C+$fV$RltE$g(=7Hj8sXoCoS)Z)(
zgg%eWi0E_oV^`;S6@C6e)n_O3#4WE;eKs4R#@O^H_dFpX2KyJgGjzc_;G?YPnNQ
zXyyLEEzK*(-*?-OE{LpS)Cg{*#-3H^!L}FJwml?9FF(M0iH)B0S4a
zhDwkA{h4vKt{9u%W8#W@@w?XrmpaINFG_(3L1t2rj}ZPRU%3yA93vp#GfvhO{$Jqv
z-$l;pl3pXYrh#i3xTb+?8n~u`{}vix{)_+NJYYZOJN-CU
z*Dv7Fw{r5jpuT-^pUb$ouQ{vJi=!s=U-(nuyRKc(o~^IHqL370H$3A`9DGA<&|
zQ)Y;QSSH^xhnIIL1$`?wCyVP+*Z3w`D}9p+vuwo*zbGF(iDk?Z%2D4MlNR)U614U;
zS9W??4sUy^L_>mp7qEv_Y)Riifnr%;-+)Yxtu%Z%XkSb^^sP~)H}%Qi@bVe!J
z*{SP{-?v!bPCBZ-LsQ^Oe*i2ID2~P&@K8Jv>_>EvG_-(MpN%c-JIIxF+cHk}
z5e5&7hpQ-BQ?bNE2~n$Jfv`4BH+CRj~
zWnMGO+YHb<^0=?8FJlwMc6xbMPce;UeZpp7HYeH`XohRfZP{iR5?y7GOmV@sKQ
zd`+4y=zk>`^z*1aq+=WM%QdhKOas@z?S}?vI(F8^?57&2^bwY7lcr*oS$u!0@SSCS
z{N@u1=~PpaxZPYMBS$mz%{CytGTj`vv72Gbx(
zl38ELi))&7Vyb*xxog?kHQ)M-b(@by=7LV%{3Ge+{WZVfD@x1c#jzhMr2f9C
zF_+l+CYE(zM_8U|ue79yH2Kf<->$$QSkU`hi^hy=y?1St7D>^I*A{Ajbu0NR}Eh
zX&_FXKg5VQFeyLgV6tAcm^WmLsZwS)%cj{#rcvH7_($Y{xYry_l{YJ2Y!E6t)0!`l
zjkd}kb`gPXZoeQuPAN9I&`NXrJU2kLLRGd3$o3dyGsNUhYxc|ozCgv_34FqXGp7B<
zGaERoin9S%_TcPk2RsFR59ht#r)(jpCDRaYQNw?P@TVV~K5dsL3%FtxcMouHs{HSo
z=I~?yFRJ)^fj_U}@1AzQXB_ZFDt-g-zftjPrb!+$S;#al)eGrz*>HkT))%!YOEimQ
zuSx!LP!RWcvc))g;?M!A^Js@{AwUC{4N
zl`jny^htA(kIf$_q`9E)UNukLb$dI=6lTgF2+HnYP9VCstozZJbRnjP)2GVc4!sB3
z83Fx3namsBQ}mr>vd$1EaG81Hd#H8wOUvXa;Q52^DaOw6@|1pFj^UV`IGKqf@;(PI
z$8xbbM3(Vo;0*ZcbC6jU`KTjJtr2fJPK)V6s{Grbfea>Vza=FQ?T3`AWa-jW(cI1Q
ziweVXQ<+n2v?S7nNm8nOa7cfh*dY-)UW3qu>pNA<+pW+$zlU~^dq5Mrb{0d
zo4fV;B0SNqKS6)<-K?1l#Q3tiIX%_u9fLxfis{epj?p8YswpbVYYK7DG{;IA66L*a
zC{xT9gZ>+bc{AIfgFT2cbD4ZYoM0B0FC|YfyT{AVDEcO@ZOu_4#L?RLOEwVW*IP
zZ+pheY{E+}v__6cizPYFyGw)wd8aZ{d{KPH^VG34S)Xv9>$DivV102}@W!9o
zLhvya@T>j@ecnbf1r}C*QN>ui^UA}RXMnNUe$hr|{n{0lo0XsJXTUk1
zZ1fQ(#CuEsFFj?w6VyD=u?Q=>`pK+EUFU$!7=?YKpP9PH6XCR}-y$YCP4dnnZQ*k#1QipjVV(mfMa7KKFfRZTr(%*c%wb?y6*Er5G|yw?
z{vee(O~V`kMpiMQ*8hg`M_@cE#;VaA2j(9tM$|B!z

[edk2] [edk2-platforms][PATCH] Platform/Hisilicon/HiKey960: add skeleton of HiKey960

[Haojian Zhuang]

Add skeleton of HiKey960 platform.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Haojian Zhuang 
---
 Platform/Hisilicon/HiKey960/HiKey960.dsc   | 457 +
 Platform/Hisilicon/HiKey960/HiKey960.fdf   | 343 
 .../HiKey960/Library/HiKey960Lib/HiKey960.c| 144 +++
 .../HiKey960/Library/HiKey960Lib/HiKey960Helper.S  |  52 +++
 .../HiKey960/Library/HiKey960Lib/HiKey960Lib.inf   |  47 +++
 .../HiKey960/Library/HiKey960Lib/HiKey960Mem.c | 167 
 6 files changed, 1210 insertions(+)
 create mode 100644 Platform/Hisilicon/HiKey960/HiKey960.dsc
 create mode 100644 Platform/Hisilicon/HiKey960/HiKey960.fdf
 create mode 100644 Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960.c
 create mode 100644 
Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Helper.S
 create mode 100644 
Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Lib.inf
 create mode 100644 
Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Mem.c

diff --git a/Platform/Hisilicon/HiKey960/HiKey960.dsc 
b/Platform/Hisilicon/HiKey960/HiKey960.dsc
new file mode 100644
index 000..85bac2c
--- /dev/null
+++ b/Platform/Hisilicon/HiKey960/HiKey960.dsc
@@ -0,0 +1,457 @@
+#
+#  Copyright (c) 2014-2017, Linaro 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.
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = HiKey960
+  PLATFORM_GUID  = bd1a557e-4423-466a-a462-38439588fd37
+  PLATFORM_VERSION   = 0.2
+  DSC_SPECIFICATION  = 0x00010019
+  OUTPUT_DIRECTORY   = Build/HiKey960
+  SUPPORTED_ARCHITECTURES= AARCH64
+  BUILD_TARGETS  = DEBUG|RELEASE
+  SKUID_IDENTIFIER   = DEFAULT
+  FLASH_DEFINITION   = Platform/Hisilicon/HiKey960/HiKey960.fdf
+
+[LibraryClasses.common]
+!if $(TARGET) == RELEASE
+  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+!else
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!endif
+  
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
+
+  ArmDisassemblerLib|ArmPkg/Library/ArmDisassemblerLib/ArmDisassemblerLib.inf
+  ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
+  ArmGicArchLib|ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
+  ArmHvcLib|ArmPkg/Library/ArmHvcLib/ArmHvcLib.inf
+  ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
+  
ArmGenericTimerCounterLib|ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.inf
+
+  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
+  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
+  
ArmPlatformLib|Platform/Hisilicon/HiKey960/Library/HiKey960Lib/HiKey960Lib.inf
+  
ArmPlatformStackLib|ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf
+
+  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  
CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
+  
DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
+  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
+  CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
+  DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
+  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+  
DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
+  
ResetSystemLib|ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
+  
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+  
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
+
+  FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
+  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
+  
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+  
PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+  
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
+
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  

Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Ni, Ruiyu]

On 2/3/2018 2:00 PM, Ni, Ruiyu wrote:




-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, February 2, 2018 4:22 PM
To: Ni, Ruiyu 
Cc: Guo Heyi ,Dong Wei ; Dong,
Eric ; edk2-devel@lists.01.org; linaro-uefi ; Kinney, Michael D ; Zeng,
Star 
Subject: Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support for
address translation

On 2 February 2018 at 00:34, Ni, Ruiyu  wrote:




-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Friday, February 2, 2018 1:23 AM
To: Ni, Ruiyu 
Cc: Guo Heyi ,Dong Wei ;

Dong,

Eric ; edk2-devel@lists.01.org; linaro-uefi
; Kinney, Michael D
; Zeng, Star 
Subject: Re: [edk2] [RFC] MdeModulePkg/PciHostBridgeDxe: Add support
for address translation

On 1 February 2018 at 05:03, Ni, Ruiyu  wrote:

On 1/29/2018 4:50 PM, Guo Heyi wrote:


Sorry for the late; I caught cold and didn't work for several days
last week :( Please see my comments below:


On Mon, Jan 22, 2018 at 11:36:14AM +0800, Ni, Ruiyu wrote:


On 1/18/2018 9:26 AM, Guo Heyi wrote:


On Wed, Jan 17, 2018 at 02:08:06PM +, Ard Biesheuvel wrote:


On 15 January 2018 at 14:46, Heyi Guo  wrote:


This is the draft patch for the discussion posted in
edk2-devel mailing list:
https://lists.01.org/pipermail/edk2-devel/2017-December/019289
.ht
ml

As discussed in the mailing list, we'd like to add support for
PCI address translation which is necessary for some non-x86
platforms. I also want to minimize the changes to the generic
host bridge driver and platform PciHostBridgeLib
implemetations, so additional two interfaces are added to
expose translation information of the platform. To be generic,
I add translation for each type of IO or memory resources.

The patch is still a RFC, so I only passed the build for
qemu64 and the function has not been tested yet.

Please let me know your comments about it.

Thanks.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
---
   .../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c  |  19 
   .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  53 ---
   .../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h   |   8 +-
   .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 101
++---
   MdeModulePkg/Include/Library/PciHostBridgeLib.h|  36



   5 files changed, 192 insertions(+), 25 deletions(-)

diff --git
a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
index 5b9c887..0c8371a 100644
---
a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
+++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.
+++ c
@@ -360,6 +360,16 @@ PciHostBridgeGetRootBridges (
 return 
   }

+PCI_ROOT_BRIDGE_TRANSLATION * EFIAPI
+PciHostBridgeGetTranslations (
+  UINTN *Count
+  )
+{
+  *Count = 0;
+  return NULL;
+}
+
   /**
 Free the root bridge instances array returned from
 PciHostBridgeGetRootBridges().
@@ -377,6 +387,15 @@ PciHostBridgeFreeRootBridges (
 ASSERT (Count == 1);
   }

+VOID
+EFIAPI
+PciHostBridgeFreeTranslations (
+  PCI_ROOT_BRIDGE_TRANSLATION *Translations,
+  UINTN   Count
+  )
+{
+}
+
   /**
 Inform the platform that the resource conflict happens.

diff --git
asame/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
index 1494848..835e411 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
@@ -360,18 +360,38 @@ InitializePciHostBridge (
 PCI_HOST_BRIDGE_INSTANCE*HostBridge;
 PCI_ROOT_BRIDGE_INSTANCE*RootBridge;
 PCI_ROOT_BRIDGE *RootBridges;
+  PCI_ROOT_BRIDGE_TRANSLATION *Translations;
 UINTN   RootBridgeCount;
+  UINTN   TranslationCount;
 UINTN   Index;
 PCI_ROOT_BRIDGE_APERTURE*MemApertures[4];



Wouldn't it be much better to add a 'translation' member to
PCI_ROOT_BRIDGE_APERTURE? That way, existing code just default
to a translation of 0, and all the handling of the separate
array can be dropped.


Actually my first idea was the same, but when I looked at the
implementation of PciHostBridgeLib of Ovmf, I found it a little
tedious to change the existing code in this way. We'll need to
check everywhere PCI_ROOT_BRIDGE_APERTURE or

PCI_ROOT_BRIDGE is

used, to make sure the 

Re: [edk2] [PATCH] MdePkg/SafeString: Directly return when length of source string is 0

[Ni, Ruiyu]

On 2/5/2018 11:55 AM, Yao, Jiewen wrote:

Thanks to catch this.

The root-cause of the failure is below line:

   SourceLen = StrnLenS (Source, DestMax);

We should only limit the Source string access within Length, not DestMax, if 
Length is smaller than DestMax.

0 is just one special case. Length might be 1, 2, or 3 and it triggers same 
failure.

So only checking 0 is not enough.

Reviewed the code with Ruiyu. We think using below check seems better way to 
handle all cases.

   SourceLen = StrnLenS (Source, MIN(DestMax, Length));

The check for 0 is not needed.


Patch v2 is sent out.



Thank you
Yao Jiewen


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Friday, February 2, 2018 9:43 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Gao, Liming 
Subject: Re: [edk2] [PATCH] MdePkg/SafeString: Directly return when length of
source string is 0

On 02/02/18 11:47, Ruiyu Ni wrote:

Today's implementation of [Ascii]StrnCpyS/[Ascii]StrnCatS doesn't
directly return the the length of source string is 0.

When length of source string is 0, it means the Source points to
a memory that shouldn't be deferenced at all.
So it's not proper to call StrnLenS() in such situation.
In a pool guard enabled environment, when using shell to edit an
existing file which contains empty line, the page fault is met.

The patch fixes the four library functions to align to the behavior
of non-safe version: directly return when length of source string
is 0.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Jian J Wang 
---
  MdePkg/Library/BaseLib/SafeString.c | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Library/BaseLib/SafeString.c

b/MdePkg/Library/BaseLib/SafeString.c

index 68c33e9b7b..fed818ef33 100644
--- a/MdePkg/Library/BaseLib/SafeString.c
+++ b/MdePkg/Library/BaseLib/SafeString.c
@@ -1,7 +1,7 @@
  /** @file
Safe String functions.

-  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2018, 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

@@ -317,6 +317,10 @@ StrnCpyS (
  {
UINTNSourceLen;

+  if (Length == 0) {
+return RETURN_SUCCESS;
+  }
+
ASSERT (((UINTN) Destination & BIT0) == 0);
ASSERT (((UINTN) Source & BIT0) == 0);

@@ -515,6 +519,10 @@ StrnCatS (
UINTN   CopyLen;
UINTN   SourceLen;

+  if (Length == 0) {
+return RETURN_SUCCESS;
+  }
+
ASSERT (((UINTN) Destination & BIT0) == 0);
ASSERT (((UINTN) Source & BIT0) == 0);

@@ -1894,6 +1902,10 @@ AsciiStrnCpyS (
  {
UINTNSourceLen;

+  if (Length == 0) {
+return RETURN_SUCCESS;
+  }
+
//
// 1. Neither Destination nor Source shall be a null pointer.
//
@@ -2082,6 +2094,10 @@ AsciiStrnCatS (
UINTN   CopyLen;
UINTN   SourceLen;

+  if (Length == 0) {
+return RETURN_SUCCESS;
+  }
+
//
// Let CopyLen denote the value DestMax - AsciiStrnLenS(Destination,

DestMax) upon entry to AsciiStrnCatS.

//



Reviewed-by: Laszlo Ersek 



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