Re: [edk2] [Patch] MdeModulePkg: Fix IPv4 UseDefaultAddress failure case.

2016-06-07 Thread Ye, Ting 
Reviewed-by: Ye Ting  

-Original Message-
From: Wu, Jiaxin 
Sent: Wednesday, June 08, 2016 1:49 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; El-Haj-Mahmoud Samer 
; Subramanian Sriram 
Subject: [Patch] MdeModulePkg: Fix IPv4 UseDefaultAddress failure case.

This patch is used to update IP4->Configure() to allow the upper layer modules 
to obtain a default address by setting UseDefaultAddress to TRUE when default 
address is not available yet.

Cc: Ye Ting 
Cc: El-Haj-Mahmoud Samer 
Cc: Subramanian Sriram 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
index e733816..91f1a67 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
@@ -674,12 +674,15 @@ Ip4ConfigProtocol (
   } else {
 //
 // Use the default address. Check the state.
 //
 if (IpSb->State == IP4_SERVICE_UNSTARTED) {
-  Status = EFI_NO_MAPPING;
-  goto ON_ERROR;
+  Status = Ip4StartAutoConfig (>Ip4Config2Instance);
+
+  if (EFI_ERROR (Status)) {
+goto ON_ERROR;
+  }
 }
 
 IpIf = IpSb->DefaultInterface;
 NET_GET_REF (IpSb->DefaultInterface);
 
--
1.9.5.msysgit.1

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

[edk2] [Patch] MdeModulePkg: Fix IPv4 UseDefaultAddress failure case.

2016-06-07 Thread Jiaxin Wu 
This patch is used to update IP4->Configure() to allow the upper layer
modules to obtain a default address by setting UseDefaultAddress to TRUE
when default address is not available yet.

Cc: Ye Ting 
Cc: El-Haj-Mahmoud Samer 
Cc: Subramanian Sriram 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
index e733816..91f1a67 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
@@ -674,12 +674,15 @@ Ip4ConfigProtocol (
   } else {
 //
 // Use the default address. Check the state.
 //
 if (IpSb->State == IP4_SERVICE_UNSTARTED) {
-  Status = EFI_NO_MAPPING;
-  goto ON_ERROR;
+  Status = Ip4StartAutoConfig (>Ip4Config2Instance);
+
+  if (EFI_ERROR (Status)) {
+goto ON_ERROR;
+  }
 }
 
 IpIf = IpSb->DefaultInterface;
 NET_GET_REF (IpSb->DefaultInterface);
 
-- 
1.9.5.msysgit.1

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

Re: [edk2] Why does gBS->FreePages() take so long ?

2016-06-07 Thread Shubha Ramani 
Fantastic info Liming ! Thanks !

Sent from Shubha Ramani's iPhone 6s Plus

> On Jun 7, 2016, at 7:30 PM, Gao, Liming  wrote:
> 
> Hi, 
>  FreePages() will trig DEBUG_CLEAR_MEMORY() macro to zero memory. This macro 
> will only be called when BIT3 is configured in PcdDebugPropertyMask value. 
> Normally, Debug Build will configure PcdDebugPropertyMask to 0x2F so that 
> this macro is enabled. You can build system BIOS with PCD value 0x27 to 
> disable it. Then,  try running your application. 
> 
> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Michael Zimmermann
>> Sent: Wednesday, June 08, 2016 1:35 AM
>> To: Shubha Ramani 
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] Why does gBS->FreePages() take so long ?
>> 
>> which system are you testing this one?
>> DEBUG builds of UEFI can be very slow because they do many checks and
>> clear
>> the memory on each alloc/free.
>> 
>> Thanks
>> Michael
>> 
>> On Tue, Jun 7, 2016 at 6:36 PM, Shubha Ramani 
>> wrote:
>> 
>>> I'm building an edk2 application which kicks off during system boot. For
>>> this application I have to allocate huge slabs of memory repeatedly (96
>>> times ) - an examplewould be 1087570 pages, allocated 96 times. I'm finding
>>> that it takes on the order of minutes to do gBS->FreePages() 96 times for
>>> my application !
>>> Here is how I allocate each time: Status =
>>> gBS->AllocatePages(AllocateAnyPages, EfiBootServicesData,
>>> mNum4kPagesPerCore,
>> (EFI_PHYSICAL_ADDRESS*)(MemToStressStartAddr));
>>> 
>>> For deallocation I use gBS->FreePages().
>>> Is there a workaround for  this ?
>>> Spending 3-4 minutes in the exit routine deallocating memory is not
>>> acceptible !
>>> Thanks,
>>> Shubha  Shubha D. ramanishubharam...@gmail.com
>>> shubharam...@yahoo.com
>>> ___
>>> 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] Why does gBS->FreePages() take so long ?

2016-06-07 Thread Gao, Liming 
Hi, 
  FreePages() will trig DEBUG_CLEAR_MEMORY() macro to zero memory. This macro 
will only be called when BIT3 is configured in PcdDebugPropertyMask value. 
Normally, Debug Build will configure PcdDebugPropertyMask to 0x2F so that this 
macro is enabled. You can build system BIOS with PCD value 0x27 to disable it. 
Then,  try running your application. 

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Michael Zimmermann
> Sent: Wednesday, June 08, 2016 1:35 AM
> To: Shubha Ramani 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Why does gBS->FreePages() take so long ?
> 
> which system are you testing this one?
> DEBUG builds of UEFI can be very slow because they do many checks and
> clear
> the memory on each alloc/free.
> 
> Thanks
> Michael
> 
> On Tue, Jun 7, 2016 at 6:36 PM, Shubha Ramani 
> wrote:
> 
> > I'm building an edk2 application which kicks off during system boot. For
> > this application I have to allocate huge slabs of memory repeatedly (96
> > times ) - an examplewould be 1087570 pages, allocated 96 times. I'm finding
> > that it takes on the order of minutes to do gBS->FreePages() 96 times for
> > my application !
> > Here is how I allocate each time: Status =
> > gBS->AllocatePages(AllocateAnyPages, EfiBootServicesData,
> > mNum4kPagesPerCore,
> (EFI_PHYSICAL_ADDRESS*)(MemToStressStartAddr));
> >
> > For deallocation I use gBS->FreePages().
> > Is there a workaround for  this ?
> > Spending 3-4 minutes in the exit routine deallocating memory is not
> > acceptible !
> > Thanks,
> > Shubha  Shubha D. ramanishubharam...@gmail.com
> > shubharam...@yahoo.com
> > ___
> > 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] Why does UEFI firmware on x64 not initialize "long mode" GDT?

2016-06-07 Thread Andrew Fish 

> On Jun 7, 2016, at 2:59 PM, Brett Stahlman  wrote:
> 
> d'Oh! Mystery solved. Working through the `info registers' output you
> sent helped me see what was happening. The system I'm working with had
> a buggy printf: in particular, it was parsing but effectively throwing
> away the `l' in a %ld or %lx specifier, so my attempts to print GDT
> entries with %lx were giving misleading results. (Yes, I realize I
> should have been using EFI's Print routine - lesson learned...) I
> apologize for the confusion.
> 
> I appreciate all the pointers from you and Andrew. I feel I have a
> much better handle on all this now.
> 

Brett,

No worries. If you work on firmware long enough Heisenberg like uncertainty 
always seem to strike at some point. 

Thanks,

Andrew Fish 

> Thanks,
> Brett S.
> 
> 
> On Tue, Jun 7, 2016 at 11:15 AM, Laszlo Ersek  wrote:
>> On 06/07/16 17:35, Andrew Fish wrote:
>>> 
 On Jun 7, 2016, at 8:31 AM, Brett Stahlman  wrote:
 
 Ah. I think I may have found the answer to at least part of my
 question, but would appreciate if someone could confirm...
 
 Section 2.3.4 of the UEFI spec states:
 "Selectors are set to be flat and are otherwise not used."
 
 Section 3.2.4 of the Intel processor spec (Vol. 3A 3-7) states:
 "In 64-bit mode, segmentation is generally (but not completely)
 disabled, creating a
 flat 64-bit linear-address space... Note that the processor does not
 perform segment limit checks at runtime in 64-bit mode."
 
 So if I'm reading all this correctly... The value of the fields
 governing the interpretation of the segment limits (e.g., L and D/B)
 are "don't cares" in IA32e 64-bit mode. But what about fields not
 directly related to limit checks: e.g., P (Present) flag, and DPL
 (Descriptor Privilege Level)? Do their values not matter either?
 
>>> 
>>> Brett,
>>> 
>>> Yes you only need valid entries for segments that are used. If I'm 
>>> remembering correctly you can use the index in the segment registers to map 
>>> to the GDT entry.
>> 
>> Right, here's the output of the "info registers" QEMU monitor command,
>> while standing in the setup browser in OVMF:
>> 
>> RAX=bfdbbcf0 RBX=beafdc84 RCX=bf645a98 
>> RDX=
>> RSI=bff5d588 RDI=bff99fb0 RBP=bff5d350 
>> RSP=bff5d328
>> R8 = R9 =0001 R10=0064 
>> R11=0040
>> R12= R13= R14= 
>> R15=
>> RIP=bfdbbcf1 RFL=0206 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1
>> ES =0030   00c09300 DPL=0 DS   [-WA]
>> CS =0038   00a09b00 DPL=0 CS64 [-RA]
>> SS =0030   00c09300 DPL=0 DS   [-WA]
>> DS =0030   00c09300 DPL=0 DS   [-WA]
>> FS =0030   00c09300 DPL=0 DS   [-WA]
>> GS =0030   00c09300 DPL=0 DS   [-WA]
>> LDT=   8200 DPL=0 LDT
>> TR =   8b00 DPL=0 TSS64-busy
>> GDT= bfeea698 0047
>> IDT= bf646018 0fff
>> CR0=8033 CR2= CR3=bfefc000 CR4=0668
>> DR0= DR1= DR2= 
>> DR3=
>> DR6=0ff0 DR7=0400
>> EFER=0500
>> FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
>> FPR0=  FPR1= 
>> FPR2=  FPR3= 
>> FPR4=  FPR5= 
>> FPR6=  FPR7= 
>> XMM00= XMM01=
>> XMM02= XMM03=
>> XMM04= XMM05=
>> XMM06= XMM07=
>> XMM08= XMM09=
>> XMM10= XMM11=
>> XMM12= XMM13=
>> XMM14= XMM15=
>> 
>> CS points to offset 0x38 in the GDT, and the other segment registers
>> (data and stack) all point to the entry at offset 0x30.
>> 
>> * For the DXE Core, the GDT is set up in
>> "MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c":
>> 
>> //
>> // Global Descriptor Table (GDT)
>> //
>> GLOBAL_REMOVE_IF_UNREFERENCED IA32_GDT gGdtEntries[] = {
>> /* selector { Global Segment Descriptor  } */
>> /* 0x00 */  {{0,  0,  0,  0,0,  0,  0,  0,0,  0, 0,  0,  0}}, 
>> //null descriptor
>> /* 0x08 */

Re: [edk2] [PATCH] SecurityPkg : Tpm12DeviceLibDTpm: Fix TPM12 wrong Response Tag check

2016-06-07 Thread Long, Qin 
The patch looks good.
And one typo was in original comment: 
   // Check the reponse data header (tag,parasize and returncode )
 --> response

Reviewed-by: Qin Long 


Best Regards & Thanks,
LONG, Qin

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang, 
> Chao B
> Sent: Tuesday, June 7, 2016 10:20 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Yao, Jiewen 
> ; Zhang, Chao B 
> Subject: [edk2] [PATCH] SecurityPkg : Tpm12DeviceLibDTpm: Fix TPM12 wrong 
> Response Tag check
> 
> TcgDxePassThroughToTpm should be able to handle all TPM12 Command & Response 
> correctly.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Chao Zhang 
> ---
>  SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c 
> b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
> index 4e04299..5e154d0 100644
> --- a/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
> +++ b/SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12Tis.c
> @@ -267,6 +267,7 @@ Tpm12TisTpmCommand (
>UINT32TpmOutSize;
>UINT16Data16;
>UINT32Data32;
> +  UINT16RspTag;
> 
>DEBUG_CODE (
>  UINTN  DebugSize;
> @@ -367,8 +368,9 @@ Tpm12TisTpmCommand (
>// Check the reponse data header (tag,parasize and returncode )
>//
>CopyMem (, BufferOut, sizeof (UINT16));
> -  if (SwapBytes16 (Data16) != TPM_TAG_RSP_COMMAND) {
> -DEBUG ((EFI_D_ERROR, "TPM12: TPM_ST_RSP error - %x\n", 
> TPM_TAG_RSP_COMMAND));
> +  RspTag = SwapBytes16 (Data16);
> +  if (RspTag != TPM_TAG_RSP_COMMAND && RspTag != TPM_TAG_RSP_AUTH1_COMMAND 
> && RspTag !=
> TPM_TAG_RSP_AUTH2_COMMAND) {
> +DEBUG ((EFI_D_ERROR, "TPM12: Response tag error - current tag value is 
> %x\n", RspTag));
>  Status = EFI_UNSUPPORTED;
>  goto Exit;
>}
> --
> 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] Why does UEFI firmware on x64 not initialize "long mode" GDT?

2016-06-07 Thread Brett Stahlman 
d'Oh! Mystery solved. Working through the `info registers' output you
sent helped me see what was happening. The system I'm working with had
a buggy printf: in particular, it was parsing but effectively throwing
away the `l' in a %ld or %lx specifier, so my attempts to print GDT
entries with %lx were giving misleading results. (Yes, I realize I
should have been using EFI's Print routine - lesson learned...) I
apologize for the confusion.

I appreciate all the pointers from you and Andrew. I feel I have a
much better handle on all this now.

Thanks,
Brett S.


On Tue, Jun 7, 2016 at 11:15 AM, Laszlo Ersek  wrote:
> On 06/07/16 17:35, Andrew Fish wrote:
>>
>>> On Jun 7, 2016, at 8:31 AM, Brett Stahlman  wrote:
>>>
>>> Ah. I think I may have found the answer to at least part of my
>>> question, but would appreciate if someone could confirm...
>>>
>>> Section 2.3.4 of the UEFI spec states:
>>> "Selectors are set to be flat and are otherwise not used."
>>>
>>> Section 3.2.4 of the Intel processor spec (Vol. 3A 3-7) states:
>>> "In 64-bit mode, segmentation is generally (but not completely)
>>> disabled, creating a
>>> flat 64-bit linear-address space... Note that the processor does not
>>> perform segment limit checks at runtime in 64-bit mode."
>>>
>>> So if I'm reading all this correctly... The value of the fields
>>> governing the interpretation of the segment limits (e.g., L and D/B)
>>> are "don't cares" in IA32e 64-bit mode. But what about fields not
>>> directly related to limit checks: e.g., P (Present) flag, and DPL
>>> (Descriptor Privilege Level)? Do their values not matter either?
>>>
>>
>> Brett,
>>
>> Yes you only need valid entries for segments that are used. If I'm 
>> remembering correctly you can use the index in the segment registers to map 
>> to the GDT entry.
>
> Right, here's the output of the "info registers" QEMU monitor command,
> while standing in the setup browser in OVMF:
>
> RAX=bfdbbcf0 RBX=beafdc84 RCX=bf645a98 
> RDX=
> RSI=bff5d588 RDI=bff99fb0 RBP=bff5d350 
> RSP=bff5d328
> R8 = R9 =0001 R10=0064 
> R11=0040
> R12= R13= R14= 
> R15=
> RIP=bfdbbcf1 RFL=0206 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1
> ES =0030   00c09300 DPL=0 DS   [-WA]
> CS =0038   00a09b00 DPL=0 CS64 [-RA]
> SS =0030   00c09300 DPL=0 DS   [-WA]
> DS =0030   00c09300 DPL=0 DS   [-WA]
> FS =0030   00c09300 DPL=0 DS   [-WA]
> GS =0030   00c09300 DPL=0 DS   [-WA]
> LDT=   8200 DPL=0 LDT
> TR =   8b00 DPL=0 TSS64-busy
> GDT= bfeea698 0047
> IDT= bf646018 0fff
> CR0=8033 CR2= CR3=bfefc000 CR4=0668
> DR0= DR1= DR2= 
> DR3=
> DR6=0ff0 DR7=0400
> EFER=0500
> FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
> FPR0=  FPR1= 
> FPR2=  FPR3= 
> FPR4=  FPR5= 
> FPR6=  FPR7= 
> XMM00= XMM01=
> XMM02= XMM03=
> XMM04= XMM05=
> XMM06= XMM07=
> XMM08= XMM09=
> XMM10= XMM11=
> XMM12= XMM13=
> XMM14= XMM15=
>
> CS points to offset 0x38 in the GDT, and the other segment registers
> (data and stack) all point to the entry at offset 0x30.
>
> * For the DXE Core, the GDT is set up in
> "MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c":
>
> //
> // Global Descriptor Table (GDT)
> //
> GLOBAL_REMOVE_IF_UNREFERENCED IA32_GDT gGdtEntries[] = {
> /* selector { Global Segment Descriptor  } */
> /* 0x00 */  {{0,  0,  0,  0,0,  0,  0,  0,0,  0, 0,  0,  0}}, 
> //null descriptor
> /* 0x08 */  {{0x, 0,  0,  0x2,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
> //linear data segment descriptor
> /* 0x10 */  {{0x, 0,  0,  0xf,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
> //linear code segment descriptor
> /* 0x18 */  {{0x, 0,  0,  0x3,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
> //system data segment descriptor
> /* 0x20 */  {{0x, 0,  0,  0xa,

Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Remove NULL cipher

2016-06-07 Thread El-Haj-Mahmoud, Samer 
Reviewed-by: Samer El-Haj-Mahmoud 

-Original Message-
From: Palmer, Thomas 
Sent: Monday, June 6, 2016 9:47 PM
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer ; jiaxin...@intel.com; 
Palmer, Thomas 
Subject: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Remove NULL 
cipher

The term "NULL" refers to NULL-MD5, NULL-SHA and NULL-SHA256 when used to set 
the SSL cipher list.  As both MD5 and SHA variants are explicitly listed in our 
code, I surmise enabling all three by setting the cipher list to just NULL was 
not the intended behavior.
This patch will remove NULL as an option for the cipher list and allow 
NULL-SHA256 instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 CryptoPkg/Library/TlsLib/TlsLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c 
b/CryptoPkg/Library/TlsLib/TlsLib.c
index 9f56b7a..b76dd20 100644
--- a/CryptoPkg/Library/TlsLib/TlsLib.c
+++ b/CryptoPkg/Library/TlsLib/TlsLib.c
@@ -53,7 +53,6 @@ typedef struct {
 // OpenSSL-used Cipher Suite name.
 //
 STATIC CONST TLS_CIPHER_PAIR TlsCipherMappingTable[] = {
-  { 0x, "NULL" }, /// TLS_NULL_WITH_NULL_NULL
   { 0x0001, "NULL-MD5" }, /// TLS_RSA_WITH_NULL_MD5
   { 0x0002, "NULL-SHA" }, /// TLS_RSA_WITH_NULL_SHA
   { 0x0004, "RC4-MD5" },  /// TLS_RSA_WITH_RC4_128_MD5
@@ -62,6 +61,7 @@ STATIC CONST TLS_CIPHER_PAIR TlsCipherMappingTable[] = {
   { 0x000A, "DES-CBC3-SHA" }, /// TLS_RSA_WITH_3DES_EDE_CBC_SHA
   { 0x002F, "AES128-SHA" },   /// TLS_RSA_WITH_AES_128_CBC_SHA
   { 0x0035, "AES256-SHA" },   /// TLS_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
 };
--
1.9.1

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

Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Handshake failure

2016-06-07 Thread El-Haj-Mahmoud, Samer 
Reviewed-by: Samer El-Haj-Mahmoud 


-Original Message-
From: Palmer, Thomas 
Sent: Tuesday, June 7, 2016 1:36 PM
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer ; jiaxin...@intel.com; 
Palmer, Thomas 
Subject: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Handshake 
failure

TlsLib should inspect the return from the SSL_do_handshake and return 
EFI_PROTOCOL_ERROR on certain conditions that are not recoverable.

For example, if a client is configured with a certain set of ciphers that the 
TLS server does not support, the server will send a fatal alert before the 
handshake finishes.  Our TLS protocol only expects an alert to come after the 
handshake, so we would have continued TLS operations.

Please note I am using types int and unsigned long to match the OpenSSL api.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 CryptoPkg/Library/TlsLib/TlsLib.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c 
b/CryptoPkg/Library/TlsLib/TlsLib.c
index b76dd20..8b441a5 100644
--- a/CryptoPkg/Library/TlsLib/TlsLib.c
+++ b/CryptoPkg/Library/TlsLib/TlsLib.c
@@ -616,6 +616,8 @@ TlsDoHandshake (
 {
   TLS_CONNECTION  *TlsConn;
   UINTN   PendingBufferSize;
+  int ret;
+  unsigned long   e;
 
   TlsConn   = (TLS_CONNECTION *) Tls;
   PendingBufferSize = 0;
@@ -638,18 +640,41 @@ TlsDoHandshake (
 PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 if (PendingBufferSize == 0) {
   SSL_set_connect_state (TlsConn->Ssl);
-  SSL_do_handshake (TlsConn->Ssl);
+  ret = SSL_do_handshake (TlsConn->Ssl);
   PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 }
   } else {
 PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 if (PendingBufferSize == 0) {
   BIO_write (TlsConn->InBio, BufferIn, (UINT32) BufferInSize);
-  SSL_do_handshake (TlsConn->Ssl);
+  ret = SSL_do_handshake (TlsConn->Ssl);
   PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 }
   }
 
+  if (ret < 1) {
+ret = SSL_get_error (TlsConn->Ssl, ret);
+if (ret == SSL_ERROR_SSL ||
+ret == SSL_ERROR_SYSCALL ||
+ret == SSL_ERROR_ZERO_RETURN) {
+  DEBUG ((DEBUG_ERROR, "%a SSL_HANDSHAKE_ERROR State=0x%x SSL_ERROR_%a\n", 
__FUNCTION__, SSL_state (TlsConn->Ssl),
+ret == SSL_ERROR_SSL ? "SSL":
+ret == SSL_ERROR_SYSCALL ? "SYSCALL":
+"ZERO_RETURN"
+));
+  DEBUG_CODE_BEGIN ();
+  while (1) {
+e = ERR_get_error ();
+if (e == 0) {
+  break;
+}
+DEBUG ((DEBUG_ERROR, "%a ERROR 0x%x=L%x:F%x:R%x\n", __FUNCTION__, e, 
ERR_GET_LIB (e), ERR_GET_FUNC (e), ERR_GET_REASON (e)));
+  }
+  DEBUG_CODE_END ();
+  return EFI_PROTOCOL_ERROR;
+}
+  }
+
   if (PendingBufferSize > *BufferOutSize) {
 *BufferOutSize = PendingBufferSize;
 return EFI_BUFFER_TOO_SMALL;
--
1.9.1

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

[edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Handshake failure

2016-06-07 Thread Thomas Palmer 
TlsLib should inspect the return from the SSL_do_handshake and return
EFI_PROTOCOL_ERROR on certain conditions that are not recoverable.

For example, if a client is configured with a certain set of ciphers
that the TLS server does not support, the server will send a fatal
alert before the handshake finishes.  Our TLS protocol only expects
an alert to come after the handshake, so we would have continued TLS
operations.

Please note I am using types int and unsigned long to match the
OpenSSL api.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 CryptoPkg/Library/TlsLib/TlsLib.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c 
b/CryptoPkg/Library/TlsLib/TlsLib.c
index b76dd20..8b441a5 100644
--- a/CryptoPkg/Library/TlsLib/TlsLib.c
+++ b/CryptoPkg/Library/TlsLib/TlsLib.c
@@ -616,6 +616,8 @@ TlsDoHandshake (
 {
   TLS_CONNECTION  *TlsConn;
   UINTN   PendingBufferSize;
+  int ret;
+  unsigned long   e;
 
   TlsConn   = (TLS_CONNECTION *) Tls;
   PendingBufferSize = 0;
@@ -638,18 +640,41 @@ TlsDoHandshake (
 PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 if (PendingBufferSize == 0) {
   SSL_set_connect_state (TlsConn->Ssl);
-  SSL_do_handshake (TlsConn->Ssl);
+  ret = SSL_do_handshake (TlsConn->Ssl);
   PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 }
   } else {
 PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 if (PendingBufferSize == 0) {
   BIO_write (TlsConn->InBio, BufferIn, (UINT32) BufferInSize);
-  SSL_do_handshake (TlsConn->Ssl);
+  ret = SSL_do_handshake (TlsConn->Ssl);
   PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 }
   }
 
+  if (ret < 1) {
+ret = SSL_get_error (TlsConn->Ssl, ret);
+if (ret == SSL_ERROR_SSL ||
+ret == SSL_ERROR_SYSCALL ||
+ret == SSL_ERROR_ZERO_RETURN) {
+  DEBUG ((DEBUG_ERROR, "%a SSL_HANDSHAKE_ERROR State=0x%x SSL_ERROR_%a\n", 
__FUNCTION__, SSL_state (TlsConn->Ssl),
+ret == SSL_ERROR_SSL ? "SSL":
+ret == SSL_ERROR_SYSCALL ? "SYSCALL":
+"ZERO_RETURN"
+));
+  DEBUG_CODE_BEGIN ();
+  while (1) {
+e = ERR_get_error ();
+if (e == 0) {
+  break;
+}
+DEBUG ((DEBUG_ERROR, "%a ERROR 0x%x=L%x:F%x:R%x\n", __FUNCTION__, e, 
ERR_GET_LIB (e), ERR_GET_FUNC (e), ERR_GET_REASON (e)));
+  }
+  DEBUG_CODE_END ();
+  return EFI_PROTOCOL_ERROR;
+}
+  }
+
   if (PendingBufferSize > *BufferOutSize) {
 *BufferOutSize = PendingBufferSize;
 return EFI_BUFFER_TOO_SMALL;
-- 
1.9.1

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

Re: [edk2] Why does gBS->FreePages() take so long ?

2016-06-07 Thread Michael Zimmermann 
which system are you testing this one?
DEBUG builds of UEFI can be very slow because they do many checks and clear
the memory on each alloc/free.

Thanks
Michael

On Tue, Jun 7, 2016 at 6:36 PM, Shubha Ramani 
wrote:

> I'm building an edk2 application which kicks off during system boot. For
> this application I have to allocate huge slabs of memory repeatedly (96
> times ) - an examplewould be 1087570 pages, allocated 96 times. I'm finding
> that it takes on the order of minutes to do gBS->FreePages() 96 times for
> my application !
> Here is how I allocate each time: Status =
> gBS->AllocatePages(AllocateAnyPages, EfiBootServicesData,
> mNum4kPagesPerCore, (EFI_PHYSICAL_ADDRESS*)(MemToStressStartAddr));
>
> For deallocation I use gBS->FreePages().
> Is there a workaround for  this ?
> Spending 3-4 minutes in the exit routine deallocating memory is not
> acceptible !
> Thanks,
> Shubha  Shubha D. ramanishubharam...@gmail.com
> shubharam...@yahoo.com
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Why does gBS->FreePages() take so long ?

2016-06-07 Thread Shubha Ramani 
I'm building an edk2 application which kicks off during system boot. For this 
application I have to allocate huge slabs of memory repeatedly (96 times ) - an 
examplewould be 1087570 pages, allocated 96 times. I'm finding that it takes on 
the order of minutes to do gBS->FreePages() 96 times for my application ! 
Here is how I allocate each time: Status = gBS->AllocatePages(AllocateAnyPages, 
EfiBootServicesData, mNum4kPagesPerCore, 
(EFI_PHYSICAL_ADDRESS*)(MemToStressStartAddr));

For deallocation I use gBS->FreePages().
Is there a workaround for  this ?
Spending 3-4 minutes in the exit routine deallocating memory is not acceptible !
Thanks,
Shubha  Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Why does UEFI firmware on x64 not initialize "long mode" GDT?

2016-06-07 Thread Laszlo Ersek 
On 06/07/16 17:35, Andrew Fish wrote:
> 
>> On Jun 7, 2016, at 8:31 AM, Brett Stahlman  wrote:
>>
>> Ah. I think I may have found the answer to at least part of my
>> question, but would appreciate if someone could confirm...
>>
>> Section 2.3.4 of the UEFI spec states:
>> "Selectors are set to be flat and are otherwise not used."
>>
>> Section 3.2.4 of the Intel processor spec (Vol. 3A 3-7) states:
>> "In 64-bit mode, segmentation is generally (but not completely)
>> disabled, creating a
>> flat 64-bit linear-address space... Note that the processor does not
>> perform segment limit checks at runtime in 64-bit mode."
>>
>> So if I'm reading all this correctly... The value of the fields
>> governing the interpretation of the segment limits (e.g., L and D/B)
>> are "don't cares" in IA32e 64-bit mode. But what about fields not
>> directly related to limit checks: e.g., P (Present) flag, and DPL
>> (Descriptor Privilege Level)? Do their values not matter either?
>>
> 
> Brett,
> 
> Yes you only need valid entries for segments that are used. If I'm 
> remembering correctly you can use the index in the segment registers to map 
> to the GDT entry. 

Right, here's the output of the "info registers" QEMU monitor command,
while standing in the setup browser in OVMF:

RAX=bfdbbcf0 RBX=beafdc84 RCX=bf645a98 
RDX=
RSI=bff5d588 RDI=bff99fb0 RBP=bff5d350 
RSP=bff5d328
R8 = R9 =0001 R10=0064 
R11=0040
R12= R13= R14= 
R15=
RIP=bfdbbcf1 RFL=0206 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1
ES =0030   00c09300 DPL=0 DS   [-WA]
CS =0038   00a09b00 DPL=0 CS64 [-RA]
SS =0030   00c09300 DPL=0 DS   [-WA]
DS =0030   00c09300 DPL=0 DS   [-WA]
FS =0030   00c09300 DPL=0 DS   [-WA]
GS =0030   00c09300 DPL=0 DS   [-WA]
LDT=   8200 DPL=0 LDT
TR =   8b00 DPL=0 TSS64-busy
GDT= bfeea698 0047
IDT= bf646018 0fff
CR0=8033 CR2= CR3=bfefc000 CR4=0668
DR0= DR1= DR2= 
DR3= 
DR6=0ff0 DR7=0400
EFER=0500
FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0=  FPR1= 
FPR2=  FPR3= 
FPR4=  FPR5= 
FPR6=  FPR7= 
XMM00= XMM01=
XMM02= XMM03=
XMM04= XMM05=
XMM06= XMM07=
XMM08= XMM09=
XMM10= XMM11=
XMM12= XMM13=
XMM14= XMM15=

CS points to offset 0x38 in the GDT, and the other segment registers
(data and stack) all point to the entry at offset 0x30.

* For the DXE Core, the GDT is set up in
"MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c":

//
// Global Descriptor Table (GDT)
//
GLOBAL_REMOVE_IF_UNREFERENCED IA32_GDT gGdtEntries[] = {
/* selector { Global Segment Descriptor  } */
/* 0x00 */  {{0,  0,  0,  0,0,  0,  0,  0,0,  0, 0,  0,  0}}, 
//null descriptor
/* 0x08 */  {{0x, 0,  0,  0x2,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
//linear data segment descriptor
/* 0x10 */  {{0x, 0,  0,  0xf,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
//linear code segment descriptor
/* 0x18 */  {{0x, 0,  0,  0x3,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
//system data segment descriptor
/* 0x20 */  {{0x, 0,  0,  0xa,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
//system code segment descriptor
/* 0x28 */  {{0,  0,  0,  0,0,  0,  0,  0,0,  0, 0,  0,  0}}, 
//spare segment descriptor
/* 0x30 */  {{0x, 0,  0,  0x2,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
//system data segment descriptor
/* 0x38 */  {{0x, 0,  0,  0xa,  1,  0,  1,  0xf,  0,  1, 0,  1,  0}}, 
//system code segment descriptor
/* 0x40 */  {{0,  0,  0,  0,0,  0,  0,  0,0,  0, 0,  0,  0}}, 
//spare segment descriptor
};

* For the DXE phase, the GDT is set up by the CpuDxe driver, in its
entry point. It uses the GDT entries at offsets LINEAR_DATA64_SEL (0x30)
and LINEAR_CODE64_SEL (0x38) in the same vein; see
InitGlobalDescriptorTable() in "UefiCpuPkg/CpuDxe/CpuGdt.c". And, the
byte-limit (= limit in

Re: [edk2] Why does UEFI firmware on x64 not initialize "long mode" GDT?

2016-06-07 Thread Andrew Fish 

> On Jun 7, 2016, at 8:31 AM, Brett Stahlman  wrote:
> 
> Ah. I think I may have found the answer to at least part of my
> question, but would appreciate if someone could confirm...
> 
> Section 2.3.4 of the UEFI spec states:
> "Selectors are set to be flat and are otherwise not used."
> 
> Section 3.2.4 of the Intel processor spec (Vol. 3A 3-7) states:
> "In 64-bit mode, segmentation is generally (but not completely)
> disabled, creating a
> flat 64-bit linear-address space... Note that the processor does not
> perform segment limit checks at runtime in 64-bit mode."
> 
> So if I'm reading all this correctly... The value of the fields
> governing the interpretation of the segment limits (e.g., L and D/B)
> are "don't cares" in IA32e 64-bit mode. But what about fields not
> directly related to limit checks: e.g., P (Present) flag, and DPL
> (Descriptor Privilege Level)? Do their values not matter either?
> 

Brett,

Yes you only need valid entries for segments that are used. If I'm remembering 
correctly you can use the index in the segment registers to map to the GDT 
entry. 

Thanks,

Andrew Fish

> Thanks,
> Brett S.
> 
> 
> 
> On Tue, Jun 7, 2016 at 8:46 AM, Brett Stahlman  
> wrote:
>> Just inside my 64-bit x64 EFI boot loader, I print out the contents of
>> the GDT to see how it was initialized by the firmware. I've tried
>> running the boot loader both in QEMU (OVMF) and VMware ESXi. In both
>> cases, the first 5 descriptors after the leading null descriptor look
>> like this:
>> 
>> 0x
>> 
>> Note all the leading zeroes: in particular, flags such as D/B and L
>> being clear seem to suggest a GDT that's inappropriate for 64-bit long
>> mode. I've verified by looking at CR* registers and such that the
>> firmware has indeed placed me in IA32e "long mode" with identity
>> paging. This is what I would expect, in light of section 2.3.4 in the
>> UEFI spec. But why does the GDT have all leading 0's?
>> 
>> Thanks,
>> Brett S.
> ___
> 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] Why does UEFI firmware on x64 not initialize "long mode" GDT?

2016-06-07 Thread Brett Stahlman 
Ah. I think I may have found the answer to at least part of my
question, but would appreciate if someone could confirm...

Section 2.3.4 of the UEFI spec states:
"Selectors are set to be flat and are otherwise not used."

Section 3.2.4 of the Intel processor spec (Vol. 3A 3-7) states:
"In 64-bit mode, segmentation is generally (but not completely)
disabled, creating a
flat 64-bit linear-address space... Note that the processor does not
perform segment limit checks at runtime in 64-bit mode."

So if I'm reading all this correctly... The value of the fields
governing the interpretation of the segment limits (e.g., L and D/B)
are "don't cares" in IA32e 64-bit mode. But what about fields not
directly related to limit checks: e.g., P (Present) flag, and DPL
(Descriptor Privilege Level)? Do their values not matter either?

Thanks,
Brett S.



On Tue, Jun 7, 2016 at 8:46 AM, Brett Stahlman  wrote:
> Just inside my 64-bit x64 EFI boot loader, I print out the contents of
> the GDT to see how it was initialized by the firmware. I've tried
> running the boot loader both in QEMU (OVMF) and VMware ESXi. In both
> cases, the first 5 descriptors after the leading null descriptor look
> like this:
>
> 0x
>
> Note all the leading zeroes: in particular, flags such as D/B and L
> being clear seem to suggest a GDT that's inappropriate for 64-bit long
> mode. I've verified by looking at CR* registers and such that the
> firmware has indeed placed me in IA32e "long mode" with identity
> paging. This is what I would expect, in light of section 2.3.4 in the
> UEFI spec. But why does the GDT have all leading 0's?
>
> Thanks,
> Brett S.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Why does UEFI firmware on x64 not initialize "long mode" GDT?

2016-06-07 Thread Brett Stahlman 
Just inside my 64-bit x64 EFI boot loader, I print out the contents of
the GDT to see how it was initialized by the firmware. I've tried
running the boot loader both in QEMU (OVMF) and VMware ESXi. In both
cases, the first 5 descriptors after the leading null descriptor look
like this:

0x

Note all the leading zeroes: in particular, flags such as D/B and L
being clear seem to suggest a GDT that's inappropriate for 64-bit long
mode. I've verified by looking at CR* registers and such that the
firmware has indeed placed me in IA32e "long mode" with identity
paging. This is what I would expect, in light of section 2.3.4 in the
UEFI spec. But why does the GDT have all leading 0's?

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

Re: [edk2] [Patch 0/3] NetworkPkg: Support TCP Cancel function and move timeout handling to HttpBootDxe

2016-06-07 Thread Hegde, Nagaraj P 
For the series:

Reviewed-by: Hegde Nagaraj P 
Tested-by: Hegde Nagaraj P 

Regards,
Nagaraj.

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com] 
Sent: Tuesday, May 31, 2016 7:47 PM
To: edk2-devel@lists.01.org
Cc: Ye Ting ; Fu Siyuan ; Zhang Lubo 
; Hegde, Nagaraj P ; Gary Lin 

Subject: [Patch 0/3] NetworkPkg: Support TCP Cancel function and move timeout 
handling to HttpBootDxe

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Cc: Hegde Nagaraj P 
Cc: Gary Lin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 

Jiaxin Wu (3):
  NetworkPkg: Support TCP Cancel function
  NetworkPkg: HttpDxe response/cancel issue fix
  NetworkPkg: Handling timeout case in httpboot driver

 NetworkPkg/HttpBootDxe/HttpBootClient.c  |   10 +-
 NetworkPkg/HttpBootDxe/HttpBootClient.h  |1 +
 NetworkPkg/HttpBootDxe/HttpBootSupport.c | 2346 ++-
 NetworkPkg/HttpBootDxe/HttpBootSupport.h |2 +
 NetworkPkg/HttpDxe/HttpImpl.c| 2918 ---
 NetworkPkg/HttpDxe/HttpProto.c   | 3770 +++---
 NetworkPkg/HttpDxe/HttpProto.h   |4 +-
 NetworkPkg/TcpDxe/SockImpl.c | 2525 ++--
 NetworkPkg/TcpDxe/SockImpl.h |  223 +-
 NetworkPkg/TcpDxe/SockInterface.c| 2080 +
 NetworkPkg/TcpDxe/Socket.h   | 1866 +++
 NetworkPkg/TcpDxe/TcpMain.c  | 2183 -
 NetworkPkg/TcpDxe/TcpMain.h  | 1549 ++--
 13 files changed, 9872 insertions(+), 9605 deletions(-)

-- 
1.9.5.msysgit.1

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