Re: [edk2] [PATCH v1 1/1] MdeModulePkg/PeiCore: Fix ConverSinglePpiPointer () typo.

[Zeng, Star]

Just pushed the patch at de74668f5ea713b7e91e01318f0d15d2bf0effce.

Thanks,
Star
-Original Message-
From: Tian, Feng 
Sent: Monday, August 15, 2016 9:32 AM
To: Zeng, Star ; marvin.haeu...@outlook.com; 
edk2-devel@lists.01.org
Cc: Tian, Feng 
Subject: RE: [PATCH v1 1/1] MdeModulePkg/PeiCore: Fix ConverSinglePpiPointer () 
typo.

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Zeng, Star 
Sent: Saturday, August 13, 2016 6:31 PM
To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org
Cc: Tian, Feng 
Subject: RE: [PATCH v1 1/1] MdeModulePkg/PeiCore: Fix ConverSinglePpiPointer () 
typo.

Reviewed-by: Star Zeng 

-Original Message-
From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] 
Sent: Saturday, August 13, 2016 9:54 AM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star 
Subject: [PATCH v1 1/1] MdeModulePkg/PeiCore: Fix ConverSinglePpiPointer () 
typo.

Rename ConverSinglePpiPointer () to ConvertSinglePpiPointer ().

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 MdeModulePkg/Core/Pei/Ppi/Ppi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Ppi/Ppi.c b/MdeModulePkg/Core/Pei/Ppi/Ppi.c 
index 706e835a7091..db6eded6d6ed 100644
--- a/MdeModulePkg/Core/Pei/Ppi/Ppi.c
+++ b/MdeModulePkg/Core/Pei/Ppi/Ppi.c
@@ -48,7 +48,7 @@ InitializePpiServices (
 
 **/
 VOID
-ConverSinglePpiPointer (
+ConvertSinglePpiPointer (
   IN PEI_PPI_LIST_POINTERS *PpiPointer,
   IN UINTN TempBottom,
   IN UINTN TempTop,
@@ -124,7 +124,7 @@ ConvertPpiPointers (
   //
   // Convert PPI pointer in old Heap
   //
-  ConverSinglePpiPointer (
+  ConvertSinglePpiPointer (
 >PpiData.PpiListPtrs[Index],
 (UINTN)SecCoreData->PeiTemporaryRamBase,
 (UINTN)SecCoreData->PeiTemporaryRamBase + 
SecCoreData->PeiTemporaryRamSize, @@ -135,7 +135,7 @@ ConvertPpiPointers (
   //
   // Convert PPI pointer in old Stack
   //
-  ConverSinglePpiPointer (
+  ConvertSinglePpiPointer (
 >PpiData.PpiListPtrs[Index],
 (UINTN)SecCoreData->StackBase,
 (UINTN)SecCoreData->StackBase + SecCoreData->StackSize, @@ -151,7 
+151,7 @@ ConvertPpiPointers (
   continue;
 }
 
-ConverSinglePpiPointer (
+ConvertSinglePpiPointer (
   >PpiData.PpiListPtrs[Index],
   (UINTN)PrivateData->HoleData[IndexHole].Base,
   (UINTN)PrivateData->HoleData[IndexHole].Base + 
PrivateData->HoleData[IndexHole].Size,
--
2.9.0.windows.1

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

[edk2] [Patch 1/3] BaseTools: Add the PKCS7 tool

[Yonghong Zhu]

Provide the PKCS7 Tool to support the CertType - EFI_CERT_TYPE_PKCS7_GUID,
then user can use this tool to add EFI_FIRMWARE_IMAGE_AUTHENTICATION
for a binary.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 BaseTools/Conf/tools_def.template  |   6 +
 BaseTools/Source/Python/Makefile   |  27 +-
 .../Python/Pkcs7Sign/GenFirmwareImageAuthPkcs7.py  | 285 +
 BaseTools/Source/Python/Pkcs7Sign/TestCert.pem |  57 +
 BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem |  19 ++
 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem |  56 
 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem |  18 ++
 BaseTools/Source/Python/Pkcs7Sign/TestSub.pem  |  57 +
 BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem  |  19 ++
 9 files changed, 541 insertions(+), 3 deletions(-)
 create mode 100644 
BaseTools/Source/Python/Pkcs7Sign/GenFirmwareImageAuthPkcs7.py
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestCert.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 974656c..a78ea77 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -7669,10 +7669,16 @@ RELEASE_RVCTCYGWIN_ARM_CC_FLAGS  = "$(CCPATH_FLAG)" 
$(ARCHCC_FLAGS) $(PLATFORM_F
 ##
 *_*_*_VPDTOOL_PATH = BPDG
 *_*_*_VPDTOOL_GUID = 8C3D856A-9BE6-468E-850A-24F7A8D38E08
 
 ##
+# Firmware Image Auth PKCS7 tool definitions
+##
+*_*_*_PKCS7_PATH   = GenFirmwareImageAuthPkcs7
+*_*_*_PKCS7_GUID   = 4AAFD29D-68DF-49EE-8AA9-347D375665A7
+
+##
 # NASM tool definitions
 ##
 *_*_*_NASM_PATH= ENV(NASM_PREFIX)nasm
 # NASMB uses NASM produce a .bin from a .nasmb NASM source file
 *_*_*_NASMB_FLAGS  = -f bin
diff --git a/BaseTools/Source/Python/Makefile b/BaseTools/Source/Python/Makefile
index 8bc213b..8d6a386 100644
--- a/BaseTools/Source/Python/Makefile
+++ b/BaseTools/Source/Python/Makefile
@@ -1,9 +1,9 @@
 ## @file
 # Windows makefile for Python tools build.
 #
-# Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
 #
@@ -29,11 +29,11 @@ 
MODULES=encodings.cp437,encodings.gbk,encodings.utf_16,encodings.utf_8,encodings
 BASE_TOOLS_PATH = $(BASE_TOOLS_PATH::\\=:\)
 EDK_TOOLS_PATH  = $(EDK_TOOLS_PATH::\\=:\)
 
 BIN_DIR=$(EDK_TOOLS_PATH)\Bin\Win32
 
-APPLICATIONS=$(BIN_DIR)\build.exe $(BIN_DIR)\GenFds.exe $(BIN_DIR)\Trim.exe 
$(BIN_DIR)\TargetTool.exe $(BIN_DIR)\GenDepex.exe 
$(BIN_DIR)\GenPatchPcdTable.exe $(BIN_DIR)\PatchPcdValue.exe 
$(BIN_DIR)\BPDG.exe $(BIN_DIR)\UPT.exe $(BIN_DIR)\Rsa2048Sha256Sign.exe 
$(BIN_DIR)\Rsa2048Sha256GenerateKeys.exe $(BIN_DIR)\Ecc.exe
+APPLICATIONS=$(BIN_DIR)\build.exe $(BIN_DIR)\GenFds.exe $(BIN_DIR)\Trim.exe 
$(BIN_DIR)\TargetTool.exe $(BIN_DIR)\GenDepex.exe 
$(BIN_DIR)\GenPatchPcdTable.exe $(BIN_DIR)\PatchPcdValue.exe 
$(BIN_DIR)\BPDG.exe $(BIN_DIR)\UPT.exe $(BIN_DIR)\Rsa2048Sha256Sign.exe 
$(BIN_DIR)\Rsa2048Sha256GenerateKeys.exe 
$(BIN_DIR)\GenFirmwareImageAuthPkcs7.exe $(BIN_DIR)\Ecc.exe
 
 COMMON_PYTHON=$(BASE_TOOLS_PATH)\Source\Python\Common\BuildToolError.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\Database.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\DataType.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\DecClassObject.py \
@@ -283,11 +283,32 @@ $(BIN_DIR)\Ecc.exe: 
$(BASE_TOOLS_PATH)\Source\Python\Ecc\Ecc.py $(CMD_ECC) $(BIN
 $(BIN_DIR)\config.ini: $(BASE_TOOLS_PATH)\Source\Python\Ecc\config.ini
   @copy /Y /B $(BASE_TOOLS_PATH)\Source\Python\Ecc\config.ini 
$(BIN_DIR)\config.ini
 
 $(BIN_DIR)\exception.xml: $(BASE_TOOLS_PATH)\Source\Python\Ecc\exception.xml
   @copy /Y /B $(BASE_TOOLS_PATH)\Source\Python\Ecc\exception.xml 
$(BIN_DIR)\exception.xml
-  
+
+$(BIN_DIR)\GenFirmwareImageAuthPkcs7.exe: 
$(BASE_TOOLS_PATH)\Source\Python\Pkcs7Sign\GenFirmwareImageAuthPkcs7.py 
$(BIN_DIR)\TestCert.pem $(BIN_DIR)\TestCert.pub.pem $(BIN_DIR)\TestRoot.pem 
$(BIN_DIR)\TestRoot.pub.pem $(BIN_DIR)\TestSub.pem $(BIN_DIR)\TestSub.pub.pem
+  @$(FREEZE) --include-modules=$(MODULES) --install-dir=$(BIN_DIR) 
Pkcs7Sign\GenFirmwareImageAuthPkcs7.py

[edk2] [Patch 3/3] BaseTools: FMP capsule add the support to generate auth info

[Yonghong Zhu]

Current BaseTools cannot generate EFI_FIRMWARE_IMAGE_AUTHENTICATION
for FMP capsule. this patch fix it by FDF spec's update to add the
definition for CERTIFICATE_GUID and  MONOTONIC_COUNT. BaseTools call
the tool by CERTIFICATE_GUID to generate the certdata and fill the header
info.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/GenFds/Capsule.py | 80 +--
 BaseTools/Source/Python/GenFds/CapsuleData.py |  4 +-
 BaseTools/Source/Python/GenFds/FdfParser.py   | 64 ++---
 BaseTools/Source/Python/GenFds/GenFds.py  | 59 +++-
 BaseTools/Source/Python/GenFds/GuidSection.py | 59 +---
 5 files changed, 194 insertions(+), 72 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/Capsule.py 
b/BaseTools/Source/Python/GenFds/Capsule.py
index 1683433..f8af12a 100644
--- a/BaseTools/Source/Python/GenFds/Capsule.py
+++ b/BaseTools/Source/Python/GenFds/Capsule.py
@@ -1,9 +1,9 @@
 ## @file
 # generate capsule
 #
-#  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
 #  http://opensource.org/licenses/bsd-license.php
@@ -23,13 +23,20 @@ import StringIO
 from Common.Misc import SaveFileOnChange
 from GenFds import GenFds
 from Common.Misc import PackRegistryFormatGuid
 import uuid
 from struct import pack
+from GenFds import FindExtendTool
+from Common import EdkLogger
+from Common.BuildToolError import *
 
 
 T_CHAR_LF = '\n'
+WIN_CERT_REVISION  = 0x0200
+WIN_CERT_TYPE_EFI_GUID = 0x0EF1
+EFI_CERT_TYPE_PKCS7_GUID = uuid.UUID('{4aafd29d-68df-49ee-8aa9-347d375665a7}')
+EFI_CERT_TYPE_RSA2048_SHA256_GUID = 
uuid.UUID('{a7717414-c616-4977-9420-844712a735bf}')
 
 ## create inf file describes what goes into capsule and call GenFv to generate 
capsule
 #
 #
 class Capsule (CapsuleClassObject) :
@@ -96,24 +103,87 @@ class Capsule (CapsuleClassObject) :
 else:
 FwMgrHdr.write(pack('=I', 0x0001))
 FwMgrHdr.write(pack('=HH', len(self.CapsuleDataList), 
len(self.FmpPayloadList)))
 FwMgrHdrSize = 
4+2+2+8*(len(self.CapsuleDataList)+len(self.FmpPayloadList))
 
+#
+# typedef struct _WIN_CERTIFICATE {
+#   UINT32 dwLength;
+#   UINT16 wRevision;
+#   UINT16 wCertificateType;
+# //UINT8 bCertificate[ANYSIZE_ARRAY];
+# } WIN_CERTIFICATE;
+#
+# typedef struct _WIN_CERTIFICATE_UEFI_GUID {
+#   WIN_CERTIFICATE Hdr;
+#   EFI_GUIDCertType;
+# //UINT8 CertData[ANYSIZE_ARRAY];
+# } WIN_CERTIFICATE_UEFI_GUID;
+#
+# typedef struct {
+#   UINT64MonotonicCount;
+#   WIN_CERTIFICATE_UEFI_GUID AuthInfo;
+# } EFI_FIRMWARE_IMAGE_AUTHENTICATION;
+#
+# typedef struct _EFI_CERT_BLOCK_RSA_2048_SHA256 {
+#   EFI_GUID HashType;
+#   UINT8 PublicKey[256];
+#   UINT8 Signature[256];
+# } EFI_CERT_BLOCK_RSA_2048_SHA256;
+#
+
 PreSize = FwMgrHdrSize
 Content = StringIO.StringIO()
 for driver in self.CapsuleDataList:
 FileName = driver.GenCapsuleSubItem()
 FwMgrHdr.write(pack('=Q', PreSize))
 PreSize += os.path.getsize(FileName)
 File = open(FileName, 'rb')
 Content.write(File.read())
 File.close()
 for fmp in self.FmpPayloadList:
-payload = fmp.GenCapsuleSubItem()
-FwMgrHdr.write(pack('=Q', PreSize))
-PreSize += len(payload)
-Content.write(payload)
+if fmp.Certificate_Guid:
+ExternalTool, ExternalOption = FindExtendTool([], 
GenFdsGlobalVariable.ArchList, fmp.Certificate_Guid)
+CmdOption = ''
+CapInputFile = fmp.ImageFile
+if not os.path.isabs(fmp.ImageFile):
+CapInputFile = 
os.path.join(GenFdsGlobalVariable.WorkSpaceDir, fmp.ImageFile)
+CapOutputTmp = os.path.join(GenFdsGlobalVariable.FvDir, 
self.UiCapsuleName) + '.tmp'
+if ExternalTool == None:
+EdkLogger.error("GenFds", GENFDS_ERROR, "No tool found 
with GUID %s" % fmp.Certificate_Guid)
+else:
+CmdOption += ExternalTool
+if ExternalOption:
+CmdOption = CmdOption + ' ' + ExternalOption
+CmdOption += ' -e ' + ' --monotonic-count ' + 
str(fmp.MonotonicCount) + ' -o ' + CapOutputTmp + ' ' + CapInputFile
+CmdList = CmdOption.split()
+   

[edk2] [Patch 2/3] BaseTools: Rsa2048Sha256Sign add new option to support Monotonic count

[Yonghong Zhu]

the EFI_FIRMWARE_IMAGE_AUTHENTICATION struct require the AuthInfo which
is a signature across the image data and the Monotonic Count value, so we
add the new option to support Monotonic count.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 .../Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py  | 31 +-
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py 
b/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
index b3254d8..3410668 100644
--- a/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
+++ b/BaseTools/Source/Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py
@@ -1,12 +1,12 @@
 ## @file
-# This tool encodes and decodes GUIDed FFS sections for a GUID type of
+# This tool encodes and decodes GUIDed FFS sections or FMP capsule for a GUID 
type of
 # EFI_CERT_TYPE_RSA2048_SHA256_GUID defined in the UEFI 2.4 Specification as
 #   {0xa7717414, 0xc616, 0x4977, {0x94, 0x20, 0x84, 0x47, 0x12, 0xa7, 0x35, 
0xbf}}
 # This tool has been tested with OpenSSL 1.0.1e 11 Feb 2013
 #
-# Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved.
+# Copyright (c) 2013 - 2016, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
 #
@@ -30,11 +30,11 @@ from Common.BuildVersion import gBUILD_VERSION
 #
 # Globals for help information
 #
 __prog__  = 'Rsa2048Sha256Sign'
 __version__   = '%s Version %s' % (__prog__, '0.9 ' + gBUILD_VERSION)
-__copyright__ = 'Copyright (c) 2013 - 2014, Intel Corporation. All rights 
reserved.'
+__copyright__ = 'Copyright (c) 2013 - 2016, Intel Corporation. All rights 
reserved.'
 __usage__ = '%s -e|-d [options] ' % (__prog__)
 
 #
 # GUID for SHA 256 Hash Algorithm from UEFI Specification
 #
@@ -64,10 +64,11 @@ if __name__ == '__main__':
   parser = argparse.ArgumentParser(prog=__prog__, version=__version__, 
usage=__usage__, description=__copyright__, conflict_handler='resolve')
   group = parser.add_mutually_exclusive_group(required=True)
   group.add_argument("-e", action="store_true", dest='Encode', help='encode 
file')
   group.add_argument("-d", action="store_true", dest='Decode', help='decode 
file')
   parser.add_argument("-o", "--output", dest='OutputFile', type=str, 
metavar='filename', help="specify the output filename", required=True)
+  parser.add_argument("--monotonic-count", dest='MonotonicCountStr', type=str, 
help="specify the MonotonicCount in FMP capsule.")
   parser.add_argument("--private-key", dest='PrivateKeyFile', 
type=argparse.FileType('rb'), help="specify the private key filename.  If not 
specified, a test signing key is used.")
   parser.add_argument("-v", "--verbose", dest='Verbose', action="store_true", 
help="increase output messages")
   parser.add_argument("-q", "--quiet", dest='Quiet', action="store_true", 
help="reduce output messages")
   parser.add_argument("--debug", dest='Debug', type=int, metavar='[0-9]', 
choices=range(0,10), default=0, help="set debug level")
   parser.add_argument(metavar="input_file", dest='InputFile', 
type=argparse.FileType('rb'), help="specify the input filename")
@@ -153,17 +154,30 @@ if __name__ == '__main__':
   while len(PublicKeyHexString) > 0:
 PublicKey = PublicKey + chr(int(PublicKeyHexString[0:2],16))
 PublicKeyHexString=PublicKeyHexString[2:]
   if Process.returncode <> 0:
 sys.exit(Process.returncode)
-  
+
+  if args.MonotonicCountStr:
+try:
+  if args.MonotonicCountStr.upper().startswith('0X'):
+args.MonotonicCountValue = (long)(args.MonotonicCountStr, 16)
+  else:
+args.MonotonicCountValue = (long)(args.MonotonicCountStr)
+except:
+pass
+
   if args.Encode:
+FullInputFileBuffer = args.InputFileBuffer
+if args.MonotonicCountStr:
+  format = "Q%ds" % len(args.InputFileBuffer)
+  FullInputFileBuffer = struct.pack(format,args.MonotonicCountValue, 
args.InputFileBuffer)
 # 
 # Sign the input file using the specified private key and capture 
signature from STDOUT
 #
 Process = subprocess.Popen('%s sha256 -sign "%s"' % (OpenSslCommand, 
args.PrivateKeyFileName), stdin=subprocess.PIPE, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
-Signature = Process.communicate(input=args.InputFileBuffer)[0]
+Signature = Process.communicate(input=FullInputFileBuffer)[0]
 if Process.returncode <> 0:
   sys.exit(Process.returncode)
   
 #
 # Write output file that contains hash GUID, Public Key, Signature, and 
Input data
@@ -194,20 +208,25 @@ if __name__ == '__main__':
 #
 if Header.PublicKey <> PublicKey:
   print 'ERROR: Public key 

[edk2] [Patch 0/3] BaseTools: Add the support for FMP capsule generate auth info

[Yonghong Zhu]

Current BaseTools cannot support the EFI_FIRMWARE_IMAGE_AUTHENTICATION struct 
for 
FMP capsule.
# typedef struct {
#   UINT64MonotonicCount;
#   WIN_CERTIFICATE_UEFI_GUID AuthInfo;
# } EFI_FIRMWARE_IMAGE_AUTHENTICATION;
Patch 1: add the PKCS7 Tool to support CertType - EFI_CERT_TYPE_PKCS7_GUID
Patch 2: update the Rsa2048Sha256Sign tool to support Monotonic count
Patch 3: update the FMP capsule generation, call the tool by CERTIFICATE_GUID 
defined in the FDF file to generate the certdata and fill the header info.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 

Yonghong Zhu (3):
  BaseTools: Add the PKCS7 tool
  BaseTools: Rsa2048Sha256Sign add new option to support Monotonic count
  BaseTools: FMP capsule add the support to generate auth info

 BaseTools/Conf/tools_def.template  |   6 +
 BaseTools/Source/Python/GenFds/Capsule.py  |  80 +-
 BaseTools/Source/Python/GenFds/CapsuleData.py  |   4 +-
 BaseTools/Source/Python/GenFds/FdfParser.py|  64 -
 BaseTools/Source/Python/GenFds/GenFds.py   |  59 -
 BaseTools/Source/Python/GenFds/GuidSection.py  |  59 +
 BaseTools/Source/Python/Makefile   |  27 +-
 .../Python/Pkcs7Sign/GenFirmwareImageAuthPkcs7.py  | 285 +
 BaseTools/Source/Python/Pkcs7Sign/TestCert.pem |  57 +
 BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem |  19 ++
 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem |  56 
 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem |  18 ++
 BaseTools/Source/Python/Pkcs7Sign/TestSub.pem  |  57 +
 BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem  |  19 ++
 .../Python/Rsa2048Sha256Sign/Rsa2048Sha256Sign.py  |  31 ++-
 15 files changed, 760 insertions(+), 81 deletions(-)
 create mode 100644 
BaseTools/Source/Python/Pkcs7Sign/GenFirmwareImageAuthPkcs7.py
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestCert.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem

-- 
2.6.1.windows.1

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

[edk2] [PATCH] UefiCpuPkg: MTRR_PHYSMASK.Valid should be one bit instead of 8 bits

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 UefiCpuPkg/Include/Register/ArchitecturalMsr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h 
b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
index a4702ed..4d4ade4 100644
--- a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
+++ b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
@@ -2092,7 +2092,7 @@ typedef union {
 ///
 /// [Bit 11] Valid Enable range mask.
 ///
-UINT32  V:8;
+UINT32  V:1;
 ///
 /// [Bits 31:12] PhysMask.  MTRR address range mask.
 ///
-- 
2.9.0.windows.1

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

Re: [edk2] [Patch 1/3] BaseTools: Add the PKCS7 tool

[Zhu, Yonghong]

Thanks. I will update it and send a new version.

Best Regards,
Zhu Yonghong


-Original Message-
From: Yao, Jiewen 
Sent: Monday, August 15, 2016 4:32 PM
To: Zhu, Yonghong ; edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: RE: [Patch 1/3] BaseTools: Add the PKCS7 tool

Hello
In order to make PKCS7 tool be consistent with RSA2048SHA256, I suggest we use 
"Pkcs7Sign.py" instead of GenFirmwareImageAuthPkcs7.py.



> -Original Message-
> From: Zhu, Yonghong
> Sent: Monday, August 15, 2016 4:18 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Yao, Jiewen 
> 
> Subject: [Patch 1/3] BaseTools: Add the PKCS7 tool
> 
> Provide the PKCS7 Tool to support the CertType - 
> EFI_CERT_TYPE_PKCS7_GUID, then user can use this tool to add 
> EFI_FIRMWARE_IMAGE_AUTHENTICATION for a binary.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  BaseTools/Conf/tools_def.template  |   6 +
>  BaseTools/Source/Python/Makefile   |  27 +-
>  .../Python/Pkcs7Sign/GenFirmwareImageAuthPkcs7.py  | 285
> +
>  BaseTools/Source/Python/Pkcs7Sign/TestCert.pem |  57 +
>  BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem |  19 ++
>  BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem |  56 
>  BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem |  18 ++
>  BaseTools/Source/Python/Pkcs7Sign/TestSub.pem  |  57 +
>  BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem  |  19 ++
>  9 files changed, 541 insertions(+), 3 deletions(-)  create mode 
> 100644 BaseTools/Source/Python/Pkcs7Sign/GenFirmwareImageAuthPkcs7.py
>  create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestCert.pem
>  create mode 100644
> BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem
>  create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem
>  create mode 100644
> BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem
>  create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pem
>  create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem
> 
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index 974656c..a78ea77 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -7669,10 +7669,16 @@ RELEASE_RVCTCYGWIN_ARM_CC_FLAGS  = 
> "$(CCPATH_FLAG)" $(ARCHCC_FLAGS) $(PLATFORM_F  ##
>  *_*_*_VPDTOOL_PATH = BPDG
>  *_*_*_VPDTOOL_GUID =
> 8C3D856A-9BE6-468E-850A-24F7A8D38E08
> 
>  ##
> +# Firmware Image Auth PKCS7 tool definitions ##
> +*_*_*_PKCS7_PATH   = GenFirmwareImageAuthPkcs7
> +*_*_*_PKCS7_GUID   =
> 4AAFD29D-68DF-49EE-8AA9-347D375665A7
> +
> +##
>  # NASM tool definitions
>  ##
>  *_*_*_NASM_PATH= ENV(NASM_PREFIX)nasm
>  # NASMB uses NASM produce a .bin from a .nasmb NASM source file
>  *_*_*_NASMB_FLAGS  = -f bin
> diff --git a/BaseTools/Source/Python/Makefile
> b/BaseTools/Source/Python/Makefile
> index 8bc213b..8d6a386 100644
> --- a/BaseTools/Source/Python/Makefile
> +++ b/BaseTools/Source/Python/Makefile
> @@ -1,9 +1,9 @@
>  ## @file
>  # Windows makefile for Python tools build.
>  #
> -# Copyright (c) 2010 - 2015, Intel Corporation. All rights 
> reserved.
> +# Copyright (c) 2010 - 2016, Intel Corporation. All rights 
> +reserved.
>  # This program and the accompanying materials  # are licensed and 
> made available under the terms and conditions of the BSD License  # 
> which accompanies this distribution.  The full text of the license may 
> be found at  # http://opensource.org/licenses/bsd-license.php
>  #
> @@ -29,11 +29,11 @@
> MODULES=encodings.cp437,encodings.gbk,encodings.utf_16,encodings.utf
> _8,encodings
>  BASE_TOOLS_PATH = $(BASE_TOOLS_PATH::\\=:\)  EDK_TOOLS_PATH  = 
> $(EDK_TOOLS_PATH::\\=:\)
> 
>  BIN_DIR=$(EDK_TOOLS_PATH)\Bin\Win32
> 
> -APPLICATIONS=$(BIN_DIR)\build.exe $(BIN_DIR)\GenFds.exe 
> $(BIN_DIR)\Trim.exe $(BIN_DIR)\TargetTool.exe $(BIN_DIR)\GenDepex.exe 
> $(BIN_DIR)\GenPatchPcdTable.exe $(BIN_DIR)\PatchPcdValue.exe 
> $(BIN_DIR)\BPDG.exe $(BIN_DIR)\UPT.exe 
> $(BIN_DIR)\Rsa2048Sha256Sign.exe 
> $(BIN_DIR)\Rsa2048Sha256GenerateKeys.exe $(BIN_DIR)\Ecc.exe
> +APPLICATIONS=$(BIN_DIR)\build.exe $(BIN_DIR)\GenFds.exe
> $(BIN_DIR)\Trim.exe $(BIN_DIR)\TargetTool.exe $(BIN_DIR)\GenDepex.exe 
> $(BIN_DIR)\GenPatchPcdTable.exe $(BIN_DIR)\PatchPcdValue.exe 
> $(BIN_DIR)\BPDG.exe $(BIN_DIR)\UPT.exe 
> $(BIN_DIR)\Rsa2048Sha256Sign.exe 
> $(BIN_DIR)\Rsa2048Sha256GenerateKeys.exe
> $(BIN_DIR)\GenFirmwareImageAuthPkcs7.exe $(BIN_DIR)\Ecc.exe
> 
> 
> COMMON_PYTHON=$(BASE_TOOLS_PATH)\Source\Python\Common\BuildT
> oolError.py \
> 
> $(BASE_TOOLS_PATH)\Source\Python\Common\Database.py \
> 
> 

Re: [edk2] [Patch 1/3] BaseTools: Add the PKCS7 tool

[Yao, Jiewen]

Hello
In order to make PKCS7 tool be consistent with RSA2048SHA256, I suggest we use 
"Pkcs7Sign.py" instead of GenFirmwareImageAuthPkcs7.py.



> -Original Message-
> From: Zhu, Yonghong
> Sent: Monday, August 15, 2016 4:18 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Yao, Jiewen
> 
> Subject: [Patch 1/3] BaseTools: Add the PKCS7 tool
> 
> Provide the PKCS7 Tool to support the CertType -
> EFI_CERT_TYPE_PKCS7_GUID,
> then user can use this tool to add EFI_FIRMWARE_IMAGE_AUTHENTICATION
> for a binary.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  BaseTools/Conf/tools_def.template  |   6 +
>  BaseTools/Source/Python/Makefile   |  27 +-
>  .../Python/Pkcs7Sign/GenFirmwareImageAuthPkcs7.py  | 285
> +
>  BaseTools/Source/Python/Pkcs7Sign/TestCert.pem |  57 +
>  BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem |  19 ++
>  BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem |  56 
>  BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem |  18 ++
>  BaseTools/Source/Python/Pkcs7Sign/TestSub.pem  |  57 +
>  BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem  |  19 ++
>  9 files changed, 541 insertions(+), 3 deletions(-)
>  create mode 100644
> BaseTools/Source/Python/Pkcs7Sign/GenFirmwareImageAuthPkcs7.py
>  create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestCert.pem
>  create mode 100644
> BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem
>  create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem
>  create mode 100644
> BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem
>  create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pem
>  create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem
> 
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index 974656c..a78ea77 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -7669,10 +7669,16 @@ RELEASE_RVCTCYGWIN_ARM_CC_FLAGS  =
> "$(CCPATH_FLAG)" $(ARCHCC_FLAGS) $(PLATFORM_F
>  ##
>  *_*_*_VPDTOOL_PATH = BPDG
>  *_*_*_VPDTOOL_GUID =
> 8C3D856A-9BE6-468E-850A-24F7A8D38E08
> 
>  ##
> +# Firmware Image Auth PKCS7 tool definitions
> +##
> +*_*_*_PKCS7_PATH   = GenFirmwareImageAuthPkcs7
> +*_*_*_PKCS7_GUID   =
> 4AAFD29D-68DF-49EE-8AA9-347D375665A7
> +
> +##
>  # NASM tool definitions
>  ##
>  *_*_*_NASM_PATH= ENV(NASM_PREFIX)nasm
>  # NASMB uses NASM produce a .bin from a .nasmb NASM source file
>  *_*_*_NASMB_FLAGS  = -f bin
> diff --git a/BaseTools/Source/Python/Makefile
> b/BaseTools/Source/Python/Makefile
> index 8bc213b..8d6a386 100644
> --- a/BaseTools/Source/Python/Makefile
> +++ b/BaseTools/Source/Python/Makefile
> @@ -1,9 +1,9 @@
>  ## @file
>  # Windows makefile for Python tools build.
>  #
> -# Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
> +# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
>  # This program and the accompanying materials
>  # are licensed and made available under the terms and conditions of the
> BSD License
>  # which accompanies this distribution.  The full text of the license may be
> found at
>  # http://opensource.org/licenses/bsd-license.php
>  #
> @@ -29,11 +29,11 @@
> MODULES=encodings.cp437,encodings.gbk,encodings.utf_16,encodings.utf
> _8,encodings
>  BASE_TOOLS_PATH = $(BASE_TOOLS_PATH::\\=:\)
>  EDK_TOOLS_PATH  = $(EDK_TOOLS_PATH::\\=:\)
> 
>  BIN_DIR=$(EDK_TOOLS_PATH)\Bin\Win32
> 
> -APPLICATIONS=$(BIN_DIR)\build.exe $(BIN_DIR)\GenFds.exe
> $(BIN_DIR)\Trim.exe $(BIN_DIR)\TargetTool.exe $(BIN_DIR)\GenDepex.exe
> $(BIN_DIR)\GenPatchPcdTable.exe $(BIN_DIR)\PatchPcdValue.exe
> $(BIN_DIR)\BPDG.exe $(BIN_DIR)\UPT.exe
> $(BIN_DIR)\Rsa2048Sha256Sign.exe
> $(BIN_DIR)\Rsa2048Sha256GenerateKeys.exe $(BIN_DIR)\Ecc.exe
> +APPLICATIONS=$(BIN_DIR)\build.exe $(BIN_DIR)\GenFds.exe
> $(BIN_DIR)\Trim.exe $(BIN_DIR)\TargetTool.exe $(BIN_DIR)\GenDepex.exe
> $(BIN_DIR)\GenPatchPcdTable.exe $(BIN_DIR)\PatchPcdValue.exe
> $(BIN_DIR)\BPDG.exe $(BIN_DIR)\UPT.exe
> $(BIN_DIR)\Rsa2048Sha256Sign.exe
> $(BIN_DIR)\Rsa2048Sha256GenerateKeys.exe
> $(BIN_DIR)\GenFirmwareImageAuthPkcs7.exe $(BIN_DIR)\Ecc.exe
> 
> 
> COMMON_PYTHON=$(BASE_TOOLS_PATH)\Source\Python\Common\BuildT
> oolError.py \
> 
> $(BASE_TOOLS_PATH)\Source\Python\Common\Database.py \
> 
> $(BASE_TOOLS_PATH)\Source\Python\Common\DataType.py \
> 
> $(BASE_TOOLS_PATH)\Source\Python\Common\DecClassObject.py \
> @@ -283,11 +283,32 @@ $(BIN_DIR)\Ecc.exe:
> $(BASE_TOOLS_PATH)\Source\Python\Ecc\Ecc.py $(CMD_ECC) $(BIN
>  $(BIN_DIR)\config.ini: $(BASE_TOOLS_PATH)\Source\Python\Ecc\config.ini
>@copy /Y /B $(BASE_TOOLS_PATH)\Source\Python\Ecc\config.ini
> 

[edk2] [Patch 1/3 V2] BaseTools: Add the PKCS7 tool

[Yonghong Zhu]

Provide the PKCS7 Tool to support the CertType - EFI_CERT_TYPE_PKCS7_GUID,
then user can use this tool to add EFI_FIRMWARE_IMAGE_AUTHENTICATION
for a binary.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
---
 BaseTools/Conf/tools_def.template  |   6 +
 BaseTools/Source/Python/Makefile   |  27 +-
 BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py | 282 +
 BaseTools/Source/Python/Pkcs7Sign/TestCert.pem |  57 +
 BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem |  19 ++
 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem |  56 
 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem |  18 ++
 BaseTools/Source/Python/Pkcs7Sign/TestSub.pem  |  57 +
 BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem  |  19 ++
 9 files changed, 538 insertions(+), 3 deletions(-)
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/Pkcs7Sign.py
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestCert.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestCert.pub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestRoot.pub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pem
 create mode 100644 BaseTools/Source/Python/Pkcs7Sign/TestSub.pub.pem

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 974656c..fe3a22b 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -7669,10 +7669,16 @@ RELEASE_RVCTCYGWIN_ARM_CC_FLAGS  = "$(CCPATH_FLAG)" 
$(ARCHCC_FLAGS) $(PLATFORM_F
 ##
 *_*_*_VPDTOOL_PATH = BPDG
 *_*_*_VPDTOOL_GUID = 8C3D856A-9BE6-468E-850A-24F7A8D38E08
 
 ##
+# Pkcs7Sign tool definitions
+##
+*_*_*_PKCS7SIGN_PATH   = Pkcs7Sign
+*_*_*_PKCS7SIGN_GUID   = 4AAFD29D-68DF-49EE-8AA9-347D375665A7
+
+##
 # NASM tool definitions
 ##
 *_*_*_NASM_PATH= ENV(NASM_PREFIX)nasm
 # NASMB uses NASM produce a .bin from a .nasmb NASM source file
 *_*_*_NASMB_FLAGS  = -f bin
diff --git a/BaseTools/Source/Python/Makefile b/BaseTools/Source/Python/Makefile
index 8bc213b..28be671 100644
--- a/BaseTools/Source/Python/Makefile
+++ b/BaseTools/Source/Python/Makefile
@@ -1,9 +1,9 @@
 ## @file
 # Windows makefile for Python tools build.
 #
-# Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
 #
@@ -29,11 +29,11 @@ 
MODULES=encodings.cp437,encodings.gbk,encodings.utf_16,encodings.utf_8,encodings
 BASE_TOOLS_PATH = $(BASE_TOOLS_PATH::\\=:\)
 EDK_TOOLS_PATH  = $(EDK_TOOLS_PATH::\\=:\)
 
 BIN_DIR=$(EDK_TOOLS_PATH)\Bin\Win32
 
-APPLICATIONS=$(BIN_DIR)\build.exe $(BIN_DIR)\GenFds.exe $(BIN_DIR)\Trim.exe 
$(BIN_DIR)\TargetTool.exe $(BIN_DIR)\GenDepex.exe 
$(BIN_DIR)\GenPatchPcdTable.exe $(BIN_DIR)\PatchPcdValue.exe 
$(BIN_DIR)\BPDG.exe $(BIN_DIR)\UPT.exe $(BIN_DIR)\Rsa2048Sha256Sign.exe 
$(BIN_DIR)\Rsa2048Sha256GenerateKeys.exe $(BIN_DIR)\Ecc.exe
+APPLICATIONS=$(BIN_DIR)\build.exe $(BIN_DIR)\GenFds.exe $(BIN_DIR)\Trim.exe 
$(BIN_DIR)\TargetTool.exe $(BIN_DIR)\GenDepex.exe 
$(BIN_DIR)\GenPatchPcdTable.exe $(BIN_DIR)\PatchPcdValue.exe 
$(BIN_DIR)\BPDG.exe $(BIN_DIR)\UPT.exe $(BIN_DIR)\Rsa2048Sha256Sign.exe 
$(BIN_DIR)\Rsa2048Sha256GenerateKeys.exe $(BIN_DIR)\Pkcs7Sign.exe 
$(BIN_DIR)\Ecc.exe
 
 COMMON_PYTHON=$(BASE_TOOLS_PATH)\Source\Python\Common\BuildToolError.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\Database.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\DataType.py \
   $(BASE_TOOLS_PATH)\Source\Python\Common\DecClassObject.py \
@@ -283,11 +283,32 @@ $(BIN_DIR)\Ecc.exe: 
$(BASE_TOOLS_PATH)\Source\Python\Ecc\Ecc.py $(CMD_ECC) $(BIN
 $(BIN_DIR)\config.ini: $(BASE_TOOLS_PATH)\Source\Python\Ecc\config.ini
   @copy /Y /B $(BASE_TOOLS_PATH)\Source\Python\Ecc\config.ini 
$(BIN_DIR)\config.ini
 
 $(BIN_DIR)\exception.xml: $(BASE_TOOLS_PATH)\Source\Python\Ecc\exception.xml
   @copy /Y /B $(BASE_TOOLS_PATH)\Source\Python\Ecc\exception.xml 
$(BIN_DIR)\exception.xml
-  
+
+$(BIN_DIR)\Pkcs7Sign.exe: 
$(BASE_TOOLS_PATH)\Source\Python\Pkcs7Sign\Pkcs7Sign.py $(BIN_DIR)\TestCert.pem 
$(BIN_DIR)\TestCert.pub.pem $(BIN_DIR)\TestRoot.pem $(BIN_DIR)\TestRoot.pub.pem 
$(BIN_DIR)\TestSub.pem $(BIN_DIR)\TestSub.pub.pem
+  @$(FREEZE) --include-modules=$(MODULES) --install-dir=$(BIN_DIR) 
Pkcs7Sign\Pkcs7Sign.py
+
+$(BIN_DIR)\TestCert.pem: 
$(BASE_TOOLS_PATH)\Source\Python\Pkcs7Sign\TestCert.pem
+  @copy /Y /B 

Re: [edk2] IP4 Config Troubles with DHCP

[Cohen, Eugene]

Jiaxin,
 
> Actually, you don't need to retry the UDP configuration loop according
> the Ip4Mode.IsConfigured flag. You are only recommended to set a
> timer to check the mapping status after the configuration:
> 
> For example:
>   Status = Nlc->Udp4->Configure(Nlc->Udp4, >UdpConfig);
>   if (EFI_ERROR (Status) && (Status != EFI_NO_MAPPING)) {
>   return  Status;
>   }
>   if (Status == EFI_NO_MAPPING && !UdpGetMapping (Nlc->Udp4)) {
>   return  Status;
>   }
> 
> In UdpGetMapping () function, create one timer to check
> Ip4Mode.IsConfigured:
> 
> For example:
> UdpGetMapping () {
>   IsMapDone = FALSE;
>   gBS->CreateEvent (EVT_TIMER, TPL_CALLBACK, NULL, NULL,
> );
>   gBS->SetTimer (TimeoutEvent, TimerRelative, AnyValue);
>   while (EFI_ERROR (gBS->CheckEvent (TimeoutEvent))) {
> Udp4->Poll (Udp4);
> Udp4->GetModeData (Udp4, , & Ip4Mode, NULL,
> NULL);
> if (Ip4Mode.IsConfigured) {
>   IsMapDone = TRUE;
>   break;
> }
>   }
>   return IsMapDone;
> }
> 
> If DHCP process succeed, Ip4Mode.IsConfigured should be updated. If
> not, any bug may be existed.

In testing the new patch (removing RECONFIG=TRUE) I see that the statement you 
made above is not accurate when the protocol is TCP.  When Configure is called 
the first time it returns EFI_NO_MAPPING.  This seems to be remembered in the 
socket state: ((Sock)->ConfigureState == SO_NO_MAPPING) so that any attempt to 
use the instance after Ip4Mode.IsConfigured goes TRUE fails (like for a TCP4 
Listen).

So for TCP we must issue another Configure request to clean up this state so 
it's not as simple as just polling the GetModeData result, at least for TCP.

Do you believe this is expected behavior?

Thanks,

Eugene


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

Re: [edk2] [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c

[Duran, Leo]

> -Original Message-
> From: Zhu, Yonghong [mailto:yonghong@intel.com]
> Sent: Sunday, August 14, 2016 7:16 PM
> To: Ard Biesheuvel ; Duran, Leo
> 
> Cc: Gao, Liming ; edk2-devel@lists.01.org; Zhu,
> Yonghong 
> Subject: RE: [edk2] [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c
> 
> Leo,   Thanks for the Contribution. It is good.
> Ard,Thanks for help to push the patch.
> 
> Best Regards,
> Zhu Yonghong
[Duran, Leo] 
Thank you Zhu and Ard.

BTW, I assume the executable 'auto-magically' gets built from source?
(I only submitted  a patch for the source... Was that sufficient?)

Thanks,
Leo.

> 
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, August 15, 2016 3:25 AM
> To: Duran, Leo 
> Cc: Gao, Liming ; Zhu, Yonghong
> ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c
> 
> On 14 August 2016 at 17:05, Duran, Leo  wrote:
> >
> >> -Original Message-
> >> From: Gao, Liming [mailto:liming@intel.com]
> >> Sent: Friday, August 12, 2016 3:32 AM
> >> To: Duran, Leo ; edk2-devel@lists.01.org
> >> Cc: Zhu, Yonghong 
> >> Subject: RE: [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c
> >>
> >> Duran:
> >>   Reusing FvForceRebase flag is a good idea to resolve this issue. I
> >> agree your change. Reviewed-by: Liming Gao 
> >>
> > [Duran, Leo]
> > Excellent, thanks!
> >
> > Please advise on "next steps":
> > 1) Do we need a reply from Yonghong Zhu?
> > 2) When would it be reasonable to expect integration of this code into
> mainline?
> >
> 
> Hi all,
> 
> I pushed this (with Liming's R-b) as
> 
> adb6ac256338 BaseTools/GenFv: Account for rebase of FV section containing
> VTF file
> 
> Thanks,
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] DHCP Automatic Configure at Driver Connect

[Cohen, Eugene]

Jiaxin,

> > > In my memory, we only talked about the performance issue before.
> > > Here, I understand your requirement: 1) The network interface should
> > > be in
> > > *un-
> > > configured* status at each boot time until the third part
> > > configuration;

Yes, we would like a policy setting (either runtime/protocol or build-time/PCD 
is fine) for this.

 2) the policy setting should be ignored, right? I
> > > don't

I don't know what you mean by this.  The static/dhcp policy shouldn't 
necessarily be ignored but if the interface is not yet configured (i.e. the IP 
layer won't respond to packets) then the static/dhcp policy doesn't really 
matter until some component calls Configure() for the first time.

> This is what I want to confirm with you that my understanding is right? You
> complained the network interface comes "up" at each boot, what does
> "comes up" exactly mean? So, I gave the above two guesses 1) and 2).

And I tried to clarify what I meant.  Another way of saying it is by being "up" 
it means performing DHCP (if that is the setting) and transmitting/receiving 
packets using the IP address.  What we are asking for is a policy where we can 
suppress this behavior until the first Configure() call like before.

> Of course not. I mean if my guessing 2) is correct, it's not reasonable 
> because
> UEFI 2.6 spec only defined Static/DHCP policy. The policy should be in one of
> them. I just recalled the old Ip4Config behavior: no policy assigned default 
> (if
> I remember correctly).  So, don't misunderstand my truly means. It's
> unrelated to the *behavior consistency*.

Perhaps not spec consistency but we need this for implementation consistency 
since we've built up years of expectations from the previous implementation.

> First, *based on the current UEFI Spec (only static / dhcp policy)*, I want to
> highlight my understanding of *un-configured* status you mentioned: policy
> should be always set, *un-configured* means *no IP address configuration*.

Correct, in that the device will neither transmit or respond at an IP layer 
initially.

> If we want to implement such a *un-configured* state, one *DXE_DRIVER*
> can be used with Ip4Config2 protocol. Detailed see below pseudocode:
> 
> First,  register a notify for Ip4Config2 protocol in your Dxe Driver 
> EntryPoint:
> EfiCreateProtocolNotifyEvent (
> ,
> TPL_CALLBACK,
> Ip4Config2InstalledCallback,
> NULL,
> 
> );
> 
> Then, In your Ip4Config2InstalledCallback() function, you can change the
> default policy for the current boot:
>  Ip4Config2InstalledCallback () {
>  gBS->LocateProtocol (
>   ,
>   Registration,
>   (VOID **) 
>   );
> 
>  //
>  // Change the policy to Ip4Config2PolicyDhcp to clean the static 
> setting.
> //
> Policy = Ip4Config2PolicyDhcp;
> Ip4Config2Instance->SetData(
> Ip4Config2Instance,
> 
> Ip4Config2DataTypePolicy,
> sizeof 
> (EFI_IP4_CONFIG2_POLICY),
> 
> );
> 
>  //
>  // Change the policy to Ip4Config2PolicyStatic to clean the DHCP 
> policy
> setting.
> //
> Policy = Ip4Config2PolicyStatic;
> Ip4Config2Instance->SetData(
> Ip4Config2Instance,
> 
> Ip4Config2DataTypePolicy,
> sizeof 
> (EFI_IP4_CONFIG2_POLICY),
> 
> );
> }
> 
> After that, your previous setting will be cleaned, and reach a  *un-
> configured* state. I know the addition Dxe Driver is an indirect way to meet
> your requirement, but based on current UEFI Spec, it's one-time event if you
> added in  your platform ahead.

There's two issues I see with this approach:

1. It destroys any previous configuration data that the user may have made 
(static IP entry or explicit selection of DHCP)
2. It's a hack where we're using one policy interface to try to accomplish 
something unrelated (auto vs on-demand config) based on attributes of the 
current implementation and not the spec

So I'd like to propose again that we define another, separate, policy value for 
automatic versus on-demand IP configuration.  It can be either through a PCD or 
a protocol interface.  My preference in the short term is to do the PCD thing 
since we can do it now where the protocol approach will require spec 
modification.

Let me know if that makes sense - I'm prepared to provide a patch for the PCD 
option if/when you're 

Re: [edk2] USB 3.1 Support in UEFI

[GN Keshava]

Hello Feng,

Thank you for the reply.

I understood, USB type C displayport alternate mode needs mux switch, and
hence should be supported by silicon vendor.

Whether DisplayPort is supported ? (not usb type c, i just need to use
DisplayPort (instead of vga display, i want to use displayport and
supported monitor and cable)).

Thanks again,
Keshava

On Mon, 15 Aug 2016 at 07:29 Tian, Feng  wrote:

> Yes, UEFI bios supports those usb3.0 host controllers which follow XHCI
> spec(
> http://www.intel.com/content/www/us/en/io/universal-serial-bus/extensible-host-controler-interface-usb-xhci.html),
> and usb3.0 device.
>
> As for usb 3.1, it's a little complicated. What I can say is we got
> feedback it works at the configuration of usb3.0/3.1 devices plus XHCI 1.1
> compliance controllers.
>
> Last, for USB Type-C and DisplayPort Alternate Mode on USB Type-C, it's
> totally transparent for UEFI USB host controller driver and usb device
> driver. It should be supported by platform/silicon driver to switch the MUX.
>
> Thanks
> Feng
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of GN
> Keshava
> Sent: Saturday, August 13, 2016 4:40 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] USB 3.1 Support in UEFI
>
> Hi all,
>
> I heard that UEFI supports USB3.0. Please confirm.
> Also let me know if *USB3.1 is supported in UEFI?*
>
> Als, It would be helpful if anybody please let me know DisplayPort or USB
> type C is supported in UEFI.
>
> Thanks,
> With regards,
> Keshava
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 01/11] MdePkg/UefiSpec.h: Align function header of ResetSystem to UEFI Spec

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Ni, Ruiyu
> Sent: Wednesday, August 10, 2016 1:56 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [PATCH 01/11] MdePkg/UefiSpec.h: Align function header of
> ResetSystem to UEFI Spec
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni 
> Cc: Liming Gao 
> ---
>  MdePkg/Include/Uefi/UefiSpec.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h
> b/MdePkg/Include/Uefi/UefiSpec.h
> index e8feed1..57cb4e8 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -1004,11 +1004,15 @@ EFI_STATUS
> 
>@param[in]  ResetType The type of reset to perform.
>@param[in]  ResetStatus   The status code for the reset.
> -  @param[in]  DataSize  The size, in bytes, of WatchdogData.
> +  @param[in]  DataSize  The size, in bytes, of ResetData.
>@param[in]  ResetData For a ResetType of EfiResetCold, 
> EfiResetWarm,
> or
>  EfiResetShutdown the data buffer starts with 
> a Null-
> terminated
>  string, optionally followed by additional 
> binary data.
> -
> +The string is a description that the caller 
> may use to further
> +indicate the reason for the system reset. 
> ResetData is only
> +valid if ResetStatus is something other than 
> EFI_SUCCESS
> +unless the ResetType is 
> EfiResetPlatformSpecific
> +where a minimum amount of ResetData is 
> always required.
>  **/
>  typedef
>  VOID
> --
> 2.9.0.windows.1

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

Re: [edk2] [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c

[Gao, Liming]

Yes. BaseTools Win32 Binary will auto be updated based on BaseTools source.

Thanks
Liming
From: Duran, Leo [mailto:leo.du...@amd.com]
Sent: Monday, August 15, 2016 9:13 PM
To: Zhu, Yonghong ; Ard Biesheuvel 

Cc: Gao, Liming ; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c



> -Original Message-
> From: Zhu, Yonghong [mailto:yonghong@intel.com]
> Sent: Sunday, August 14, 2016 7:16 PM
> To: Ard Biesheuvel ; Duran, Leo
>
> Cc: Gao, Liming ; edk2-devel@lists.01.org; 
> Zhu,
> Yonghong
> Subject: RE: [edk2] [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c
>
> Leo, Thanks for the Contribution. It is good.
> Ard, Thanks for help to push the patch.
>
> Best Regards,
> Zhu Yonghong
[Duran, Leo]
Thank you Zhu and Ard.

BTW, I assume the executable 'auto-magically' gets built from source?
(I only submitted a patch for the source... Was that sufficient?)

Thanks,
Leo.

>
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, August 15, 2016 3:25 AM
> To: Duran, Leo
> Cc: Gao, Liming ; Zhu, Yonghong
> ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c
>
> On 14 August 2016 at 17:05, Duran, Leo wrote:
> >
> >> -Original Message-
> >> From: Gao, Liming [mailto:liming@intel.com]
> >> Sent: Friday, August 12, 2016 3:32 AM
> >> To: Duran, Leo ; edk2-devel@lists.01.org
> >> Cc: Zhu, Yonghong
> >> Subject: RE: [PATCH] BaseTools/Source/C/GenFv/GenFvInternalLib.c
> >>
> >> Duran:
> >> Reusing FvForceRebase flag is a good idea to resolve this issue. I
> >> agree your change. Reviewed-by: Liming Gao
> >>
> > [Duran, Leo]
> > Excellent, thanks!
> >
> > Please advise on "next steps":
> > 1) Do we need a reply from Yonghong Zhu?
> > 2) When would it be reasonable to expect integration of this code into
> mainline?
> >
>
> Hi all,
>
> I pushed this (with Liming's R-b) as
>
> adb6ac256338 BaseTools/GenFv: Account for rebase of FV section containing
> VTF file
>
> Thanks,
> Ard.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Setting BuildOptions by module type does not seem to work

[Andrew Fish]

> On Aug 15, 2016, at 9:10 AM, Kurt Kennett  wrote:
> 
> DSC spec (January 2016 1.26) says I can do this:
> 
> (Section 3.6 pp 76)
> 
> ...
> * [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
> ...
> 
> And this works fine:
> 
> [BuildOptions.AARCH64.common]
>*_VS2015x86_*_DLINK_FLAGS = /BORK
> 
> But when I also do:
> 
> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>*_VS2015x86_*_DLINK_FLAGS = /PLOR
> 
> The link flags are not affected on the command line - they get the /BORK for 
> all module types, but not the /PLOR for DXE_RUNTIME_DRIVERs.
> 

Kurt,

Have you tried [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]? Do you need EDK 
compatibility? 

I'm guessing that works given:
~/work/src/edk2(master)>git grep "BuildOptions." -- *.dsc | grep 
DXE_RUNTIME_DRIVER
OvmfPkg/OvmfPkgIa32.dsc:49:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
OvmfPkg/OvmfPkgIa32X64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
OvmfPkg/OvmfPkgX64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
QuarkPlatformPkg/Quark.dsc:885:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]


> I'm not familiar with the DSC processing tools source.  Anybody know where to 
> look to see why not?
> 

It starts here: 
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/build/build.py
 and uses some code from: 
https://github.com/tianocore/edk2/tree/master/BaseTools/Source/Python/Common

Thanks,

Andrew Fish

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

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

Re: [edk2] Setting BuildOptions by module type does not seem to work

[Andrew Fish]

> On Aug 15, 2016, at 9:34 AM, Kurt Kennett  wrote:
> 
> No, I had not tried that.  I tried it now and it does not seem to work.
> 
> I have:
> 
> [BuildOptions.AARCH64.common]
>*_VS2015x86_AARCH64_DLINK_FLAGS = /BORK
> 
> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>*_VS2015x86_AARCH64_DLINK_FLAGS = /PLOR
> 
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
>*_VS2015x86_AARCH64_DLINK_FLAGS = /BONK
> 
> And the only one that makes it to the command line is the /BORK one.
> 
> (The tools do not complain about the specification of options as above).
> 

I'm guessing the syntax checking is not very good? 
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
[BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]

I see the [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] form used in other 
places, but you have an extra .common? 

Thanks,

Andrew Fish

> K2
> 
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com] 
> Sent: Monday, August 15, 2016 9:22 AM
> To: Kurt Kennett 
> Cc: edk2-devel 
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work
> 
> 
>> On Aug 15, 2016, at 9:10 AM, Kurt Kennett  wrote:
>> 
>> DSC spec (January 2016 1.26) says I can do this:
>> 
>> (Section 3.6 pp 76)
>> 
>> ...
>> * [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
>> ...
>> 
>> And this works fine:
>> 
>> [BuildOptions.AARCH64.common]
>>   *_VS2015x86_*_DLINK_FLAGS = /BORK
>> 
>> But when I also do:
>> 
>> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>>   *_VS2015x86_*_DLINK_FLAGS = /PLOR
>> 
>> The link flags are not affected on the command line - they get the /BORK for 
>> all module types, but not the /PLOR for DXE_RUNTIME_DRIVERs.
>> 
> 
> Kurt,
> 
> Have you tried [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]? Do you need 
> EDK compatibility? 
> 
> I'm guessing that works given:
> ~/work/src/edk2(master)>git grep "BuildOptions." -- *.dsc | grep 
> DXE_RUNTIME_DRIVER 
> OvmfPkg/OvmfPkgIa32.dsc:49:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> OvmfPkg/OvmfPkgIa32X64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> OvmfPkg/OvmfPkgX64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> QuarkPlatformPkg/Quark.dsc:885:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> 
> 
>> I'm not familiar with the DSC processing tools source.  Anybody know where 
>> to look to see why not?
>> 
> 
> It starts here: 
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/build/build.py
>  and uses some code from: 
> https://github.com/tianocore/edk2/tree/master/BaseTools/Source/Python/Common
> 
> Thanks,
> 
> Andrew Fish
> 
>> K2
>> 
>> 
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core by grabbing memory from PeiTemporaryRamBase?

[Andrew Fish]

> On Aug 15, 2016, at 8:54 AM, Gao, Liming  wrote:
> 
> Andrew:
>  In permanent memory, PeiCore places heap base as stack top. Heap is above 
> stack. There is no hole between them. SEC needs to follow this layout and 
> migrate the temporary memory to permanent memory. It should copy TemporaryRam 
> HEAP and STACK range separately. HEAP range is specified by 
> PeiTemporaryRamBase and PeiTemporaryRamSize, and STACK range is specified by 
> StackBase and StackSize. The grabbed memory is not migrated, because PeiCore 
> doesn't know it. But, EmulatorPkg Sec SecTemporaryRamSupport() migrates the 
> whole temporary memory together. The grabbed memory is also migrated and 
> wrongly regarded as heap data. So, the fix is to update 
> SecTemporaryRamSupport() implementation in SEC. 
> 

Limiing,

I don't see any info in the PPI definition or the PI spec that defines the heap 
and stack are copied separately? The PPI just passes the entire ranges? That is 
why I assumes in the PPI case the offsets should be relative to the big shift?

/**
  This service of the EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI that migrates temporary 
RAM into
  permanent memory.

  @param PeiServicesPointer to the PEI Services Table.
  @param TemporaryMemoryBaseSource Address in temporary memory from which 
the SEC or PEIM will copy the
Temporary RAM contents.
  @param PermanentMemoryBaseDestination Address in permanent memory into 
which the SEC or PEIM will copy the
Temporary RAM contents.
  @param CopySize   Amount of memory to migrate from temporary to 
permanent memory.

  @retval EFI_SUCCESS   The data was successfully returned.
  @retval EFI_INVALID_PARAMETER PermanentMemoryBase + CopySize > 
TemporaryMemoryBase when
TemporaryMemoryBase > PermanentMemoryBase.

**/
typedef
EFI_STATUS
(EFIAPI * TEMPORARY_RAM_MIGRATION)(
  IN CONST EFI_PEI_SERVICES   **PeiServices,
  IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase,
  IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase,
  IN UINTNCopySize
);


Thanks,

Andrew Fish

> Thanks
> Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
> Fish
> Sent: Saturday, August 13, 2016 7:25 AM
> To: edk2-devel 
> Subject: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core 
> by grabbing memory from PeiTemporaryRamBase?
> 
> I grabbed some memory between SEC and the PEI Core by adjusting SecCoreData-> 
> PeiTemporaryRamBase and SecCoreData-> PeiTemporaryRamSize.
> 
> When looking at the code I don't really understand the logic of the 
> algorithm? So maybe I'm doing something wrong. 
> 
> This adjustment does not seem right to me?
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c#L768
>  //
>  // Heap Offset
>  //
>  BaseOfNewHeap = TopOfNewStack;
>  if (BaseOfNewHeap >= (UINTN)SecCoreData->PeiTemporaryRamBase) {
>Private->HeapOffsetPositive = TRUE;
>Private->HeapOffset = (UINTN)(BaseOfNewHeap - 
> (UINTN)SecCoreData->PeiTemporaryRamBase);
>  } else {
>Private->HeapOffsetPositive = FALSE;
>Private->HeapOffset = (UINTN)((UINTN)SecCoreData->PeiTemporaryRamBase 
> - BaseOfNewHeap);
>  }
> 
> 
> The above code seems to be making a very strange adjustment. I noticed the 
> adjustment in my failing case was off by 0xC0 which is the amount of memory I 
> carved out prior to entering the PEI Core. 
> 
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c#L796
> 
>  //
>  // Temporary Ram Support PPI is provided by platform, it will copy 
>  // temporary memory to permenent memory and do stack switching.
>  // After invoking Temporary Ram Support PPI, the following code's 
>  // stack is in permanent memory.
>  //
>  TemporaryRamSupportPpi->TemporaryRamMigration (
>PeiServices,
>TemporaryRamBase,
>(EFI_PHYSICAL_ADDRESS)(UINTN)(TopOfNewStack - 
> TemporaryStackSize),
>TemporaryRamSize
>);
> 
> 
> And this is also a case in which the stack got bigger. But it seems to me the 
> shift if really defined by TemporaryRamBase, TopOfNewStack, and 
> TemporaryStackSize in this case. 
> 
> The failure I hit was OldCoreData->Fv pointer was shifted so when the PPI was 
> called the system crashed. Is this a bug in the 
> gEfiTemporaryRamSupportPpiGuid path?
> 
> If I changed the HeadOffset algorithm my crash went away? Private->HeapOffset 
> = ((UINTN)TopOfNewStack - TemporaryStackSize) - TemporaryRamBase;
> 
> Thanks,
> 
> Andrew Fish
> 
> PS My failure case was the EmulatorPkg. I've not had a chance to verify this 
> failure in 

Re: [edk2] Setting BuildOptions by module type does not seem to work

[Kurt Kennett]

No, I had not tried that.  I tried it now and it does not seem to work.

I have:

[BuildOptions.AARCH64.common]
*_VS2015x86_AARCH64_DLINK_FLAGS = /BORK

[BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
*_VS2015x86_AARCH64_DLINK_FLAGS = /PLOR

[BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
*_VS2015x86_AARCH64_DLINK_FLAGS = /BONK

And the only one that makes it to the command line is the /BORK one.

(The tools do not complain about the specification of options as above).

K2

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Monday, August 15, 2016 9:22 AM
To: Kurt Kennett 
Cc: edk2-devel 
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work


> On Aug 15, 2016, at 9:10 AM, Kurt Kennett  wrote:
> 
> DSC spec (January 2016 1.26) says I can do this:
> 
> (Section 3.6 pp 76)
> 
> ...
> * [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
> ...
> 
> And this works fine:
> 
> [BuildOptions.AARCH64.common]
>*_VS2015x86_*_DLINK_FLAGS = /BORK
> 
> But when I also do:
> 
> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>*_VS2015x86_*_DLINK_FLAGS = /PLOR
> 
> The link flags are not affected on the command line - they get the /BORK for 
> all module types, but not the /PLOR for DXE_RUNTIME_DRIVERs.
> 

Kurt,

Have you tried [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]? Do you need EDK 
compatibility? 

I'm guessing that works given:
~/work/src/edk2(master)>git grep "BuildOptions." -- *.dsc | grep 
DXE_RUNTIME_DRIVER 
OvmfPkg/OvmfPkgIa32.dsc:49:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
OvmfPkg/OvmfPkgIa32X64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
OvmfPkg/OvmfPkgX64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
QuarkPlatformPkg/Quark.dsc:885:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]


> I'm not familiar with the DSC processing tools source.  Anybody know where to 
> look to see why not?
> 

It starts here: 
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/build/build.py
 and uses some code from: 
https://github.com/tianocore/edk2/tree/master/BaseTools/Source/Python/Common

Thanks,

Andrew Fish

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

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

Re: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core by grabbing memory from PeiTemporaryRamBase?

[Gao, Liming]

Andrew:
  In permanent memory, PeiCore places heap base as stack top. Heap is above 
stack. There is no hole between them. SEC needs to follow this layout and 
migrate the temporary memory to permanent memory. It should copy TemporaryRam 
HEAP and STACK range separately. HEAP range is specified by PeiTemporaryRamBase 
and PeiTemporaryRamSize, and STACK range is specified by StackBase and 
StackSize. The grabbed memory is not migrated, because PeiCore doesn't know it. 
But, EmulatorPkg Sec SecTemporaryRamSupport() migrates the whole temporary 
memory together. The grabbed memory is also migrated and wrongly regarded as 
heap data. So, the fix is to update SecTemporaryRamSupport() implementation in 
SEC. 

Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Saturday, August 13, 2016 7:25 AM
To: edk2-devel 
Subject: [edk2] [MdeModulePkg][PeiCore] I seemed to have crashed the PEI Core 
by grabbing memory from PeiTemporaryRamBase?

I grabbed some memory between SEC and the PEI Core by adjusting SecCoreData-> 
PeiTemporaryRamBase and SecCoreData-> PeiTemporaryRamSize.

When looking at the code I don't really understand the logic of the algorithm? 
So maybe I'm doing something wrong. 

This adjustment does not seem right to me?
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c#L768
  //
  // Heap Offset
  //
  BaseOfNewHeap = TopOfNewStack;
  if (BaseOfNewHeap >= (UINTN)SecCoreData->PeiTemporaryRamBase) {
Private->HeapOffsetPositive = TRUE;
Private->HeapOffset = (UINTN)(BaseOfNewHeap - 
(UINTN)SecCoreData->PeiTemporaryRamBase);
  } else {
Private->HeapOffsetPositive = FALSE;
Private->HeapOffset = (UINTN)((UINTN)SecCoreData->PeiTemporaryRamBase - 
BaseOfNewHeap);
  }


The above code seems to be making a very strange adjustment. I noticed the 
adjustment in my failing case was off by 0xC0 which is the amount of memory I 
carved out prior to entering the PEI Core. 

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c#L796

  //
  // Temporary Ram Support PPI is provided by platform, it will copy 
  // temporary memory to permenent memory and do stack switching.
  // After invoking Temporary Ram Support PPI, the following code's 
  // stack is in permanent memory.
  //
  TemporaryRamSupportPpi->TemporaryRamMigration (
PeiServices,
TemporaryRamBase,
(EFI_PHYSICAL_ADDRESS)(UINTN)(TopOfNewStack - 
TemporaryStackSize),
TemporaryRamSize
);


And this is also a case in which the stack got bigger. But it seems to me the 
shift if really defined by TemporaryRamBase, TopOfNewStack, and 
TemporaryStackSize in this case. 

The failure I hit was OldCoreData->Fv pointer was shifted so when the PPI was 
called the system crashed. Is this a bug in the gEfiTemporaryRamSupportPpiGuid 
path?

If I changed the HeadOffset algorithm my crash went away? Private->HeapOffset = 
((UINTN)TopOfNewStack - TemporaryStackSize) - TemporaryRamBase;

Thanks,

Andrew Fish

PS My failure case was the EmulatorPkg. I've not had a chance to verify this 
failure in the open source yet, but I'm guessing reversing this #if will make 
it happen.


https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Sec/Sec.c#L107

#if 0
  // Tell the PEI Core to not use our buffer in temp RAM
  SecPpiList = (EFI_PEI_PPI_DESCRIPTOR *)SecCoreData->PeiTemporaryRamBase;
  SecCoreData->PeiTemporaryRamBase = (VOID 
*)((UINTN)SecCoreData->PeiTemporaryRamBase + SecReseveredMemorySize);
  SecCoreData->PeiTemporaryRamSize -= SecReseveredMemorySize;
#else
  {
//
// When I subtrack from SecCoreData->PeiTemporaryRamBase PEI Core crashes? 
Either there is a bug
// or I don't understand temp RAM correctly?
//
EFI_PEI_PPI_DESCRIPTORPpiArray[10];

SecPpiList = [0];
ASSERT (sizeof (PpiArray) >= SecReseveredMemorySize);
  }
#endif




___
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] Setting BuildOptions by module type does not seem to work

[Kurt Kennett]

DSC spec (January 2016 1.26) says I can do this:

(Section 3.6 pp 76)

...
* [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
...

And this works fine:

[BuildOptions.AARCH64.common]
*_VS2015x86_*_DLINK_FLAGS = /BORK

But when I also do:

[BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
*_VS2015x86_*_DLINK_FLAGS = /PLOR

The link flags are not affected on the command line - they get the /BORK for 
all module types, but not the /PLOR for DXE_RUNTIME_DRIVERs.

I'm not familiar with the DSC processing tools source.  Anybody know where to 
look to see why not?

K2


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

Re: [edk2] [PATCH] ArmVirtPkg: Add NFIT report feature for ArmVirtPkg for ramdisks

[Laszlo Ersek]

On 08/09/16 11:55, Sajjan, Vikas C wrote:
> Adding Maintainers.
> 
> -Original Message-
> From: Sajjan, Vikas C 
> Sent: Tuesday, August 09, 2016 1:28 PM
> To: edk2-devel@lists.01.org
> Cc: Sajjan, Vikas C 
> Subject: [PATCH] ArmVirtPkg: Add NFIT report feature for ArmVirtPkg for 
> ramdisks
> 
> Adds NFIT report feature for ArmVirtPkg for ramdisks of reserved memory type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Vikas C Sajjan 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc  | 4 
>  ArmVirtPkg/ArmVirtQemu.fdf  | 2 ++
>  ArmVirtPkg/ArmVirtRules.fdf.inc | 2 ++
>  3 files changed, 8 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index 
> 9f88786..35a3d8f 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -103,6 +103,9 @@
># Activate KVM workaround for now.
>gArmVirtTokenSpaceGuid.PcdKludgeMapPciMmioAsCached|TRUE
>  
> +  # Activate AcpiSdtProtocol.
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
> +
>  !if $(PURE_ACPI_BOOT_ENABLE) == TRUE
>gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
>  !endif
> @@ -397,6 +400,7 @@
># ACPI Support
>#
>MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
>OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
>  
>NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf index 
> c6a22dc..7d6737b 100644
> --- a/ArmVirtPkg/ArmVirtQemu.fdf
> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
> @@ -110,6 +110,8 @@ READ_LOCK_STATUS   = TRUE
>INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
>INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
>INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> +  INF MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>  
>FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>  SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED 
> = TRUE { diff --git a/ArmVirtPkg/ArmVirtRules.fdf.inc 
> b/ArmVirtPkg/ArmVirtRules.fdf.inc index 8952c67..5ff3004 100644
> --- a/ArmVirtPkg/ArmVirtRules.fdf.inc
> +++ b/ArmVirtPkg/ArmVirtRules.fdf.inc
> @@ -85,6 +85,8 @@
>  DXE_DEPEXDXE_DEPEX  Optional 
> $(INF_OUTPUT)/$(MODULE_NAME).depex
>  PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
>  UI   STRING="$(MODULE_NAME)" Optional
> +RAW  ACPI  Optional   |.acpi
> +RAW  ASL   Optional   |.aml
>}
>  
>  [Rule.Common.DXE_RUNTIME_DRIVER]
> --
> 1.9.1

(1) Please clarify in the commit message (including the subject line)
that this patch is actually about adding the RAM Disk driver to the
ArmVirtPkg platforms, not just the NFIT reporting feature of the driver.

(2) Please mention that this patch ports OvmfPkg commit 259d87146b07 to
ArmVirtPkg.

(3) Please investigate whether the RAM Disk driver makes any sense for
32-bit ARM (note that only AARCH64 platforms include the ACPI Table
Protocol). This will have an impact on (4b) below.

I think RAM Disks make sense for 32-bit ARM as well, even without the
NFIT table.

(4) I think this feature should be enabled for all of ArmVirtQemu,
ArmVirtQemuKernel, and ArmVirtXen.

(4a) In preparation for that, please prepend a patch to the series that
extracts "MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf"
from all of the DSC files, into "ArmVirt.dsc.inc", section
[Components.AARCH64].

The FDF files are fine already.

(4b) Please add RamDiskDxe.inf to "ArmVirtQemuFvMain.fdf.inc" and
"ArmVirtXen.fdf", and "ArmVirt.dsc.inc". This ensures that the RAM Disk
driver is built for all platforms. Restrict this as needed to AARCH64
(see (3)).

(4c) In the second patch, PcdInstallAcpiSdtProtocol should go into
"ArmVirt.dsc.inc", section [PcdsFeatureFlag.AARCH64], for matching (4a).

(4d) The DXE_DRIVER build rules should also be updated in "ArmVirtXen.fdf".

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

Re: [edk2] AppPkg with python enabled - build fails

[Kottilil, Vasudevan]

After tweaking the build flags, got this to build on fedora22 just for testing.
The Python.Efi does not launch in EDK shell - throws an error
Error: Image at 00074E03000 start failed: Aborted. (there is another python 
assertion failure before this line)

We also tried to build this in a different environment and tool chain (windows, 
visual studio) and got the same runtime error in EDK shell.

Please let us know what we are missing here. Other sample app from AppPkg 
(Hello.Efi) launches without any issues.

-Vasudevan Kottilil


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
Kottilil, Vasudevan
Sent: Wednesday, August 10, 2016 4:31 PM
To: edk2-devel@lists.01.org
Subject: [edk2] AppPkg with python enabled - build fails

Hi,
I am trying to build this and seeing this error. I was able to build another 
package without any errors using the same configuration.
Thanks much.
Vasudevan Kottilil

Build environment: Linux-4.0.4-301.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two
Build start time: 15:21:44, Aug.10 2016

WORKSPACE= /home/vasu/edk2
ECP_SOURCE   = /home/vasu/edk2/EdkCompatibilityPkg
EDK_SOURCE   = /home/vasu/edk2/EdkCompatibilityPkg
EFI_SOURCE   = /home/vasu/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /home/vasu/edk2/BaseTools


Architecture(s)  = X64
Build target = DEBUG
Toolchain= GCC5

Active Platform  = /home/vasu/edk2/AppPkg/AppPkg.dsc

Processing meta-data .. done!
Building ... /home/vasu/edk2/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf 
[X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf 
[X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/MdePkg/Library/BaseLib/BaseLib.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... 
/home/vasu/edk2/MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... 
/home/vasu/edk2/MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
 [X64]
make: Nothing to be done for 'tbuild'.
Building ... 
/home/vasu/edk2/MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
 [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/MdePkg/Library/BasePrintLib/BasePrintLib.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... 
/home/vasu/edk2/MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
 [X64]
make: Nothing to be done for 'tbuild'.
Building ... 
/home/vasu/edk2/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... 
/home/vasu/edk2/MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
 [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/MdePkg/Library/UefiLib/UefiLib.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... 
/home/vasu/edk2/ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/AppPkg/Applications/Hello/Hello.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Signal/Signal.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Uefi/Devices/daUtility.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/PosixLib/Gen/LibGen.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Uefi/Uefi.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Time/Time.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/String/String.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/StdLib/StdLib.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Locale/Locale.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/gdtoa/gdtoa.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Ctype/Ctype.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Stdio/Stdio.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/LibC.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Containers/ContainerLib.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Uefi/InteractiveIO/IIO.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Wchar/Wchar.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/StdLib/LibC/Uefi/Devices/daConsole.inf [X64]
make: Nothing to be done for 'tbuild'.
Building ... /home/vasu/edk2/MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf 
[X64]
make: Nothing to be done for 'tbuild'.
Building ... 

Re: [edk2] DHCP Automatic Configure at Driver Connect

[Ye, Ting]

Hi Eugene,

I think we need fully understand your usage before analyzing the problem. Could 
you please explain more details? You mentioned you only wanted to enable the 
network interface when directed by an application. If so, is it possible that 
you don't connect your network device until you really need that? 

Thanks,
Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Thursday, August 11, 2016 10:23 PM
To: Wu, Jiaxin ; Ye, Ting ; 
edk2-devel@lists.01.org
Subject: Re: [edk2] DHCP Automatic Configure at Driver Connect

Ting and Jiaxin, thank you both for clarifying.

In our situation DHCP is being set on a previous boot and we are now observing 
DHCP being attempted on every boot (since the controllers are connected).  So 
this is consistent with the behavior you describe - even though the default was 
originally static/manual the fact that we configured DHCP once causes this to 
be stored to NVRAM and perform dhcp process at every boot.

The issue is not just a performance issue around DHCP timing.  Even with a 
static IP address set the fact that the network interface comes "up" at each 
boot is problematic because our requirement is only to enable the network 
interface when directed to by an application.

Modifying the IP configuration dynamically to suppress the interface coming up 
at every boot is also problematic because it means we would need to store the 
IP address configuration in another NVRAM location.  In other words, the 
combining of the IP address settings storage *and* the policy of whether to 
configure at boot or wait until explicitly requested is problematic - we really 
would like to control these settings independently.  Is that possible within 
the scope of the spec?  Could we just have a PCD that suppresses the automatic 
configure at boot under any circumstance?

Thanks,

Eugene

> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Thursday, August 11, 2016 12:00 AM
> To: Ye, Ting ; Cohen, Eugene ; 
> edk2-devel@lists.01.org
> Subject: RE: DHCP Automatic Configure at Driver Connect
> 
> Thanks Ting's more background clarification.
> 
> I assume the difference you mentioned is between "SHA-1:
> 3d0a49ad47619c30c84bbee8a33f54b64dddbcec" and "SHA-1:
> 7648748e99eeeadec38fda7568adb260c4acc861". The two commits does cause 
> the different behavior as Ting said below. Git version 3d0a49ad will 
> only set the policy to dhcp but don't trigger D.O.R.A while 7648748e 
> always trigger D.O.R.A if policy is DHCP.
> 
> Version 7648748e commit is also the current behavior of Ip4Config2:
> DHCP policy together with D.O.R.A process, which is similar to the old 
> Ip4Config behavior. The version 3d0a49ad did was trying to resolve the 
> Ip4Dxe performance but it's not workable for IPv6, so we reverted it.
> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: Ye, Ting
> > Sent: Thursday, August 11, 2016 11:03 AM
> > To: Cohen, Eugene ; edk2-devel@lists.01.org;
> Wu, Jiaxin
> > 
> > Subject: RE: DHCP Automatic Configure at Driver Connect
> >
> > Hi Eugene,
> >
> > Actually this is exactly the problem Samer raised to the mailing 
> > list in
> Aug 2015.
> > We ever fixed it with following patch:
> >
> > SHA-1: 3d0a49ad47619c30c84bbee8a33f54b64dddbcec
> >
> > * MdeModulePkg: Fix issue about current Ip4Dxe implementation
> for DHCP
> > DORA process
> >
> > DHCP policy is applied as default at boot time on all NICs in the
> system, which
> > results in all NIC ports attempting DHCP and trying to acquire IP
> addresses
> > during boot.
> > Ip4 driver should only set dhcp as default policy, and not trigger
> DORA at
> > driver binding start(). We should start DORA until one IP child is
> configured to
> > use default address.
> >
> > Later HP raised the same performance impact in IPv6 stack. We
> realized we
> > couldn't use the same logic to defer DHCP6 SARR process.
> > Instead, we discussed the issue in spec group and we removed the 
> > restriction from UEFI specification that the default policy should 
> > be Ip4Config2PolicyDhcp or Ip6ConfigPolicyAutomatic. It's up to 
> > implementation's choice.
> > The EDKII implementation was later updated that the default policy
> was
> > changed to Ip4Config2PolicyStatic and IP6ConfigPolicyManual. Also
> the
> > previous change was reverted, in order to keep IP4/IP6 solution
> consistent.
> > See patch (also reviewed by Samer):
> >
> > SHA-1: 7648748e99eeeadec38fda7568adb260c4acc861
> >
> > * MdeModulePkg: Change the default IPv4 config policy
> >
> > Git version '3d0a49ad' commit provided a scenario to resolve the 
> > performance issue for IPv4, but it's not workable for IPv6. To avoid
> IPv4 and
> > IPv6 inconsistency, we decided to revert that version fix.
> >
> > If so, the default policy for Ip4Config2 is 

Re: [edk2] IP4 Config Troubles with DHCP

[Wu, Jiaxin]

> > Actually, you don't need to retry the UDP configuration loop according
> > the Ip4Mode.IsConfigured flag. You are only recommended to set a timer
> > to check the mapping status after the configuration:
> >
> > For example:
> >   Status = Nlc->Udp4->Configure(Nlc->Udp4, >UdpConfig);
> >   if (EFI_ERROR (Status) && (Status != EFI_NO_MAPPING)) {
> >   return  Status;
> >   }
> >   if (Status == EFI_NO_MAPPING && !UdpGetMapping (Nlc->Udp4)) {
> >   return  Status;
> >   }
> >
> > In UdpGetMapping () function, create one timer to check
> > Ip4Mode.IsConfigured:
> >
> > For example:
> > UdpGetMapping () {
> >   IsMapDone = FALSE;
> >   gBS->CreateEvent (EVT_TIMER, TPL_CALLBACK, NULL, NULL,
> > );
> >   gBS->SetTimer (TimeoutEvent, TimerRelative, AnyValue);
> >   while (EFI_ERROR (gBS->CheckEvent (TimeoutEvent))) {
> > Udp4->Poll (Udp4);
> > Udp4->GetModeData (Udp4, , & Ip4Mode, NULL, NULL);
> > if (Ip4Mode.IsConfigured) {
> >   IsMapDone = TRUE;
> >   break;
> > }
> >   }
> >   return IsMapDone;
> > }
> >
> > If DHCP process succeed, Ip4Mode.IsConfigured should be updated. If
> > not, any bug may be existed.
> 
> In testing the new patch (removing RECONFIG=TRUE) I see that the
> statement you made above is not accurate when the protocol is TCP.  When
> Configure is called the first time it returns EFI_NO_MAPPING.  This seems to
> be remembered in the socket state: ((Sock)->ConfigureState ==
> SO_NO_MAPPING) so that any attempt to use the instance after
> Ip4Mode.IsConfigured goes TRUE fails (like for a TCP4 Listen).
> 
> So for TCP we must issue another Configure request to clean up this state so
> it's not as simple as just polling the GetModeData result, at least for TCP.

Yeah. When I was drafting the UDP APP to test the new fix, I found the same 
case you mentioned. We must issue another UDP Configure () to clean the 
previous state once the  Ip4Mode.IsConfigured is TRUE. So, the above example is 
not accurate with my the current implementation:(. But I'm still not recommend 
to loop the UDP configuration every time if Ip4Mode.IsConfigured is false. The 
right behavior for UDP/TCP is 1) timer check the Ip4Mode.IsConfigured, 2) Once 
Ip4Mode.IsConfigured is TRUE, reconfigure the instance again. Sorry for the 
above example was troubling you. Also use UDP as example, correct as below:

Udata.UseDefaultAddress = TRUE;
Status = Udp4->Configure (Udp4, );
if (EFI_ERROR (Status) && (Status != EFI_NO_MAPPING)) {
  return Status;
}
if ((Status == EFI_NO_MAPPING) && !UdpGetMapping (Udp4, )) {
  return Status;
}

In UdpGetMapping () function:

BOOLEAN
UdpGetMapping (
  IN EFI_UDP4_PROTOCOL  *Udp4,
  IN EFI_UDP4_CONFIG_DATA   *UdpCfgData
  )
{
  EFI_STATUS  Status;
  EFI_EVENTTimeoutEvent;
  EFI_IP4_MODE_DATAIp4ModeData;
  BOOLEAN  IsMapDone;

  IsMapDone = FALSE;

  ZeroMem (, sizeof (EFI_IP4_MODE_DATA));

  Status = gBS->CreateEvent (EVT_TIMER, TPL_CALLBACK, NULL, NULL, 
);
  if (EFI_ERROR (Status)) {
return IsMapDone;
  }

  //
  // Start the timer, it will timeout after 5 seconds.
  //
  gBS->SetTimer (TimeoutEvent, TimerRelative, 5);

  while (EFI_ERROR (gBS->CheckEvent (TimeoutEvent))) {
Udp4->Poll (Udp4);

if (!EFI_ERROR (Udp4->GetModeData (Udp4, NULL, , NULL, NULL)) &&
Ip4ModeData.IsConfigured) {
  Udp4->Configure (Udp4, NULL);
  IsMapDone = (BOOLEAN) (Udp4->Configure (Udp4, UdpCfgData) == EFI_SUCCESS);
  break;
}
  }

  gBS->CloseEvent (TimeoutEvent);

  return IsMapDone;
}

> 
> Do you believe this is expected behavior?
> 
> Thanks,
> 
> Eugene
> 

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

Re: [edk2] [Patch] MdePkg: Fix guid conflict.

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Dong, Eric
> Sent: Friday, August 12, 2016 10:10 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Cecil Sheng 
> Subject: [Patch] MdePkg: Fix guid conflict.
> 
> Update Image Decoder Protocol GUID value to fix GUID
> conflict with EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eric Dong 
> Cc: Liming Gao 
> Cc: Cecil Sheng 
> ---
>  MdePkg/Include/Protocol/ImageDecoder.h | 10 +-
>  MdePkg/MdePkg.dec  | 14 +++---
>  2 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/ImageDecoder.h
> b/MdePkg/Include/Protocol/ImageDecoder.h
> index f1985bc..aebb813 100644
> --- a/MdePkg/Include/Protocol/ImageDecoder.h
> +++ b/MdePkg/Include/Protocol/ImageDecoder.h
> @@ -18,8 +18,16 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include 
> 
> 
> +//
> +// In UEFI 2.6 spec,this guid value is duplicate with
> +// EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID. Now update this guid
> value to
> +// avoid the duplicate guid issue. So its value is not consistent with
> +// UEFI spec definition now. We have proposed to update UEFI spec to
> +// use this new guid. After new spec released, we will remove this
> +// comments.
> +//
>  #define EFI_HII_IMAGE_DECODER_PROTOCOL_GUID \
> -  { 0x2f707ebb, 0x4a1a, 0x11d4, {0x9a,0x38,0x00,0x90,0x27,0x3f,0xc1,0x4d}}
> +  {0x9e66f251, 0x727c, 0x418c, { 0xbf, 0xd6, 0xc2, 0xb4, 0x25, 0x28, 0x18,
> 0xea }}
> 
> 
>  #define EFI_HII_IMAGE_DECODER_NAME_JPEG_GUID \
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index 458d568..606e2f1 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -393,7 +393,7 @@
> 
>## Include/Guid/MemoryOverwriteControl.h
>gEfiMemoryOverwriteControlDataGuid = { 0xe20939be, 0x32d4, 0x41be,
> {0xa1, 0x50, 0x89, 0x7f, 0x85, 0xd4, 0x98, 0x29 }}
> -
> +
>## Include/IndustryStandard/MemoryOverwriteRequestControlLock.h
>gEfiMemoryOverwriteRequestControlLockGuid = { 0xBB983CCF, 0x151D,
> 0x40E1, {0xA0, 0x7B, 0x4A, 0x17, 0xBE, 0x16, 0x82, 0x92}}
> 
> @@ -1384,7 +1384,7 @@
> 
>## Include/Protocol/TrEEProtocol.h
>gEfiTrEEProtocolGuid   = {0x607f766c, 0x7455, 0x42be, { 0x93, 
> 0x0b, 0xe4,
> 0xd7, 0x6d, 0xb2, 0x72, 0x0f }}
> -
> +
>## Include/Protocol/Tcg2Protocol.h
>gEfiTcg2ProtocolGuid   = {0x607f766c, 0x7455, 0x42be, { 0x93, 
> 0x0b, 0xe4,
> 0xd7, 0x6d, 0xb2, 0x72, 0x0f }}
>gEfiTcg2FinalEventsTableGuid   = {0x1e2ed096, 0x30e2, 0x4254, { 0xbd, 0x89,
> 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25 }}
> @@ -1620,7 +1620,15 @@
>gEfiRamDiskProtocolGuid  = { 0xab38a0df, 0x6873, 0x44a9, { 
> 0x87,
> 0xe6, 0xd4, 0xeb, 0x56, 0x14, 0x84, 0x49 }}
> 
>## Include/Protocol/ImageDecoder.h
> -  gEfiHiiImageDecoderProtocolGuid  = { 0x2f707ebb, 0x4a1a, 0x11d4, { 
> 0x9a,
> 0x38, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d }}
> +  ##
> +  ## In UEFI 2.6 spec,this guid value is duplicate with
> +  ## EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID. Now update this guid
> value to
> +  ## avoid the duplicate guid issue. So its value is not consistent with
> +  ## UEFI spec definition now. We have proposed to update UEFI spec to
> +  ## use this new guid. After new spec released, we will remove this
> +  ## comments.
> +  ##
> +  gEfiHiiImageDecoderProtocolGuid  = { 0x9e66f251, 0x727c, 0x418c, { 
> 0xbf,
> 0xd6, 0xc2, 0xb4, 0x25, 0x28, 0x18, 0xea }}
> 
>## Include/Protocol/HiiImageEx.h
>gEfiHiiImageExProtocolGuid   = { 0x1a1241e6, 0x8f19, 0x41a9, { 
> 0xbc, 0xe,
> 0xe8, 0xef, 0x39, 0xe0, 0x65, 0x46 }}
> --
> 2.6.4.windows.1

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

Re: [edk2] Setting BuildOptions by module type does not seem to work

[Gao, Liming]

Hi,
  This style has been defined in DSC spec 1.26. It can be downloaded from 
https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20Specifications

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kurt 
Kennett
Sent: Tuesday, August 16, 2016 1:56 AM
To: af...@apple.com
Cc: edk2-devel 
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work

Okay this seems to work:

[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]

Thanks Andrew.

(doesn't match the spec though :) )

K2

-Original Message-
From: af...@apple.com [mailto:af...@apple.com]
Sent: Monday, August 15, 2016 10:30 AM
To: Kurt Kennett
Cc: edk2-devel
Subject: Re: [edk2] Setting BuildOptions by module type does not seem to work


> On Aug 15, 2016, at 9:34 AM, Kurt Kennett wrote:
>
> No, I had not tried that. I tried it now and it does not seem to work.
>
> I have:
>
> [BuildOptions.AARCH64.common]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /BORK
>
> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /PLOR
>
> [BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]
> *_VS2015x86_AARCH64_DLINK_FLAGS = /BONK
>
> And the only one that makes it to the command line is the /BORK one.
>
> (The tools do not complain about the specification of options as above).
>

I'm guessing the syntax checking is not very good?
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
[BuildOptions.AARCH64.common.EDKII.DXE_RUNTIME_DRIVER]

I see the [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] form used in other 
places, but you have an extra .common?

Thanks,

Andrew Fish

> K2
>
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Monday, August 15, 2016 9:22 AM
> To: Kurt Kennett
> Cc: edk2-devel
> Subject: Re: [edk2] Setting BuildOptions by module type does not seem
> to work
>
>
>> On Aug 15, 2016, at 9:10 AM, Kurt Kennett wrote:
>>
>> DSC spec (January 2016 1.26) says I can do this:
>>
>> (Section 3.6 pp 76)
>>
>> ...
>> * [BuildOptions.$(arch).CodeBase.Edk2ModuleType]
>> ...
>>
>> And this works fine:
>>
>> [BuildOptions.AARCH64.common]
>> *_VS2015x86_*_DLINK_FLAGS = /BORK
>>
>> But when I also do:
>>
>> [BuildOptions.AARCH64.common.DXE_RUNTIME_DRIVER]
>> *_VS2015x86_*_DLINK_FLAGS = /PLOR
>>
>> The link flags are not affected on the command line - they get the /BORK for 
>> all module types, but not the /PLOR for DXE_RUNTIME_DRIVERs.
>>
>
> Kurt,
>
> Have you tried [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]? Do you need 
> EDK compatibility?
>
> I'm guessing that works given:
> ~/work/src/edk2(master)>git grep "BuildOptions." -- *.dsc | grep
> DXE_RUNTIME_DRIVER
> OvmfPkg/OvmfPkgIa32.dsc:49:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIV
> ER]
> OvmfPkg/OvmfPkgIa32X64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_D
> RIVER]
> OvmfPkg/OvmfPkgX64.dsc:54:[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVE
> R]
> QuarkPlatformPkg/Quark.dsc:885:[BuildOptions.common.EDKII.DXE_RUNTIME_
> DRIVER]
>
>
>> I'm not familiar with the DSC processing tools source. Anybody know where to 
>> look to see why not?
>>
>
> It starts here:
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/
> build/build.py and uses some code from:
> https://github.com/tianocore/edk2/tree/master/BaseTools/Source/Python/
> Common
>
> Thanks,
>
> Andrew Fish
>
>> K2
>>
>>
>> ___
>> 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

[edk2] [PATCH] SecurityPkg: AuthVariableLib: Fix potential inconsistency corner case for Time Auth variable 2 steps are used to create/delete a time based variable. For create, step 1: Insert Signer C

[Zhang, Chao B]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 SecurityPkg/Library/AuthVariableLib/AuthService.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 6e1e284..b013d42 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -2100,7 +2100,7 @@ CleanCertsFromDb (

);
 
-  if (EFI_ERROR(Status)) {
+  if (EFI_ERROR(Status) || (AuthVariableInfo.Attributes & 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) == 0) {
 Status  = DeleteCertsFromDb(
 VariableName,
 ,
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH] ArmVirtPkg: Add NFIT report feature for ArmVirtPkg for ramdisks

[Sajjan, Vikas C]

Hi Laszlo,

Thank you for reviewing the patch.

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, August 16, 2016 2:08 AM
To: Sajjan, Vikas C 
Cc: edk2-devel@lists.01.org ; 
ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Shannon Zhao (Linaro 
address) 
Subject: Re: [edk2] [PATCH] ArmVirtPkg: Add NFIT report feature for ArmVirtPkg 
for ramdisks

On 08/09/16 11:55, Sajjan, Vikas C wrote:
> Adding Maintainers.
> 
> -Original Message-
> From: Sajjan, Vikas C
> Sent: Tuesday, August 09, 2016 1:28 PM
> To: edk2-devel@lists.01.org
> Cc: Sajjan, Vikas C 
> Subject: [PATCH] ArmVirtPkg: Add NFIT report feature for ArmVirtPkg 
> for ramdisks
> 
> Adds NFIT report feature for ArmVirtPkg for ramdisks of reserved memory type.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Vikas C Sajjan 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc  | 4 
>  ArmVirtPkg/ArmVirtQemu.fdf  | 2 ++
>  ArmVirtPkg/ArmVirtRules.fdf.inc | 2 ++
>  3 files changed, 8 insertions(+)
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc 
> index 9f88786..35a3d8f 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -103,6 +103,9 @@
># Activate KVM workaround for now.
>gArmVirtTokenSpaceGuid.PcdKludgeMapPciMmioAsCached|TRUE
>  
> +  # Activate AcpiSdtProtocol.
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
> +
>  !if $(PURE_ACPI_BOOT_ENABLE) == TRUE
>gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
>  !endif
> @@ -397,6 +400,7 @@
># ACPI Support
>#
>MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
>OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
>  
>
> NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf 
> index c6a22dc..7d6737b 100644
> --- a/ArmVirtPkg/ArmVirtQemu.fdf
> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
> @@ -110,6 +110,8 @@ READ_LOCK_STATUS   = TRUE
>INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
>INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
>INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> +  INF MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>  
>FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
>  SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF 
> PROCESSING_REQUIRED = TRUE { diff --git 
> a/ArmVirtPkg/ArmVirtRules.fdf.inc b/ArmVirtPkg/ArmVirtRules.fdf.inc 
> index 8952c67..5ff3004 100644
> --- a/ArmVirtPkg/ArmVirtRules.fdf.inc
> +++ b/ArmVirtPkg/ArmVirtRules.fdf.inc
> @@ -85,6 +85,8 @@
>  DXE_DEPEXDXE_DEPEX  Optional 
> $(INF_OUTPUT)/$(MODULE_NAME).depex
>  PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
>  UI   STRING="$(MODULE_NAME)" Optional
> +RAW  ACPI  Optional   |.acpi
> +RAW  ASL   Optional   |.aml
>}
>  
>  [Rule.Common.DXE_RUNTIME_DRIVER]
> --
> 1.9.1

(1) Please clarify in the commit message (including the subject line) that this 
patch is actually about adding the RAM Disk driver to the ArmVirtPkg platforms, 
not just the NFIT reporting feature of the driver.

Sure will do.

(2) Please mention that this patch ports OvmfPkg commit 259d87146b07 to 
ArmVirtPkg.

   OK.

(3) Please investigate whether the RAM Disk driver makes any sense for 32-bit 
ARM (note that only AARCH64 platforms include the ACPI Table Protocol). This 
will have an impact on (4b) below.

I think RAM Disks make sense for 32-bit ARM as well, even without the NFIT 
table.

(4) I think this feature should be enabled for all of ArmVirtQemu, 
ArmVirtQemuKernel, and ArmVirtXen.

(4a) In preparation for that, please prepend a patch to the series that 
extracts "MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf"
from all of the DSC files, into "ArmVirt.dsc.inc", section [Components.AARCH64].

 OK.

The FDF files are fine already.

(4b) Please add RamDiskDxe.inf to "ArmVirtQemuFvMain.fdf.inc" and 
"ArmVirtXen.fdf", and "ArmVirt.dsc.inc". This ensures that the RAM Disk driver 
is built for all platforms. Restrict this as needed to AARCH64 (see (3)).

OK.

(4c) In the second patch, PcdInstallAcpiSdtProtocol should go into 
"ArmVirt.dsc.inc", section [PcdsFeatureFlag.AARCH64], for matching (4a).

OK.

(4d) The DXE_DRIVER build rules should also be updated in "ArmVirtXen.fdf".
OK.

Thanks
Laszlo

Thanks and Regards
Vikas Sajjan

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

[edk2] [PATCH V1] SecurityPkg: AuthVariableLib: Fix potential inconsistency corner case for Time Auth variable

[Zhang, Chao B]

  2 steps are used to create/delete a time based variable. For create, step 1: 
Insert Signer Cert to CertDB. Step 2: Insert Payload to Variable. For delete, 
step 1: Delete Variable. Step 2: Delete Cert from CertDB. System may breaks 
between step 1 & step 2, so CertDB may contains useless Cert in the next 
reboot. AuthVariableLib choose to sync consistent state between CertDB & Time 
Auth Variable on initialization. However, it doesn't apply Time Auth attribute 
check. Now add it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 SecurityPkg/Library/AuthVariableLib/AuthService.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 6e1e284..b013d42 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -2100,7 +2100,7 @@ CleanCertsFromDb (

);
 
-  if (EFI_ERROR(Status)) {
+  if (EFI_ERROR(Status) || (AuthVariableInfo.Attributes & 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) == 0) {
 Status  = DeleteCertsFromDb(
 VariableName,
 ,
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH V1] SecurityPkg: AuthVariableLib: Fix potential inconsistency corner case for Time Auth variable

[Fu, Siyuan]

Reviewed-by: Fu Siyuan 



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Zhang, Chao B
> Sent: Tuesday, August 16, 2016 10:39 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Zhang, Chao B
> ; Zeng, Star 
> Subject: [edk2] [PATCH V1] SecurityPkg: AuthVariableLib: Fix potential
> inconsistency corner case for Time Auth variable
> 
>   2 steps are used to create/delete a time based variable. For create,
> step 1: Insert Signer Cert to CertDB. Step 2: Insert Payload to Variable.
> For delete, step 1: Delete Variable. Step 2: Delete Cert from CertDB.
> System may breaks between step 1 & step 2, so CertDB may contains useless
> Cert in the next reboot. AuthVariableLib choose to sync consistent state
> between CertDB & Time Auth Variable on initialization. However, it doesn't
> apply Time Auth attribute check. Now add it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Chao Zhang 
> ---
>  SecurityPkg/Library/AuthVariableLib/AuthService.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c
> b/SecurityPkg/Library/AuthVariableLib/AuthService.c
> index 6e1e284..b013d42 100644
> --- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
> +++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
> @@ -2100,7 +2100,7 @@ CleanCertsFromDb (
> 
> );
> 
> -  if (EFI_ERROR(Status)) {
> +  if (EFI_ERROR(Status) || (AuthVariableInfo.Attributes &
> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) == 0) {
>  Status  = DeleteCertsFromDb(
>  VariableName,
>  ,
> --
> 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: [edk2] DHCP Automatic Configure at Driver Connect

[Wu, Jiaxin]

Eugene,

> > > > In my memory, we only talked about the performance issue before.
> > > > Here, I understand your requirement: 1) The network interface
> > > > should be in
> > > > *un-
> > > > configured* status at each boot time until the third part
> > > > configuration;
> 
> Yes, we would like a policy setting (either runtime/protocol or build-
> time/PCD is fine) for this.
> 
>  2) the policy setting should be ignored, right? I
> > > > don't
> 
> I don't know what you mean by this.  The static/dhcp policy shouldn't
> necessarily be ignored but if the interface is not yet configured (i.e. the IP
> layer won't respond to packets) then the static/dhcp policy doesn't really
> matter until some component calls Configure() for the first time.

I mean I didn't know whether the *un-configured* status you want contain *no 
policy setting * or not. But it doesn't matter now, from your statement here, I 
know you don't care the policy setting.

> 
> > This is what I want to confirm with you that my understanding is
> > right? You complained the network interface comes "up" at each boot,
> > what does "comes up" exactly mean? So, I gave the above two guesses 1)
> and 2).
> 
> And I tried to clarify what I meant.  Another way of saying it is by being 
> "up" it
> means performing DHCP (if that is the setting) and transmitting/receiving
> packets using the IP address.  What we are asking for is a policy where we
> can suppress this behavior until the first Configure() call like before.

As I said in previous email, " The current behavior of Ip4Config2: DHCP policy 
together with D.O.R.A process, which is the same case as the old Ip4Config 
behavior ". From the case you described here, are you want to separate the DHCP 
policy setting and D.O.R.A process? We don't know.

> 
> > Of course not. I mean if my guessing 2) is correct, it's not
> > reasonable because UEFI 2.6 spec only defined Static/DHCP policy. The
> > policy should be in one of them. I just recalled the old Ip4Config
> > behavior: no policy assigned default (if I remember correctly).  So,
> > don't misunderstand my truly means. It's unrelated to the *behavior
> consistency*.
> 
> Perhaps not spec consistency but we need this for implementation
> consistency since we've built up years of expectations from the previous
> implementation.

We also don't know what is the *specific/explicit* *implementation consistency* 
you want here. Can you describe it more detail? I know the one difference 
between the old Ip4Config and Ip4Config2 is about the policy assignment. The 
old Ip4Config has no policy assigned default but currently we have the default 
one according the UEFI2.6. I think this difference is enrolled by the Spec 
updated. And this is also why I have the guess 2).  

> 
> > First, *based on the current UEFI Spec (only static / dhcp policy)*, I
> > want to highlight my understanding of *un-configured* status you
> > mentioned: policy should be always set, *un-configured* means *no IP
> address configuration*.
> 
> Correct, in that the device will neither transmit or respond at an IP layer
> initially.

Ok, that's fine.


> 
> > If we want to implement such a *un-configured* state, one *DXE_DRIVER*
> > can be used with Ip4Config2 protocol. Detailed see below pseudocode:
> >
> > First,  register a notify for Ip4Config2 protocol in your Dxe Driver 
> > EntryPoint:
> > EfiCreateProtocolNotifyEvent (
> > ,
> > TPL_CALLBACK,
> > Ip4Config2InstalledCallback,
> > NULL,
> > 
> > );
> >
> > Then, In your Ip4Config2InstalledCallback() function, you can change
> > the default policy for the current boot:
> >  Ip4Config2InstalledCallback () {
> >  gBS->LocateProtocol (
> >   ,
> >   Registration,
> >   (VOID **) 
> >   );
> >
> >  //
> >  // Change the policy to Ip4Config2PolicyDhcp to clean the static 
> > setting.
> > //
> > Policy = Ip4Config2PolicyDhcp;
> > Ip4Config2Instance->SetData(
> > Ip4Config2Instance,
> > 
> > Ip4Config2DataTypePolicy,
> > sizeof 
> > (EFI_IP4_CONFIG2_POLICY),
> > 
> > );
> >
> >  //
> >  // Change the policy to Ip4Config2PolicyStatic to clean the
> > DHCP policy setting.
> > //
> > Policy = Ip4Config2PolicyStatic;
> > Ip4Config2Instance->SetData(
> > Ip4Config2Instance,
> > 
> > Ip4Config2DataTypePolicy,
> > sizeof 
> > (EFI_IP4_CONFIG2_POLICY),
> > 

Re: [edk2] [PATCH] SecurityPkg: AuthVariableLib: Fix potential inconsistency corner case for Time Auth variable 2 steps are used to create/delete a time based variable. For create, step 1: Insert Sign

[Gao, Liming]

Chao:
  Please short the title, and move the detail in commit description. 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang, 
Chao B
Sent: Tuesday, August 16, 2016 10:25 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Zhang, Chao B ; 
Zeng, Star 
Subject: [edk2] [PATCH] SecurityPkg: AuthVariableLib: Fix potential 
inconsistency corner case for Time Auth variable 2 steps are used to 
create/delete a time based variable. For create, step 1: Insert Signer Cert to 
CertDB. Step 2: Insert Payload to Variable. F...

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 SecurityPkg/Library/AuthVariableLib/AuthService.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 6e1e284..b013d42 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -2100,7 +2100,7 @@ CleanCertsFromDb (

);
 
-  if (EFI_ERROR(Status)) {
+  if (EFI_ERROR(Status) || (AuthVariableInfo.Attributes & 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) == 0) {
 Status  = DeleteCertsFromDb(
 VariableName,
 ,
-- 
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: [edk2] [PATCH] SecurityPkg: AuthVariableLib: Fix potential inconsistency corner case for Time Auth variable 2 steps are used to create/delete a time based variable. For create, step 1: Insert Sign

[Zhang, Chao B]

Liming:
  Thanks for remind. I have resent V1 patch to fix this problem.





Thanks & Best regards
Chao Zhang

-Original Message-
From: Gao, Liming 
Sent: Tuesday, August 16, 2016 11:05 AM
To: Zhang, Chao B; edk2-devel@lists.01.org
Cc: Fu, Siyuan; Zhang, Chao B; Zeng, Star
Subject: RE: [edk2] [PATCH] SecurityPkg: AuthVariableLib: Fix potential 
inconsistency corner case for Time Auth variable 2 steps are used to 
create/delete a time based variable. For create, step 1: Insert Signer Cert to 
CertDB. Step 2: Insert Payload to Variable. 

Chao:
  Please short the title, and move the detail in commit description. 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang, 
Chao B
Sent: Tuesday, August 16, 2016 10:25 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Zhang, Chao B ; 
Zeng, Star 
Subject: [edk2] [PATCH] SecurityPkg: AuthVariableLib: Fix potential 
inconsistency corner case for Time Auth variable 2 steps are used to 
create/delete a time based variable. For create, step 1: Insert Signer Cert to 
CertDB. Step 2: Insert Payload to Variable. F...

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 SecurityPkg/Library/AuthVariableLib/AuthService.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 6e1e284..b013d42 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -2100,7 +2100,7 @@ CleanCertsFromDb (

);
 
-  if (EFI_ERROR(Status)) {
+  if (EFI_ERROR(Status) || (AuthVariableInfo.Attributes & 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) == 0) {
 Status  = DeleteCertsFromDb(
 VariableName,
 ,
-- 
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: [edk2] [PATCH V1] SecurityPkg: AuthVariableLib: Fix potential inconsistency corner case for Time Auth variable

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang, 
Chao B
Sent: Tuesday, August 16, 2016 10:39 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Zhang, Chao B ; 
Zeng, Star 
Subject: [edk2] [PATCH V1] SecurityPkg: AuthVariableLib: Fix potential 
inconsistency corner case for Time Auth variable

  2 steps are used to create/delete a time based variable. For create, step 1: 
Insert Signer Cert to CertDB. Step 2: Insert Payload to Variable. For delete, 
step 1: Delete Variable. Step 2: Delete Cert from CertDB. System may breaks 
between step 1 & step 2, so CertDB may contains useless Cert in the next 
reboot. AuthVariableLib choose to sync consistent state between CertDB & Time 
Auth Variable on initialization. However, it doesn't apply Time Auth attribute 
check. Now add it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 SecurityPkg/Library/AuthVariableLib/AuthService.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SecurityPkg/Library/AuthVariableLib/AuthService.c 
b/SecurityPkg/Library/AuthVariableLib/AuthService.c
index 6e1e284..b013d42 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthService.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthService.c
@@ -2100,7 +2100,7 @@ CleanCertsFromDb (

);
 
-  if (EFI_ERROR(Status)) {
+  if (EFI_ERROR(Status) || (AuthVariableInfo.Attributes & 
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) == 0) {
 Status  = DeleteCertsFromDb(
 VariableName,
 ,
-- 
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