Date   

Re: [Patch] MdeModulePkg LoadFileOnFv2: Correct copy right format

Tian, Feng <feng.tian@...>
 

Reviewed-by: Feng Tian <feng.tian@intel.com>

Thanks
Feng

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Liming Gao
Sent: Tuesday, August 2, 2016 10:36 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch] MdeModulePkg LoadFileOnFv2: Correct copy right format

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
index 6ef9fac..9eea50d 100644
--- a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
+++ b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
@@ -1,8 +1,8 @@
/** @file
Produce Load File Protocol for UEFI Applications in Firmware Volumes

- Copyright (c) 2011 - 2013, Intel Corporation
- All rights reserved. This program and the accompanying materials
+ Copyright (c) 2011 - 2016, Intel Corporation. All rights
+ reserved.<BR> 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
--
2.8.0.windows.1

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


Re: [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

Liming Gao
 

Ard:
This update works. It is better. For my question, I get the answer from your previous patch. Please ignore it.

Patches 3&4&6&8 are good to me. Reviewed-by: Liming Gao <liming.gao@intel.com>

Thanks
Liming

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Gao, Liming
Sent: Tuesday, August 02, 2016 10:39 AM
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org;
leif.lindholm@linaro.org; lersek@redhat.com
Subject: Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility
for module entry points

Ard:
I will verify it. And, I would ask why only X64 requires it? IA32, ARM and
AARCH64 doesn't specially handle it?

Thanks
Liming
-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Tuesday, August 02, 2016 12:12 AM
To: Gao, Liming <liming.gao@intel.com>
Cc: Shi, Steven <steven.shi@intel.com>; Zhu, Yonghong
<yonghong.zhu@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>;
edk2-devel@lists.01.org; lersek@redhat.com; leif.lindholm@linaro.org
Subject: Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden'
visibility
for module entry points

On 1 August 2016 at 17:51, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:
On 1 August 2016 at 16:56, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:
On 1 August 2016 at 16:49, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:
On 1 August 2016 at 16:18, Gao, Liming <liming.gao@intel.com> wrote:
Ard:
I don't think it is good way to define GCC_VISIBILITY_PROTECTED
and
apply it in EntryPointLib. We only need to expose _ModuleEntryPoint. It
has
been specified in LINK_FLAGS in tools_def.txt. Could we also specify its
attribute in CC_FLAGS or LINK_FLAGS in tools_def.txt?
It seems this does the trick as well

diff --git a/BaseTools/Scripts/GccBase.lds
b/BaseTools/Scripts/GccBase.lds
index 281af8a9bd33..02387d4f8d6f 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -80,3 +80,7 @@ SECTIONS {
*(COMMON)
}
}
+
+VERSION {
+ { global: _ModuleEntryPoint*; };
+};


Note that * at the end: this is necessary since _ModuleEntryPoint will
be called _ModuleEntryPoint.lto_priv.xxx in the LTO objects.
Hmm, looks like I spoke too soon. I don't know what I did wrong, but
this does not actually work.
The only alternative I can think of is to add a static non-lto object
to the tree that refers to _ModuleEntryPoint, similar to the way I
handle the ARM intrinsics in patch #5
As it turns out, the LTO linker does not need to visibility pragma to
prevent it from emitting GOT based relocations. This makes sense,
considering that the LTO linker can see that no symbol references are
ever satisfied across dynamic object boundaries. That means I could
work around this in the following way:

diff --git a/BaseTools/Conf/tools_def.template
b/BaseTools/Conf/tools_def.template
index 314adaf6bfa8..983e2fea7390 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4462,7 +4462,7 @@ DEFINE GCC49_ARM_ASLDLINK_FLAGS =
DEF(GCC48_ARM_ASLDLINK_FLAGS)
DEFINE GCC49_AARCH64_ASLDLINK_FLAGS =
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)

DEFINE GCC5_IA32_CC_FLAGS = DEF(GCC49_IA32_CC_FLAGS) -flto
-fno-builtin
-DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -flto
-fno-builtin
+DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -flto
-fno-builtin -DUSING_LTO
DEFINE GCC5_IA32_X64_DLINK_COMMON =
DEF(GCC49_IA32_X64_DLINK_COMMON)
DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS =
DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
DEFINE GCC5_IA32_X64_DLINK_FLAGS =
DEF(GCC49_IA32_X64_DLINK_FLAGS) -flto
diff --git a/MdePkg/Include/X64/ProcessorBind.h
b/MdePkg/Include/X64/ProcessorBind.h
index 666cc8e8bd16..77fab7055afc 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -27,12 +27,15 @@
#pragma pack()
#endif

-#if defined(__GNUC__) && defined(__pic__)
+#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO)
//
// Mark all symbol declarations and references as hidden, meaning they
will
// not be subject to symbol preemption. This allows the compiler to refer
to
// symbols directly using relative references rather than via the GOT, which
// contains absolute symbol addresses that are subject to runtime
relocation.
+// The LTO linker will not emit GOT based relocations anyway, so there is
no
+// need to set the pragma in that case (and doing so will cause issues of its
+// own)
//
#pragma GCC visibility push (hidden)
#endif

and I can drop this patch.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Foreign keyboard support in UEFI

Senthilarasu_ARUNACH@...
 

Hi,
Any one shed some light on supporting multi language key board support on UEFI application? Scan code received from EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL not returns value for
certain keys in German/Arabic USB keyboard. We are also not sure in mapping UEFI code from EFI_HII_DATABASE_PROTOCOL.GetKeyBoardLayOut()).


Thanks
Senthil


Re: [patch] BaseTool/UPT: Add Test Install

Zhu, Yonghong <yonghong.zhu@...>
 

Please remove the trailing whitespace when commit.

Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>

Best Regards,
Zhu Yonghong

-----Original Message-----
From: Chen, Hesheng
Sent: Friday, July 29, 2016 3:58 PM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong <yonghong.zhu@intel.com>
Subject: [patch] BaseTool/UPT: Add Test Install

Add a new function to test if a DIST file list one by one to see if they can meet the requirement of Dependency.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: hesschen <hesheng.chen@intel.com>
---
.../Source/Python/UPT/Core/DependencyRules.py | 21 ++++-
BaseTools/Source/Python/UPT/Logger/StringTable.py | 5 ++
BaseTools/Source/Python/UPT/TestInstall.py | 100 +++++++++++++++++++++
BaseTools/Source/Python/UPT/UPT.py | 16 ++++
4 files changed, 141 insertions(+), 1 deletion(-) create mode 100644 BaseTools/Source/Python/UPT/TestInstall.py

diff --git a/BaseTools/Source/Python/UPT/Core/DependencyRules.py b/BaseTools/Source/Python/UPT/Core/DependencyRules.py
index 4608ed6..ee06c53 100644
--- a/BaseTools/Source/Python/UPT/Core/DependencyRules.py
+++ b/BaseTools/Source/Python/UPT/Core/DependencyRules.py
@@ -1,7 +1,7 @@
## @file
# This file is for installed package information database operations # -# Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2011 - 2016, Intel Corporation. All rights
+reserved.<BR>
#
# This program and the accompanying materials are licensed and made available # under the terms and conditions of the BSD License which accompanies this @@ -183,6 +183,25 @@ class DependencyRules(object):
def CheckInstallDpDepexSatisfied(self, DpObj):
self.PkgsToBeDepend = [(PkgInfo[1], PkgInfo[2]) for PkgInfo in self.WsPkgList]
return self.CheckDpDepexSatisfied(DpObj)
+
+ # # Check whether multiple DP depex satisfied by current workspace for Install
+ #
+ # @param DpObjList: A distribution object list
+ # @return: True if distribution depex satisfied
+ # False else
+ #
+ def CheckTestInstallPdDepexSatisfied(self, DpObjList):
+ self.PkgsToBeDepend = [(PkgInfo[1], PkgInfo[2]) for PkgInfo in self.WsPkgList]
+ for DpObj in DpObjList:
+ if self.CheckDpDepexSatisfied(DpObj):
+ for PkgKey in DpObj.PackageSurfaceArea.keys():
+ PkgObj = DpObj.PackageSurfaceArea[PkgKey]
+ self.PkgsToBeDepend.append((PkgObj.Guid, PkgObj.Version))
+ else:
+ return False, DpObj
+
+ return True, DpObj
+

## Check whether a DP depex satisfied by current workspace
# (excluding the original distribution's packages to be replaced) for Replace diff --git a/BaseTools/Source/Python/UPT/Logger/StringTable.py b/BaseTools/Source/Python/UPT/Logger/StringTable.py
index 96f0e1c..4c42661 100644
--- a/BaseTools/Source/Python/UPT/Logger/StringTable.py
+++ b/BaseTools/Source/Python/UPT/Logger/StringTable.py
@@ -858,3 +858,8 @@ HLP_SPECIFY_PACKAGE_NAME_TO_BE_REPLACED = _(
"Specify the UEFI Distribution Package file name to be replaced") HLP_USE_GUIDED_PATHS = _(
"Install packages to the following directory path by default: <PackageName>_<PACKAGE_GUID>_<PACKAGE_VERSION>")
+HLP_TEST_INSTALL = _(
+ "Specify the UEFI Distribution Package filenames to install")
+
+MSG_TEST_INSTALL_PASS = _("All distribution package file are satisfied
+for dependence check.") MSG_TEST_INSTALL_FAIL = _("NOT all distribution
+package file are satisfied for dependence check.")
diff --git a/BaseTools/Source/Python/UPT/TestInstall.py b/BaseTools/Source/Python/UPT/TestInstall.py
new file mode 100644
index 0000000..71fe928
--- /dev/null
+++ b/BaseTools/Source/Python/UPT/TestInstall.py
@@ -0,0 +1,100 @@
+# # @file
+# Test Install distribution package
+#
+# Copyright (c) 2016, Intel Corporation. All rights reserved.<BR> # #
+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.
+#
+"""
+Test Install multiple distribution package """
+# #
+# Import Modules
+#
+from Library import GlobalData
+import Logger.Log as Logger
+from Logger import StringTable as ST
+import Logger.ToolError as TE
+from Core.DependencyRules import DependencyRules from InstallPkg import
+UnZipDp
+
+import shutil
+from traceback import format_exc
+from platform import python_version
+from sys import platform
+
+# # Tool entrance method
+#
+# This method mainly dispatch specific methods per the command line options.
+# If no error found, return zero value so the caller of this tool can
+know # if it's executed successfully or not.
+#
+# @param Options: command Options
+#
+def Main(Options=None):
+ ContentZipFile, DistFile = None, None
+ ReturnCode = 0
+
+ try:
+ DataBase = GlobalData.gDB
+ WorkspaceDir = GlobalData.gWORKSPACE
+ if not Options.DistFiles:
+ Logger.Error("TestInstallPkg", TE.OPTION_MISSING,
+ ExtraData=ST.ERR_SPECIFY_PACKAGE)
+
+ DistPkgList = []
+ for DistFile in Options.DistFiles:
+ DistPkg, ContentZipFile, __, DistFile = UnZipDp(WorkspaceDir, DistFile)
+ DistPkgList.append(DistPkg)
+
+ #
+ # check dependency
+ #
+ Dep = DependencyRules(DataBase)
+ Result = True
+ DpObj = None
+ try:
+ Result, DpObj = Dep.CheckTestInstallPdDepexSatisfied(DistPkgList)
+ except:
+ Result = False
+
+ if Result:
+ Logger.Quiet(ST.MSG_TEST_INSTALL_PASS)
+ else:
+ Logger.Quiet(ST.MSG_TEST_INSTALL_FAIL)
+
+ except TE.FatalError, XExcept:
+ ReturnCode = XExcept.args[0]
+ if Logger.GetLevel() <= Logger.DEBUG_9:
+ Logger.Quiet(ST.MSG_PYTHON_ON % (python_version(),
+ platform) + format_exc())
+
+ except Exception, x:
+ ReturnCode = TE.CODE_ERROR
+ Logger.Error(
+ "\nTestInstallPkg",
+ TE.CODE_ERROR,
+ ST.ERR_UNKNOWN_FATAL_INSTALL_ERR % Options.DistFiles,
+ ExtraData=ST.MSG_SEARCH_FOR_HELP,
+ RaiseError=False
+ )
+ Logger.Quiet(ST.MSG_PYTHON_ON % (python_version(), platform) +
+ format_exc())
+
+ finally:
+ Logger.Quiet(ST.MSG_REMOVE_TEMP_FILE_STARTED)
+ if DistFile:
+ DistFile.Close()
+ if ContentZipFile:
+ ContentZipFile.Close()
+ if GlobalData.gUNPACK_DIR:
+ shutil.rmtree(GlobalData.gUNPACK_DIR)
+ GlobalData.gUNPACK_DIR = None
+ Logger.Quiet(ST.MSG_REMOVE_TEMP_FILE_DONE)
+ if ReturnCode == 0:
+ Logger.Quiet(ST.MSG_FINISH)
+ return ReturnCode
+
diff --git a/BaseTools/Source/Python/UPT/UPT.py b/BaseTools/Source/Python/UPT/UPT.py
index 59c4a88..8dd949a 100644
--- a/BaseTools/Source/Python/UPT/UPT.py
+++ b/BaseTools/Source/Python/UPT/UPT.py
@@ -46,6 +46,7 @@ import InstallPkg
import RmPkg
import InventoryWs
import ReplacePkg
+import TestInstall
from Library.Misc import GetWorkspace
from Library import GlobalData
from Core.IpiDb import IpiDatabase
@@ -69,6 +70,9 @@ def CheckConflictOption(Opt):
Logger.Error("UPT", OPTION_CONFLICT, ExtraData=ST.ERR_I_R_EXCLUSIVE)
elif Opt.PackFileToCreate and Opt.PackFileToRemove:
Logger.Error("UPT", OPTION_CONFLICT, ExtraData=ST.ERR_C_R_EXCLUSIVE)
+ elif Opt.TestDistFiles and (Opt.PackFileToCreate or Opt.PackFileToInstall \
+ or Opt.PackFileToRemove or Opt.PackFileToReplace):
+ Logger.Error("UPT", OPTION_CONFLICT,
+ ExtraData=ST.ERR_C_R_EXCLUSIVE)

if Opt.CustomPath and Opt.UseGuidedPkgPath:
Logger.Warn("UPT", ST.WARN_CUSTOMPATH_OVERRIDE_USEGUIDEDPATH)
@@ -146,6 +150,9 @@ def Main():

Parser.add_option("--use-guided-paths", action="store_true", dest="Use_Guided_Paths", help=ST.HLP_USE_GUIDED_PATHS)

+ Parser.add_option("-j", "--test-install", action="append", type="string",
+ dest="Test_Install_Distribution_Package_Files",
+ help=ST.HLP_TEST_INSTALL)
+
Opt = Parser.parse_args()[0]

Var2Var = [
@@ -159,6 +166,7 @@ def Main():
("PackFileToReplace", Opt.Replace_Distribution_Package_File),
("PackFileToBeReplaced", Opt.Original_Distribution_Package_File),
("UseGuidedPkgPath", Opt.Use_Guided_Paths),
+ ("TestDistFiles", Opt.Test_Install_Distribution_Package_Files)
]

for Var in Var2Var:
@@ -265,6 +273,14 @@ def Main():
Opt.PackFileToReplace = AbsPath
RunModule = ReplacePkg.Main

+ elif Opt.Test_Install_Distribution_Package_Files:
+ for Dist in Opt.Test_Install_Distribution_Package_Files:
+ if not Dist.endswith('.dist'):
+ Logger.Error("TestInstall", FILE_TYPE_MISMATCH,
+ ExtraData=ST.ERR_DIST_EXT_ERROR % Dist)
+
+ setattr(Opt, 'DistFiles', Opt.Test_Install_Distribution_Package_Files)
+ RunModule = TestInstall.Main
+
else:
Parser.print_usage()
return OPTION_MISSING
--
2.7.2.windows.1


Re: [patch] BaseTool/Upt: Avoid UNI file name conflict

Zhu, Yonghong <yonghong.zhu@...>
 

Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>

Best Regards,
Zhu Yonghong

-----Original Message-----
From: Chen, Hesheng
Sent: Friday, July 29, 2016 2:09 PM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong <yonghong.zhu@intel.com>
Subject: [patch] BaseTool/Upt: Avoid UNI file name conflict

When creating a UNI file if there is a name conflict, add an index from 0 to the file name

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: hesschen <hesheng.chen@intel.com>
---
.../Source/Python/UPT/GenMetaFile/GenDecFile.py | 5 +++--
.../Source/Python/UPT/GenMetaFile/GenInfFile.py | 7 +++---
BaseTools/Source/Python/UPT/Library/String.py | 26 +++++++++++++++++++++-
3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py b/BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py
index 31abd23..d39c182 100644
--- a/BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py
+++ b/BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py
@@ -65,6 +65,7 @@ from Library.DataType import TAB_SECTION_END from Library.DataType import TAB_SPLIT import Library.DataType as DT from Library.UniClassObject import FormatUniEntry
+from Library.String import GetUniFileName

def GenPcd(Package, Content):
#
@@ -586,9 +587,9 @@ def GenPackageUNIEncodeFile(PackageObject, UniFileHeader = '', Encoding=TAB_ENCO

if not os.path.exists(os.path.dirname(PackageObject.GetFullPath())):
os.makedirs(os.path.dirname(PackageObject.GetFullPath()))
- ContainerFile = os.path.normpath(os.path.join(os.path.dirname(PackageObject.GetFullPath()),
- (PackageObject.GetBaseName() + '.uni')))

+ ContainerFile =
+ GetUniFileName(os.path.dirname(PackageObject.GetFullPath()),
+ PackageObject.GetBaseName())
+
Content = UniFileHeader + '\r\n'
Content += '\r\n'

diff --git a/BaseTools/Source/Python/UPT/GenMetaFile/GenInfFile.py b/BaseTools/Source/Python/UPT/GenMetaFile/GenInfFile.py
index a131f98..c1362e6 100644
--- a/BaseTools/Source/Python/UPT/GenMetaFile/GenInfFile.py
+++ b/BaseTools/Source/Python/UPT/GenMetaFile/GenInfFile.py
@@ -2,7 +2,7 @@
#
# This file contained the logical of transfer package object to INF files.
#
-# Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2011 - 2016, Intel Corporation. All rights
+reserved.<BR>
#
# This program and the accompanying materials are licensed and made available # under the terms and conditions of the BSD License which accompanies this @@ -41,6 +41,7 @@ import Logger.Log as Logger from Library import DataType as DT from GenMetaFile import GenMetaFileMisc from Library.UniClassObject import FormatUniEntry
+from Library.String import GetUniFileName


## Transfer Module Object to Inf files
@@ -225,8 +226,8 @@ def GenModuleUNIEncodeFile(ModuleObject, UniFileHeader='', Encoding=DT.TAB_ENCOD
return
else:
ModuleObject.UNIFlag = True
- ContainerFile = os.path.normpath(os.path.join(os.path.dirname(ModuleObject.GetFullPath()),
- (ModuleObject.GetBaseName() + '.uni')))
+ ContainerFile = GetUniFileName(os.path.dirname(ModuleObject.GetFullPath()), ModuleObject.GetBaseName())
+
if not os.path.exists(os.path.dirname(ModuleObject.GetFullPath())):
os.makedirs(os.path.dirname(ModuleObject.GetFullPath()))

diff --git a/BaseTools/Source/Python/UPT/Library/String.py b/BaseTools/Source/Python/UPT/Library/String.py
index 37ce141..05b5fb1 100644
--- a/BaseTools/Source/Python/UPT/Library/String.py
+++ b/BaseTools/Source/Python/UPT/Library/String.py
@@ -2,7 +2,7 @@
# This file is used to define common string related functions used in parsing
# process
#
-# Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.<BR>
#
# This program and the accompanying materials are licensed and made available
# under the terms and conditions of the BSD License which accompanies this
@@ -957,3 +957,27 @@ def IsMatchArch(Arch1, Arch2):
return True

return False
+
+# Search all files in FilePath to find the FileName with the largest index
+# Return the FileName with index +1 under the FilePath
+#
+def GetUniFileName(FilePath, FileName):
+ Files = os.listdir(FilePath)
+ LargestIndex = -1
+ for File in Files:
+ if File.upper().startswith(FileName.upper()) and File.upper().endswith('.UNI'):
+ Index = File.upper().replace(FileName.upper(), '').replace('.UNI', '')
+ if Index:
+ try:
+ Index = int(Index)
+ except Exception:
+ Index = -1
+ else:
+ Index = 0
+ if Index > LargestIndex:
+ LargestIndex = Index + 1
+
+ if LargestIndex > -1:
+ return os.path.normpath(os.path.join(FilePath, FileName + str(LargestIndex) + '.uni'))
+ else:
+ return os.path.normpath(os.path.join(FilePath, FileName + '.uni'))
--
2.7.2.windows.1


Re: [patch 2/2] BaseTool/Upt: Add support for Private

Zhu, Yonghong <yonghong.zhu@...>
 

Please remove the trailing whitespace when commit.

Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>


Best Regards,
Zhu Yonghong

-----Original Message-----
From: Chen, Hesheng
Sent: Friday, July 29, 2016 10:31 AM
To: edk2-devel@lists.01.org
Cc: Zhu, Yonghong <yonghong.zhu@intel.com>
Subject: [patch 2/2] BaseTool/Upt: Add support for Private

Support new syntax in package DEC file as below:
[Includes.Common.Private]
[Ppis.Common.Private]
[Guids.Common.Private]
[Protocols.Common.Private]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: hesschen <hesheng.chen@intel.com>
---
.../Source/Python/UPT/GenMetaFile/GenDecFile.py | 9 +++++++-
BaseTools/Source/Python/UPT/Library/DataType.py | 4 +++-
.../Source/Python/UPT/Library/UniClassObject.py | 16 +++++++-------
BaseTools/Source/Python/UPT/Parser/DecParser.py | 25 ++++++++++++++++++++--
.../Python/UPT/PomAdapter/DecPomAlignment.py | 11 +++++++++-
5 files changed, 52 insertions(+), 13 deletions(-)

diff --git a/BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py b/BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py
index f22363b..31abd23 100644
--- a/BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py
+++ b/BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py
@@ -2,7 +2,7 @@
#
# This file contained the logical of transfer package object to DEC files.
#
-# Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2011 - 2016, Intel Corporation. All rights
+reserved.<BR>
#
# This program and the accompanying materials are licensed and made available # under the terms and conditions of the BSD License which accompanies this @@ -63,6 +63,7 @@ from Library.DataType import TAB_PCD_ERROR from Library.DataType import TAB_SECTION_START from Library.DataType import TAB_SECTION_END from Library.DataType import TAB_SPLIT
+import Library.DataType as DT
from Library.UniClassObject import FormatUniEntry

def GenPcd(Package, Content):
@@ -487,6 +488,12 @@ def PackageToDec(Package, DistHeader = None):
if UserExtension.GetUserID() == TAB_BINARY_HEADER_USERID and \
UserExtension.GetIdentifier() == TAB_BINARY_HEADER_IDENTIFIER:
continue
+
+ # Generate Private Section first
+ if UserExtension.GetUserID() == DT.TAB_INTEL and UserExtension.GetIdentifier() == DT.TAB_PRIVATE:
+ Content += '\n' + UserExtension.GetStatement()
+ continue
+
Statement = UserExtension.GetStatement()
if not Statement:
continue
diff --git a/BaseTools/Source/Python/UPT/Library/DataType.py b/BaseTools/Source/Python/UPT/Library/DataType.py
index 8449dc8..c151be3 100644
--- a/BaseTools/Source/Python/UPT/Library/DataType.py
+++ b/BaseTools/Source/Python/UPT/Library/DataType.py
@@ -1,7 +1,7 @@
## @file
# This file is used to define class for data type structure # -# Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2011 - 2016, Intel Corporation. All rights
+reserved.<BR>
#
# This program and the accompanying materials are licensed and made available # under the terms and conditions of the BSD License which accompanies this @@ -680,6 +680,8 @@ TAB_DEFINE = 'DEFINE'
TAB_NMAKE = 'Nmake'
TAB_USER_EXTENSIONS = 'UserExtensions'
TAB_INCLUDE = '!include'
+TAB_PRIVATE = 'Private'
+TAB_INTEL = 'Intel'

#
# Common Define
diff --git a/BaseTools/Source/Python/UPT/Library/UniClassObject.py b/BaseTools/Source/Python/UPT/Library/UniClassObject.py
index 1e73d3e..27804cc 100644
--- a/BaseTools/Source/Python/UPT/Library/UniClassObject.py
+++ b/BaseTools/Source/Python/UPT/Library/UniClassObject.py
@@ -328,11 +328,11 @@ class UniFileClassObject(object):
Lang = distutils.util.split_quoted((Line.split(u"//")[0]))
if len(Lang) != 3:
try:
- FileIn = codecs.open(File.Path, mode='rb', encoding='utf_8').read()
+ FileIn = codecs.open(File.Path, mode='rb',
+ encoding='utf_8').readlines()
except UnicodeError, Xstr:
- FileIn = codecs.open(File.Path, mode='rb', encoding='utf_16').read()
+ FileIn = codecs.open(File.Path, mode='rb',
+ encoding='utf_16').readlines()
except UnicodeError, Xstr:
- FileIn = codecs.open(File.Path, mode='rb', encoding='utf_16_le').read()
+ FileIn = codecs.open(File.Path, mode='rb',
+ encoding='utf_16_le').readlines()
except:
EdkLogger.Error("Unicode File Parser",
ToolError.FILE_OPEN_FAILURE, @@ -437,7 +437,7 @@ class UniFileClassObject(object):
# ExtraData='The file %s is either invalid UTF-16LE or it is missing the BOM.' % File.Path)

try:
- FileIn = codecs.open(File.Path, mode='rb', encoding='utf_8').read()
+ FileIn = codecs.open(File.Path, mode='rb',
+ encoding='utf_8').readlines()
except UnicodeError, Xstr:
FileIn = codecs.open(File.Path, mode='rb', encoding='utf_16').readlines()
except UnicodeError:
@@ -579,9 +579,9 @@ class UniFileClassObject(object):
#
if Line.startswith(u'"'):
if StringEntryExistsFlag == 2:
- EdkLogger.Error("Unicode File Parser", ToolError.FORMAT_INVALID,
+ EdkLogger.Error("Unicode File Parser",
+ ToolError.FORMAT_INVALID,
Message=ST.ERR_UNIPARSE_LINEFEED_UP_EXIST % Line, ExtraData=File.Path)
-
+
StringEntryExistsFlag = 1
if not Line.endswith('"'):
EdkLogger.Error("Unicode File Parser", ToolError.FORMAT_INVALID, @@ -589,7 +589,7 @@ class UniFileClassObject(object):
% (LineCount, File.Path))
elif Line.startswith(u'#language'):
if StringEntryExistsFlag == 2:
- EdkLogger.Error("Unicode File Parser", ToolError.FORMAT_INVALID,
+ EdkLogger.Error("Unicode File Parser",
+ ToolError.FORMAT_INVALID,
Message=ST.ERR_UNI_MISS_STRING_ENTRY % Line, ExtraData=File.Path)
StringEntryExistsFlag = 0
else:
@@ -1050,7 +1050,7 @@ class UniFileClassObject(object):
ToolError.FILE_NOT_FOUND,
ExtraData=FilaPath)
try:
- FileIn = codecs.open(FilaPath, mode='rb', encoding='utf_8').read()
+ FileIn = codecs.open(FilaPath, mode='rb',
+ encoding='utf_8').readlines()
except UnicodeError, Xstr:
FileIn = codecs.open(FilaPath, mode='rb', encoding='utf_16').readlines()
except UnicodeError:
diff --git a/BaseTools/Source/Python/UPT/Parser/DecParser.py b/BaseTools/Source/Python/UPT/Parser/DecParser.py
index 23d1ed4..e6658a9 100644
--- a/BaseTools/Source/Python/UPT/Parser/DecParser.py
+++ b/BaseTools/Source/Python/UPT/Parser/DecParser.py
@@ -1,7 +1,7 @@
## @file
# This file is used to parse DEC file. It will consumed by DecParser # -# Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2011 - 2016, Intel Corporation. All rights
+reserved.<BR>
#
# This program and the accompanying materials are licensed and made available # under the terms and conditions of the BSD License which accompanies this @@ -742,7 +742,26 @@ class Dec(_DecBase, _DecComments):
except BaseException:
Logger.Error(TOOL_NAME, FILE_OPEN_FAILURE, File=DecFile,
ExtraData=ST.ERR_DECPARSE_FILEOPEN % DecFile)
- RawData = FileContent(DecFile, Content)
+
+ #
+ # Pre-parser for Private section
+ #
+ self._Private = ''
+ __IsFoundPrivate = False
+ NewContent = []
+ for Line in Content:
+ Line = Line.strip()
+ if Line.startswith(DT.TAB_SECTION_START) and Line.endswith(DT.TAB_PRIVATE + DT.TAB_SECTION_END):
+ __IsFoundPrivate = True
+ if Line.startswith(DT.TAB_SECTION_START) and Line.endswith(DT.TAB_SECTION_END)\
+ and not Line.endswith(DT.TAB_PRIVATE + DT.TAB_SECTION_END):
+ __IsFoundPrivate = False
+ if __IsFoundPrivate:
+ self._Private += Line + '\r'
+ if not __IsFoundPrivate:
+ NewContent.append(Line + '\r')
+
+ RawData = FileContent(DecFile, NewContent)

_DecComments.__init__(self)
_DecBase.__init__(self, RawData) @@ -1060,3 +1079,5 @@ class Dec(_DecBase, _DecComments):
return self._Define.GetDataObject().GetPackageVersion()
def GetPackageUniFile(self):
return self._Define.GetDataObject().GetPackageUniFile()
+ def GetPrivateSections(self):
+ return self._Private
diff --git a/BaseTools/Source/Python/UPT/PomAdapter/DecPomAlignment.py b/BaseTools/Source/Python/UPT/PomAdapter/DecPomAlignment.py
index 11b0359..88edf35 100644
--- a/BaseTools/Source/Python/UPT/PomAdapter/DecPomAlignment.py
+++ b/BaseTools/Source/Python/UPT/PomAdapter/DecPomAlignment.py
@@ -1,7 +1,7 @@
## @file DecPomAlignment.py
# This file contained the adapter for convert INF parser object to POM Object # -# Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2011 - 2016, Intel Corporation. All rights
+reserved.<BR>
#
# This program and the accompanying materials are licensed and made available # under the terms and conditions of the BSD License which accompanies this @@ -63,6 +63,7 @@ from Library.DataType import TAB_STR_TOKENHELP from Library.DataType import TAB_STR_TOKENERR from Library.DataType import TAB_HEX_START from Library.DataType import TAB_SPLIT
+import Library.DataType as DT
from Library.CommentParsing import ParseHeaderCommentSection from Library.CommentParsing import ParseGenericComment from Library.CommentParsing import ParseDecPcdGenericComment @@ -221,6 +222,14 @@ class DecPomAlignment(PackageObject):
self.SetUserExtensionList(
self.GetUserExtensionList() + [UserExtension]
)
+
+ # Add Private sections to UserExtension
+ if self.DecParser.GetPrivateSections():
+ PrivateUserExtension = UserExtensionObject()
+ PrivateUserExtension.SetStatement(self.DecParser.GetPrivateSections())
+ PrivateUserExtension.SetIdentifier(DT.TAB_PRIVATE)
+ PrivateUserExtension.SetUserID(DT.TAB_INTEL)
+ self.SetUserExtensionList(self.GetUserExtensionList() +
+ [PrivateUserExtension])

## Generate miscellaneous files on DEC file
#
--
2.7.2.windows.1


Re: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Long, Qin <qin.long@...>
 

The supported cipher suite should be one self-defined scope (I am not sure if any minimal sets for TLS from RFC/Spec. Need to double-check). It's one typical cipher negotiation process in TLS protocol. Tell the peer what I support, what you support, then agree one set supported by both.
We can add other cipher supports according to the real requirements. It's OK to remove those unsupported cipher suite for this phase.


Best Regards & Thanks,
LONG, Qin

-----Original Message-----
From: Wu, Jiaxin
Sent: Tuesday, August 02, 2016 10:03 AM
To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Gao, Liming
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with
the standardized one

Thomas,

Thanks your effort to test the new ciphers, can you provide the info which
one is unsupported currently?

As Qin's comments, "we'd better to keep the current supported cipher suite
for our UEFI- TLS enabling". If so, I agree to remove the unsupported one in
TlsCipherMappingTable instead of changing the current openssl configuration.
If dsa /idea is required in future, then we can consider how to enable the
configuration.

So, can you provide the patch to remove the unsupported one in
TlsCipherMappingTable?


Thanks,
Jiaxin



-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Tuesday, August 2, 2016 9:51 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Long, Qin <qin.long@intel.com>;
edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one


Hi Jiaxin,

It sounds like we both agree that TlsCipherMappingTable is the list
of what UEFI officially supports. If it is advertised in
TlsCipherMappingTable then OpenSSL needs to support it.

My proposal of removing no-dsa / no-idea and adding weak-ciphers
is
specifically aimed to syncing how OpenSSL is configured/built to what
is in TlsCipherMappingTable. I was busy last week testing out the new
ciphers and realized a few were not even getting configured in OpenSSL.

Thomas

-----Original Message-----
From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com]
Sent: Monday, August 1, 2016 8:34 PM
To: Palmer, Thomas <thomas.palmer@hpe.com>; Long, Qin
<qin.long@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Hi Thomas,

Since the Tls1.h is used to hold the standardized definitions, openssl
part is not taken into consideration. The Cipher Suites added in
Tls1.h only refers to
A.5 of rfc-2246, rfc-4346 and rfc-5246. The criteria is removing all
the limited/insecurity/deprecated ones that specified in RFC -- "Note
that this mode is vulnerable to man-in-the middle attacks and is
therefore deprecated." I know the IDEA and DES cipher suites are also
deprecated in TLS1.2, but it does means to TLS1.1. So, some of them are
still kept in Tls1.h.

As for the TlsCipherMappingTable, it takes on the link between Tls1.h
defined cipher suites and openssl supported cipher suites. If we
eliminate the factors of configuration, I believe the cipher suites in
TlsCipherMappingTable should be implemented in OpenSSL lib. I haven't
check them one by one but openssl official document is referred @
https://www.openssl.org/docs/manmaster/apps/ciphers.html, which
gives
the lists of TLS cipher suites names from the relevant specification
and their OpenSSL equivalents.

If the cipher suites in Tls1.h is not found in TlsCipherMappingTable,
EFI_UNSUPPORTED will be returned. I think it's reasonable.

Thanks,
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
Of Palmer, Thomas
Sent: Tuesday, August 2, 2016 5:46 AM
To: Long, Qin <qin.long@intel.com>; Wu, Jiaxin
<jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin / Qin,


I'm unaware of what criteria is required for a cipher to be in this
TlsCipherMappingTable. I had presumed that it would be b/c UEFI
supported the cipher for TLS operation. If unsupported ciphers are
allowed ... then logically wouldn't we need to add all ciphers?
What advantage do we gain by having an entry in this table but not
actually use
the cipher in communication?

Currently TlsGetCipherString is the only means we have to validate
the cipher string. If a cipher is in the table but not in OpenSSL
lib, then we will provide imperfect feedback if the unsupported
cipher is buried in a list of supported ciphers. OpenSSL will
simply use only the ciphers it supports and quietly drop the unsupported
cipher.
A user that inspects the list of set ciphers would be curious why a
certain
cipher was being "dropped" /
"filtered". However, if TlsGetCipherString sees that the cipher is not in
our
mapping table the TlsSetCipherList function will return immediate
feedback.

I'm not enthralled with supporting weak/idea ciphers either. I
would vouch for us removing those ciphers from
TlsCipherMappingTable. It is not our responsibility to document the
IANA/Description string description in code.

This document
(http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52
r1
.pdf) would be a good list for initial cipher support. We have some
of the ciphers on the list already. Here is the sorted list:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CCM17
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CCM
TLS_RSA_WITH_AES_256_GCM_SHA384

Thomas

-----Original Message-----
From: Long, Qin [mailto:qin.long@intel.com]
Sent: Sunday, July 31, 2016 8:48 PM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

I personally prefer to keep the current supported cipher suite for
our
UEFI- TLS enabling. We can have the full RFC definitions, and
platform specific cipher sets for validation now. It's better to
maintain one minimal scope in this phase.

"enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the
recommendation for hardening SSL communications.
For other ciphers (idea, dsa, etc), we can enable them step-by-step
depending on the real requirements.


Best Regards & Thanks,
LONG, Qin

-----Original Message-----
From: Wu, Jiaxin
Sent: Monday, August 01, 2016 9:23 AM
To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Gao, Liming
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Thomas,
I agree some of them are not supported due to the UEFI OpenSSL
configuration, but it doesn't affect those mapping relationship
added in the patch. So, I have no strong opinion whether to
support it by modifying the current OpenSSL configuration. Since
Qin is the OpenSSL expert, I'd like to hear his views.

Qin,
What's your opinion?

Thanks.
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
Behalf Of Palmer, Thomas
Sent: Saturday, July 30, 2016 6:03 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan
<siyuan.fu@intel.com>; Gao, Liming <liming.gao@intel.com>; Long,
Qin <qin.long@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the
TLS definitions with the standardized one

Jiaxin,

UEFI's OpenSSL library does not support all the ciphers that
were added in your patch due to the UEFI configuration. We need
to remove
"no- idea" and "no-dsa" from the process_files.sh and add
"enable-weak-ssl- ciphers"

While we are modifying process_files.sh, we can remove "no-
pqueue"
from process_files.sh so that OpensslLib.inf is in sync.

I can send out a patch to do so if you wish.

Thomas

-----Original Message-----
From: Jiaxin Wu [mailto:jiaxin.wu@intel.com]
Sent: Thursday, July 14, 2016 12:51 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao <liming.gao@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; Long Qin <qin.long@intel.com>; Ye Ting
<ting.ye@intel.com>; Fu Siyuan <siyuan.fu@intel.com>; Wu Jiaxin
<jiaxin.wu@intel.com>
Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

The series patches are used to replace the TLS definitions with
the standardized one. In addition, more TLS cipher suite mapping
between Cipher Suite definitions and OpenSSL-used Cipher Suite
name
are added.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>

Jiaxin Wu (4):
MdePkg: Add a header to standardize TLS definitions
CryptoPkg: Add more TLS cipher suite mapping
NetworkPkg/TlsDxe: Replace the definitions with the
standardized
one
NetworkPkg/HttpDxe: Replace the definitions with the
standardized one

CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++-------
--
---
--
--
MdePkg/Include/IndustryStandard/Tls1.h | 93 +
NetworkPkg/HttpDxe/HttpDriver.h | 2 +
NetworkPkg/HttpDxe/HttpProto.c | 12 +-
NetworkPkg/HttpDxe/HttpsSupport.c | 22 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 44 -
NetworkPkg/TlsDxe/TlsImpl.c | 56 +-
NetworkPkg/TlsDxe/TlsImpl.h | 30 +-
NetworkPkg/TlsDxe/TlsProtocol.c | 2 +-
9 files changed, 1945 insertions(+), 1901 deletions(-) create
mode
100644 MdePkg/Include/IndustryStandard/Tls1.h

--
1.9.5.msysgit.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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [PATCH] MdePkg: move to 'hidden' visibility for all symbols under GCC/X64

Liming Gao
 

Reviewed-by: Liming Gao <liming.gao@intel.com>

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Monday, August 01, 2016 2:57 PM
To: Shi, Steven <steven.shi@intel.com>; Zhu, Yonghong
<yonghong.zhu@intel.com>; Gao, Liming <liming.gao@intel.com>; Justen,
Jordan L <jordan.l.justen@intel.com>; edk2-devel@lists.01.org
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH] MdePkg: move to 'hidden' visibility for all symbols under
GCC/X64

When using GCC to build for X64, we switched to the position independent
small code model, which is much more efficient in terms of code generation
and runtime relocation footprint, and produces binaries that can execute
correctly from any offset.

However, the PIC routines are by default geared towards hosted binaries
containing symbol references that may resolve to definitions in other
dynamic objects, and for this reason, external symbol references are
indirected via a GOT entry by default (which also results in a .reloc fixup
entry) unless we annotate them.

For this reason, we introduced the 'protected' visibility annotation for
all symbol definitions and references, by setting the GCC visibility
pragma. However, as it turns out, this is not sufficient for all versions
of GCC, and in some cases (GCC 5.x using the GCC49 toolchain tag), may
still result in GOT based relocations.

So switch to 'hidden' visibility instead, which is slightly stronger, and
fixes this issue for the versions of GCC that exhibit the problem.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
MdePkg/Include/X64/ProcessorBind.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/X64/ProcessorBind.h
b/MdePkg/Include/X64/ProcessorBind.h
index a4aad3e524e8..666cc8e8bd16 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -29,12 +29,12 @@

#if defined(__GNUC__) && defined(__pic__)
//
-// Mark all symbol declarations and references as protected, meaning they
will
+// Mark all symbol declarations and references as hidden, meaning they will
// not be subject to symbol preemption. This allows the compiler to refer to
// symbols directly using relative references rather than via the GOT, which
// contains absolute symbol addresses that are subject to runtime relocation.
//
-#pragma GCC visibility push (protected)
+#pragma GCC visibility push (hidden)
#endif

#if defined(__INTEL_COMPILER)
--
2.7.4


Re: [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility for module entry points

Liming Gao
 

Ard:
I will verify it. And, I would ask why only X64 requires it? IA32, ARM and AARCH64 doesn't specially handle it?

Thanks
Liming

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Tuesday, August 02, 2016 12:12 AM
To: Gao, Liming <liming.gao@intel.com>
Cc: Shi, Steven <steven.shi@intel.com>; Zhu, Yonghong
<yonghong.zhu@intel.com>; Justen, Jordan L <jordan.l.justen@intel.com>;
edk2-devel@lists.01.org; lersek@redhat.com; leif.lindholm@linaro.org
Subject: Re: [edk2] [PATCH v5 7/8] MdePkg GCC/X64: avoid 'hidden' visibility
for module entry points

On 1 August 2016 at 17:51, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:
On 1 August 2016 at 16:56, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:
On 1 August 2016 at 16:49, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:
On 1 August 2016 at 16:18, Gao, Liming <liming.gao@intel.com> wrote:
Ard:
I don't think it is good way to define GCC_VISIBILITY_PROTECTED and
apply it in EntryPointLib. We only need to expose _ModuleEntryPoint. It has
been specified in LINK_FLAGS in tools_def.txt. Could we also specify its
attribute in CC_FLAGS or LINK_FLAGS in tools_def.txt?
It seems this does the trick as well

diff --git a/BaseTools/Scripts/GccBase.lds
b/BaseTools/Scripts/GccBase.lds
index 281af8a9bd33..02387d4f8d6f 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -80,3 +80,7 @@ SECTIONS {
*(COMMON)
}
}
+
+VERSION {
+ { global: _ModuleEntryPoint*; };
+};


Note that * at the end: this is necessary since _ModuleEntryPoint will
be called _ModuleEntryPoint.lto_priv.xxx in the LTO objects.
Hmm, looks like I spoke too soon. I don't know what I did wrong, but
this does not actually work.
The only alternative I can think of is to add a static non-lto object
to the tree that refers to _ModuleEntryPoint, similar to the way I
handle the ARM intrinsics in patch #5
As it turns out, the LTO linker does not need to visibility pragma to
prevent it from emitting GOT based relocations. This makes sense,
considering that the LTO linker can see that no symbol references are
ever satisfied across dynamic object boundaries. That means I could
work around this in the following way:

diff --git a/BaseTools/Conf/tools_def.template
b/BaseTools/Conf/tools_def.template
index 314adaf6bfa8..983e2fea7390 100644
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4462,7 +4462,7 @@ DEFINE GCC49_ARM_ASLDLINK_FLAGS =
DEF(GCC48_ARM_ASLDLINK_FLAGS)
DEFINE GCC49_AARCH64_ASLDLINK_FLAGS =
DEF(GCC48_AARCH64_ASLDLINK_FLAGS)

DEFINE GCC5_IA32_CC_FLAGS = DEF(GCC49_IA32_CC_FLAGS) -flto
-fno-builtin
-DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -flto
-fno-builtin
+DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) -flto
-fno-builtin -DUSING_LTO
DEFINE GCC5_IA32_X64_DLINK_COMMON =
DEF(GCC49_IA32_X64_DLINK_COMMON)
DEFINE GCC5_IA32_X64_ASLDLINK_FLAGS =
DEF(GCC49_IA32_X64_ASLDLINK_FLAGS)
DEFINE GCC5_IA32_X64_DLINK_FLAGS =
DEF(GCC49_IA32_X64_DLINK_FLAGS) -flto
diff --git a/MdePkg/Include/X64/ProcessorBind.h
b/MdePkg/Include/X64/ProcessorBind.h
index 666cc8e8bd16..77fab7055afc 100644
--- a/MdePkg/Include/X64/ProcessorBind.h
+++ b/MdePkg/Include/X64/ProcessorBind.h
@@ -27,12 +27,15 @@
#pragma pack()
#endif

-#if defined(__GNUC__) && defined(__pic__)
+#if defined(__GNUC__) && defined(__pic__) && !defined(USING_LTO)
//
// Mark all symbol declarations and references as hidden, meaning they will
// not be subject to symbol preemption. This allows the compiler to refer to
// symbols directly using relative references rather than via the GOT, which
// contains absolute symbol addresses that are subject to runtime relocation.
+// The LTO linker will not emit GOT based relocations anyway, so there is no
+// need to set the pragma in that case (and doing so will cause issues of its
+// own)
//
#pragma GCC visibility push (hidden)
#endif

and I can drop this patch.


[Patch] MdeModulePkg UefiBootManagerLib: Fix VS2012 build failure

Liming Gao
 

Initialize local variable Description as NULL first.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index d5818ca..ecd0ae3 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2213,6 +2213,7 @@ BmRegisterBootManagerMenu (
UINTN DataSize;

DevicePath = NULL;
+ Description = NULL;
//
// Try to find BootMenuApp from LoadFile protocol
//
--
2.8.0.windows.1


[Patch] MdeModulePkg LoadFileOnFv2: Correct copy right format

Liming Gao
 

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
---
MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
index 6ef9fac..9eea50d 100644
--- a/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
+++ b/MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c
@@ -1,8 +1,8 @@
/** @file
Produce Load File Protocol for UEFI Applications in Firmware Volumes

- Copyright (c) 2011 - 2013, Intel Corporation
- All rights reserved. This program and the accompanying materials
+ Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.<BR>
+ 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
--
2.8.0.windows.1


Re: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Wu, Jiaxin <jiaxin.wu@...>
 

Thomas,

Thanks your effort to test the new ciphers, can you provide the info which one is unsupported currently?

As Qin's comments, "we'd better to keep the current supported cipher suite for our UEFI- TLS enabling". If so, I agree to remove the unsupported one in TlsCipherMappingTable instead of changing the current openssl configuration. If dsa /idea is required in future, then we can consider how to enable the configuration.

So, can you provide the patch to remove the unsupported one in TlsCipherMappingTable?


Thanks,
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Tuesday, August 2, 2016 9:51 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Long, Qin <qin.long@intel.com>;
edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao,
Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one


Hi Jiaxin,

It sounds like we both agree that TlsCipherMappingTable is the list of
what UEFI officially supports. If it is advertised in TlsCipherMappingTable
then OpenSSL needs to support it.

My proposal of removing no-dsa / no-idea and adding weak-ciphers
is specifically aimed to syncing how OpenSSL is configured/built to what is in
TlsCipherMappingTable. I was busy last week testing out the new ciphers
and realized a few were not even getting configured in OpenSSL.

Thomas

-----Original Message-----
From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com]
Sent: Monday, August 1, 2016 8:34 PM
To: Palmer, Thomas <thomas.palmer@hpe.com>; Long, Qin
<qin.long@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao,
Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with
the standardized one

Hi Thomas,

Since the Tls1.h is used to hold the standardized definitions, openssl part is
not taken into consideration. The Cipher Suites added in Tls1.h only refers to
A.5 of rfc-2246, rfc-4346 and rfc-5246. The criteria is removing all the
limited/insecurity/deprecated ones that specified in RFC -- "Note that this
mode is vulnerable to man-in-the middle attacks and is therefore
deprecated." I know the IDEA and DES cipher suites are also deprecated in
TLS1.2, but it does means to TLS1.1. So, some of them are still kept in Tls1.h.

As for the TlsCipherMappingTable, it takes on the link between Tls1.h
defined cipher suites and openssl supported cipher suites. If we eliminate
the factors of configuration, I believe the cipher suites in
TlsCipherMappingTable should be implemented in OpenSSL lib. I haven't
check them one by one but openssl official document is referred @
https://www.openssl.org/docs/manmaster/apps/ciphers.html, which gives
the lists of TLS cipher suites names from the relevant specification and their
OpenSSL equivalents.

If the cipher suites in Tls1.h is not found in TlsCipherMappingTable,
EFI_UNSUPPORTED will be returned. I think it's reasonable.

Thanks,
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Tuesday, August 2, 2016 5:46 AM
To: Long, Qin <qin.long@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>;
edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin / Qin,


I'm unaware of what criteria is required for a cipher to be in this
TlsCipherMappingTable. I had presumed that it would be b/c UEFI
supported the cipher for TLS operation. If unsupported ciphers are
allowed ... then logically wouldn't we need to add all ciphers? What
advantage do we gain by having an entry in this table but not actually use
the cipher in communication?

Currently TlsGetCipherString is the only means we have to validate
the cipher string. If a cipher is in the table but not in OpenSSL
lib, then we will provide imperfect feedback if the unsupported cipher
is buried in a list of supported ciphers. OpenSSL will simply use
only the ciphers it supports and quietly drop the unsupported cipher.
A user that inspects the list of set ciphers would be curious why a certain
cipher was being "dropped" /
"filtered". However, if TlsGetCipherString sees that the cipher is not in our
mapping table the TlsSetCipherList function will return immediate feedback.

I'm not enthralled with supporting weak/idea ciphers either. I would
vouch for us removing those ciphers from TlsCipherMappingTable. It is
not our responsibility to document the IANA/Description string
description in code.

This document
(http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1
.pdf) would be a good list for initial cipher support. We have some
of the ciphers on the list already. Here is the sorted list:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CCM17
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CCM
TLS_RSA_WITH_AES_256_GCM_SHA384

Thomas

-----Original Message-----
From: Long, Qin [mailto:qin.long@intel.com]
Sent: Sunday, July 31, 2016 8:48 PM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

I personally prefer to keep the current supported cipher suite for our
UEFI- TLS enabling. We can have the full RFC definitions, and platform
specific cipher sets for validation now. It's better to maintain one
minimal scope in this phase.

"enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the
recommendation for hardening SSL communications.
For other ciphers (idea, dsa, etc), we can enable them step-by-step
depending on the real requirements.


Best Regards & Thanks,
LONG, Qin

-----Original Message-----
From: Wu, Jiaxin
Sent: Monday, August 01, 2016 9:23 AM
To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Gao, Liming
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Thomas,
I agree some of them are not supported due to the UEFI OpenSSL
configuration, but it doesn't affect those mapping relationship
added in the patch. So, I have no strong opinion whether to support
it by modifying the current OpenSSL configuration. Since Qin is the
OpenSSL expert, I'd like to hear his views.

Qin,
What's your opinion?

Thanks.
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
Behalf Of Palmer, Thomas
Sent: Saturday, July 30, 2016 6:03 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan
<siyuan.fu@intel.com>; Gao, Liming <liming.gao@intel.com>; Long,
Qin <qin.long@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin,

UEFI's OpenSSL library does not support all the ciphers that were
added in your patch due to the UEFI configuration. We need to
remove
"no- idea" and "no-dsa" from the process_files.sh and add
"enable-weak-ssl- ciphers"

While we are modifying process_files.sh, we can remove "no-
pqueue"
from process_files.sh so that OpensslLib.inf is in sync.

I can send out a patch to do so if you wish.

Thomas

-----Original Message-----
From: Jiaxin Wu [mailto:jiaxin.wu@intel.com]
Sent: Thursday, July 14, 2016 12:51 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao <liming.gao@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; Long Qin <qin.long@intel.com>; Ye Ting
<ting.ye@intel.com>; Fu Siyuan <siyuan.fu@intel.com>; Wu Jiaxin
<jiaxin.wu@intel.com>
Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

The series patches are used to replace the TLS definitions with
the standardized one. In addition, more TLS cipher suite mapping
between Cipher Suite definitions and OpenSSL-used Cipher Suite name
are added.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>

Jiaxin Wu (4):
MdePkg: Add a header to standardize TLS definitions
CryptoPkg: Add more TLS cipher suite mapping
NetworkPkg/TlsDxe: Replace the definitions with the standardized
one
NetworkPkg/HttpDxe: Replace the definitions with the
standardized one

CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++---------
---
--
--
MdePkg/Include/IndustryStandard/Tls1.h | 93 +
NetworkPkg/HttpDxe/HttpDriver.h | 2 +
NetworkPkg/HttpDxe/HttpProto.c | 12 +-
NetworkPkg/HttpDxe/HttpsSupport.c | 22 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 44 -
NetworkPkg/TlsDxe/TlsImpl.c | 56 +-
NetworkPkg/TlsDxe/TlsImpl.h | 30 +-
NetworkPkg/TlsDxe/TlsProtocol.c | 2 +-
9 files changed, 1945 insertions(+), 1901 deletions(-) create
mode
100644 MdePkg/Include/IndustryStandard/Tls1.h

--
1.9.5.msysgit.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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [PATCH] add top-level .gitattributes file, dealing with .depex

Liming Gao
 

Tim:
FDF syntax doesn't support .ffs.

Thanks
Liming

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Tim Lewis
Sent: Tuesday, August 02, 2016 1:03 AM
To: Justen, Jordan L <jordan.l.justen@intel.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>;
Kinney, Michael D <michael.d.kinney@intel.com>
Cc: edk2-devel@lists.01.org; Laszlo Ersek <lersek@redhat.com>; Andrew Fish
<afish@apple.com>
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file, dealing
with .depex

Jordan --

As a company that delivers a lot of mixed binary/source builds, we
see .depex as actually important for ease of maintenance. The .fdf syntax
can work, as you mention, but it is actually requires an extra step for those of
us maintaining binary modules. Why? Because .depex is derived from the .inf
of the module *and* the .infs of all library instances which the module is
linked against. While this can be tracked down using a build report, it is
problematic and likely to introduce hard to track bugs. Since .depex is a
normal product of the source build process, it is convenient.

As for the open-source, I would only note that it is used only in the exact
same cases where the module itself is delivered as a binary. In fact, it could
be checked in to the tree as a complete FFS file (no .efi at all).

Thanks,

Tim




-----Original Message-----
From: Jordan Justen [mailto:jordan.l.justen@intel.com]
Sent: Monday, August 01, 2016 12:03 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Leif Lindholm
<leif.lindholm@linaro.org>; Tim Lewis <tim.lewis@insyde.com>; Kinney,
Michael D <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org; Andrew Fish
<afish@apple.com>
Subject: RE: [edk2] [PATCH] add top-level .gitattributes file, dealing
with .depex

On 2016-07-31 16:52:23, Kinney, Michael D wrote:
Jordan,

UEFI Drivers distributed as binaries do not need depex sections.

PI modules distributed as binaries do require a .depex binary.
They may require a depex, but, as mentioned below, they can also add it
directly in the .fdf. As it stands, apparently we have 1 .depex file in the tree,
and it is unused.

Aside from this, under what conditions would we take such binaries into the
EDK II tree? Today we have the ShellPkg and FatPkg binaries in the EDK II tree,
but we recently discussed removing even those.

For an open source project, I think it is best to not have pre-built binaries,
unless there is some very compelling reason. Previously there was some
license funniness on FatPkg, but now that is gone. If it took an hour to build
FatPkg, then that might also be something to discuss. :)

I don't think adding the .gitattributes is really a problem, aside from the fact
that it implies that we might actually have a reason to add a .depex file to the
source tree.

-Jordan

So I would recommend .depex binary files be treated the same as binary
.efi files by GIT. So it does sound like we need some minor updates
to GIT attributes.

If we have an example of a binary module that is providing more binary
leaf sections than are actually required and/or used, then yes, the
binary module should be cleaned up to remove the unused content.

Thanks,

Mike

-----Original Message-----
From: Justen, Jordan L
Sent: Sunday, July 31, 2016 3:58 PM
To: Leif Lindholm <leif.lindholm@linaro.org>; Tim Lewis
<tim.lewis@insyde.com>
Cc: Laszlo Ersek <lersek@redhat.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; edk2-devel@ml01.01.org
<edk2-devel@lists.01.org>; Andrew Fish <afish@apple.com>
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file,
dealing with .depex

On 2016-07-30 11:33:43, Leif Lindholm wrote:
Hi Tim,

Thanks for the warning, and investigation.

Does this mean that you think we should ban the inclusion of
.depex files in EDK2, including future platform trees?
I don't know about banning it, but at least we could wait for
someone to make a reasonable argument why they are needed.

Even for binary only modules, it looks like the fdf method outlined
below is preferable to a pre-built .depex.

If (at a future point) the reason for using a .depex is to support a
binary only module in a supposedly open platform under EDK II, then
I guess we can decide if that is a good idea at that point.

Should we delete this one unused .depex from the tree?

-Jordan

(If not, this patch is
still needed for git to work predictably with these files.)

Regards,

Leif

On Fri, Jul 29, 2016 at 05:12:49PM +0000, Tim Lewis wrote:
It appears that this file is not actually used. It is only
referenced in the [Rule.Common.UEFI_DRIVER.NATIVE_BINARY] rule
in PlatformPkg.fdf. A little further research shows that an
alternate method was used for the actual GOP binary (see below).
A grep of the entire tree shows that no one uses this rule
NATIVE_BINARY. So it looks like it can just be cut out.

BTW, the downside of the method used for the binary version of
the GOP driver, is that those drivers cannot use PCDs, since the
PCD database is created based on references in the .inf. GOP
works because it is pure UEFI and (therefore) doesn't use PCDs.

Tim

FILE DRIVER = FF0C8745-3270-4439-B74F-3E45F8C77064 {
SECTION DXE_DEPEX_EXP = {gPlatformGOPPolicyGuid}
SECTION PE32 =
Vlv2MiscBinariesPkg/GOP/7.2.1011/RELEASE_VS2008x86/$(DXE_ARCHITECT
UR
E)/IntelGopDriver.e
fi
SECTION UI = "IntelGopDriver"
}

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
Behalf Of Leif
Lindholm
Sent: Friday, July 29, 2016 9:45 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: michael.d.kinney@intel.com; Jordan Justen
<jordan.l.justen@intel.com>; edk2-
devel@ml01.01.org; Andrew Fish <afish@apple.com>
Subject: Re: [edk2] [PATCH] add top-level .gitattributes file,
dealing with .depex

On Thu, Jul 07, 2016 at 05:03:13PM +0200, Laszlo Ersek wrote:
On 07/07/16 16:24, Leif Lindholm wrote:
Git tends to see .depex files as text, causing hideous
patches being generated (and breaking PatchCheck.py).

Add a .gitattributes file instructing git to treat them as binary.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
---
.gitattributes | 1 +
1 file changed, 1 insertion(+) create mode 100644
.gitattributes

diff --git a/.gitattributes b/.gitattributes new file mode
100644 index 0000000..2d8a45b
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+*.depex binary
What generates .depex files? I've never seen any.

Also, unless you add .depex files with "git add" to the set of
tracked files, no patches / diffs should cover them. What am I
missing? :)

... Hm, after

$ find . -iname "*.depex"

I see .depex files in Build/ (which should be ignored
altogether), and

./Vlv2TbltDevicePkg/IntelGopDepex/IntelGopDriver.depex

Why does that file exist in the tree? Let me see... git log
says nothing relevant
(the file dates back to commit 3cbfba02fef9, "Upload BSD-licensed
Vlv2TbltDevicePkg and Vlv2DeviceRefCodePkg to").

Grepping the tree for the filename itself leads to:

Vlv2TbltDevicePkg/PlatformPkg.fdf: DXE_DEPEX DXE_DEPEX
Optional
$(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.de
pex
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf: DXE_DEPEX DXE_DEPEX
Optional
$(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.de
pex

Do these rules exist to override the DEPEX sections of
binary-only modules? If
so: that's horrible.

Anyway, given that edk2 contains at least one .depex file, and
your patch is
correct according to <https://git-scm.com/book/en/v2/Customizing-Git-
Git-Attributes>:

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks!

I had hoped for comments from someone else on cc, since we don't
have any
Maintainers.txt entry for the top level directory :)

But if I don't hear anything before Monday, I'll push it then.

Regards,

Leif

_______________________________________________
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: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Palmer, Thomas <thomas.palmer@...>
 

Hi Jiaxin,

It sounds like we both agree that TlsCipherMappingTable is the list of what UEFI officially supports. If it is advertised in TlsCipherMappingTable then OpenSSL needs to support it.

My proposal of removing no-dsa / no-idea and adding weak-ciphers is specifically aimed to syncing how OpenSSL is configured/built to what is in TlsCipherMappingTable. I was busy last week testing out the new ciphers and realized a few were not even getting configured in OpenSSL.

Thomas

-----Original Message-----
From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com]
Sent: Monday, August 1, 2016 8:34 PM
To: Palmer, Thomas <thomas.palmer@hpe.com>; Long, Qin <qin.long@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Hi Thomas,

Since the Tls1.h is used to hold the standardized definitions, openssl part is not taken into consideration. The Cipher Suites added in Tls1.h only refers to A.5 of rfc-2246, rfc-4346 and rfc-5246. The criteria is removing all the limited/insecurity/deprecated ones that specified in RFC -- "Note that this mode is vulnerable to man-in-the middle attacks and is therefore deprecated." I know the IDEA and DES cipher suites are also deprecated in TLS1.2, but it does means to TLS1.1. So, some of them are still kept in Tls1.h.

As for the TlsCipherMappingTable, it takes on the link between Tls1.h defined cipher suites and openssl supported cipher suites. If we eliminate the factors of configuration, I believe the cipher suites in TlsCipherMappingTable should be implemented in OpenSSL lib. I haven't check them one by one but openssl official document is referred @ https://www.openssl.org/docs/manmaster/apps/ciphers.html, which gives the lists of TLS cipher suites names from the relevant specification and their OpenSSL equivalents.

If the cipher suites in Tls1.h is not found in TlsCipherMappingTable, EFI_UNSUPPORTED will be returned. I think it's reasonable.

Thanks,
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Tuesday, August 2, 2016 5:46 AM
To: Long, Qin <qin.long@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>;
edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin / Qin,


I'm unaware of what criteria is required for a cipher to be in this
TlsCipherMappingTable. I had presumed that it would be b/c UEFI
supported the cipher for TLS operation. If unsupported ciphers are
allowed ... then logically wouldn't we need to add all ciphers? What
advantage do we gain by having an entry in this table but not actually use the cipher in communication?

Currently TlsGetCipherString is the only means we have to validate
the cipher string. If a cipher is in the table but not in OpenSSL
lib, then we will provide imperfect feedback if the unsupported cipher
is buried in a list of supported ciphers. OpenSSL will simply use
only the ciphers it supports and quietly drop the unsupported cipher.
A user that inspects the list of set ciphers would be curious why a certain cipher was being "dropped" /
"filtered". However, if TlsGetCipherString sees that the cipher is not in our
mapping table the TlsSetCipherList function will return immediate feedback.

I'm not enthralled with supporting weak/idea ciphers either. I would
vouch for us removing those ciphers from TlsCipherMappingTable. It is
not our responsibility to document the IANA/Description string
description in code.

This document
(http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1
.pdf) would be a good list for initial cipher support. We have some
of the ciphers on the list already. Here is the sorted list:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CCM17
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CCM
TLS_RSA_WITH_AES_256_GCM_SHA384

Thomas

-----Original Message-----
From: Long, Qin [mailto:qin.long@intel.com]
Sent: Sunday, July 31, 2016 8:48 PM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

I personally prefer to keep the current supported cipher suite for our
UEFI- TLS enabling. We can have the full RFC definitions, and platform
specific cipher sets for validation now. It's better to maintain one
minimal scope in this phase.

"enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the
recommendation for hardening SSL communications.
For other ciphers (idea, dsa, etc), we can enable them step-by-step
depending on the real requirements.


Best Regards & Thanks,
LONG, Qin

-----Original Message-----
From: Wu, Jiaxin
Sent: Monday, August 01, 2016 9:23 AM
To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Gao, Liming
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Thomas,
I agree some of them are not supported due to the UEFI OpenSSL
configuration, but it doesn't affect those mapping relationship
added in the patch. So, I have no strong opinion whether to support
it by modifying the current OpenSSL configuration. Since Qin is the
OpenSSL expert, I'd like to hear his views.

Qin,
What's your opinion?

Thanks.
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
Behalf Of Palmer, Thomas
Sent: Saturday, July 30, 2016 6:03 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan
<siyuan.fu@intel.com>; Gao, Liming <liming.gao@intel.com>; Long,
Qin <qin.long@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin,

UEFI's OpenSSL library does not support all the ciphers that were
added in your patch due to the UEFI configuration. We need to
remove
"no- idea" and "no-dsa" from the process_files.sh and add
"enable-weak-ssl- ciphers"

While we are modifying process_files.sh, we can remove "no-
pqueue"
from process_files.sh so that OpensslLib.inf is in sync.

I can send out a patch to do so if you wish.

Thomas

-----Original Message-----
From: Jiaxin Wu [mailto:jiaxin.wu@intel.com]
Sent: Thursday, July 14, 2016 12:51 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao <liming.gao@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; Long Qin <qin.long@intel.com>; Ye Ting
<ting.ye@intel.com>; Fu Siyuan <siyuan.fu@intel.com>; Wu Jiaxin
<jiaxin.wu@intel.com>
Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

The series patches are used to replace the TLS definitions with
the standardized one. In addition, more TLS cipher suite mapping
between Cipher Suite definitions and OpenSSL-used Cipher Suite name are added.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>

Jiaxin Wu (4):
MdePkg: Add a header to standardize TLS definitions
CryptoPkg: Add more TLS cipher suite mapping
NetworkPkg/TlsDxe: Replace the definitions with the standardized one
NetworkPkg/HttpDxe: Replace the definitions with the
standardized one

CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++------------
--
--
MdePkg/Include/IndustryStandard/Tls1.h | 93 +
NetworkPkg/HttpDxe/HttpDriver.h | 2 +
NetworkPkg/HttpDxe/HttpProto.c | 12 +-
NetworkPkg/HttpDxe/HttpsSupport.c | 22 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 44 -
NetworkPkg/TlsDxe/TlsImpl.c | 56 +-
NetworkPkg/TlsDxe/TlsImpl.h | 30 +-
NetworkPkg/TlsDxe/TlsProtocol.c | 2 +-
9 files changed, 1945 insertions(+), 1901 deletions(-) create
mode
100644 MdePkg/Include/IndustryStandard/Tls1.h

--
1.9.5.msysgit.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: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Wu, Jiaxin <jiaxin.wu@...>
 

Hi Thomas,

Since the Tls1.h is used to hold the standardized definitions, openssl part is not taken into consideration. The Cipher Suites added in Tls1.h only refers to A.5 of rfc-2246, rfc-4346 and rfc-5246. The criteria is removing all the limited/insecurity/deprecated ones that specified in RFC -- "Note that this mode is vulnerable to man-in-the middle attacks and is therefore deprecated." I know the IDEA and DES cipher suites are also deprecated in TLS1.2, but it does means to TLS1.1. So, some of them are still kept in Tls1.h.

As for the TlsCipherMappingTable, it takes on the link between Tls1.h defined cipher suites and openssl supported cipher suites. If we eliminate the factors of configuration, I believe the cipher suites in TlsCipherMappingTable should be implemented in OpenSSL lib. I haven't check them one by one but openssl official document is referred @ https://www.openssl.org/docs/manmaster/apps/ciphers.html, which gives the lists of TLS cipher suites names from the relevant specification and their OpenSSL equivalents.

If the cipher suites in Tls1.h is not found in TlsCipherMappingTable, EFI_UNSUPPORTED will be returned. I think it's reasonable.

Thanks,
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Palmer, Thomas
Sent: Tuesday, August 2, 2016 5:46 AM
To: Long, Qin <qin.long@intel.com>; Wu, Jiaxin <jiaxin.wu@intel.com>;
edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao,
Liming <liming.gao@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin / Qin,


I'm unaware of what criteria is required for a cipher to be in this
TlsCipherMappingTable. I had presumed that it would be b/c UEFI supported
the cipher for TLS operation. If unsupported ciphers are allowed ... then
logically wouldn't we need to add all ciphers? What advantage do we gain by
having an entry in this table but not actually use the cipher in communication?

Currently TlsGetCipherString is the only means we have to validate
the cipher string. If a cipher is in the table but not in OpenSSL lib, then we will
provide imperfect feedback if the unsupported cipher is buried in a list of
supported ciphers. OpenSSL will simply use only the ciphers it supports and
quietly drop the unsupported cipher. A user that inspects the list of set
ciphers would be curious why a certain cipher was being "dropped" /
"filtered". However, if TlsGetCipherString sees that the cipher is not in our
mapping table the TlsSetCipherList function will return immediate feedback.

I'm not enthralled with supporting weak/idea ciphers either. I would
vouch for us removing those ciphers from TlsCipherMappingTable. It is not
our responsibility to document the IANA/Description string description in
code.

This document
(http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf)
would be a good list for initial cipher support. We have some of the ciphers
on the list already. Here is the sorted list:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CCM17
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CCM
TLS_RSA_WITH_AES_256_GCM_SHA384

Thomas

-----Original Message-----
From: Long, Qin [mailto:qin.long@intel.com]
Sent: Sunday, July 31, 2016 8:48 PM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao,
Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with
the standardized one

I personally prefer to keep the current supported cipher suite for our UEFI-
TLS enabling. We can have the full RFC definitions, and platform specific
cipher sets for validation now. It's better to maintain one minimal scope in
this phase.

"enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the
recommendation for hardening SSL communications.
For other ciphers (idea, dsa, etc), we can enable them step-by-step
depending on the real requirements.


Best Regards & Thanks,
LONG, Qin

-----Original Message-----
From: Wu, Jiaxin
Sent: Monday, August 01, 2016 9:23 AM
To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Gao, Liming
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Thomas,
I agree some of them are not supported due to the UEFI OpenSSL
configuration, but it doesn't affect those mapping relationship added
in the patch. So, I have no strong opinion whether to support it by
modifying the current OpenSSL configuration. Since Qin is the OpenSSL
expert, I'd like to hear his views.

Qin,
What's your opinion?

Thanks.
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
Of Palmer, Thomas
Sent: Saturday, July 30, 2016 6:03 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>; Long, Qin <qin.long@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin,

UEFI's OpenSSL library does not support all the ciphers that were
added in your patch due to the UEFI configuration. We need to
remove
"no- idea" and "no-dsa" from the process_files.sh and add
"enable-weak-ssl- ciphers"

While we are modifying process_files.sh, we can remove "no-
pqueue"
from process_files.sh so that OpensslLib.inf is in sync.

I can send out a patch to do so if you wish.

Thomas

-----Original Message-----
From: Jiaxin Wu [mailto:jiaxin.wu@intel.com]
Sent: Thursday, July 14, 2016 12:51 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao <liming.gao@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; Long Qin <qin.long@intel.com>; Ye Ting
<ting.ye@intel.com>; Fu Siyuan <siyuan.fu@intel.com>; Wu Jiaxin
<jiaxin.wu@intel.com>
Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions
with the standardized one

The series patches are used to replace the TLS definitions with the
standardized one. In addition, more TLS cipher suite mapping between
Cipher Suite definitions and OpenSSL-used Cipher Suite name are added.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>

Jiaxin Wu (4):
MdePkg: Add a header to standardize TLS definitions
CryptoPkg: Add more TLS cipher suite mapping
NetworkPkg/TlsDxe: Replace the definitions with the standardized one
NetworkPkg/HttpDxe: Replace the definitions with the standardized
one

CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++------------
--
--
MdePkg/Include/IndustryStandard/Tls1.h | 93 +
NetworkPkg/HttpDxe/HttpDriver.h | 2 +
NetworkPkg/HttpDxe/HttpProto.c | 12 +-
NetworkPkg/HttpDxe/HttpsSupport.c | 22 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 44 -
NetworkPkg/TlsDxe/TlsImpl.c | 56 +-
NetworkPkg/TlsDxe/TlsImpl.h | 30 +-
NetworkPkg/TlsDxe/TlsProtocol.c | 2 +-
9 files changed, 1945 insertions(+), 1901 deletions(-) create mode
100644 MdePkg/Include/IndustryStandard/Tls1.h

--
1.9.5.msysgit.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: [PATCH] OvmfPkg: use StatusCode Router and Handler from MdeModulePkg

Laszlo Ersek
 

On 08/01/16 09:08, Cinnamon Shia wrote:
Use StatusCode Router and Handler from MdeModulePkg instead of
IntelFrameworkModulePkg.

MdeModulePkg ones follows PI spec to implement StatusCode
Router/Handler and provide StatusCode service.
It allows the different status code handlers to be registered.

IntelFrameworkModulePkg one just provides StatusCode service.
It has no Router services.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
---
OvmfPkg/OvmfPkgIa32.dsc | 7 +++++--
OvmfPkg/OvmfPkgIa32.fdf | 7 +++++--
OvmfPkg/OvmfPkgIa32X64.dsc | 7 +++++--
OvmfPkg/OvmfPkgIa32X64.fdf | 7 +++++--
OvmfPkg/OvmfPkgX64.dsc | 7 +++++--
OvmfPkg/OvmfPkgX64.fdf | 7 +++++--
6 files changed, 30 insertions(+), 12 deletions(-)
Thanks for the patch!

I'd like to see a lot more documentation in the commit message. I was
completely unfamiliar with this area before Liming's suggestion and your
patch.

I understand it now, I think, but in retrospect, I just can't fathom why
you guys didn't provide me with more info weeks ago. I've been in the
dark, even though the explanation is fairly simple. :(

(1) So, here's what I would like to see in the commit message:

----------

In the Platform Init v1.4a spec,
- Volume 1 "4.7 Status Code Service" defines the
EFI_PEI_REPORT_STATUS_CODE.ReportStatusCode() service,
- Volume 1 "6.3.5 Status Code PPI (Optional)" defines the
EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above),
- Volume 2 "14.2 Status Code Runtime Protocol" defines the
EFI_STATUS_CODE_PROTOCOL.

These allow PEIMs and DXE (and later) modules to report status codes.

Currently OvmfPkg uses modules from under
"IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above
abstractions (PPI and PROTOCOL) directly, and write the status codes, as
they are reported, to the serial port or to a memory buffer. This is
called "handling" the status codes.

In the Platform Init v1.4a spec,
- Volume 3 "7.2.2 Report Status Code Handler PPI" defines
EFI_PEI_RSC_HANDLER_PPI,
- Volume 3 "7.2.1 Report Status Code Handler Protocol" defines
EFI_RSC_HANDLER_PROTOCOL.

These allow PEIMs and runtime DXE drivers to register several callbacks
for status code handling.

MdeModulePkg offers a PEIM under
"MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that procudes both
EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE
driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe"
that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL.

MdeModulePkg also offers status code handler modules under
MdeModulePkg/Universal/StatusCodeHandler/ that depend on
EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively.

The StatusCodeHandler modules register themselves with
ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI /
EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code
through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches
phase-matching ReportStatusCodeRouter module first, which in turn passes
the status code to the pre-registered, phase-matching StatusCodeHandler
module.

The status code handling in the StatusCodeHandler modules is identical
to the one currently provided by the IntelFrameworkModulePkg modules.
Replace the IntelFareworkModulePkg modules with the MdeModulePkg ones,
so we can decrease our dependency on IntelFareworkModulePkg.

----------

(2) The commit message should contain the following tags as well:

Suggested-by: Liming Gao <liming.gao@intel.com>
Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63

Then,

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 8af3267..aeb87b9 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -2,6 +2,7 @@
# EFI/Framework Open Virtual Machine Firmware (OVMF) platform
#
# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -497,7 +498,8 @@
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
}
- IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
+ MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
+ MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
@@ -534,7 +536,8 @@
DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
}

- IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.inf
+ MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+ MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 1369734..258938a 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -2,6 +2,7 @@
# Open Virtual Machine Firmware: FDF
#
# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -154,7 +155,8 @@ APRIORI PEI {
#
INF MdeModulePkg/Core/Pei/PeiMain.inf
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
-INF IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
+INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
+INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
INF OvmfPkg/PlatformPei/PlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -198,8 +200,9 @@ APRIORI DXE {
#
INF MdeModulePkg/Core/Dxe/DxeMain.inf

-INF IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.inf
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+INF MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+INF MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
(3) Any particular reason that you add the replacement text under the
Pcd.inf module? In all the other places, the replacements are more focused.

Looks good to me otherwise. Can you please submit a v2?

Thanks!
Laszlo


INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 4bb38d0..44da638 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -2,6 +2,7 @@
# EFI/Framework Open Virtual Machine Firmware (OVMF) platform
#
# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -505,7 +506,8 @@
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
}
- IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
+ MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
+ MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
@@ -543,7 +545,8 @@
DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
}

- IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.inf
+ MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+ MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 34f8938..dc9374c 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -2,6 +2,7 @@
# Open Virtual Machine Firmware: FDF
#
# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -154,7 +155,8 @@ APRIORI PEI {
#
INF MdeModulePkg/Core/Pei/PeiMain.inf
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
-INF IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
+INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
+INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
INF OvmfPkg/PlatformPei/PlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -198,8 +200,9 @@ APRIORI DXE {
#
INF MdeModulePkg/Core/Dxe/DxeMain.inf

-INF IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.inf
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+INF MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+INF MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf

INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index be3aa1f..89cd3a1 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -2,6 +2,7 @@
# EFI/Framework Open Virtual Machine Firmware (OVMF) platform
#
# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -504,7 +505,8 @@
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
}
- IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
+ MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
+ MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
@@ -541,7 +543,8 @@
DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
}

- IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.inf
+ MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+ MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
<LibraryClasses>
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 630c295..119e226 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -2,6 +2,7 @@
# Open Virtual Machine Firmware: FDF
#
# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.<BR>
+# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
#
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the BSD License
@@ -154,7 +155,8 @@ APRIORI PEI {
#
INF MdeModulePkg/Core/Pei/PeiMain.inf
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
-INF IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
+INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
+INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
INF OvmfPkg/PlatformPei/PlatformPei.inf
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -198,8 +200,9 @@ APRIORI DXE {
#
INF MdeModulePkg/Core/Dxe/DxeMain.inf

-INF IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.inf
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+INF MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+INF MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf

INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf


Re: [PATCHV2] MdePkg: Add DmaRemappingReportingTable.h

Michael D Kinney
 

Giri,

The updates look good.

Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>

Mike

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Giri P Mudusuru
Sent: Monday, August 1, 2016 4:17 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>;
Gao, Liming <liming.gao@intel.com>
Subject: [edk2] [PATCHV2] MdePkg: Add DmaRemappingReportingTable.h

DMA Remapping Reporting (DMAR) ACPI table definitions from Intel(R)
Virtualization Technology for Directed I/O (VT-D) Architecture
Specification v2.4 dated June 2016.

This replaces the DMARemappingReportingTable.h from
EdkCompatibilityPkg\Foundation\Include\IndustryStandard

Patch V2: added below defines and re-arranged the file.
EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL
EFI_ACPI_DMAR_ATSR_FLAGS_ALL_PORTS

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
---
.../IndustryStandard/DmaRemappingReportingTable.h | 261 +++++++++++++++++++++
1 file changed, 261 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h

diff --git a/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
new file mode 100644
index 0000000..a4a7e00
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
@@ -0,0 +1,261 @@
+/** @file
+ DMA Remapping Reporting (DMAR) ACPI table definition from Intel(R)
+ Virtualization Technology for Directed I/O (VT-D) Architecture Specification.
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ 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.
+
+ @par Revision Reference:
+ - Intel(R) Virtualization Technology for Directed I/O (VT-D) Architecture
+ Specification v2.4, Dated June 2016.
+ http://www.intel.com/content/dam/www/public/us/en/documents/product-
specifications/vt-directed-io-spec.pdf
+
+ @par Glossary:
+ - HPET - High Precision Event Timer
+ - NUMA - Non-uniform Memory Access
+**/
+#ifndef _DMA_REMAPPING_REPORTING_TABLE_H_
+#define _DMA_REMAPPING_REPORTING_TABLE_H_
+
+#pragma pack(1)
+
+///
+/// DMA-Remapping Reporting Structure definitions from section 8.1
+///@{
+#define EFI_ACPI_DMAR_REVISION 0x01
+
+#define EFI_ACPI_DMAR_FLAGS_INTR_REMAP BIT0
+#define EFI_ACPI_DMAR_FLAGS_X2APIC_OPT_OUT BIT1
+///@}
+
+///
+/// Remapping Structure Types definitions from section 8.2
+///@{
+#define EFI_ACPI_DMAR_TYPE_DRHD 0x00
+#define EFI_ACPI_DMAR_TYPE_RMRR 0x01
+#define EFI_ACPI_DMAR_TYPE_ATSR 0x02
+#define EFI_ACPI_DMAR_TYPE_RHSA 0x03
+#define EFI_ACPI_DMAR_TYPE_ANDD 0x04
+///@}
+
+///
+/// DMA-Remapping Hardware Unit definitions from section 8.3
+///
+#define EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL BIT0
+
+///
+/// DMA-Remapping Device Scope Entry Structure definitions from section 8.3.1
+///@{
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_ENDPOINT 0x01
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_BRIDGE 0x02
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_IOAPIC 0x03
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_MSI_CAPABLE_HPET 0x04
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_ACPI_NAMESPACE_DEVICE 0x05
+///@}
+
+///
+/// Root Port ATS Capability Reporting Structure definitions from section 8.5
+///
+#define EFI_ACPI_DMAR_ATSR_FLAGS_ALL_PORTS BIT0
+
+///
+/// Definition for DMA Remapping Structure Header
+///
+typedef struct {
+ UINT16 Type;
+ UINT16 Length;
+} EFI_ACPI_DMAR_STRUCTURE_HEADER;
+
+///
+/// Definition for DMA-Remapping PCI Path
+///
+typedef struct {
+ UINT8 Device;
+ UINT8 Function;
+} EFI_ACPI_DMAR_PCI_PATH;
+
+///
+/// Device Scope Structure is defined in section 8.3.1
+///
+typedef struct {
+ UINT8 Type;
+ UINT8 Length;
+ UINT16 Reserved2;
+ UINT8 EnumerationId;
+ UINT8 StartBusNumber;
+} EFI_ACPI_DMAR_DEVICE_SCOPE_STRUCTURE_HEADER;
+
+/**
+ DMA-remapping hardware unit definition (DRHD) structure is defined in
+ section 8.3. This uniquely represents a remapping hardware unit present
+ in the platform. There must be at least one instance of this structure
+ for each PCI segment in the platform.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ /**
+ - Bit[0]: INCLUDE_PCI_ALL
+ - If Set, this remapping hardware unit has under its scope all
+ PCI compatible devices in the specified Segment, except devices
+ reported under the scope of other remapping hardware units for
+ the same Segment.
+ - If Clear, this remapping hardware unit has under its scope only
+ devices in the specified Segment that are explicitly identified
+ through the DeviceScope field.
+ - Bits[7:1] Reserved.
+ **/
+ UINT8 Flags;
+ UINT8 Reserved;
+ ///
+ /// The PCI Segment associated with this unit.
+ ///
+ UINT16 SegmentNumber;
+ ///
+ /// Base address of remapping hardware register-set for this unit.
+ ///
+ UINT64 RegisterBaseAddress;
+} EFI_ACPI_DMAR_DRHD_HEADER;
+
+/**
+ Reserved Memory Region Reporting Structure (RMRR) is described in section 8.4
+ Reserved memory ranges that may be DMA targets may be reported through the
+ RMRR structures, along with the devices that requires access to the specified
+ reserved memory region.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ UINT8 Reserved[2];
+ ///
+ /// PCI Segment Number associated with devices identified through
+ /// the Device Scope field.
+ ///
+ UINT16 SegmentNumber;
+ ///
+ /// Base address of 4KB-aligned reserved memory region
+ ///
+ UINT64 ReservedMemoryRegionBaseAddress;
+ /**
+ Last address of the reserved memory region. Value in this field must be
+ greater than the value in Reserved Memory Region Base Address field.
+ The reserved memory region size (Limit - Base + 1) must be an integer
+ multiple of 4KB.
+ **/
+ UINT64 ReservedMemoryRegionLimitAddress;
+} EFI_ACPI_DMAR_RMRR_HEADER;
+
+/**
+ Root Port ATS Capability Reporting (ATSR) structure is defined in section 8.5.
+ This structure is applicable only for platforms supporting Device-TLBs as
+ reported through the Extended Capability Register. For each PCI Segment in
+ the platform that supports Device-TLBs, BIOS provides an ATSR structure. The
+ ATSR structures identifies PCI-Express Root-Ports supporting Address
+ Translation Services (ATS) transactions. Software must enable ATS on endpoint
+ devices behind a Root Port only if the Root Port is reported as supporting
+ ATS transactions.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ /**
+ - Bit[0]: ALL_PORTS:
+ - If Set, indicates all PCI Express Root Ports in the specified
+ PCI Segment supports ATS transactions.
+ - If Clear, indicates ATS transactions are supported only on
+ Root Ports identified through the Device Scope field.
+ - Bits[7:1] Reserved.
+ **/
+ UINT8 Flags;
+ UINT8 Reserved;
+ ///
+ /// The PCI Segment associated with this ATSR structure
+ ///
+ UINT16 SegmentNumber;
+} EFI_ACPI_DMAR_ATSR_HEADER;
+
+/**
+ Remapping Hardware Static Affinity (RHSA) is an optional structure defined
+ in section 8.6. This is intended to be used only on NUMA platforms with
+ Remapping hardware units and memory spanned across multiple nodes.
+ When used, there must be a RHSA structure for each Remapping hardware unit
+ reported through DRHD structure.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ UINT8 Reserved[4];
+ ///
+ /// Register Base Address of this Remap hardware unit reported in the
+ /// corresponding DRHD structure.
+ ///
+ UINT64 RegisterBaseAddress;
+ ///
+ /// Proximity Domain to which the Remap hardware unit identified by the
+ /// Register Base Address field belongs.
+ ///
+ UINT32 ProximityDomain;
+} EFI_ACPI_DMAR_RHSA_HEADER;
+
+/**
+ An ACPI Name-space Device Declaration (ANDD) structure is defined in section
+ 8.7 and uniquely represents an ACPI name-space enumerated device capable of
+ issuing DMA requests in the platform. ANDD structures are used in conjunction
+ with Device-Scope entries of type ACPI_NAMESPACE_DEVICE.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ UINT8 Reserved[3];
+ /**
+ Each ACPI device enumerated through an ANDD structure must have a unique
+ value for this field. To report an ACPI device with ACPI Device Number
+ value of X, under the scope of a DRHD unit, a Device-Scope entry of type
+ ACPI_NAMESPACE_DEVICE is used with value of X in the Enumeration ID field.
+ The Start Bus Number and Path fields in the Device-Scope together
+ provides the 16-bit source-id allocated by platform for the ACPI device.
+ **/
+ UINT8 AcpiDeviceNumber;
+} EFI_ACPI_DMAR_ANDD_HEADER;
+
+/**
+ DMA Remapping Reporting Structure Header as defined in section 8.1
+ This header will be followed by list of Remapping Structures listed below
+ - DMA Remapping Hardware Unit Definition (DRHD)
+ - Reserved Memory Region Reporting (RMRR)
+ - Root Port ATS Capability Reporting (ATSR)
+ - Remapping Hardware Static Affinity (RHSA)
+ - ACPI Name-space Device Declaration (ANDD)
+ These structure types must by reported in numerical order.
+ i.e., All remapping structures of type 0 (DRHD) enumerated before remapping
+ structures of type 1 (RMRR), and so forth.
+**/
+typedef struct {
+ EFI_ACPI_DESCRIPTION_HEADER Header;
+ /**
+ This field indicates the maximum DMA physical addressability supported by
+ this platform. The system address map reported by the BIOS indicates what
+ portions of this addresses are populated. The Host Address Width (HAW) of
+ the platform is computed as (N+1), where N is the value reported in this
+ field.
+ For example, for a platform supporting 40 bits of physical addressability,
+ the value of 100111b is reported in this field.
+ **/
+ UINT8 HostAddressWidth;
+ /**
+ - Bit[0]: INTR_REMAP - If Clear, the platform does not support interrupt
+ remapping. If Set, the platform supports interrupt remapping.
+ - Bit[1]: X2APIC_OPT_OUT - For firmware compatibility reasons, platform
+ firmware may Set this field to request system software to opt
+ out of enabling Extended xAPIC (X2APIC) mode. This field is
+ valid only when the INTR_REMAP field (bit 0) is Set.
+ - Bits[7:2] Reserved.
+ **/
+ UINT8 Flags;
+ UINT8 Reserved[10];
+} EFI_ACPI_DMAR_HEADER;
+
+#pragma pack()
+
+#endif
--
2.9.0.windows.1

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


[PATCHV2] MdePkg: Add DmaRemappingReportingTable.h

Giri P Mudusuru <giri.p.mudusuru@...>
 

DMA Remapping Reporting (DMAR) ACPI table definitions from Intel(R)
Virtualization Technology for Directed I/O (VT-D) Architecture
Specification v2.4 dated June 2016.

This replaces the DMARemappingReportingTable.h from
EdkCompatibilityPkg\Foundation\Include\IndustryStandard

Patch V2: added below defines and re-arranged the file.
EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL
EFI_ACPI_DMAR_ATSR_FLAGS_ALL_PORTS

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
---
.../IndustryStandard/DmaRemappingReportingTable.h | 261 +++++++++++++++++++++
1 file changed, 261 insertions(+)
create mode 100644 MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h

diff --git a/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
new file mode 100644
index 0000000..a4a7e00
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
@@ -0,0 +1,261 @@
+/** @file
+ DMA Remapping Reporting (DMAR) ACPI table definition from Intel(R)
+ Virtualization Technology for Directed I/O (VT-D) Architecture Specification.
+
+ Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
+ 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.
+
+ @par Revision Reference:
+ - Intel(R) Virtualization Technology for Directed I/O (VT-D) Architecture
+ Specification v2.4, Dated June 2016.
+ http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf
+
+ @par Glossary:
+ - HPET - High Precision Event Timer
+ - NUMA - Non-uniform Memory Access
+**/
+#ifndef _DMA_REMAPPING_REPORTING_TABLE_H_
+#define _DMA_REMAPPING_REPORTING_TABLE_H_
+
+#pragma pack(1)
+
+///
+/// DMA-Remapping Reporting Structure definitions from section 8.1
+///@{
+#define EFI_ACPI_DMAR_REVISION 0x01
+
+#define EFI_ACPI_DMAR_FLAGS_INTR_REMAP BIT0
+#define EFI_ACPI_DMAR_FLAGS_X2APIC_OPT_OUT BIT1
+///@}
+
+///
+/// Remapping Structure Types definitions from section 8.2
+///@{
+#define EFI_ACPI_DMAR_TYPE_DRHD 0x00
+#define EFI_ACPI_DMAR_TYPE_RMRR 0x01
+#define EFI_ACPI_DMAR_TYPE_ATSR 0x02
+#define EFI_ACPI_DMAR_TYPE_RHSA 0x03
+#define EFI_ACPI_DMAR_TYPE_ANDD 0x04
+///@}
+
+///
+/// DMA-Remapping Hardware Unit definitions from section 8.3
+///
+#define EFI_ACPI_DMAR_DRHD_FLAGS_INCLUDE_PCI_ALL BIT0
+
+///
+/// DMA-Remapping Device Scope Entry Structure definitions from section 8.3.1
+///@{
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_ENDPOINT 0x01
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_BRIDGE 0x02
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_IOAPIC 0x03
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_MSI_CAPABLE_HPET 0x04
+#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_ACPI_NAMESPACE_DEVICE 0x05
+///@}
+
+///
+/// Root Port ATS Capability Reporting Structure definitions from section 8.5
+///
+#define EFI_ACPI_DMAR_ATSR_FLAGS_ALL_PORTS BIT0
+
+///
+/// Definition for DMA Remapping Structure Header
+///
+typedef struct {
+ UINT16 Type;
+ UINT16 Length;
+} EFI_ACPI_DMAR_STRUCTURE_HEADER;
+
+///
+/// Definition for DMA-Remapping PCI Path
+///
+typedef struct {
+ UINT8 Device;
+ UINT8 Function;
+} EFI_ACPI_DMAR_PCI_PATH;
+
+///
+/// Device Scope Structure is defined in section 8.3.1
+///
+typedef struct {
+ UINT8 Type;
+ UINT8 Length;
+ UINT16 Reserved2;
+ UINT8 EnumerationId;
+ UINT8 StartBusNumber;
+} EFI_ACPI_DMAR_DEVICE_SCOPE_STRUCTURE_HEADER;
+
+/**
+ DMA-remapping hardware unit definition (DRHD) structure is defined in
+ section 8.3. This uniquely represents a remapping hardware unit present
+ in the platform. There must be at least one instance of this structure
+ for each PCI segment in the platform.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ /**
+ - Bit[0]: INCLUDE_PCI_ALL
+ - If Set, this remapping hardware unit has under its scope all
+ PCI compatible devices in the specified Segment, except devices
+ reported under the scope of other remapping hardware units for
+ the same Segment.
+ - If Clear, this remapping hardware unit has under its scope only
+ devices in the specified Segment that are explicitly identified
+ through the DeviceScope field.
+ - Bits[7:1] Reserved.
+ **/
+ UINT8 Flags;
+ UINT8 Reserved;
+ ///
+ /// The PCI Segment associated with this unit.
+ ///
+ UINT16 SegmentNumber;
+ ///
+ /// Base address of remapping hardware register-set for this unit.
+ ///
+ UINT64 RegisterBaseAddress;
+} EFI_ACPI_DMAR_DRHD_HEADER;
+
+/**
+ Reserved Memory Region Reporting Structure (RMRR) is described in section 8.4
+ Reserved memory ranges that may be DMA targets may be reported through the
+ RMRR structures, along with the devices that requires access to the specified
+ reserved memory region.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ UINT8 Reserved[2];
+ ///
+ /// PCI Segment Number associated with devices identified through
+ /// the Device Scope field.
+ ///
+ UINT16 SegmentNumber;
+ ///
+ /// Base address of 4KB-aligned reserved memory region
+ ///
+ UINT64 ReservedMemoryRegionBaseAddress;
+ /**
+ Last address of the reserved memory region. Value in this field must be
+ greater than the value in Reserved Memory Region Base Address field.
+ The reserved memory region size (Limit - Base + 1) must be an integer
+ multiple of 4KB.
+ **/
+ UINT64 ReservedMemoryRegionLimitAddress;
+} EFI_ACPI_DMAR_RMRR_HEADER;
+
+/**
+ Root Port ATS Capability Reporting (ATSR) structure is defined in section 8.5.
+ This structure is applicable only for platforms supporting Device-TLBs as
+ reported through the Extended Capability Register. For each PCI Segment in
+ the platform that supports Device-TLBs, BIOS provides an ATSR structure. The
+ ATSR structures identifies PCI-Express Root-Ports supporting Address
+ Translation Services (ATS) transactions. Software must enable ATS on endpoint
+ devices behind a Root Port only if the Root Port is reported as supporting
+ ATS transactions.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ /**
+ - Bit[0]: ALL_PORTS:
+ - If Set, indicates all PCI Express Root Ports in the specified
+ PCI Segment supports ATS transactions.
+ - If Clear, indicates ATS transactions are supported only on
+ Root Ports identified through the Device Scope field.
+ - Bits[7:1] Reserved.
+ **/
+ UINT8 Flags;
+ UINT8 Reserved;
+ ///
+ /// The PCI Segment associated with this ATSR structure
+ ///
+ UINT16 SegmentNumber;
+} EFI_ACPI_DMAR_ATSR_HEADER;
+
+/**
+ Remapping Hardware Static Affinity (RHSA) is an optional structure defined
+ in section 8.6. This is intended to be used only on NUMA platforms with
+ Remapping hardware units and memory spanned across multiple nodes.
+ When used, there must be a RHSA structure for each Remapping hardware unit
+ reported through DRHD structure.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ UINT8 Reserved[4];
+ ///
+ /// Register Base Address of this Remap hardware unit reported in the
+ /// corresponding DRHD structure.
+ ///
+ UINT64 RegisterBaseAddress;
+ ///
+ /// Proximity Domain to which the Remap hardware unit identified by the
+ /// Register Base Address field belongs.
+ ///
+ UINT32 ProximityDomain;
+} EFI_ACPI_DMAR_RHSA_HEADER;
+
+/**
+ An ACPI Name-space Device Declaration (ANDD) structure is defined in section
+ 8.7 and uniquely represents an ACPI name-space enumerated device capable of
+ issuing DMA requests in the platform. ANDD structures are used in conjunction
+ with Device-Scope entries of type ACPI_NAMESPACE_DEVICE.
+**/
+typedef struct {
+ EFI_ACPI_DMAR_STRUCTURE_HEADER Header;
+ UINT8 Reserved[3];
+ /**
+ Each ACPI device enumerated through an ANDD structure must have a unique
+ value for this field. To report an ACPI device with ACPI Device Number
+ value of X, under the scope of a DRHD unit, a Device-Scope entry of type
+ ACPI_NAMESPACE_DEVICE is used with value of X in the Enumeration ID field.
+ The Start Bus Number and Path fields in the Device-Scope together
+ provides the 16-bit source-id allocated by platform for the ACPI device.
+ **/
+ UINT8 AcpiDeviceNumber;
+} EFI_ACPI_DMAR_ANDD_HEADER;
+
+/**
+ DMA Remapping Reporting Structure Header as defined in section 8.1
+ This header will be followed by list of Remapping Structures listed below
+ - DMA Remapping Hardware Unit Definition (DRHD)
+ - Reserved Memory Region Reporting (RMRR)
+ - Root Port ATS Capability Reporting (ATSR)
+ - Remapping Hardware Static Affinity (RHSA)
+ - ACPI Name-space Device Declaration (ANDD)
+ These structure types must by reported in numerical order.
+ i.e., All remapping structures of type 0 (DRHD) enumerated before remapping
+ structures of type 1 (RMRR), and so forth.
+**/
+typedef struct {
+ EFI_ACPI_DESCRIPTION_HEADER Header;
+ /**
+ This field indicates the maximum DMA physical addressability supported by
+ this platform. The system address map reported by the BIOS indicates what
+ portions of this addresses are populated. The Host Address Width (HAW) of
+ the platform is computed as (N+1), where N is the value reported in this
+ field.
+ For example, for a platform supporting 40 bits of physical addressability,
+ the value of 100111b is reported in this field.
+ **/
+ UINT8 HostAddressWidth;
+ /**
+ - Bit[0]: INTR_REMAP - If Clear, the platform does not support interrupt
+ remapping. If Set, the platform supports interrupt remapping.
+ - Bit[1]: X2APIC_OPT_OUT - For firmware compatibility reasons, platform
+ firmware may Set this field to request system software to opt
+ out of enabling Extended xAPIC (X2APIC) mode. This field is
+ valid only when the INTR_REMAP field (bit 0) is Set.
+ - Bits[7:2] Reserved.
+ **/
+ UINT8 Flags;
+ UINT8 Reserved[10];
+} EFI_ACPI_DMAR_HEADER;
+
+#pragma pack()
+
+#endif
--
2.9.0.windows.1


Re: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

Palmer, Thomas <thomas.palmer@...>
 

Jiaxin / Qin,


I'm unaware of what criteria is required for a cipher to be in this TlsCipherMappingTable. I had presumed that it would be b/c UEFI supported the cipher for TLS operation. If unsupported ciphers are allowed ... then logically wouldn't we need to add all ciphers? What advantage do we gain by having an entry in this table but not actually use the cipher in communication?

Currently TlsGetCipherString is the only means we have to validate the cipher string. If a cipher is in the table but not in OpenSSL lib, then we will provide imperfect feedback if the unsupported cipher is buried in a list of supported ciphers. OpenSSL will simply use only the ciphers it supports and quietly drop the unsupported cipher. A user that inspects the list of set ciphers would be curious why a certain cipher was being "dropped" / "filtered". However, if TlsGetCipherString sees that the cipher is not in our mapping table the TlsSetCipherList function will return immediate feedback.

I'm not enthralled with supporting weak/idea ciphers either. I would vouch for us removing those ciphers from TlsCipherMappingTable. It is not our responsibility to document the IANA/Description string description in code.

This document (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf) would be a good list for initial cipher support. We have some of the ciphers on the list already. Here is the sorted list:

TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CCM17
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CCM
TLS_RSA_WITH_AES_256_GCM_SHA384

Thomas

-----Original Message-----
From: Long, Qin [mailto:qin.long@intel.com]
Sent: Sunday, July 31, 2016 8:48 PM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; Palmer, Thomas <thomas.palmer@hpe.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions with the standardized one

I personally prefer to keep the current supported cipher suite for our UEFI-TLS enabling. We can have the full RFC definitions, and platform specific cipher sets for validation now. It's better to maintain one minimal scope in this phase.

"enable-weak-ssl-ciphers" looks odd. Disabling weak ciphers is the recommendation for hardening SSL communications.
For other ciphers (idea, dsa, etc), we can enable them step-by-step depending on the real requirements.


Best Regards & Thanks,
LONG, Qin

-----Original Message-----
From: Wu, Jiaxin
Sent: Monday, August 01, 2016 9:23 AM
To: Palmer, Thomas; Long, Qin; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Gao, Liming
Subject: RE: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Thomas,
I agree some of them are not supported due to the UEFI OpenSSL
configuration, but it doesn't affect those mapping relationship added
in the patch. So, I have no strong opinion whether to support it by
modifying the current OpenSSL configuration. Since Qin is the OpenSSL
expert, I'd like to hear his views.

Qin,
What's your opinion?

Thanks.
Jiaxin

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
Of Palmer, Thomas
Sent: Saturday, July 30, 2016 6:03 AM
To: Wu, Jiaxin <jiaxin.wu@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>;
Gao, Liming <liming.gao@intel.com>; Long, Qin <qin.long@intel.com>
Subject: Re: [edk2] [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS
definitions with the standardized one

Jiaxin,

UEFI's OpenSSL library does not support all the ciphers that were
added in your patch due to the UEFI configuration. We need to
remove
"no- idea" and "no-dsa" from the process_files.sh and add
"enable-weak-ssl- ciphers"

While we are modifying process_files.sh, we can remove "no-
pqueue"
from process_files.sh so that OpensslLib.inf is in sync.

I can send out a patch to do so if you wish.

Thomas

-----Original Message-----
From: Jiaxin Wu [mailto:jiaxin.wu@intel.com]
Sent: Thursday, July 14, 2016 12:51 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao <liming.gao@intel.com>; Palmer, Thomas
<thomas.palmer@hpe.com>; Long Qin <qin.long@intel.com>; Ye Ting
<ting.ye@intel.com>; Fu Siyuan <siyuan.fu@intel.com>; Wu Jiaxin
<jiaxin.wu@intel.com>
Subject: [staging/HTTPS-TLS][PATCH 0/4] Replace the TLS definitions
with the standardized one

The series patches are used to replace the TLS definitions with the
standardized one. In addition, more TLS cipher suite mapping between
Cipher Suite definitions and OpenSSL-used Cipher Suite name are added.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Palmer Thomas <thomas.palmer@hpe.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>

Jiaxin Wu (4):
MdePkg: Add a header to standardize TLS definitions
CryptoPkg: Add more TLS cipher suite mapping
NetworkPkg/TlsDxe: Replace the definitions with the standardized one
NetworkPkg/HttpDxe: Replace the definitions with the standardized
one

CryptoPkg/Library/TlsLib/TlsLib.c | 3585 ++++++++++++++++--------------
--
MdePkg/Include/IndustryStandard/Tls1.h | 93 +
NetworkPkg/HttpDxe/HttpDriver.h | 2 +
NetworkPkg/HttpDxe/HttpProto.c | 12 +-
NetworkPkg/HttpDxe/HttpsSupport.c | 22 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 44 -
NetworkPkg/TlsDxe/TlsImpl.c | 56 +-
NetworkPkg/TlsDxe/TlsImpl.h | 30 +-
NetworkPkg/TlsDxe/TlsProtocol.c | 2 +-
9 files changed, 1945 insertions(+), 1901 deletions(-) create mode
100644 MdePkg/Include/IndustryStandard/Tls1.h

--
1.9.5.msysgit.1

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


Re: [PATCH] IntelFsp2Pkg: Locate FSP Info Header dynamically

Mudusuru, Giri P <giri.p.mudusuru@...>
 

Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>

Please update the comments for the opcode to be in line similar to the https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm

Thanks,
-Giri

-----Original Message-----
From: Yarlagadda, Satya P
Sent: Monday, August 1, 2016 4:42 AM
To: edk2-devel@lists.01.org
Cc: Ma, Maurice <maurice.ma@intel.com>; Yao, Jiewen
<jiewen.yao@intel.com>; Mudusuru, Giri P <giri.p.mudusuru@intel.com>
Subject: [PATCH] IntelFsp2Pkg: Locate FSP Info Header dynamically

we need to locate the FSP Info Header by calculating offset dynamically to
handle the scenario of FSP component is being rebased to different location.

Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Satya Yarlagadda <satya.p.yarlagadda@intel.com>
---
IntelFsp2Pkg/FspSecCore/Ia32/FspHelper.nasm | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/FspHelper.nasm
b/IntelFsp2Pkg/FspSecCore/Ia32/FspHelper.nasm
index 00e953b..7d5fa5e 100644
--- a/IntelFsp2Pkg/FspSecCore/Ia32/FspHelper.nasm
+++ b/IntelFsp2Pkg/FspSecCore/Ia32/FspHelper.nasm
@@ -14,22 +14,22 @@
SECTION .text

global ASM_PFX(FspInfoHeaderRelativeOff)
-ASM_PFX(FspInfoHeaderRelativeOff):
- ;
- ; This value will be pached by the build script
- ;
- DD 0x12345678

global ASM_PFX(AsmGetFspBaseAddress)
ASM_PFX(AsmGetFspBaseAddress):
- mov eax, ASM_PFX(AsmGetFspInfoHeader)
- sub eax, dword [ASM_PFX(FspInfoHeaderRelativeOff)]
+ call ASM_PFX(AsmGetFspInfoHeader)
add eax, 0x1C
mov eax, dword [eax]
ret

global ASM_PFX(AsmGetFspInfoHeader)
ASM_PFX(AsmGetFspInfoHeader):
- mov eax, ASM_PFX(AsmGetFspInfoHeader)
- sub eax, dword [ASM_PFX(FspInfoHeaderRelativeOff)]
+ call ASM_PFX(NextInstruction)
+ASM_PFX(NextInstruction):
+ pop eax
+ sub eax, ASM_PFX(NextInstruction)
+ add eax, ASM_PFX(AsmGetFspInfoHeader)
+ ;sub eax, 012345678h
+ DB 02Dh
+ASM_PFX(FspInfoHeaderRelativeOff): DD 0x12345678
ret
--
2.9.2.windows.1