Date   

[patch] MdeModulePkg/UsbMass: Not retry if usb bot transfer execution fail

Feng Tian <feng.tian@...>
 

[Sorry, this patch was pushed into EDKII trunk by wrong operation.

If the review mail could pass review, I would prefer to not do a roll-back.
Sorry again for that.

If there is other opinions, please let me know.]

The retry mechanism will bring issue if the usb device is unplugged
from XHCI HC but s/w is trying to access it through BlockIo. The
current cmd will get device error return status, but the sequential
cmds will be timeout. This behavior will cause system unresponsive
for a long while and bring bad user experience.

So we break the retry loop if found device error.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
---
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c | 9 +++++++--
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c | 8 ++++++--
2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
index 9f99650..96c3622 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
@@ -2,7 +2,7 @@
Implementation of the command set of USB Mass Storage Specification
for Bootability, Revision 1.0.

-Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -189,6 +189,11 @@ UsbBootExecCmd (
return EFI_TIMEOUT;
}

+ if (Status == EFI_DEVICE_ERROR) {
+ DEBUG ((EFI_D_ERROR, "UsbBootExecCmd: Device Error to Exec 0x%x Cmd\n", *(UINT8 *)Cmd));
+ return EFI_DEVICE_ERROR;
+ }
+
//
// If ExecCommand() returns no error and CmdResult is success,
// then the commnad transfer is successful.
@@ -271,7 +276,7 @@ UsbBootExecCmdWithRetry (
DataLen,
Timeout
);
- if (Status == EFI_SUCCESS || Status == EFI_MEDIA_CHANGED || Status == EFI_NO_MEDIA) {
+ if (Status == EFI_SUCCESS || Status == EFI_MEDIA_CHANGED || Status == EFI_NO_MEDIA || Status == EFI_DEVICE_ERROR) {
break;
}
//
diff --git a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
index dd83540..0767ff0 100644
--- a/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
+++ b/MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
@@ -2,7 +2,7 @@
Implementation of the USB mass storage Bulk-Only Transport protocol,
according to USB Mass Storage Class Bulk-Only Transport, Revision 1.0.

-Copyright (c) 2007 - 2011, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2007 - 2016, Intel Corporation. All rights reserved.<BR>
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD License
which accompanies this distribution. The full text of the license may be found at
@@ -432,7 +432,11 @@ UsbBotExecCommand (
// whether it succeeds or fails.
//
TransLen = (UINTN) DataLen;
- UsbBotDataTransfer (UsbBot, DataDir, Data, &TransLen, Timeout);
+ Status = UsbBotDataTransfer (UsbBot, DataDir, Data, &TransLen, Timeout);
+ if (Status == EFI_DEVICE_ERROR) {
+ DEBUG ((EFI_D_ERROR, "UsbBotExecCommand: UsbBotDataTransfer (%r)\n", Status));
+ return Status;
+ }

//
// Get the status, if that succeeds, interpret the result
--
2.7.1.windows.2


Re: Foreign keyboard support in UEFI

Senthilarasu_ARUNACH@...
 

Aaron,
Thanks for detailed information to start our investigation . Will keep update our findings in this forum.



From: Aaron.Pop@congatec.com<mailto:Aaron.Pop@congatec.com> [mailto:Aaron.Pop@congatec.com]
Sent: Tuesday, August 2, 2016 2:16 PM
To: Arunachalam, Senthil <Senthilarasu_ARUNACH@Dell.com<mailto:Senthilarasu_ARUNACH@Dell.com>>
Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: Re: [edk2] Foreign keyboard support in UEFI

Hi Senthil,

Multi language keyboards support should be pretty transparent to an application. The simple text input protocols are designed to return a unicode character, and the protocols leave the mapping of keypress into the current keyboard layout to the system firmware. Keyboard layouts are installed into the Hii database, and then a set keyboard layout call is made to tell the system which keyboard layout to use. Each regional keyboard has a different layout (https://msdn.microsoft.com/en-us/goglobal/bb964651.aspx). The UEFI specification (section 31.2.4) maps a keyboard into an enumerated value (EFI_KEY in MdePkg\Include\Uefi\UefiInternalFormRepresentation.h) and that enumerated value is used as an index into the keyboard layout data to return a unicode character for a specific keypress.

If you are not getting a valid return character when you press a key on a usb keyboard, then there is a chance that the UsbKbDxe driver does not consider the key you pressed as a valid Usb key for the given keyboard layout. USB keyboards return a Usage ID for a given key press (http://www.usb.org/developers/hidpage/Hut1_12v2.pdf). The EDK2 Usb keyboard driver (MdeModulePkg/Bus/Usb/UsbKbDxe) retrieves the USB usage id and translates it into an EFI_KEY_DATA entry by using the tables in the top of the Keyboard.c file (EfiKeyToUsbKeyCodeConvertionTable and mUsbKeyboardLayoutBin). It is possible that your system does not correctly map the hid usage id to a valid EFI_KEY enum based on the current keyboard mapping layout.

I hope this gives you enough information to start to figure out your issue.





From: <Senthilarasu_ARUNACH@Dell.com<mailto:Senthilarasu_ARUNACH@Dell.com>>
To: <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Date: 08/01/2016 09:53 PM
Subject: [edk2] Foreign keyboard support in UEFI
Sent by: "edk2-devel" <edk2-devel-bounces@lists.01.org<mailto:edk2-devel-bounces@lists.01.org>>
________________________________



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


Thanks
Senthil





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


Re: Foreign keyboard support in UEFI

Senthilarasu_ARUNACH@...
 

Dell - Internal Use - Confidential
Aaron,
Thanks for detailed information to start our investigation . Will keep update our findings in this forum.


From: Aaron.Pop@congatec.com [mailto:Aaron.Pop@congatec.com]
Sent: Tuesday, August 2, 2016 2:16 PM
To: Arunachalam, Senthil <Senthilarasu_ARUNACH@Dell.com>
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Foreign keyboard support in UEFI

Hi Senthil,

Multi language keyboards support should be pretty transparent to an application. The simple text input protocols are designed to return a unicode character, and the protocols leave the mapping of keypress into the current keyboard layout to the system firmware. Keyboard layouts are installed into the Hii database, and then a set keyboard layout call is made to tell the system which keyboard layout to use. Each regional keyboard has a different layout (https://msdn.microsoft.com/en-us/goglobal/bb964651.aspx). The UEFI specification (section 31.2.4) maps a keyboard into an enumerated value (EFI_KEY in MdePkg\Include\Uefi\UefiInternalFormRepresentation.h) and that enumerated value is used as an index into the keyboard layout data to return a unicode character for a specific keypress.

If you are not getting a valid return character when you press a key on a usb keyboard, then there is a chance that the UsbKbDxe driver does not consider the key you pressed as a valid Usb key for the given keyboard layout. USB keyboards return a Usage ID for a given key press (http://www.usb.org/developers/hidpage/Hut1_12v2.pdf). The EDK2 Usb keyboard driver (MdeModulePkg/Bus/Usb/UsbKbDxe) retrieves the USB usage id and translates it into an EFI_KEY_DATA entry by using the tables in the top of the Keyboard.c file (EfiKeyToUsbKeyCodeConvertionTable and mUsbKeyboardLayoutBin). It is possible that your system does not correctly map the hid usage id to a valid EFI_KEY enum based on the current keyboard mapping layout.

I hope this gives you enough information to start to figure out your issue.





From: <Senthilarasu_ARUNACH@Dell.com<mailto:Senthilarasu_ARUNACH@Dell.com>>
To: <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Date: 08/01/2016 09:53 PM
Subject: [edk2] Foreign keyboard support in UEFI
Sent by: "edk2-devel" <edk2-devel-bounces@lists.01.org<mailto:edk2-devel-bounces@lists.01.org>>
________________________________



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


Thanks
Senthil





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


Re: [Patch] SecurityPkg OpalPasswordDxe: Fix buffer overflow issue.

Zeng, Star <star.zeng@...>
 

Reviewed-by: Star Zeng <star.zeng@intel.com>

-----Original Message-----
From: Dong, Eric
Sent: Tuesday, August 2, 2016 7:33 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star <star.zeng@intel.com>
Subject: [Patch] SecurityPkg OpalPasswordDxe: Fix buffer overflow issue.

In current code, PSID is processed as string and the length is 0x20.
Current code only reserved 0x20 length buffer for it, no extra buffer for the '\0'. When driver call UnicodeStrToAsciiStrS to convert PSID, it search the '\0' for the end. So extra dirty data saved in PSID info which caused PSID revert action failed. This patch reserved extra 1 byte data for the '\0'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong <eric.dong@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
---
SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c | 5 ++++-
SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c b/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c
index 9a44c56..ee73697 100644
--- a/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c
+++ b/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHii.c
@@ -595,12 +595,15 @@ HiiPsidRevert(
OPAL_DISK *OpalDisk;
TCG_RESULT Ret;
OPAL_SESSION Session;
+ UINT8 TmpBuf[PSID_CHARACTER_STRING_END_LENGTH];

Ret = TcgResultFailure;

OpalHiiGetBrowserData();

- UnicodeStrToAsciiStrS (gHiiConfiguration.Psid, (CHAR8*)Psid.Psid, PSID_CHARACTER_LENGTH);
+ ZeroMem (TmpBuf, sizeof (TmpBuf));
+ UnicodeStrToAsciiStrS (gHiiConfiguration.Psid, (CHAR8*)TmpBuf,
+ PSID_CHARACTER_STRING_END_LENGTH);
+ CopyMem (Psid.Psid, TmpBuf, PSID_CHARACTER_LENGTH);

OpalDisk = HiiGetOpalDiskCB (gHiiConfiguration.SelectedDiskIndex);
if (OpalDisk != NULL) {
diff --git a/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h b/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h
index 138bcb8..88cf9f5 100644
--- a/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h
+++ b/SecurityPkg/Tcg/Opal/OpalPasswordDxe/OpalHiiFormValues.h
@@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.

// PSID Length
#define PSID_CHARACTER_LENGTH 0x20
+#define PSID_CHARACTER_STRING_END_LENGTH 0x21

// ID's for various forms that will be used by HII
#define FORMID_VALUE_MAIN_MENU 0x01
@@ -38,7 +39,7 @@ typedef struct {
UINT8 KeepUserData;
UINT16 AvailableFields;
UINT16 Password[MAX_PASSWORD_CHARACTER_LENGTH];
- UINT16 Psid[PSID_CHARACTER_LENGTH];
+ UINT16 Psid[PSID_CHARACTER_STRING_END_LENGTH];
UINT8 EnableBlockSid;
} OPAL_HII_CONFIGURATION;
#pragma pack()
--
2.6.4.windows.1


Re: Build traceback with new CLANG35 toolset

Shi, Steven <steven.shi@...>
 

Cran,
We will send CLANG38 patch to support X86, and the new CLANG38 patch will base on current GCC5 implementation. FYI.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Bruce Cran
Sent: Wednesday, August 03, 2016 2:56 AM
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: [edk2] Build traceback with new CLANG35 toolset

On 8/2/2016 12:53 PM, Ard Biesheuvel wrote:

CLANG35 is not new, and currently only supports ARM and AARCH64
Oops - thanks. I was thinking of CLANG38 that hasn't been committed yet.

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


[PATCH] [staging/HTTPS-TLS] Delete extra TlsCipherMappingTable entries

Thomas Palmer <thomas.palmer@...>
 

The TlsCipherMappingTable will be used to control which ciphers UEFI
officially supports. When a user configures the ciphers, each cipher
is checked against this table and if not found is sent the
EFI_UNSUPPORTED error.

However, when an entry is present in TlsCipherMappingTable, but our
library does not have support for it, the user will not see any
error if other ciphers are being set at the same time.

This patch will remove entries from TlsLib's TlsCipherMappingTable
that our OpenSSL library is not configured to support. This restores
behavior of immediate feedback to user.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com>
---
CryptoPkg/Library/TlsLib/TlsLib.c | 7 -------
1 file changed, 7 deletions(-)

diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c b/CryptoPkg/Library/TlsLib/TlsLib.c
index 1f3554a..aa08595 100644
--- a/CryptoPkg/Library/TlsLib/TlsLib.c
+++ b/CryptoPkg/Library/TlsLib/TlsLib.c
@@ -57,31 +57,24 @@ STATIC CONST TLS_CIPHER_PAIR TlsCipherMappingTable[] = {
{ 0x0002, "NULL-SHA" }, /// TLS_RSA_WITH_NULL_SHA
{ 0x0004, "RC4-MD5" }, /// TLS_RSA_WITH_RC4_128_MD5
{ 0x0005, "RC4-SHA" }, /// TLS_RSA_WITH_RC4_128_SHA
- { 0x0007, "IDEA-CBC-SHA" }, /// TLS_RSA_WITH_IDEA_CBC_SHA
- { 0x0009, "DES-CBC-SHA" }, /// TLS_RSA_WITH_DES_CBC_SHA
{ 0x000A, "DES-CBC3-SHA" }, /// TLS_RSA_WITH_3DES_EDE_CBC_SHA, mandatory TLS 1.1
- { 0x0013, "DHE-DSS-DES-CBC3-SHA" }, /// TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, mandatory TLS 1.0
{ 0x0016, "DHE-RSA-DES-CBC3-SHA" }, /// TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
{ 0x002F, "AES128-SHA" }, /// TLS_RSA_WITH_AES_128_CBC_SHA, mandatory TLS 1.2
{ 0x0030, "DH-DSS-AES128-SHA" }, /// TLS_DH_DSS_WITH_AES_128_CBC_SHA
{ 0x0031, "DH-RSA-AES128-SHA" }, /// TLS_DH_RSA_WITH_AES_128_CBC_SHA
- { 0x0032, "DHE-DSS-AES128-SHA" }, /// TLS_DHE_DSS_WITH_AES_128_CBC_SHA
{ 0x0033, "DHE-RSA-AES128-SHA" }, /// TLS_DHE_RSA_WITH_AES_128_CBC_SHA
{ 0x0035, "AES256-SHA" }, /// TLS_RSA_WITH_AES_256_CBC_SHA
{ 0x0036, "DH-DSS-AES256-SHA" }, /// TLS_DH_DSS_WITH_AES_256_CBC_SHA
{ 0x0037, "DH-RSA-AES256-SHA" }, /// TLS_DH_RSA_WITH_AES_256_CBC_SHA
- { 0x0038, "DHE-DSS-AES256-SHA" }, /// TLS_DHE_DSS_WITH_AES_256_CBC_SHA
{ 0x0039, "DHE-RSA-AES256-SHA" }, /// TLS_DHE_RSA_WITH_AES_256_CBC_SHA
{ 0x003B, "NULL-SHA256" }, /// TLS_RSA_WITH_NULL_SHA256
{ 0x003C, "AES128-SHA256" }, /// TLS_RSA_WITH_AES_128_CBC_SHA256
{ 0x003D, "AES256-SHA256" }, /// TLS_RSA_WITH_AES_256_CBC_SHA256
{ 0x003E, "DH-DSS-AES128-SHA256" }, /// TLS_DH_DSS_WITH_AES_128_CBC_SHA256
{ 0x003F, "DH-RSA-AES128-SHA256" }, /// TLS_DH_RSA_WITH_AES_128_CBC_SHA256
- { 0x0040, "DHE-DSS-AES128-SHA256" }, /// TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
{ 0x0067, "DHE-RSA-AES128-SHA256" }, /// TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
{ 0x0068, "DH-DSS-AES256-SHA256" }, /// TLS_DH_DSS_WITH_AES_256_CBC_SHA256
{ 0x0069, "DH-RSA-AES256-SHA256" }, /// TLS_DH_RSA_WITH_AES_256_CBC_SHA256
- { 0x006A, "DHE-DSS-AES256-SHA256" }, /// TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
{ 0x006B, "DHE-RSA-AES256-SHA256" } /// TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
};

--
1.9.1


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

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

I have two sets of lists, one for the ciphers the OpenSSL by default configures in a new CTX and the other after setting all ciphers available in the mapping table. For both sets I show the affect of removing no-idea/no-dsa and adding enable-weak-ciphers

These are the ciphers that are supported by TLS immediately after a TLS_CTX_new operation with current OpenSSL config (34):
AES128-GCM-SHA256
AES128-SHA
AES128-SHA256
AES256-GCM-SHA384
AES256-SHA
AES256-SHA256
DES-CBC3-SHA
DH-DSS-AES128-GCM-SHA256
DH-DSS-AES128-SHA
DH-DSS-AES128-SHA256
DH-DSS-AES256-GCM-SHA384
DH-DSS-AES256-SHA
DH-DSS-AES256-SHA256
DH-DSS-DES-CBC3-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA256
DH-RSA-AES128-GCM-SHA256
DH-RSA-AES128-SHA
DH-RSA-AES128-SHA256
DH-RSA-AES256-GCM-SHA384
DH-RSA-AES256-SHA
DH-RSA-AES256-SHA256
DH-RSA-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
PSK-3DES-EDE-CBC-SHA
PSK-AES128-CBC-SHA
PSK-AES256-CBC-SHA
PSK-RC4-SHA
RC4-MD5
RC4-SHA

By removing "no-idea" in process_files we gain (1):
IDEA-CBC-SHA

By removing "no-dsa" in process_files we gain (7):
DHE-DSS-AES128-GCM-SHA256
DHE-DSS-AES128-SHA
DHE-DSS-AES128-SHA256
DHE-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-SHA
DHE-DSS-AES256-SHA256
EDH-DSS-DES-CBC3-SHA

We do not gain any more ciphers with enable-weak-ssl-ciphers at this point.


Now here are the ciphers after TlsSetCipherList has been run with setting all ciphers currently in TlsCipherMappingTable.
With original OpenSSL configuration (23):
AES128-SHA
AES128-SHA256
AES256-SHA
AES256-SHA256
DES-CBC3-SHA
DH-DSS-AES128-SHA
DH-DSS-AES128-SHA256
DH-DSS-AES256-SHA
DH-DSS-AES256-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA256
DH-RSA-AES128-SHA
DH-RSA-AES128-SHA256
DH-RSA-AES256-SHA
DH-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA
NULL-MD5
NULL-SHA
NULL-SHA256
RC4-MD5
RC4-SHA

By removing "no-idea" in process_files we gain (1):
IDEA-CBC-SHA

By removing "no-dsa" in process_files we gain (5):
DHE-DSS-AES256-SHA
DHE-DSS-AES256-SHA256
DHE-DSS-AES128-SHA
DHE-DSS-AES128-SHA256
EDH-DSS-DES-CBC3-SHA

Be adding enable-weak-ssl-ciphers we gain (1):
DES-CBC-SHA


Thomas

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

Thomas,

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

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

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


Thanks,
Jiaxin



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


Hi Jiaxin,

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

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

Thomas

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

Hi Thomas,

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

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

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

Thanks,
Jiaxin

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

Jiaxin / Qin,


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

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

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

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

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

Thomas

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

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

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


Best Regards & Thanks,
LONG, Qin

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

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

Qin,
What's your opinion?

Thanks.
Jiaxin

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

Jiaxin,

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

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

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

Thomas

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

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

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

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

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

--
1.9.5.msysgit.1

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


Re: Tianocore Bugzilla Server is now live

Andrew Fish
 

On Aug 2, 2016, at 12:43 PM, Michael Zimmermann <sigmaepsilon92@gmail.com> wrote:

How are security issues treated in UEFI anyway?
They follow the standard ethical disclosure process like then one discussed here: http://www.uefi.org/security

Are they kept a secret forever or just for a specific time span?
The ethical disclosure processes is followed and an timespan is picked that lets systems that are going to get updates get fixed. This is how things security work in general.

A reason for keeping them a secret forever(while pushing
unsuspicious fixes) probably would be the fact that most UEFI systems don't
get updated.
No after some reasonable amount of time there will be disclosure to the public. The embargo of information is to let as many folks as possible get patches in place before the issue is public.

Thanks,

Andrew Fish

Thanks
Michael

On Tue, Aug 2, 2016 at 9:34 PM, Laszlo Ersek <lersek@redhat.com> wrote:

On 08/02/16 21:10, Kinney, Michael D wrote:
Michael,

I am open to suggestions on this topic.

If there is a strong opinion that we need to protect specific fields
from being modified, then we can look into updating the configuration.

I think with Bugzilla change history and edk2-bugs mailing list, we can
all see the changes to any issue, so even if someone does do an
incorrect edit, I think we can put it back.
Does "editbugs" include changing the product from "Tianocore Security
Issues" to something else, possibly exposing the security issue to the
world?

Hm... It probably doesn't matter. If a security issue can be looked at
(which is a pre-requisite for the product field to be changed) by anyone
in the first place, then they can expose the contents to the world in
other ways too. :)

So I think trusting all registered accounts with "editbugs" is a good
starting point too.

Thanks
Laszlo


*From:*Michael Zimmermann [mailto:sigmaepsilon92@gmail.com]
*Sent:* Tuesday, August 2, 2016 11:57 AM
*To:* Laszlo Ersek <lersek@redhat.com>
*Cc:* Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel-01
<edk2-devel@ml01.01.org>
*Subject:* Re: [edk2] Tianocore Bugzilla Server is now live



Is it just my account or does everybody have the permission
"editbugs Can edit all bug fields"?



It sounds like this is something only moderators should be able to do.



Thanks

Michael



On Thu, Jul 21, 2016 at 8:43 PM, Laszlo Ersek <lersek@redhat.com
<mailto:lersek@redhat.com>> wrote:

On 07/21/16 20:07, Kinney, Michael D wrote:
Laszlo,

Try again...it was disabled for a short period of time.
Yes, it's working now.

I'll let you know when I'm done with the clipboard "wizardry" and the
occasional reformatting :)

Thanks!
Laszlo

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
<mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of Laszlo Ersek
Sent: Thursday, July 21, 2016 10:33 AM
To: Kinney, Michael D <michael.d.kinney@intel.com <mailto:
michael.d.kinney@intel.com>>
Cc: edk2-devel-01 <edk2-devel@ml01.01.org <mailto:
edk2-devel@ml01.01.org>>
Subject: Re: [edk2] Tianocore Bugzilla Server is now live

On 07/21/16 19:05, Kinney, Michael D wrote:
Laszlo,

Yes. We can hold off disabling GitHub. Let us know when you
are ready.

Thank you! However, github is rejecting my new comments in the
browser
tabs that I have open already, and it rejects my fresh requests
for
issue URLs.

Thanks,
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org <mailto: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


Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

Larry Cleeton <Larry.Cleeton@...>
 

This commit (fdc4b0b147b386e966e99893526181dfae9eaeef) changed a data structure that is stored in an NVRAM variable.
See NetworkPkg/Ip6Dxe/Ip6ConfigImpl.[c,h]

This data structure:

typedef struct {
UINT16 Offset;
UINTN DataSize;
EFI_IP6_CONFIG_DATA_TYPE DataType;
} IP6_CONFIG_DATA_RECORD;

Is now:

typedef struct {
UINT16 Offset;
UINT32 DataSize; <---------------- changed size in 64bit environments
EFI_IP6_CONFIG_DATA_TYPE DataType;
} IP6_CONFIG_DATA_RECORD;

Unfortunately with a 64bit implementation this current structure is now *not* compatible with an existing NVRAM variable written with the previous version of the structure. It's causing me considerable grief so I'm just sharing the discovery. It would only impact you if you update some 64bit machine's firmware with a new version containing this change.

--Larry


[PATCH] CorebootModulePkg/SecCore: Adding NASM files in SecCore module

Ma, Maurice
 

Ported MASM/GAS assembly files into NASM files and updated the
inf file to refer to NASM files.

This change has been tested with GCC 4.8 and VS2013 build.

Cc: Prince Agyeman <prince.agyeman@intel.com>
Cc: Lee Leahy <leroy.p.leahy@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
---
CorebootModulePkg/SecCore/Ia32/SecEntry.nasm | 72 +++++++++++++++++++++++++
CorebootModulePkg/SecCore/Ia32/Stack.nasm | 78 ++++++++++++++++++++++++++++
CorebootModulePkg/SecCore/SecCore.inf | 6 +--
3 files changed, 152 insertions(+), 4 deletions(-)
create mode 100644 CorebootModulePkg/SecCore/Ia32/SecEntry.nasm
create mode 100644 CorebootModulePkg/SecCore/Ia32/Stack.nasm

diff --git a/CorebootModulePkg/SecCore/Ia32/SecEntry.nasm b/CorebootModulePkg/SecCore/Ia32/SecEntry.nasm
new file mode 100644
index 000000000000..2b9b80549900
--- /dev/null
+++ b/CorebootModulePkg/SecCore/Ia32/SecEntry.nasm
@@ -0,0 +1,72 @@
+;------------------------------------------------------------------------------
+;
+; Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.<BR>
+; This program and the accompanying materials
+; are licensed and made available under the terms and conditions of the BSD License
+; which accompanies this distribution. The full text of the license may be found at
+; http://opensource.org/licenses/bsd-license.php.
+;
+; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+;
+; Abstract:
+;
+; Entry point for the coreboot UEFI payload.
+;
+;------------------------------------------------------------------------------
+
+SECTION .text
+
+; C Functions
+extern ASM_PFX(SecStartup)
+
+; Pcds
+extern ASM_PFX(PcdGet32 (PcdPayloadFdMemBase))
+
+;
+; SecCore Entry Point
+;
+; Processor is in flat protected mode
+;
+; @param[in] EAX Initial value of the EAX register (BIST: Built-in Self Test)
+; @param[in] DI 'BP': boot-strap processor, or 'AP': application processor
+; @param[in] EBP Pointer to the start of the Boot Firmware Volume
+;
+; @return None This routine does not return
+;
+global ASM_PFX(_ModuleEntryPoint)
+ASM_PFX(_ModuleEntryPoint):
+ ;
+ ; Disable all the interrupts
+ ;
+ cli
+ ;
+ ; Construct the temporary memory at 0x80000, length 0x10000
+ ;
+ mov esp, (BASE_512KB + SIZE_64KB)
+
+ ;
+ ; Pass BFV into the PEI Core
+ ;
+ push DWORD [ASM_PFX(PcdGet32 (PcdPayloadFdMemBase))]
+
+ ;
+ ; Pass stack base into the PEI Core
+ ;
+ push BASE_512KB
+
+ ;
+ ; Pass stack size into the PEI Core
+ ;
+ push SIZE_64KB
+
+ ;
+ ; Pass Control into the PEI Core
+ ;
+ call ASM_PFX(SecStartup)
+
+ ;
+ ; Should never return
+ ;
+ jmp $
+
diff --git a/CorebootModulePkg/SecCore/Ia32/Stack.nasm b/CorebootModulePkg/SecCore/Ia32/Stack.nasm
new file mode 100644
index 000000000000..c877e52e52b8
--- /dev/null
+++ b/CorebootModulePkg/SecCore/Ia32/Stack.nasm
@@ -0,0 +1,78 @@
+;------------------------------------------------------------------------------
+;
+; Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.<BR>
+; This program and the accompanying materials
+; are licensed and made available under the terms and conditions of the BSD License
+; which accompanies this distribution. The full text of the license may be found at
+; http://opensource.org/licenses/bsd-license.php.
+;
+; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+;
+; Abstract:
+;
+; Switch the stack from temporary memory to permanent memory.
+;
+;------------------------------------------------------------------------------
+
+SECTION .text
+
+;------------------------------------------------------------------------------
+; VOID
+; EFIAPI
+; SecSwitchStack (
+; UINT32 TemporaryMemoryBase,
+; UINT32 PermenentMemoryBase
+; );
+;------------------------------------------------------------------------------
+global ASM_PFX(SecSwitchStack)
+ASM_PFX(SecSwitchStack):
+ ;
+ ; Save three register: eax, ebx, ecx
+ ;
+ push eax
+ push ebx
+ push ecx
+ push edx
+
+ ;
+ ; !!CAUTION!! this function address's is pushed into stack after
+ ; migration of whole temporary memory, so need save it to permanent
+ ; memory at first!
+ ;
+
+ mov ebx, [esp + 20] ; Save the first parameter
+ mov ecx, [esp + 24] ; Save the second parameter
+
+ ;
+ ; Save this function's return address into permanent memory at first.
+ ; Then, Fixup the esp point to permanent memory
+ ;
+ mov eax, esp
+ sub eax, ebx
+ add eax, ecx
+ mov edx, [esp] ; copy pushed register's value to permanent memory
+ mov [eax], edx
+ mov edx, [esp + 4]
+ mov [eax + 4], edx
+ mov edx, [esp + 8]
+ mov [eax + 8], edx
+ mov edx, [esp + 12]
+ mov [eax + 12], edx
+ mov edx, [esp + 16] ; Update return address into permanent memory
+ mov [eax + 16], edx
+ mov esp, eax ; From now, esp is pointed to permanent memory
+
+ ;
+ ; Fixup the ebp point to permenent memory
+ ;
+ mov eax, ebp
+ sub eax, ebx
+ add eax, ecx
+ mov ebp, eax ; From now, ebp is pointed to permanent memory
+
+ pop edx
+ pop ecx
+ pop ebx
+ pop eax
+ ret
diff --git a/CorebootModulePkg/SecCore/SecCore.inf b/CorebootModulePkg/SecCore/SecCore.inf
index f8468f4c24af..9fa99c4b0083 100644
--- a/CorebootModulePkg/SecCore/SecCore.inf
+++ b/CorebootModulePkg/SecCore/SecCore.inf
@@ -33,10 +33,8 @@
FindPeiCore.c

[Sources.IA32]
- Ia32/Stack.asm | MSFT
- Ia32/Stack.S | GCC
- Ia32/SecEntry.asm | MSFT
- Ia32/SecEntry.S | GCC
+ Ia32/Stack.nasm
+ Ia32/SecEntry.nasm

[Packages]
MdePkg/MdePkg.dec
--
1.9.5.msysgit.0


Re: [PATCH v2] OvmfPkg: use StatusCode Router and Handler from MdeModulePkg

Laszlo Ersek
 

On 08/02/16 20:23, Jordan Justen wrote:
On 2016-08-02 10:25:10, Cinnamon Shia wrote:
In the Platform Init v1.4a spec,
- Volume 1 "4.7 Status Code Service" defines the
EFI_PEI_SERVICES.ReportStatusCode() service,
- Volume 1 "6.3.5 Status Code PPI (Optional)" defines the
EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above),
- Volume 2 "14.2 Status Code Runtime Protocol" defines the
EFI_STATUS_CODE_PROTOCOL.

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

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

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

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

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

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

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

The status code handling in the StatusCodeHandler modules is identical
to the one currently provided by the IntelFrameworkModulePkg modules.
Replace the IntelFareworkModulePkg modules with the MdeModulePkg ones,
so we can decrease our dependency on IntelFareworkModulePkg.
Noting two typos of 'Farework' here. We can fix during commit.
Yeah, that's just more mess from me. I should probably not propose
commit messages at 3 AM :)

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

I'll give Laszlo some time to respond too since he's already spent
some time on it previously.
Thank you.

[jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>

Commit a6d594c5fabd.

I also closed <https://tianocore.acgmultimedia.com/show_bug.cgi?id=63>.

Thank you Cinnamon for the contribution!

Cheers
Laszlo


-Jordan


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Suggested-by: Liming Gao <liming.gao@intel.com>
Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63
---
OvmfPkg/OvmfPkgIa32.dsc | 7 +++++--
OvmfPkg/OvmfPkgIa32.fdf | 7 +++++--
OvmfPkg/OvmfPkgIa32X64.dsc | 7 +++++--
OvmfPkg/OvmfPkgIa32X64.fdf | 7 +++++--
OvmfPkg/OvmfPkgX64.dsc | 7 +++++--
OvmfPkg/OvmfPkgX64.fdf | 7 +++++--
6 files changed, 30 insertions(+), 12 deletions(-)

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

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

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

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

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

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

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

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

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

INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
--
2.9.0.windows.1
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: Tianocore Bugzilla Server is now live

Michael Zimmermann
 

How are security issues treated in UEFI anyway?
Are they kept a secret forever or just for a specific time span?

A reason for keeping them a secret forever(while pushing
unsuspicious fixes) probably would be the fact that most UEFI systems don't
get updated.

Thanks
Michael

On Tue, Aug 2, 2016 at 9:34 PM, Laszlo Ersek <lersek@redhat.com> wrote:

On 08/02/16 21:10, Kinney, Michael D wrote:
Michael,

I am open to suggestions on this topic.

If there is a strong opinion that we need to protect specific fields
from being modified, then we can look into updating the configuration.

I think with Bugzilla change history and edk2-bugs mailing list, we can
all see the changes to any issue, so even if someone does do an
incorrect edit, I think we can put it back.
Does "editbugs" include changing the product from "Tianocore Security
Issues" to something else, possibly exposing the security issue to the
world?

Hm... It probably doesn't matter. If a security issue can be looked at
(which is a pre-requisite for the product field to be changed) by anyone
in the first place, then they can expose the contents to the world in
other ways too. :)

So I think trusting all registered accounts with "editbugs" is a good
starting point too.

Thanks
Laszlo


*From:*Michael Zimmermann [mailto:sigmaepsilon92@gmail.com]
*Sent:* Tuesday, August 2, 2016 11:57 AM
*To:* Laszlo Ersek <lersek@redhat.com>
*Cc:* Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel-01
<edk2-devel@ml01.01.org>
*Subject:* Re: [edk2] Tianocore Bugzilla Server is now live



Is it just my account or does everybody have the permission
"editbugs Can edit all bug fields"?



It sounds like this is something only moderators should be able to do.



Thanks

Michael



On Thu, Jul 21, 2016 at 8:43 PM, Laszlo Ersek <lersek@redhat.com
<mailto:lersek@redhat.com>> wrote:

On 07/21/16 20:07, Kinney, Michael D wrote:
> Laszlo,
>
> Try again...it was disabled for a short period of time.

Yes, it's working now.

I'll let you know when I'm done with the clipboard "wizardry" and the
occasional reformatting :)

Thanks!
Laszlo

>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
<mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of Laszlo Ersek
>> Sent: Thursday, July 21, 2016 10:33 AM
>> To: Kinney, Michael D <michael.d.kinney@intel.com <mailto:
michael.d.kinney@intel.com>>
>> Cc: edk2-devel-01 <edk2-devel@ml01.01.org <mailto:
edk2-devel@ml01.01.org>>
>> Subject: Re: [edk2] Tianocore Bugzilla Server is now live
>>
>> On 07/21/16 19:05, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> Yes. We can hold off disabling GitHub. Let us know when you
are ready.
>>
>> Thank you! However, github is rejecting my new comments in the
browser
>> tabs that I have open already, and it rejects my fresh requests
for
>> issue URLs.
>>
>> Thanks,
>> Laszlo

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



Re: Tianocore Bugzilla Server is now live

Laszlo Ersek
 

On 08/02/16 21:10, Kinney, Michael D wrote:
Michael,

I am open to suggestions on this topic.

If there is a strong opinion that we need to protect specific fields
from being modified, then we can look into updating the configuration.

I think with Bugzilla change history and edk2-bugs mailing list, we can
all see the changes to any issue, so even if someone does do an
incorrect edit, I think we can put it back.
Does "editbugs" include changing the product from "Tianocore Security
Issues" to something else, possibly exposing the security issue to the
world?

Hm... It probably doesn't matter. If a security issue can be looked at
(which is a pre-requisite for the product field to be changed) by anyone
in the first place, then they can expose the contents to the world in
other ways too. :)

So I think trusting all registered accounts with "editbugs" is a good
starting point too.

Thanks
Laszlo


*From:*Michael Zimmermann [mailto:sigmaepsilon92@gmail.com]
*Sent:* Tuesday, August 2, 2016 11:57 AM
*To:* Laszlo Ersek <lersek@redhat.com>
*Cc:* Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel-01
<edk2-devel@ml01.01.org>
*Subject:* Re: [edk2] Tianocore Bugzilla Server is now live



Is it just my account or does everybody have the permission
"editbugs Can edit all bug fields"?



It sounds like this is something only moderators should be able to do.



Thanks

Michael



On Thu, Jul 21, 2016 at 8:43 PM, Laszlo Ersek <lersek@redhat.com
<mailto:lersek@redhat.com>> wrote:

On 07/21/16 20:07, Kinney, Michael D wrote:
> Laszlo,
>
> Try again...it was disabled for a short period of time.

Yes, it's working now.

I'll let you know when I'm done with the clipboard "wizardry" and the
occasional reformatting :)

Thanks!
Laszlo

>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
<mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of Laszlo Ersek
>> Sent: Thursday, July 21, 2016 10:33 AM
>> To: Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>>
>> Cc: edk2-devel-01 <edk2-devel@ml01.01.org <mailto:edk2-devel@ml01.01.org>>
>> Subject: Re: [edk2] Tianocore Bugzilla Server is now live
>>
>> On 07/21/16 19:05, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> Yes. We can hold off disabling GitHub. Let us know when you are ready.
>>
>> Thank you! However, github is rejecting my new comments in the browser
>> tabs that I have open already, and it rejects my fresh requests for
>> issue URLs.
>>
>> Thanks,
>> Laszlo

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



Re: Foreign keyboard support in UEFI

Aaron.Pop@...
 

Hi Senthil,

Multi language keyboards support should be pretty transparent to an
application. The simple text input protocols are designed to return a
unicode character, and the protocols leave the mapping of keypress into
the current keyboard layout to the system firmware. Keyboard layouts are
installed into the Hii database, and then a set keyboard layout call is
made to tell the system which keyboard layout to use. Each regional
keyboard has a different layout (
https://msdn.microsoft.com/en-us/goglobal/bb964651.aspx). The UEFI
specification (section 31.2.4) maps a keyboard into an enumerated value
(EFI_KEY in MdePkg\Include\Uefi\UefiInternalFormRepresentation.h) and that
enumerated value is used as an index into the keyboard layout data to
return a unicode character for a specific keypress.

If you are not getting a valid return character when you press a key on a
usb keyboard, then there is a chance that the UsbKbDxe driver does not
consider the key you pressed as a valid Usb key for the given keyboard
layout. USB keyboards return a Usage ID for a given key press (
http://www.usb.org/developers/hidpage/Hut1_12v2.pdf). The EDK2 Usb
keyboard driver (MdeModulePkg/Bus/Usb/UsbKbDxe) retrieves the USB usage id
and translates it into an EFI_KEY_DATA entry by using the tables in the
top of the Keyboard.c file (EfiKeyToUsbKeyCodeConvertionTable and
mUsbKeyboardLayoutBin). It is possible that your system does not
correctly map the hid usage id to a valid EFI_KEY enum based on the
current keyboard mapping layout.

I hope this gives you enough information to start to figure out your
issue.





From: <Senthilarasu_ARUNACH@Dell.com>
To: <edk2-devel@lists.01.org>
Date: 08/01/2016 09:53 PM
Subject: [edk2] Foreign keyboard support in UEFI
Sent by: "edk2-devel" <edk2-devel-bounces@lists.01.org>



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


Thanks
Senthil





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


Re: Tianocore Bugzilla Server is now live

Laszlo Ersek
 

On 08/02/16 20:57, Michael Zimmermann wrote:
Is it just my account or does everybody have the permission "editbugsCan
edit all bug fields"?

It sounds like this is something only moderators should be able to do.
Indeed I noticed this permission when I last looked (in the "whine" thread).

I think it might make sense to restrict this permission to package
maintainers. And, I think "refinements" beyond that should not be
necessary -- I for one certainly would like to be able to edit all
bugzilla fields, regardless of their current values! :)

Thanks
Laszlo


Thanks
Michael

On Thu, Jul 21, 2016 at 8:43 PM, Laszlo Ersek <lersek@redhat.com
<mailto:lersek@redhat.com>> wrote:

On 07/21/16 20:07, Kinney, Michael D wrote:
> Laszlo,
>
> Try again...it was disabled for a short period of time.

Yes, it's working now.

I'll let you know when I'm done with the clipboard "wizardry" and the
occasional reformatting :)

Thanks!
Laszlo

>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org
<mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of Laszlo Ersek
>> Sent: Thursday, July 21, 2016 10:33 AM
>> To: Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>>
>> Cc: edk2-devel-01 <edk2-devel@ml01.01.org <mailto:edk2-devel@ml01.01.org>>
>> Subject: Re: [edk2] Tianocore Bugzilla Server is now live
>>
>> On 07/21/16 19:05, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> Yes. We can hold off disabling GitHub. Let us know when you are ready.
>>
>> Thank you! However, github is rejecting my new comments in the browser
>> tabs that I have open already, and it rejects my fresh requests for
>> issue URLs.
>>
>> Thanks,
>> Laszlo

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


Re: Tianocore Bugzilla Server is now live

Michael D Kinney
 

Michael,

I am open to suggestions on this topic.

If there is a strong opinion that we need to protect specific fields from being modified, then we can look into updating the configuration.

I think with Bugzilla change history and edk2-bugs mailing list, we can all see the changes to any issue, so even if someone does do an incorrect edit, I think we can put it back.

Mike


From: Michael Zimmermann [mailto:sigmaepsilon92@gmail.com]
Sent: Tuesday, August 2, 2016 11:57 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel-01 <edk2-devel@ml01.01.org>
Subject: Re: [edk2] Tianocore Bugzilla Server is now live

Is it just my account or does everybody have the permission "editbugs Can edit all bug fields"?

It sounds like this is something only moderators should be able to do.

Thanks
Michael

On Thu, Jul 21, 2016 at 8:43 PM, Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>> wrote:
On 07/21/16 20:07, Kinney, Michael D wrote:
Laszlo,

Try again...it was disabled for a short period of time.
Yes, it's working now.

I'll let you know when I'm done with the clipboard "wizardry" and the
occasional reformatting :)

Thanks!
Laszlo

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org<mailto:edk2-devel-bounces@lists.01.org>] On Behalf Of Laszlo Ersek
Sent: Thursday, July 21, 2016 10:33 AM
To: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: edk2-devel-01 <edk2-devel@ml01.01.org<mailto:edk2-devel@ml01.01.org>>
Subject: Re: [edk2] Tianocore Bugzilla Server is now live

On 07/21/16 19:05, Kinney, Michael D wrote:
Laszlo,

Yes. We can hold off disabling GitHub. Let us know when you are ready.
Thank you! However, github is rejecting my new comments in the browser
tabs that I have open already, and it rejects my fresh requests for
issue URLs.

Thanks,
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel


Re: Tianocore Bugzilla Server is now live

Michael Zimmermann
 

Is it just my account or does everybody have the permission "editbugs Can
edit all bug fields"?

It sounds like this is something only moderators should be able to do.

Thanks
Michael

On Thu, Jul 21, 2016 at 8:43 PM, Laszlo Ersek <lersek@redhat.com> wrote:

On 07/21/16 20:07, Kinney, Michael D wrote:
Laszlo,

Try again...it was disabled for a short period of time.
Yes, it's working now.

I'll let you know when I'm done with the clipboard "wizardry" and the
occasional reformatting :)

Thanks!
Laszlo

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
Laszlo Ersek
Sent: Thursday, July 21, 2016 10:33 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>
Cc: edk2-devel-01 <edk2-devel@ml01.01.org>
Subject: Re: [edk2] Tianocore Bugzilla Server is now live

On 07/21/16 19:05, Kinney, Michael D wrote:
Laszlo,

Yes. We can hold off disabling GitHub. Let us know when you are
ready.

Thank you! However, github is rejecting my new comments in the browser
tabs that I have open already, and it rejects my fresh requests for
issue URLs.

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


Re: [Patch v5 00/48] MP Initialize Library

Michael D Kinney
 

Jeff,

All the updates look good to me. There are 2 copyright date updates
missing in the SourceLevelDebugPkg that I replied to separately.

I have tested this on Galileo Gen 2 with SOURCE_DEBUG_ENABLE on and off
and also tested OS boot and ACPI S3.

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

Best regards,

Mike

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Jeff Fan
Sent: Tuesday, August 2, 2016 1:59 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch v5 00/48] MP Initialize Library

We add MP Initialize Library defined in UefiCpuPkg/Include/Library/MpInitLib.h.
It will provide basic functionalities of MP services and could be consumed by
CPU MP PEI and CPU MP DXE to produce CPU MP PPI and CPU MP Protocol. Then most
of code could be shared between PEI and DXE modules.

PeiMpInitLib and DxeMpInitLib are added to make the CpuMpPei and CpuDxe more
simply.

I also updated the Ovmf Platform and Quark platform to consume MP Initialize
library.

Thanks Laszlo to verify on OVMF and Mike to verify on Quark.

v5:
1. Update Patches #1, #5, #10 - #12, #14, #16 - #18, #20, #21, #28, #29, #37,
#43.
2. Add Patches #44, #48
(Please see the patches commit log for more details)

v4:
1. Update Patches #2 - #6, #10, #15, #28, #30, #31, #33, #34, #38, #41, #43.
2. Add Patches #7, #8, #42, #44 - #46.
3. Add Reviewed-by: Laszlo Ersek <lersek@redhat.com> on Patches #1, #2.
(Please see the patches commit log for more details)

v3:
1. Update Patch #2, #4 - #8, #28, #33, #36, #38 per Giri's comments to
a. Update SDM date to June, 2016
b. Mention BCD format in CPU_MICROCODE_DATE
c. Rename ProcessorChecksum to Checksum to match SDM.
d. Add whitespace after MpInitLibInitialize
e. Rename MpInitLibSwitchBsp to MpInitLibSwitchBSP to match PI spec.
f. Rename NumApsExecutingLoction to NumApsExecutingLocation
g. Add whitespace after ; in .nasm file
h. Rename *RellocateAp* to *RelocateAp*
2. Update Patch #16, #17, #29-#32 to
a. Use CamelCase for mStopCheckAllApsStatus and CheckAndUpdateApsStatus().
3. Update Patch #36 and #39 to
a. Add PeiMpInitLib instance in UefiCpuPkg.dsc
b. Add DxeMpInitLib instance in UefiCpuPkg.dsc
4. Update Patch #39 and #40 to
a. move the code of consuming MP Initialize library from patch #40 to
patch #39.
5. Update Patch #1, #3 - #8, #16 to
a. Add Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>

I fork the whole tree with the updated v3 patches
at https://github.com/vanjeff/edk2/tree/MpInitLibV5 for review.


Jeff Fan (48):
UefiCpuPkg/LocalApic.h: Remove duplicated/conflicted definitions
UefiCpuPkg/MpInitLib: Add microcode definitions defined in IA32 SDM
UefiCpuPkg/CpuS3DataDxe: Move StartupVector allocation to EndOfDxe()
UefiCpuPkg/MpInitLib: Add MP Initialize library class definition
UefiCpuPkg/MpInitLib: Add two instances PeiMpInitLib and DxeMpInitLib
UefiCpuPkg/MpInitLib: Add AP assembly code and MP_CPU_EXCHANGE_INFO
UefiCpuPkg/MpInitLib: Fix typo and clean up the code
UefiCpuPkg/MpInitLib: Add EnableExecuteDisable in MP_CPU_EXCHANGE_INFO
UefiCpuPkg/MpInitLib: Add AsmRelocateApLoop() assembly code
UefiCpuPkg/MpInitLib: Add MP_ASSEMBLY_ADDRESS_MAP
UefiCpuPkg/MpInitLib: Get ApLoopMode and MointorFilter size
UefiCpuPkg/MpInitLib: Allocate and initialize memory of MP Data buffer
UefiCpuPkg/MpInitLib: Initialize CPU_AP_DATA for CPU APs
UefiCpuPkg/MpInitLib: Add CPU_VOLATILE_REGISTERS & worker functions
UefiCpuPkg/MpInitLib: Add MicrocodeDetect() and load microcode on BSP
UefiCpuPkg/MpInitLib: Save CPU MP Data pointer
UefiCpuPkg/MpInitLib: Register one End of PEI callback function
UefiCpuPkg/MpInitLib: Register one period event to check APs status
UefiCpuPkg/MpInitLib: Allocate AP reset vector buffer under 1MB
UefiCpuPkg/MpInitLib: Add ApWakeupFunction() executed by assembly code
UefiCpuPkg/MpInitLib: Fill MP_CPU_EXCHANGE_INFO fields
UefiCpuPkg/MpInitLib: Add WakeUpAP()
UefiCpuPkg/MpInitLib: Send INIT-SIPI-SIPI to get processor count
UefiCpuPkg/MpInitLib: Enable x2APIC mode on BSP/APs
UefiCpuPkg/MpInitLib: Sort processor by ascending order of APIC ID
UefiCpuPkg/MpInitLib: Skip collect processor count if GUIDed HOB exist
UefiCpuPkg/MpInitLib: Implementation of
MpInitLibGetNumberOfProcessors()
UefiCpuPkg/MpInitLib: Implementation of MpInitLibGetProcessorInfo()
UefiCpuPkg/MpInitLib: Implementation of MpInitLibWhoAmI()
UefiCpuPkg/MpInitLib: Implementation of MpInitLibSwitchBSP()
UefiCpuPkg/MpInitLib: Implementation of MpInitLibEnableDisableAP()
UefiCpuPkg/MpInitLib: Check APs Status and update APs status
UefiCpuPkg/MpInitLib: Implementation of MpInitLibStartupThisAP()
UefiCpuPkg/MpInitLib: Implementation of MpInitLibStartupAllAPs()
UefiCpuPkg/MpInitLib: Place APs in safe loop before hand-off to OS
OvmfPkg: Add MpInitLib reference in DSC files.
QuarkPlatformPkg: Add MpInitLib reference in DSC files.
UefiCpuPkg/CpuMpPei: Consume MpInitLib to produce CPU MP PPI services
UefiCpuPkg/CpuMpPei: Remove unused files and codes
UefiCpuPkg/CpuMpPei: Delete PeiMpServices.c and PeiMpServices.h
UefiCpuPkg/CpuDxe: Consume MpInitLib to produce CPU MP Protocol
services
UefiCpuPkg/CpuDxe: Move SetMtrrsFromBuffer() location.
UefiCpuPkg/CpuDxe: Remove unused codes and files
UefiCpuPkg/CpuDxe: Remove PcdCpuMaxLogicalProcessorNumber consuming
MdePkg/MpService.h: Fixed typo in function header to match PI spec
MdePkg/MpService.h: Trim whitespace at end of line
UefiCpuPkg/CpuDxe: Fixed typo in function header to match PI spec
UefiCpuPkg/PiSmmCpuDxeSmm: Add gEfiVariableArchProtocolGuid dependency

MdePkg/Include/Protocol/MpService.h | 490 ++---
OvmfPkg/OvmfPkgIa32.dsc | 2 +
OvmfPkg/OvmfPkgIa32X64.dsc | 2 +
OvmfPkg/OvmfPkgX64.dsc | 2 +
QuarkPlatformPkg/Quark.dsc | 2 +
QuarkPlatformPkg/QuarkMin.dsc | 4 +-
.../DebugAgent/DebugAgentCommon/DebugAgent.h | 1 +
.../Library/DebugAgent/DebugAgentCommon/DebugMp.c | 5 +-
UefiCpuPkg/CpuDxe/ApStartup.c | 478 -----
UefiCpuPkg/CpuDxe/CpuDxe.c | 17 +-
UefiCpuPkg/CpuDxe/CpuDxe.h | 13 +-
UefiCpuPkg/CpuDxe/CpuDxe.inf | 17 +-
UefiCpuPkg/CpuDxe/CpuDxe.uni | 10 +-
UefiCpuPkg/CpuDxe/CpuDxeExtra.uni | 4 +-
UefiCpuPkg/CpuDxe/CpuMp.c | 1306 +------------
UefiCpuPkg/CpuDxe/CpuMp.h | 186 +-
UefiCpuPkg/CpuDxe/Ia32/MpAsm.asm | 76 -
UefiCpuPkg/CpuDxe/Ia32/MpAsm.nasm | 68 -
UefiCpuPkg/CpuDxe/X64/MpAsm.asm | 76 -
UefiCpuPkg/CpuDxe/X64/MpAsm.nasm | 70 -
UefiCpuPkg/CpuMpPei/CpuBist.c | 53 +-
UefiCpuPkg/CpuMpPei/CpuMpPei.c | 1118 ++++-------
UefiCpuPkg/CpuMpPei/CpuMpPei.h | 515 ++---
UefiCpuPkg/CpuMpPei/CpuMpPei.inf | 32 +-
UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm | 250 ---
UefiCpuPkg/CpuMpPei/Microcode.h | 58 -
UefiCpuPkg/CpuMpPei/PeiMpServices.c | 956 ----------
UefiCpuPkg/CpuMpPei/PeiMpServices.h | 377 ----
UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm | 290 ---
UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c | 42 +-
UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf | 2 +-
UefiCpuPkg/Include/Library/MpInitLib.h | 353 ++++
UefiCpuPkg/Include/Register/LocalApic.h | 20 +-
UefiCpuPkg/Include/Register/Microcode.h | 200 ++
UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c | 29 +-
.../BaseXApicX2ApicLib/BaseXApicX2ApicLib.c | 51 +-
.../MpInitLib/DxeMpInitLib.inf} | 68 +-
.../MpInitLib/DxeMpInitLib.uni} | 12 +-
UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 649 +++++++
.../{CpuMpPei => Library/MpInitLib}/Ia32/MpEqu.inc | 4 +-
.../MpInitLib}/Ia32/MpFuncs.nasm | 66 +-
.../{CpuMpPei => Library/MpInitLib}/Microcode.c | 77 +-
UefiCpuPkg/Library/MpInitLib/MpLib.c | 2013 ++++++++++++++++++++
UefiCpuPkg/Library/MpInitLib/MpLib.h | 554 ++++++
.../MpInitLib/PeiMpInitLib.inf} | 60 +-
.../MpInitLib/PeiMpInitLib.uni} | 12 +-
UefiCpuPkg/Library/MpInitLib/PeiMpLib.c | 643 +++++++
.../{CpuMpPei => Library/MpInitLib}/X64/MpEqu.inc | 6 +-
.../MpInitLib}/X64/MpFuncs.nasm | 84 +-
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 4 +-
UefiCpuPkg/UefiCpuPkg.dec | 4 +
UefiCpuPkg/UefiCpuPkg.dsc | 4 +
52 files changed, 5777 insertions(+), 5658 deletions(-)
delete mode 100644 UefiCpuPkg/CpuDxe/ApStartup.c
delete mode 100644 UefiCpuPkg/CpuDxe/Ia32/MpAsm.asm
delete mode 100644 UefiCpuPkg/CpuDxe/Ia32/MpAsm.nasm
delete mode 100644 UefiCpuPkg/CpuDxe/X64/MpAsm.asm
delete mode 100644 UefiCpuPkg/CpuDxe/X64/MpAsm.nasm
delete mode 100644 UefiCpuPkg/CpuMpPei/Ia32/MpFuncs.asm
delete mode 100644 UefiCpuPkg/CpuMpPei/Microcode.h
delete mode 100644 UefiCpuPkg/CpuMpPei/PeiMpServices.c
delete mode 100644 UefiCpuPkg/CpuMpPei/PeiMpServices.h
delete mode 100644 UefiCpuPkg/CpuMpPei/X64/MpFuncs.asm
create mode 100644 UefiCpuPkg/Include/Library/MpInitLib.h
create mode 100644 UefiCpuPkg/Include/Register/Microcode.h
copy UefiCpuPkg/{CpuMpPei/CpuMpPei.inf => Library/MpInitLib/DxeMpInitLib.inf} (52%)
copy UefiCpuPkg/{CpuDxe/CpuDxeExtra.uni => Library/MpInitLib/DxeMpInitLib.uni} (53%)
create mode 100644 UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
rename UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/Ia32/MpEqu.inc (88%)
rename UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/Ia32/MpFuncs.nasm (77%)
rename UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/Microcode.c (68%)
create mode 100644 UefiCpuPkg/Library/MpInitLib/MpLib.c
create mode 100644 UefiCpuPkg/Library/MpInitLib/MpLib.h
copy UefiCpuPkg/{CpuMpPei/CpuMpPei.inf => Library/MpInitLib/PeiMpInitLib.inf} (58%)
copy UefiCpuPkg/{CpuDxe/CpuDxeExtra.uni => Library/MpInitLib/PeiMpInitLib.uni} (53%)
create mode 100644 UefiCpuPkg/Library/MpInitLib/PeiMpLib.c
rename UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/X64/MpEqu.inc (88%)
rename UefiCpuPkg/{CpuMpPei => Library/MpInitLib}/X64/MpFuncs.nasm (73%)

--
2.7.4.windows.1

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


Re: Build traceback with new CLANG35 toolset

Bruce Cran <bruce@...>
 

On 8/2/2016 12:53 PM, Ard Biesheuvel wrote:

CLANG35 is not new, and currently only supports ARM and AARCH64
Oops - thanks. I was thinking of CLANG38 that hasn't been committed yet.

--
Bruce


Re: Build traceback with new CLANG35 toolset

Ard Biesheuvel
 

On 2 August 2016 at 20:24, Bruce Cran <bruce@cran.org.uk> wrote:
I was just testing the new GCC5 and CLANG35 toolsets that have landed in git
master: GCC5 works perfectly, but with CLANG35 I get the following log and
traceback:
CLANG35 is not new, and currently only supports ARM and AARCH64


Build environment: Linux-4.6.4-2-default-x86_64-with-SuSE-20160728-x86_64
Build start time: 12:12:40, Aug.02 2016

WORKSPACE = /mnt/user/workspace/edk2
ECP_SOURCE = /mnt/user/workspace/edk2/EdkCompatibilityPkg
EDK_SOURCE = /mnt/user/workspace/edk2/EdkCompatibilityPkg
EFI_SOURCE = /mnt/user/workspace/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH = /mnt/user/workspace/edk2/BaseTools

Architecture(s) = X64
Build target = RELEASE
Toolchain = CLANG35

Active Platform = /mnt/user/workspace/edk2/MyPkg/MyPkg.dsc

Processing meta-data .

build.py...
: error C0DE: Unknown fatal error when processing
[/mnt/user/workspace/edk2/MyPkg/MyPkg.inf]

(Please send email to edk2-devel@lists.01.org for help, attaching following
call stack trace!)

(Python 2.7.12 on linux2) Traceback (most recent call last):
File
"/mnt/user/workspace/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 2270, in Main
MyBuild.Launch()
File
"/mnt/user/workspace/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 2022, in Launch
self._MultiThreadBuildPlatform()
File
"/mnt/user/workspace/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 1857, in _MultiThreadBuildPlatform
Ma.CreateMakeFile(True)
File
"/mnt/user/workspace/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line
3923, in CreateMakeFile
if Makefile.Generate():
File
"/mnt/user/workspace/edk2/BaseTools/Source/Python/AutoGen/GenMake.py", line
184, in Generate
FileContent = self._TEMPLATE_.Replace(self._TemplateDict)
File
"/mnt/user/workspace/edk2/BaseTools/Source/Python/AutoGen/GenMake.py", line
525, in _CreateTemplateDict
RespDict = self.CommandExceedLimit()
File
"/mnt/user/workspace/edk2/BaseTools/Source/Python/AutoGen/GenMake.py", line
716, in CommandExceedLimit
Str = self._AutoGenObject._BuildOption[Tool]['FLAGS']
KeyError: 'FLAGS'

--
Bruce

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