Date   

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


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

Ma, Maurice
 

It looks good to me.
Reviewed by: Maurice Ma <maurice.ma@intel.com>

Regards,
Maurice

-----Original Message-----
From: Yarlagadda, Satya P
Sent: Monday, August 01, 2016 4:42 AM
To: edk2-devel@lists.01.org
Cc: Ma, Maurice; Yao, Jiewen; Mudusuru, Giri P
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


Re: [PATCH] ArmPkg/Library: Add ArmReadSctlr for aarch64

Supreeth Venkatesh
 

Thanks Ard.

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Monday, August 01, 2016 7:11 AM
To: Supreeth Venkatesh
Cc: edk2-devel-01; Leif Lindholm; John Powell
Subject: Re: [PATCH] ArmPkg/Library: Add ArmReadSctlr for aarch64

On 30 July 2016 at 01:06, Supreeth Venkatesh <supreeth.venkatesh@arm.com> wrote:
One of the UEFI Self Certification tests (UEFI-SCT) need to read the
current exception level SCTLR Register.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: John Powell <john.powell@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
---
Thanks for the patch. I don't think mentioning the UEFI-SCT here makes any sense, since the function is defined in ArmLIb.h, and simply missing from the AARCH64 implementation.

I fixed this up when applying (07783fdd67e4)

Thanks,
Ard.




ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S | 12
+++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
b/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
index a6fd5e3..c9f3bd1 100644
--- a/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
+++ b/ArmPkg/Library/ArmLib/Common/AArch64/ArmLibSupport.S
@@ -1,7 +1,7 @@

#---------------------------------------------------------------------
---------
#
# Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR> -#
Copyright (c) 2011 - 2014, ARM Limited. All rights reserved.
+# Copyright (c) 2011 - 2016, ARM Limited. All rights reserved.
#
# This program and the accompanying materials # are licensed and
made available under the terms and conditions of the BSD License @@
-39,6 +39,7 @@ GCC_ASM_EXPORT (ArmCallWFE) GCC_ASM_EXPORT
(ArmCallSEV) GCC_ASM_EXPORT (ArmReadCpuActlr) GCC_ASM_EXPORT
(ArmWriteCpuActlr)
+GCC_ASM_EXPORT (ArmReadSctlr)


#---------------------------------------------------------------------
---------

@@ -205,4 +206,13 @@ ASM_PFX(ArmWriteCpuActlr):
isb
ret

+ASM_PFX(ArmReadSctlr):
+ EL1_OR_EL2_OR_EL3(x1)
+1:mrs x0, sctlr_el1
+ ret
+2:mrs x0, sctlr_el2
+ ret
+3:mrs x0, sctlr_el3
+4:ret
+
ASM_FUNCTION_REMOVE_IF_UNREFERENCED
--
2.8.0
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Michael D Kinney
 

Giri,

Based on the information in this thread, I am in favor of adding to MdePkg.

If the number of files in MdePkg/Include/IndustryStandard grows too large
then some additional directory organization may be required.

Mike

-----Original Message-----
From: Mudusuru, Giri P
Sent: Monday, August 1, 2016 9:52 AM
To: Rothman, Michael A <michael.a.rothman@intel.com>; Tim Lewis <tim.lewis@insyde.com>;
Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-
devel@lists.01.org <edk2-devel@ml01.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming <liming.gao@intel.com>; Mudusuru,
Giri P <giri.p.mudusuru@intel.com>
Subject: RE: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Thanks for detailed conversation and I agree with direction.

As it is ACPI related which has multiple vendors owning specific tables referred by
ACPI spec MdePkg for now seems to be right place. That said we can start separate
discussion if we want to create vendor folders for better organization in future.

For now we can close this thread to include in MdePkg. Any objections?

Thanks,
-Giri

-----Original Message-----
From: Rothman, Michael A
Sent: Thursday, July 28, 2016 11:53 AM
To: Mudusuru, Giri P <giri.p.mudusuru@intel.com>; Tim Lewis
<tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-
devel@ml01.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: RE: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Personally,

I see that we have two classes of data we have external references to in the
codebase.

We have data that is in a standards-maintained spec like ACPI, UEFI, etc. This
might be something like FPDT, which is a reservation in ACPI, but also has a
litany of definitions contained within the main ACPI specification and bug fixes
or extensions associated with it will show up in the main spec.

We also have data that one of the main industry specs may reference, but don't
define explicitly. Things like the PE/COFF format, XENV, DMAR, etc. These are
maintained by vendor owners such as MSFT, INTC, or others.

In my mind, both of these categories are in essence industry spec material.
They're used by the industry and thus at least show up in some form within the
main industry specs.

However, the key difference is who is maintaining it.

I can easily see argued that the industrystandard directory should contain them
all.
I could further argue that if we end up having too much in the main
industrystandard directory, we could start to bucket them by having
subdirectories noting who maintains it.

Being that it is reference by an industry standard seems to be the simplest litmus
test for what main directory (and thus .h file) it gets placed in - otherwise it
might get pretty confusing.

Definitely feels like something the Codebase Grand Poobahs(Kinney/Fish/Leif)
need to discuss. :-)

Thanks,
Mike Rothman
(迈克 罗斯曼 / माइकल रोथ्मेन् / Михаил Ротман / משה רוטמן)
רועה עיקרי של חתולים


-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Mudusuru, Giri P
Sent: Thursday, July 28, 2016 10:59 AM
To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-
devel@lists.01.org <edk2-devel@ml01.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Hi Tim,
Yes it is historical, and if we want to change that let's define the guidelines.

In initial review added to IntelSiliconPkg but looking at other usage and to keep
it consistent I have moved to MdePkg.

For example HPET and SPMI is another example which falls under the same
bucket from Intel side.

For now we have place for Intel silicon related at IntelSiliconPkg but not all
vendors have same.

Will wait for the stewards (Mike, Leif and Andrew) to recommend the final
location.

Thanks,
-Giri

-----Original Message-----
From: Tim Lewis [mailto:tim.lewis@insyde.com]
Sent: Thursday, July 28, 2016 9:55 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek
<lersek@redhat.com>; Mudusuru, Giri P <giri.p.mudusuru@intel.com>;
edk2- devel@lists.01.org <edk2-devel@ml01.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming
<liming.gao@intel.com>
Subject: RE: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Mike --

Not quite. That table has historically been a registry of claimed
table IDs similar to the registry for \EFI directory names. As noted,
there is a link to a page that gives the links to the actual spec,
which is hosted by Intel (or Microsoft or Xen) The listing in this
table is not an endorsement of an "industry standard" any more than XENV.
(XEN Project Table). They are just vendor links.

Tim

-----Original Message-----
From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]
Sent: Thursday, July 28, 2016 9:51 AM
To: Tim Lewis <tim.lewis@insyde.com>; Laszlo Ersek
<lersek@redhat.com>; Mudusuru, Giri P <giri.p.mudusuru@intel.com>;
edk2-devel@lists.01.org <edk2- devel@ml01.01.org>; Kinney, Michael D
<michael.d.kinney@intel.com>
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming
<liming.gao@intel.com>
Subject: RE: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Tim,

The 'DMAR' table is defined in the ACPI Specification.

This is similar to 'DBG2':

MdePkg/Include/IndustryStandard/DebugPort2Table.h

And 'SPCD':

MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h

Mike

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
Of Tim Lewis
Sent: Thursday, July 28, 2016 9:42 AM
To: Laszlo Ersek <lersek@redhat.com>; Mudusuru, Giri P
<giri.p.mudusuru@intel.com>; edk2-devel@lists.01.org
<edk2-devel@ml01.01.org>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen
<jiewen.yao@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

Laszlo --

I hear what you are saying. However, I think this is a different case:

1) How many ARM-defined standards are in the
MdePkg\Include\IndustryStandards.h file?
By my count, none. This is by design. They are all in other packages.
DMAR is there because it was grandfathered in from a generation of
tianocore when only architectures provided by Intel were prevalent for UEFI.
2) Now that there is an Intel package for Intel-silicon related
header files and modules, now is the time to move it.
3) OS cases are a little different, since we don't usually produce
Microsoft (or Redhat or Canonical or BSD) specific modules for UEFI.
There are header files and a smattering of files that deal with these.
If we created a MicrosoftOsPkg, I'd move the header files there as well.

Tim

-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Thursday, July 28, 2016 9:29 AM
To: Tim Lewis <tim.lewis@insyde.com>; Giri P Mudusuru
<giri.p.mudusuru@intel.com>; edk2-devel@lists.01.org
<edk2-devel@ml01.01.org>
Cc: Michael Kinney <michael.d.kinney@intel.com>; Jiewen Yao
<jiewen.yao@intel.com>; Liming Gao <liming.gao@intel.com>
Subject: Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h

On 07/28/16 18:00, Tim Lewis wrote:
Giri --

Is MdePkg the right place for this? This appears to be an
Intel-specific definition, right? I understand that it was in
IndustryStandard for EdkCompatibilityPkg, but it might do better
now in the IntelSiliconPkg.
DMAR is defined by a widely used industry standard / spec; I think
it belongs to MdePkg.

Prior art (gathered with

git log --reverse --stat=1000 --stat-graph-width=20 --
MdePkg/Include/IndustryStandard

and by searching for "Microsoft", case-insensitively):

(1)

commit 32df01ff685b9de50555bac040166b17a061ea9b
Author: Chao Zhang <chao.b.zhang@intel.com>
Date: Wed May 13 08:27:04 2015 +0000

MdePkg: Add Microsoft UX capsule GUID & layout

Add Microsoft UX capsule GUID & layout into IndustryStandard

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Gao Liming <liming.gao@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17424
6f19259b-4bc3-
4df7-8a09-765794883524

MdePkg/Include/IndustryStandard/WindowsUxCapsule.h | 46
++++++++++++++++++++
1 file changed, 46 insertions(+)

(2)

commit c374aa43a199a5aab53218ef3cf99284ba19ae98
Author: Heyi Guo <heyi.guo@linaro.org>
Date: Fri Nov 13 03:27:54 2015 +0000

Update SPCR table definition per SPCR specification v1.03.

Document link:

http://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=
vs
.85).aspx

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Heyi Guo" <heyi.guo@linaro.org>
Reviewed-by: "Jiewen Yao" <jiewen.yao@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18782
6f19259b-4bc3-
4df7-8a09-765794883524

MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
|
12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

(3)

commit 31a9d3b419accbbc5463c71221b3b30a46f9ee73
Author: Yao, Jiewen <jiewen.yao@intel.com>
Date: Tue Jan 19 13:17:10 2016 +0000

MdePkg: Update MorLock comment to latest doc.

Microsoft updated secure MOR lock document with version 2.
So we update comment here.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed: "Zhang, Chao B" <chao.b.zhang@intel.com>


git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19687
6f19259b-4bc3-
4df7-8a09-765794883524

MdePkg/Include/IndustryStandard/MemoryOverwriteRequestControlLock.h
|
16 ++++++++-----
---
1 file changed, 8 insertions(+), 8 deletions(-)

(4)

commit a0606fc705f5bdfbe2366a7f3c6dd7491da74394
Author: Sami Mujawar <sami.mujawar@arm.com>
Date: Fri Mar 4 14:58:33 2016 +0000

MdePkg: Add ARM Serial Port Subtype definitions

The Serial Port Console Redirection Table specification Version 1.03 -
August 10, 2015 adds support for Serial Port Subtypes for ARM. These
Subtypes are described in the Table 3 of the Microsoft Debug Port Table
2 (DBG2) Specification - December 10, 2015.

This patch adds macro definitions for these.

Code at:
https://github.com/EvanLloyd/tianocore/commit/79678a0f399e97883cfba092
75e750861e24cd70

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>

MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
|
25
++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)

(5)

commit 9f0b995e64b8d6beec2edef7fdddc3374e624e42
Author: Sami Mujawar <sami.mujawar@arm.com>
Date: Fri Mar 4 17:24:41 2016 +0000

MdePkg: Add ARM Serial Port Subtypes to DBG2

The Microsoft Debug Port Table 2 (DBG2) specification revision
October 6, 2015 adds support for Serial Port Subtypes for ARM.

This patch adds these definitions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>

MdePkg/Include/IndustryStandard/DebugPort2Table.h | 6 ++++++
1 file changed, 6 insertions(+)

(6)

commit 6a0d24221241bb1b13bafc7b2d264240d19d2993
Author: Jiewen Yao <jiewen.yao@intel.com>
Date: Fri Apr 22 10:23:19 2016 +0800

MdePkg: Add WSMT definition.

This patch adds Windows SMM Security Mitigation
Table @
http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-
BAA2-
1A54E0E490B6/WSMT.docx

Cc: "Gao, Liming" <liming.gao@intel.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Gao, Liming" <liming.gao@intel.com>

MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h
|
39
++++++++++++++++++++
1 file changed, 39 insertions(+)

Thanks
Laszlo

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
Behalf Of Giri P Mudusuru
Sent: Wednesday, July 27, 2016 11:46 PM
To: edk2-devel@lists.01.org
Cc: Michael Kinney <michael.d.kinney@intel.com>; Jiewen Yao
<jiewen.yao@intel.com>; Liming Gao <liming.gao@intel.com>
Subject: [edk2] [PATCH] 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

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>
---
.../IndustryStandard/DmaRemappingReportingTable.h | 254
+++++++++++++++++++++
1 file changed, 254 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..691aea0
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
@@ -0,0 +1,254 @@
+/** @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/produc
+ t- sp ecifications/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 Table Revision ///
+#define EFI_ACPI_DMAR_DESCRIPTION_TABLE_REVISION 0x01
+
+///
+/// DMA-Remapping Reporting ACPI Table definitions from section
+8.1 ///@{
+#define EFI_ACPI_DMAR_TABLE_FLAGS_INTR_REMAP_SET BIT0
+#define EFI_ACPI_DMAR_TABLE_FLAGS_X2APIC_OPT_OUT_SET 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
+///@}
+
+///
+/// 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;
+
+///
+/// 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 ///@}
+
+///
+/// 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
_______________________________________________
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

Tim Lewis
 

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_ARCHITECTUR
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.depex
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf: DXE_DEPEX DXE_DEPEX Optional
$(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex

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


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

Michael D Kinney
 

Jordan,

I agree that we should not be adding .efi binaries or .depex binary files
to our source repos. There are several repos for EDK II, and some of
those do accept binaries. Specifically, the edk2-non-osi and edk2-platforms
would be repos where .depex may occur. Possibly edk2-staging as well.
I think it is easier to manage things like GIT attributes so they are the
same for all repos in the project.

Mike

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
Sent: Monday, August 1, 2016 1:19 AM
To: Justen, Jordan L <jordan.l.justen@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Tim Lewis <tim.lewis@insyde.com>;
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 Mon, Aug 01, 2016 at 12:03:06AM -0700, Jordan Justen wrote:
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.
While I don't disagree, the PI dependency expression instruction set
(section 10.7, PI spec 1.4 vol2) does not look Turing complete to me.
Meaning it's "binary" in much the same way a .uni file is.

(This is historically where someone pulls out an operating system
kernel written entirely in PI depex binary.)

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.
And I agree it would send that signal.

Regards,

Leif

-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_ARCHITECTURE)/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.depex
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf: DXE_DEPEX DXE_DEPEX Optional
$(WORKSPACE)/$(PLATFORM_PACKAGE)/IntelGopDepex/IntelGopDriver.depex

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